People looking for somewhere to eat tend to look for the same three things, in this order: is it open tonight, what is on the menu, and can I still get a table. Everything else on a restaurant website — the history of the house, the terrace photo in evening light, the award from three years ago — gets read only once those three questions are answered. And yet many sites hide exactly those answers: the menu as a PDF attachment that opens at postage-stamp size on a phone, the opening hours as an image, the reservation as a bare email address with no hint of which details are actually needed. This article describes how to build the menu, allergen labelling, special hours and a reservation request so that guests can take them in within thirty seconds on a phone — and so that the business can change them in minutes instead of re-typesetting a file.
Three questions decide on the visit
Food service in Germany is a small-business sector, and it is under pressure. The restaurant and pub trade counts 153,545 (DEHOGA Bundesverband) companies, joined by 40,158 (DEHOGA Bundesverband) accommodation businesses and 12,402 (DEHOGA Bundesverband) caterers and other food service providers — 206,105 (DEHOGA Bundesverband) hospitality businesses in total. Revenue is strained: in May 2026 the hospitality sector turned over 2.0 percent (Federal Statistical Office) less in real terms than in the previous month, restaurant revenue was 7.1 percent (Federal Statistical Office) below the same month a year earlier in real terms while rising 0.7 percent (Federal Statistical Office) in nominal terms, and accommodation revenue fell 2.8 percent (Federal Statistical Office) in real terms year on year. Where guests come less often and pay more, every avoidable hurdle before the visit counts.
Those hurdles rarely appear at the table. They appear beforehand, on the way there. Mobile devices are the most used way onto the internet in the EU at 88 percent (Eurostat), and in Germany 97 percent (Federal Statistical Office) of people aged 16 to 74 use the internet at all. That describes the typical situation: one hand on the phone, little time, often a weak connection, frequently on the move. Anyone who has to download a file first and then push it around to read the price of a starter will pick the place next door whose menu simply sits there. How a business gets into local search results in the first place is covered in the article on local visibility for trades and hospitality; this one is about what happens afterwards — the content of the page and how easy it is to maintain.
Is it open?
The hours sit on the page as text rather than inside an image, and they hold up on public holidays too. A weekly closing day belongs there as clearly as the opening time, otherwise the guest ends up at a locked door.
What is on the menu?
Dishes, short descriptions, prices and labelling, readable without a download. Anyone who has to work around an intolerance needs that information before setting off, not once seated at the table.
Can I get a table?
A way to request a reservation that asks for the details a confirmation actually depends on: date, time window, party size, anything special. Without those four points every request starts with a follow-up question.
The thirty-second test
Why the PDF menu fails on a phone
In most businesses the PDF menu is a by-product: it was created for print, typeset for the table stands and then put on the website as well. That means it inherits every property of a printed item. A PDF has a fixed page width, usually A4. On a screen six or seven centimetres wide that leaves two options: the text shrinks to a third of its size, or the guest pushes the page left and right line by line. No reflow happens, because the format does not provide for it.
The requirements for readable content, by contrast, are stated plainly. Text has to be resizable up to 200 percent (W3C, WCAG 2.2, success criterion 1.4.4) without assistive technology and without loss of content or function. Content should be presentable at a width of 320 CSS pixels (W3C, WCAG 2.2, success criterion 1.4.10) without requiring additional horizontal scrolling. Pointer targets should measure at least 24 by 24 CSS pixels (W3C, WCAG 2.2, success criterion 2.5.8). A file typeset for A4 tends not to meet those points inside a phone browser, and the built-in document viewer changes little about it, because it is not allowed to recalculate the layout.
| Criterion | Menu as a PDF | Menu as a page |
|---|---|---|
| Reading on a phone | Fixed page width, pinch and pan | Text reflows, the font size follows the system setting |
| Changing a price | Re-typeset the file, export, upload, replace the old version | Change a field, save, done |
| Finding a single dish | The content sits in a file next to the page | Dishes are text on the page and findable via the browser's own search |
| Reading aloud and zooming | Depends on how the file was produced | Headings, lists and labels are present |
| Linking | Only the file as a whole | Individual sections via anchors, for example straight to the lunch menu |
| Labelling | Footnotes at the bottom of the page, often in very small type | Codes at the dish, legend expandable in the same place |
The PDF can stay — as an extra
Building the menu as a maintained page
A menu built as a page consists of a few recurring building blocks: categories, dishes, and per dish a name, a short description, a price and the labelling. That structure is the real gain, because it makes the menu editable without anyone having to touch a layout. Adjusting the price of a dish means changing a field. Removing a dish means deleting an entry. The styling stays put, because it does not live inside the content. For a sense of scale: home pages serve a median of 364 words (HTTP Archive Web Almanac) on mobile — a menu with thirty items is therefore a small website in its own right and deserves a structure of its own.
- Define and limit the categories: starters, mains, sides, desserts, drinks. Five to seven sections stay manageable on a phone.
- Within each category, list dishes in the order they are actually ordered in, not alphabetically and not by kitchen logic.
- For every dish capture name, a one-sentence description, the total price and the labelling codes — in the same four fields, for every entry.
- Carry the codes directly at the dish and put the legend on the same page as an expandable section, not on a sub-page.
- Treat notes such as vegetarian, vegan or spicy as their own attribute, so a filter can be built from them later.
- Read the finished menu out loud, or have it read out: whatever trips you up when spoken will trip up readers on a phone.
The description is the part that produces the most text and the least effect. „Tenderly braised beef from local pastures, lovingly accompanied by homemade dumplings“ says less than „Beef roulade with red cabbage and potato dumplings, braised in red wine“. The second sentence names what is on the plate; the first one rates it. Guests decide based on ingredients, sides and preparation, not on adjectives. Which wording carries weight and which only takes up space is covered in detail in the article on writing website copy people actually read.
- Name ingredients and sides instead of replacing them with adjectives.
- Use origin claims only where they can be evidenced and are upheld in the kitchen.
- One sentence per dish is enough; two lines on a phone is the upper limit.
- State quantity or weight where it sets expectations, for example with steaks or portion sizes.
- Name the preparation where it makes the difference: braised, grilled, deep-fried, smoked.
- Drop value judgements such as „unique“ or „incomparable“ — they appear on every second menu.
Photos on the menu are a balancing act. One good photo per category helps; one photo per dish creates expectations the kitchen has to meet on a busy Saturday. Where photos are used, they belong on the page in suitable formats and with alternative text so they load quickly and can be read out; the details are in the article on image formats and alternative text. One level up sits the question of whether the menu gets a page of its own or stays part of the home page — worth a look at the overview of which pages a business website really needs. From roughly twenty items onwards, a dedicated page is the sturdier choice.
Declaring allergens and additives correctly
The legal basis is European. The Food Information Regulation requires every ingredient listed in Annex II that causes allergies or intolerances to be declared (Article 9(1)(c), Regulation (EU) No 1169/2011). Annex II names 14 (Regulation (EU) No 1169/2011) groups of substances. The selection is not arbitrary: according to the German consumer advice organisation Verbraucherzentrale it covers around 90 percent (Verbraucherzentrale) of all food allergies. The duty to inform applies to food sold loose as well — that is, to practically everything served at the table or over the counter in a restaurant; member states only regulate the form (Article 44, Regulation (EU) No 1169/2011). In prepacked food these ingredients also have to be emphasised within the ingredients list, for example by font, style or background colour (Article 21, Regulation (EU) No 1169/2011).
- Cereals containing gluten, named specifically: wheat, rye, barley, oats, spelt or kamut
- Crustaceans and products thereof
- Eggs and products thereof
- Fish and products thereof
- Peanuts and products thereof
- Soybeans and products thereof
- Milk and products thereof, including lactose
- Tree nuts, named specifically: almond, hazelnut, walnut, cashew, pecan, brazil nut, pistachio or macadamia
- Celery and products thereof
- Mustard and products thereof
- Sesame seeds and products thereof
- Sulphur dioxide and sulphites at more than 10 milligrams per kilogram or per litre
- Lupin and products thereof
- Molluscs and products thereof
How that information reaches the guest is governed in Germany by the national implementing regulation for food information, the LMIDV. The details have to be provided clearly visible, legible and easy to read: on a sign next to the food, on the food or drinks menu, in the price list, on a notice, or in other written or electronic information that is easily accessible (Section 4(3) LMIDV). Verbal information from staff is permitted, but not informally: a written or electronic record of the ingredients used has to exist, it has to be accessible to the supervisory authorities and, on request, to guests, and this option has to be clearly signposted (Section 4(4) LMIDV).
Electronic information is explicitly foreseen
Beyond allergens, certain additives and treatments have to be indicated. On menus this is traditionally done with numbers and a legend, for example with colouring, with preservative, with antioxidant, with flavour enhancer, sulphured, blackened, waxed, with phosphate, with sweeteners, contains a source of phenylalanine, contains caffeine or contains quinine. Two systems side by side — letters for allergens, numbers for additives — are common and work, as long as the legend sits in the same place as the menu rather than on another page. Which declarations your business needs in detail is a matter for the responsible food safety authority; on the website, the question is reliable presentation.
Codes at the dish
Every dish carries its codes directly after the name or the price. The eye does not have to travel, and when the page is printed the mapping survives.
An expandable legend
The key to the codes sits at the end of each category or as an expandable section. On a phone that saves space without hiding the information.
Attributes you can filter
Vegetarian, vegan, gluten-free and lactose-free as attributes in their own right rather than as a clause in running text. A filter can be built from that later without rewriting the menu.
Prices, surcharges and the list by the door
Prices in hospitality follow a rule of their own, and it is older than any website. Anyone offering food or drink in restaurants and similar businesses has to state the prices in a price list (Section 13 of the German Price Indication Ordinance, PAngV). At the time of the offer the list has to be displayed legibly, laid out on the tables, or presented to every guest before the order is taken and, on request, when settling the bill. In addition, a price list showing the prices of the main food and drinks on offer has to be displayed next to the entrance (Section 13 PAngV).
The prices shown in those lists have to include the service charge and all other surcharges (Section 13 PAngV). For the website that means one thing above all: the price on the page is the price the guest pays. Surcharges for terrace service, holiday supplements or a „small service contribution“ belong in the price or clearly visible next to it, not in a footnote. And whoever shows prices online should maintain them there: an outdated figure on the web weighs more heavily than none at all, because it creates an expectation that is disappointed at the table later. How much price information helps a business, and in which form, is sorted out in the article on showing prices on your website.
- All prices on the website are total prices including service charge and surcharges.
- The list by the door, the menu at the table and the menu on the website state the same figures.
- Surcharges for extras sit directly at the dish, not only in a collected line at the end.
- Drinks carry their volume, so the price can be put into perspective.
- Where a price varies daily, for example with fish, the note sits exactly where the price would be.
- After every price change the website is brought in line the same day.
A price that is identical by the door, at the table and on the web costs around ten minutes of upkeep a month. A price that is not costs a conversation when the bill arrives — and sometimes the guest.
Daily specials and changing menus
The lunch menu is the acid test for menu upkeep. It changes daily or weekly, it is decided at short notice, and it is exactly the content guests search for most often. Where it is maintained as a PDF, the familiar chain appears: open the file, replace the text, export, upload, delete the old file, hope the browser does not serve the old version. That chain has five places to fail, so on busy days it gets skipped — with the result that on Thursday the page still shows Monday.
| Model | Works when | Upkeep effort |
|---|---|---|
| Fixed menu | The offering stays stable for months | Two to four times a year, mostly for price adjustments |
| Daily menu | The lunch offering changes every day | A few minutes the evening before or in the morning |
| Weekly menu | The plan is set on Friday for the following week | Once a week, plannable and easy to delegate |
| Seasonal menu | The kitchen works in quarterly cycles | Four larger passes a year |
| Extra menu for occasions | Christmas menu, Easter, local festivals | Set up once, then updated annually |
A field, not a document
Public holidays, closing days and vacation
Regular opening hours are the easy part. The exceptions are the hard part, because they come up rarely and therefore barely turn into routine: the weekly closing day, holiday arrangements, annual closures, last orders in the kitchen, hot food until, reservations only until. How much current details count is shown by a survey on local retail: 73 percent (Bitkom) would like online access to up-to-date information about what is currently available locally, and 40 percent (Bitkom) would shop locally more often if the opening hours allowed it. Applied to hospitality that means the time information is not a detail, it is part of the offer.
- Once in January, transfer every public holiday in your federal state into the calendar and decide per holiday: open, closed or special hours.
- Set a reminder ten days ahead for each of those dates, so the announcement has lead time.
- State annual closures with a start, an end and the first day back — the last point is the one most often missing.
- State kitchen closing time and last orders separately from the opening hours, otherwise guests arrive too late.
- Name the weekly closing day as plainly as the opening hours, rather than leaving a gap in a table.
- After each change, do a round of every place where hours appear: website, business profile, notice on the door, phone message.
The wording matters as much as the timing. „We are closed for our annual holidays“ leaves the one question that counts unanswered: from when again. „Closed from 22 July to 5 August, back to normal from Wednesday 6 August, opening at 5 pm“ answers it in full — and saves the phone calls. How to maintain hours centrally and keep them in sync across several channels is described in the article on keeping opening hours and availability current.
The rule for a closing day
What a reservation request really needs
A reservation request is not a contact form with a different heading. It has a clearly bounded purpose: to hand the business exactly the details it needs to confirm or decline without a follow-up. If one of them is missing, a second round begins — and every second round costs time on both sides and lowers the likelihood that the reservation happens at all. Four details carry most cases; two more decide the quality of the evening.
Date and time window
Not just „7 pm“ but a window: „from 6:30, 7:30 at the latest“. That gives table planning room to move and prevents declines that come down to half an hour.
Party size
Capture adults and children separately, because the choice of table depends on it. Above a group size you set yourself, the form can point to the phone instead.
High chair and children's menu
A checkbox is enough. Families plan the evening around it, and the business knows in advance whether a high chair belongs at the table and whether a smaller portion is needed.
Step-free access
A field for the need: step-free entry, room for a wheelchair at the table, an accessible toilet on the ground floor. Honest details count for more than flattering ones — if there is a step, write it down.
Occasion and notes
Birthday, business dinner, intolerances within the group. A free field with an explanatory label often delivers the piece of information that decides the evening.
Contact and reply
A name, one way to get in touch and a note about when to expect an answer. Without that note, every request stays an open end for the guest.
What happens after the send button decides whether the request turns into a table. A confirmation page that repeats the details, a reply within a realistic window and a prepared wording for fully booked evenings are quick to set up and take effect immediately. On the legal side, a request needs a note about how the data is processed, a retention period and restraint in the fields: whatever is not needed for the confirmation is not asked. The mechanics are described in the article on contact forms that turn visits into enquiries; the mandatory disclosures around privacy and imprint are covered in the article on legal pages for a business website.
- The form asks for date, time window, party size and contact — there are no further mandatory fields.
- High chair, accessibility and notes are optional fields with clear labels.
- A confirmation page repeats the details and states the response time.
- For large groups a note points to the telephone route.
- Requests land in a mailbox someone reads during the annual closure too.
- Declines get answered rather than ignored — with an alternative date where possible.
The upkeep routine: who changes what, and when
Everything described so far works only if it is clear who does it. In small businesses, website upkeep rarely fails on the technology and mostly on responsibility: the menu belongs to the kitchen, the prices to bookkeeping, the hours to the service team, the website to nobody. A short allocation solves that, and it fits on one page.
| Occasion | What changes | Who and how long |
|---|---|---|
| New daily special | One text field with dish and price | Kitchen or service, around two minutes |
| Price adjustment | Prices in the menu, the notice and the table card | Management, around thirty minutes |
| New dish on the menu | Entry with description and labelling | Kitchen, with a look at the recipe, around ten minutes |
| Public holiday or new closing day | Hours on the website and the business profile | Service team, around five minutes per channel |
| Annual closure | Announcement, period and first day back | Management, ten days in advance |
| Annual review | Menu, labelling, photos, copy, form fields | Once in January, one to two hours |
The allocation weighs more than the tool
Menu, labelling and requests in XICflow
XICflow is an AI website builder: a briefing produces a complete website with structure, copy and images, which is then edited in the Flow Builder. For hospitality businesses that mainly means the menu is not an attachment but a block with fields — and that changing it takes about as long as the typing.
Menu as a block
Categories, dishes, description, price and labelling as fields. New dishes get inserted, removed ones deleted, the layout stays untouched and the printout stays readable.
Hours and special hours
Opening hours, closing days, kitchen closing time and annual closures in one place, with matching machine-readable details for the presentation in search results.
Reservation request
A form with date, time window and party size plus optional fields for a high chair, access and notes, including a confirmation page and a stated response time.
Getting started needs little preparation: put your printed menu next to your phone, open your own website and compare line by line. Wherever the figures differ, you have found the first task. For an impression of what finished sites look like, see the demo websites; the path from briefing to published page is described on how it works, the feature overview sits under features and flow blocks and the plans on the pricing overview.
What counts in the end
Sources and studies