Your QR Code Points to a PDF. That's the Problem.

A guest sits down, scans the little card on the table, waits for a 4 MB file to download, and then spends the next thirty seconds pinching and dragging around a page designed for A4 paper. They find the starters. They lose the starters. They give up and ask the server what the fish is.

This happens in thousands of restaurants every night, and it is entirely avoidable. The QR code is not the problem. What sits behind it is.

A PDF was designed to be printed, not read on a phone

That is literally the format's job, and it does it well. A PDF locks a layout to fixed dimensions so it comes out of a printer looking the way the designer intended. Every one of those properties works against you on a 6-inch screen.

Text does not reflow, so the guest zooms. Once they zoom, they lose their place, because the visible area is now smaller than a business card. Tap targets do not exist. Two-column layouts, the standard for printed menus, are the worst offenders: the guest reads halfway down the left column, scrolls, and has no idea whether they are still in Mains or have wandered into Desserts.

Then there is the download itself. A designer's export with embedded fonts and a photo of your dining room can easily hit 5 MB. On patchy in-restaurant signal, that is a wait, and the guest is sitting there watching a spinner while their table companion has already picked a wine.

Accessibility is the part nobody mentions. Screen readers handle well-tagged PDFs adequately and untagged ones terribly, and almost every restaurant menu exported from InDesign or Canva is untagged. A guest with low vision cannot increase the text size, because the text size is baked into the file.

Google mostly cannot read it, and definitely cannot rank it

Search engines can index PDFs. That is technically true and practically useless for a menu.

What actually happens: the PDF gets treated as one flat document with no headings, no structured markup, and often no meaningful title beyond "menu-final-v3-PRINT.pdf". Google cannot tell that "Grilled sea bass, fennel, salsa verde, 24" is a dish with a price. It cannot pull individual items into search results. It cannot associate the menu with your opening hours, your location, or your booking link, because none of that context lives in the file.

Meanwhile the searches you want to win are all item-level and intent-heavy. "Gluten free pizza near me." "Vegan brunch Ljubljana." "Restaurants with a tasting menu in Graz." Those queries get matched against page text, headings, and structured data. A PDF supplies none of that in a form Google can work with.

There is also the schema problem. Google supports a Menu structured-data type that lets you describe sections, items, prices, and dietary information in machine-readable form. You cannot attach that to a PDF. On an HTML page, it is a block of JSON in the head, and it is the difference between "we have a website" and "search engines know what we serve."

AI assistants have made this worse, or better, depending on which side you are on. When someone asks a chatbot for a restaurant nearby that does a proper Sunday roast, the model is working from crawlable text. Restaurants whose menus are readable get mentioned. Restaurants whose menus are locked in a PDF do not exist to it.

You cannot change it at 19:40 on a Friday

The kitchen runs out of the lamb. It is Friday, the room is full, and the menu says lamb.

With a PDF, fixing that means opening the design file, editing it, exporting, uploading it somewhere, and hoping the QR code still points at the right place. Nobody does this mid-service. What actually happens is the server tells forty tables in a row that the lamb is off, some guests get annoyed, and the menu stays wrong until someone gets around to it next Tuesday.

The same friction kills anything time-sensitive. Lunch specials that should appear at 11:30 and vanish at 15:00. A seasonal dish you want to push for two weeks. A price change on a supplier item that just jumped 30%. Every one of those becomes a small design job instead of a thirty-second edit, so most of them never happen, and your menu slowly drifts away from what your kitchen actually serves.

An HTML menu is a database with a nice front end. Mark the lamb unavailable, and it greys out or disappears on every phone in the room instantly. No re-export, no re-print, no new QR code.

What you get instead

Here is the practical difference, once the menu is a real web page.

1. It reads properly on a phone. Text reflows to the screen, sections collapse and expand, and the guest can jump straight to Desserts without scrolling past everything else. That is the whole point of the exercise.
2. Google sees dishes, not a document. Every item is text on a page, wrapped in headings, with schema markup describing prices and sections. Item-level searches can find you.
3. Allergens live next to the dish. In the EU, the fourteen major allergens have to be declared, and a footnote on page four of a PDF is a poor way to do it. On a web page, allergens can sit on the item itself, and guests can filter to what they can safely eat. Verify the exact declaration requirements with your local food authority, since enforcement details vary by country.
4. Changes happen in seconds. Sold out, price change, new special, seasonal swap. One edit, live everywhere.

There is a fifth thing that is harder to see: you learn what people look at. A web menu can tell you which dishes get viewed, which sections people abandon, and how long the average guest spends deciding. A PDF tells you nothing, ever.

The awkward middle ground

Plenty of restaurants have a website with a "Menu" page that contains a single embedded PDF viewer, or worse, a photograph of the printed menu. Both are the same problem in a nicer wrapper. If the words are inside an image or a file, they are not on your page, and everything above still applies.

The fix is not complicated and does not require rebuilding your site. Put the actual dish names, descriptions, and prices in the page as text. Keep the PDF around as a download for whoever wants to print it. The web version is the one that works, and it is the one that ranks.

The short version

A PDF menu behind a QR code was a reasonable panic response in 2020 and is a liability now. It frustrates the guest in front of you, hides you from the guest searching on their phone two streets away, and freezes your menu at whatever it said the last time someone opened the design file.

Move the menu to a real page. Same QR code, same table cards, much better night for everybody.