Should a restaurant put its menu on the site or link a PDF

Almost every restaurant we speak to already has a menu on its website. It is a PDF, it is the same menu that goes on the table, and the reasonable position is that a menu is a menu. The objection is fair. The trouble is that the document was drawn for a sheet of paper held at arm’s length, and it is being read on a phone held in one hand outside the door.

The arithmetic of a phone screen

A PDF opens at fit to width. An A4 page is five hundred and ninety five points across. A phone gives it about three hundred and ninety, so everything on the page arrives at roughly sixty five percent of the size it was drawn at. Body copy set at ten point lands at under seven pixels. Comfortable reading on a phone starts at about sixteen. The menu is not merely small. It is about two fifths of readable, before you account for the menus that were laid out at A3 or as a double page spread.

That would matter less if the menu were a minor page. Owner, an American restaurant software company, surveyed thirteen hundred diners and found eighty percent go to a restaurant website mainly to look at the menu, and eighty four percent go looking for photographs of the dishes. It is not a minor page. It is the page.

What actually breaks

• The visitor leaves your site. A PDF opens in a viewer or downloads, and the route back to the booking button becomes a browser control rather than a design decision
• Nobody can see what was read. A page tells you which sections held attention. A download tells you a file was fetched
• The prices go stale, because changing a PDF means opening the design file, exporting, and uploading, and that is three people on a Tuesday
• You cannot mark it up. A menu page can carry structured data that states the dishes and the prices in a form search engines read. A PDF carries a filename
• A screen reader copes with a well built page. It copes badly with an exported PDF and not at all with a photograph of a laminated card

None of this is the usual claim that Google cannot see a PDF. It can, it indexes them, and your PDF menu will surface for somebody searching the restaurant by name. Visibility is not the problem. The problem is that the most important thing you serve is sitting in a separate document with no way back into the rest of the site.

What we do instead

Matador on Church Road in Hove arrived with exactly this setup, a PDF menu and a booking widget belonging to somebody else, sitting on a page nobody wanted to look at. The menu became a real page, sectioned and priced, built to be read on a phone in a queue rather than pinched and zoomed. The booking came inside the site too, so the last step feels like the same restaurant as the first.

House Kitchen and Bar above Kalamar Bay in Kalkan had a harder version of the same problem. The menu existed only as a photograph of a laminated card in a TripAdvisor upload. That became a readable page as well, and it now sits one click from the reservation and from the reviews.

The shape is the same either way. Sections a thumb can jump between, prices in plain text, and the booking never more than one tap from wherever somebody stopped reading.

The honest limit

A menu page only beats a PDF if somebody keeps it current. If the menu genuinely lives in a design file, and the person who owns that file is never going to log in to a website, then a current PDF beats a page still listing last winter’s prices. The fix in that case is not a page. It is a way for the kitchen to change a price in under a minute, and where that does not exist the menu will rot in whichever format you choose.

And keep the PDF. Put it behind a small print link for the people who want it on paper. Having both costs nothing. What costs something is making the download the only route to the thing eighty percent of your visitors came for.