Test your first digital menu
A menu is not finished when it looks right on your screen. It is finished when a guest sitting at a table, using their own phone and the restaurant's connection, scans a code and reads it comfortably.
This test rehearses that moment before any code is printed. It proves four separate things: the public menu works while signed out, the QR code points at the right address, the printed file is scannable, and the menu is usable on a phone in the dining room.
Before you start
- One menu type published, with at least one full category of items.
- The QR codes generator tool enabled under Settings → Restaurant settings → Enabled tools.
- A phone that is not signed in to the site.
1. Confirm the destination first
Open a private browser window and visit the public menu you intend to link to. Copy that address.
Decide deliberately what the code should open:
| Destination | Use it for |
|---|---|
| The home page | A single code at the entrance, when guests should choose between several menus |
| A menu archive | A table code for a restaurant with one main menu |
| A category archive | A specific code, for example a wine list section on the bar counter |
| A custom URL | Anything outside the menus: reservations, an event page, a review link |
Generating a code for a page you have not opened yourself is the most common cause of reprinting.
2. Generate the code
- Open QR generator in the sidebar.
- Tick the destinations you want. Home Page is ticked by default; untick it if you do not need it.
- Menu archives are listed first, category archives after them, with the menu type they belong to shown in brackets.
- To add a destination that is not on the list, paste it into Custom URL. Include
https://. - Select Generate Codes.
The results appear grouped. On a multilingual site there is one group per language, each labelled with the language, so a Spanish code and an English code are never confused with each other.
3. Download the right file
Each result offers two downloads:
- PNG — an image, right for a quick screen preview, a slide, or a social post.
- SVG — a vector file that stays sharp at any size. Use this one for anything a printer will produce: table tents, posters, coasters, menus.
Download the SVG for print and keep the PNG for digital use. Send the SVG to the print shop; do not let anyone enlarge the PNG instead.
4. Scan it before printing
- Open the downloaded file on a computer screen.
- Scan it with a phone that is signed out of the site.
- Confirm the address that opens is exactly the one you copied in step 1 — the right site, the right menu, the right language.
- Confirm the page loads without a login prompt.
If the code opens an unexpected page, do not adjust the printed material. Fix the destination and generate the code again.
5. Read the menu as a guest would
Still on the phone, with the menu open:
- Scroll the whole menu. Every category should be reachable.
- Use the category navigation to jump between sections.
- Check that prices are legible without zooming.
- Open an item and expand its long description.
- If the archive offers the allergen filter, the favorites view or the language switcher, try each one.
- Check the contact dock: every link in it should open something real.
- Confirm no draft or unfinished item is visible.
Then repeat the scan in the dining room itself, on the restaurant's own connection and under its own lighting. A menu that reads well at a desk can be unreadable at a candlelit table.
6. Print a single proof
Print one code at its final size before ordering the full run.
- Keep a clear margin of quiet space around the code; artwork pressed against its edges breaks the scan.
- Do not print the code in a color with poor contrast against its background.
- Do not stretch it out of square.
- Do not laminate a proof before scanning it; glossy finishes can defeat some cameras under direct light.
Scan the printed proof at the distance a seated guest would hold their phone. Only then order the rest.
7. Plan for change
The code encodes an address, not the menu content. That has a practical consequence worth deciding once:
- Changing a dish, a price or a photo does not require reprinting anything.
- Changing the address — renaming a category, restructuring the menus, moving to a new domain — breaks every printed code that pointed at the old address.
So point table codes at stable destinations: the home page or a menu archive rather than a seasonal category. Keep the generated SVG files in a shared folder with the date and the destination in the file name, so a reprint never means guessing which file was used.
If the code does not work
| Symptom | Likely cause |
|---|---|
| No codes are generated | Nothing was selected, or the custom URL was entered without https:// |
| A menu type is missing from the list | Its archive is not published, or the menu type is not enabled |
| The scan opens a login screen | The destination is not public; test it in a private window |
| The scan opens the wrong language | A code from the wrong language group was downloaded |
| The printed code fails but the screen version works | Print size, contrast, margin or finish — reprint the proof before changing anything else |
When the code, the phone and the dining-room test all agree, work through the Restaurant menu launch checklist before the menu goes live for real.