Your menu should not be a PDF

To be clear about the claim: a downloadable PDF alongside a web menu is perfectly reasonable, and some customers genuinely want one to print or send.

The problem is PDF-only — when the download is the only way to see what you serve. That is a decision made for the restaurant’s convenience, and it costs more than it saves.

The customer test

Picture the actual moment. Somebody is standing on a sidewalk, or sitting in a parked car, with one hand free, deciding between you and the place across the street. They tap your menu link.

With a web menu: the page loads and they read it.

With a PDF: the file downloads, opens in a separate viewer, appears at a zoom level designed for a sheet of paper, and they pinch and drag around a document laid out for a table. On a slow connection they wait. Some proportion of them go to the other restaurant instead, and you never find out.

That is the whole argument, and it does not need a statistic attached.

Search engines can use a web page better

Search engines can read PDFs, so this is not a claim that a PDF menu is invisible. It is that a PDF is a worse container for the content.

A web menu has headings, prices as text, and dish names in the page itself — so when somebody searches for a dish plus your town, there is something to match. A PDF is one file with an awkward address, it cannot carry the structure a page can, and it is a dead end for internal linking.

Practically, restaurants lose two kinds of search this way: people looking for a specific dish nearby, and people checking whether you do the thing they want before deciding.

Some customers cannot read it at all

This one is worth taking seriously rather than treating as a technicality.

PDFs are frequently inaccessible to screen readers. A menu scanned from a printed sheet is an image with no text in it at all, which means somebody using a screen reader gets nothing — not a poor experience, nothing. Even properly generated PDFs often lose reading order in multi-column layouts, so prices end up detached from dishes.

Accessibility organizations have covered this in more depth than we can here, and the practical summary is straightforward: an HTML menu is usable by assistive technology by default, and a PDF menu usually is not without deliberate work nobody does.

The one that costs you every week: updating it

Here is the argument that actually changes behavior, because it is about your time.

Changing a price on a web menu: log in, edit the number, save. About a minute, from a phone if necessary.

Changing a price on a PDF menu: find the original design file, open the software it was made in (or find the person who has it), edit, export, upload, and check it replaced the old one. That is if the file still exists — plenty of restaurants have a menu PDF and no editable original, at which point a price change means recreating the whole thing.

The result is predictable and visible on restaurant websites everywhere: the online menu is out of date. Prices are wrong, the seasonal menu ended in March, and the specials page describes autumn. Every one of those is a customer arriving with the wrong expectation, and wrong prices are where arguments at the till come from.

What to do instead

1. Put the menu on the site as a web page. Sections as headings, dishes and prices as text.
2. Make it editable by somebody who works there. This is the whole point — if changing a price needs a developer, you are back where you started.
3. Keep the PDF as a secondary option if you want one. “Download a printable menu” underneath the web version is genuinely useful for catering and large bookings.
4. If you have several menus — lunch, dinner, drinks, seasonal — give each its own page rather than one enormous file.
5. Keep prices on it. A menu without prices sends people away to find out.
6. Check it on a phone, because that is where it will be read.

The listing, and structured data

Two smaller benefits worth mentioning without overclaiming.

Your Google Business Profile has a place for menu information, and pointing it at a web page is more useful than pointing it at a file. Some restaurants find the menu appears more usefully in search as a result.

There is also structured data for menus, which lets search engines understand sections, dishes and prices as data rather than as text. Support for how that gets displayed varies and changes, so it is worth doing where it is easy and not worth promising anything about. The reliable benefit is the plain one: your menu is a page, and pages can be read.

Common questions

Should a restaurant menu be a PDF or a web page?

A web page, with a downloadable PDF alongside it if you want one. PDF-only is the problem: it adds a step for the customer, carries less structure for search, and makes every price change a design job.

Can Google read a PDF menu?

Yes, but less usefully than a web page. A page carries headings, dish names and prices as text that can match a search for a specific dish nearby, and it can be linked to from the rest of the site.

Are PDF menus accessible?

Often not. A scanned menu is an image with no readable text at all, and even generated PDFs frequently lose reading order in multi-column layouts, separating prices from dishes.

How often should I update my online menu?

Whenever it changes — which is the real argument for a web menu. If updating means opening a design file and exporting, it will not happen, and an out-of-date menu is worse than an unglamorous one.

Should I show prices on my online menu?

Yes. A menu without prices sends people elsewhere to find out, and they may not come back. It is also the single most common reason somebody opened the menu in the first place.