How restaurants should publish allergen information online
Hiding allergens behind a PDF or 'ask a member of staff' is not digital UX. It is a liability dressed as hospitality.
We take restaurant information seriously. That is not a consultancy pitch. It is the reason Quiteful exists, and why A Little Bit Nuts talks to diners who cannot treat a maybe as a yes.
The typical restaurant website still treats allergens as a legal footnote. A PDF in the footer. A sentence that says speak to the team. A chart that was accurate in March. For someone with a severe allergy, that is not cautious — it is unusable.
Good publishing is specific. Which of the 14 regulated allergens does this dish contain? Which might it contain? Where does cross-contact sit? When was this last checked? Who is allowed to change it? If the garnish changed at 4pm, did the QR menu change too?
Do not let a language model decide allergen facts. AI can help turn an 80-row spreadsheet into structured dishes. A human who knows the kitchen has to confirm the allergen record before it goes live. That is a product decision, not a vibe.
Put the information where the diner already is: on the dish, on the phone, on the website, with a timestamp. Then give staff a workflow that does not require a developer. Current. Clear. Traceable. Useful to diners. Useful to staff.
Common questions
- Is 'ask a member of staff' enough online?
- It is a useful backup, not a publishing strategy. Diners who rely on allergen information should be able to filter and read it before they arrive — and it should match what the kitchen is actually cooking.
- What does good allergen publishing look like?
- Contains, may-contain and cross-contact logic against the 14 UK/EU allergens, kept with the dish, last-updated, and maintained from one source of truth across website, QR and print.