What a restaurant website needs to include

A good restaurant website answers four questions on a phone, in a few seconds: what's on the menu, when you're open, where you are and how to get a table. The story of the place and the gallery come after that. If someone has to dig for your hours or download a PDF to see the menu, most of the time they close the tab and call the place next door.

Here's the checklist we use when we build a site for a restaurant, with the reason behind each item.

The menu, as real text

The menu is the most visited page on almost any restaurant site. That's why we build it as text on the page, not an image or a PDF.

Text reads well on any phone without pinch-zooming. Search engines understand it, so someone searching for "shrimp pasta" near you has a chance of finding you. A visitor's phone browser can translate it, which it can't do with a photo. And maybe most important, you can change it in two minutes when an ingredient gets more expensive or a dish comes off the menu.

A PDF feels simpler, but it loads slowly on mobile data, translates badly and stays out of date for months because "someone has to redo the file." If you already have QR codes on the tables, they can point straight to the same menu page. That's how our digital menu works: you change dishes and prices, and the code on the table stays the same.

Allergens: what the law says

In the EU, Regulation (EU) No 1169/2011 requires allergen information for food served on the spot, not only for packaged food. Article 44 makes allergen information mandatory for non-prepacked food, and Annex II lists the 14 allergens: cereals containing gluten, crustaceans, eggs, fish, peanuts, soybeans, milk, nuts, celery, mustard, sesame, sulfites, lupin and molluscs.

The same article lets each member state decide how the information reaches the customer: printed on the menu, on a sign, or given by staff. Before you pick one, check with your local food safety authority which format they accept during inspections.

On a website, the simplest approach is to list allergens under each dish, using the same names as Annex II. A guest with a celery allergy doesn't have time to guess what's in the "house soup."

Hours, address, phone: on the first screen

These seem obvious, which is exactly why they go missing. On a phone, put them on the first screen or in a sticky bar at the bottom:

• opening hours, including the days that are different (holidays, off-season, private events);
• the address, with a map that opens in the visitor's navigation app;
• the phone number as a tappable link, so they can call with one tap instead of copying digits;
• a WhatsApp button, if someone actually answers there.

Then make sure the exact same details appear on your Google Business Profile. The profile has fields for hours (including special hours), for phone numbers (up to two more besides the main one), for your website, and a menu editor just for food and drink businesses. When the site says "closed Mondays" and Google says "open," the customer believes whichever they saw last. And they blame you.

Booking, without detours

If you take reservations, the booking button sits next to the menu and in the bottom bar, not at the very end after the gallery. It can be a simple form, a WhatsApp link or a booking system. What matters is that it's one step away and says clearly what happens next: "we'll call you to confirm" or "you'll get a confirmation email."

If you can, take bookings directly on your site, with no platform commission, and keep the WhatsApp button always in view on mobile. That way guests book with you, not through a middleman.

Real photos, few and good

Stock photos of some random plate hurt you: people show up, get something else and feel misled. Shoot your own dishes, in your own light, on your own plates. Ten to twenty good photos are plenty: a few signature dishes, the dining room, the terrace, maybe the kitchen. Compress them before uploading, or the site loads slowly on exactly the phone that's standing outside your door.

What Google reads

Besides the visible text, your site can tell search engines, in a standard format, what kind of place it is. The vocabulary is called schema.org, and it has a Restaurant type, which is a kind of FoodEstablishment. The useful properties are hasMenu (the menu or a link to it), servesCuisine, acceptsReservations (yes or no, or a booking link) and openingHours.

Google's local business documentation requires a name and address, and recommends phone, hours, menu, cuisine and coordinates. It also tells you to use the most specific type, so Restaurant rather than plain LocalBusiness. Structured data doesn't guarantee anything in search results, but it tells Google clearly what you are, with the same details shown on the page.

Speed on a phone

Most people look at your site on a phone, often on mobile data, sometimes before they even leave home. Google measures three things it calls Core Web Vitals. For a good score, the largest element on the page (usually the top photo) shows up within 2.5 seconds, the page responds to a tap within 200 milliseconds, and the layout doesn't jump around (a CLS score of 0.1 or less). These targets are judged at 75% of visits, separately for mobile and desktop.

In practice: compressed photos, a single video only if it really says something, and no pop-up covering the menu on arrival.

Checklist

If you'd like to go through what's missing from your current site, our services page shows what we do for restaurants.