Start with a menu people can read on the page.
The homepage menu button should lead directly to the current dishes. Text on a web page can adapt to a narrow screen and be selected. A photographed menu, however, needs text large enough to read within the image.
A PDF can be offered for downloading or printing. If it is the only way to read the menu, check that it works on a phone and matches the version used elsewhere by the restaurant. Do not send guests to an old document simply because the link still works.
Menu checklist: information to gather before the build.
Prepare a simple brief with one row per dish or drink. The kitchen and the person responsible for pricing should check it before publication. Clear headings help guests find the relevant part of the menu.
- Categories: use your actual sections, such as lunch, dinner, children’s menu and non-alcoholic drinks. Do not create empty categories for things you do not offer.
- Name and description: explain what the dish is and enough about its ingredients to help guests choose. Avoid internal kitchen abbreviations.
- Price and portion: show what the price covers, such as a dish, portion, glass or bottle. Explain extras where needed.
- Hours and availability: state which days or times the menu applies when that affects ordering. Keep temporary offers clearly separate.
- Languages: if you use several languages, update the same dish and price in every version. Do not translate only the categories.
- Contact: decide how guests can ask about ingredients and particular needs before visiting or ordering.
Run a short mobile check with a real task.
Ask someone to find a dish, its price and directions to the restaurant on their phone. Watch what they actually do. If they need to pinch to zoom, guess a symbol’s meaning or return to the homepage repeatedly, you have a specific improvement to make.
Use a calm reading layout with clear differences between names, descriptions and prices. A long menu can have category links. Collapsible sections need understandable headings and a clear opening action; important information should not disappear when a category is closed.
- Read on a narrow screen without moving the menu sideways.
- Check readability, touch targets and any need to zoom.
- Open a category, PDF and contact option; check the way back too.
- Try a mobile connection and see whether anything prevents the menu appearing.
Make the route to allergen information clear.
Swedish Food Agency guidance says that information about allergens covered by the rules can be given in different ways, including verbally. If guests need to ask, it must be clear that the information is available. This is not a general requirement to list every dish’s allergens on the website menu.
Clearly invite guests to ask staff, and decide how staff receive up-to-date information from the kitchen. If you publish allergen information for each dish, it needs to follow changes in recipes and ingredients. Do not add symbols such as gluten-free based on assumptions.
A short dish description is not automatically complete allergen information. Make sure questions can be answered using current information about food and handling. A published symbol or statement should not be presented as a guarantee that the food suits every guest with an allergy.
Name someone responsible for the next menu change.
Agree who supplies changes, who approves the content and who publishes it. Keep the current menu in one place as the source. With every change, check the PDF, any translations and your own channels where the menu appears.
Make the routine work during absences too: who covers, how urgent changes are sent and who checks the finished page. Set a checkpoint before a new menu period. A beautiful but incorrect menu still creates questions during service.
A public example: TIME Bar’s menu.
TIME Bar’s public menu page links to categories such as food, cocktails and non-alcoholic drinks. Names, descriptions and prices appear as page text, and guests are invited to ask staff about allergens. A PDF is available as an additional download.
Nolera’s TIME case study describes separate entry points for the programme, menu and visiting information. Use the approach as an example of structure and content. Adapt the categories to your own restaurant; a short lunch menu does not need all the bar’s sections.
Make the next step fit how guests actually visit you.
After reading the menu, guests may need the address, a phone number or a booking option. Show the route you actually use. If booking is handled by an external provider, the link should lead to the right restaurant and work on mobile. If you accept walk-ins, explain that rather than creating a booking button.
Agree the scope before ordering. Nolera’s basic package at €29/month excluding VAT covers 1–5 information pages as agreed. Booking systems, ordering features, integrations and ongoing menu updates need separate scoping and pricing.
Frequently asked questions
Can we still offer our menu as a PDF?
Yes. Make a readable menu on the page the main option and the PDF an addition. Check that both show current information.
Does the menu need a booking system?
That depends on how you work. A link to an existing system, a phone option and a technical integration are different orders.
Who changes the menu after launch?
This needs to be agreed. Name the responsible person and define how changes are submitted, approved, ordered and charged.