Restaurant Websites and QR Menus That Work

The QR menu problem is a PDF problem

Almost every complaint about QR menus is really a complaint about one implementation of them. Somebody exported the printed menu as a PDF, uploaded it, generated a code, and stuck it on the table.

What the guest gets is a document sized for A4 opened on a screen the size of a hand. They pinch, they zoom, they lose their place, they scroll sideways, and the file is four megabytes on restaurant wifi that is already carrying eleven other tables. Then somebody at the table gives up and asks for a paper menu, and the restaurant concludes that guests do not like QR menus.

Guests do not dislike QR menus. They dislike PDFs. The fix is that the code should open a real mobile web page: text that reflows, images that load at the size they are displayed, sections you can jump to, and a page the person at the counter can edit without exporting anything.

That distinction is the entire reason we built the platform side of MenuFly rather than treating the digital menu as a file to host.

What a guest actually does with their phone at the table

Worth being specific, because it is different from what a restaurant expects.

They are not reading the menu end to end. They are looking for one of three things: whether there is something for the person at the table with a dietary restriction, what a dish they have not heard of actually is, and roughly what this is going to cost. Then they put the phone down.

That tells you what the digital menu has to be good at:

• Jumping to a section fast. Starters, mains, breads, desserts. If they have to scroll past forty items to reach the thing they wanted, the phone goes back in the pocket.
• Saying what a dish is. One line of description does more work than a photograph on anything unfamiliar.
• Marking the obvious categories. Vegetarian, contains nuts, spice level. This is the single most useful thing on a menu for the person who needs it and invisible to everybody else.
• Loading on bad wifi. Every megabyte you add is paid for by a guest on a congested network in a building with thick walls.

Photographs are where this last point goes wrong. A phone camera produces a four megabyte image and a menu with twenty of them is a menu nobody sees. Resize to the box they display in and compress to a budget. The image compressor will do it without uploading anything anywhere.

The printed menu is still doing the selling

There is a tendency to treat the physical menu as a legacy cost now that the digital one exists. That is backwards, because they are doing different jobs.

The printed menu is the only piece of marketing you hand directly to somebody who has already decided to spend money. Where a dish sits on the page, whether it carries a photograph, and how the price is set beside it change what a table orders. A menu designed around the dishes the kitchen actually makes money on is worth considerably more than the print run costs.

The digital menu is a reference. It gets consulted, not read. It is where somebody checks an ingredient or looks at the menu before they leave home.

Designing both as though they were the same document produces a printed menu that reads like a database export, and a digital menu that is a photograph of a card. They should carry the same dishes and the same prices, and they should be laid out for completely different moments.

What a restaurant website is actually for

Most restaurant websites are built as though the visitor has already chosen the restaurant. Large photograph, the word Welcome, a paragraph about passion, and the menu somewhere in the navigation.

Almost every visitor is in one of four situations, and the site should answer all four above the fold:

1. Are you open, and where exactly are you? Hours and a map, on the page, not in an image.
2. What do you serve and what does it cost? The menu, one click away at most, as a page rather than a download.
3. Can I book, and how? A phone number that dials on a tap, or a booking link. Not a contact form.
4. Do you deliver, and through which app? One line, with the links.

Everything else is decoration on top of those four. The restaurants that get this right tend to look less impressive and convert considerably better.

The same page is also what gets pasted into a group chat when somebody suggests dinner, so check what that link looks like in WhatsApp before you print a single code. A missing image or a generic title there is a tag problem, and why link previews look wrong covers how to fix it.

WhatsApp is worth a second code of its own, next to the menu one. A click to chat link opens a chat on the restaurant number with a booking line already in the box, which is a far shorter path to a table than a form, and the rules for building one are fussier than they look. The WhatsApp link for business guide sets out the number format, the characters that silently truncate a pre-filled message, and the print sizing that keeps the code scannable on a table card.

Photographs are most of the job

Food photography is the one place where spending is almost always justified, and where the common mistakes are consistent:

• Shoot the dishes you want to sell, not the ones that photograph best. These are not the same list.
• Shoot them as the kitchen actually plates them. A photograph the kitchen cannot reproduce creates a disappointed table, which is worse than no photograph.
• Do not photograph everything. A menu where every item has a picture flattens the hierarchy. A handful of images marks out what you want ordered.
• Check the text on top of them. White text over a photograph is the most common accessibility failure on restaurant sites, and it becomes unreadable in daylight on a phone at a table outside. The contrast checker settles it in a few seconds.

Keeping the two menus in agreement

The operational failure that undoes all of this is price drift. The card on the table says one number, the page on the phone says another, and the guest noticed before the server did.

That is why the digital menu has to be editable by the person at the counter. If changing a price means emailing an agency, the digital menu is out of date within a month and the restaurant stops trusting it. It is also the argument for the printed card carrying the code rather than the whole story: the printed menu establishes what the place is, the code is how it stays current, and you do not reprint a table's worth of standees because one supplier raised a price.

If you are generating codes yourself, the QR code generator is free and runs in your browser. Print it large enough to scan from a seated distance, keep a decent quiet margin around it, and test it on a cheap phone in low light rather than on a new one in daylight.

What to fix first

If the menu is a PDF, that is the whole project. Nothing else on the site matters as much as replacing it with a real page, and it is the change guests notice immediately.

After that: put the hours, the location and the phone number where they can be seen without scrolling, compress every photograph on the site, and make sure somebody in the restaurant can change a price without asking anyone.

When you want the platform rather than the patch, that is SaaS product development, and the website around it is web application development. MenuFly is the reference build for both, including the design and printing side, and it is rated 4.63 out of 5 from 133 Google reviews.