Restaurant website checklist for 2026

A guest opens your restaurant website on their phone. They want today's menu, the right branch and a table reservation. An impressive opening image offers little help if the menu is out of date or the booking link goes nowhere.

This checklist is for restaurants operating in Germany. It follows practical tasks on your own website. Your Google Business Profile is one possible starting point; managing it belongs in a separate guide. The ten checks and their priorities are OzyCore recommendations, not an official certification.

1. Define guest tasks
2. Open the mobile website
3. Find the current menu
4. Follow reservations and orders
5. Match location and contact details
6. Switch languages
7. Check usability
8. Check loading
9. Check search access
10. Assign responsibility

Before you begin

Have your approved menu, current opening hours and intended booking and ordering destinations ready. Use a real phone and a desktop browser. Record the device, date, language and starting URL so someone else can reproduce a problem. Keep the approved references alongside the findings, so disagreements can be checked against the same information.

Mark each check passed, open or not offered. Missing access does not mean a pass. Record the finding, affected URL, responsible role and deadline. This turns a review into work your team or agency can act on.

1. Define three specific guest tasks

Choose tasks that fit your restaurant: reading today's menu, requesting a table or arranging collection from the correct branch. A restaurant without delivery does not need an invented delivery journey. Check the location mapping separately for each branch.

Start from the homepage and a realistic entry point, such as the website link on your Google profile. Ask someone unfamiliar with the site to try the tasks. Follow the route guests can actually see, including the labels they have to interpret along the way. Record detours and confusing labels. A specific point where someone gets stuck is more useful than an invented universal target for the number of clicks.

Result: You have recorded the tasks, starting points and expected destinations.

2. Open the mobile site as a new guest

Open the site without a saved login. Can guests identify the restaurant, location, cuisine and main action? Check that navigation opens and closes, and that consent controls, chat windows or fixed elements do not cover the menu or booking link.

Try portrait, landscape and a narrow screen. Essential information should not be available only on desktop. Google's mobile-first indexing guidance explains that it uses the mobile version of content for indexing.

Result: Guests can start all three tasks on mobile, with no essential desktop information missing.

Follow navigation and visible menu links. Check dishes, availability and other details against the approved version. Make the validity of food, drinks and seasonal menus clear. An old download should not quietly replace the current menu.

Check readability on a small screen without logging in. Text is easier to search and enlarge than a photograph. Test any PDF separately: a working website layout does not make a download readable. Assign someone to carry changes in the restaurant through to the website. Keep the reviewed version with your notes, so the team knows which menu the finding refers to.

Result: Guests reach a readable, current menu with a known source and maintenance owner.

4. Follow reservations and orders to the handoff

Follow the actual button to its destination. Check the branch, date or order type, and next step. Make the difference between a non-binding enquiry and a confirmed reservation clear. Ordering journeys should distinguish collection from delivery and identify the responsible branch.

Stop before making a binding submission. Arrange any complete transaction test with the provider in its test system. There, check both the confirmation and receipt by the restaurant. A working button alone does not confirm a processed order. Provide a reachable fallback contact for failures.

Result: Destination, branch and status are clear; untested completions remain explicitly open.

5. Match branch, hours and contact details

Compare addresses, phone numbers and hours across the homepage, contact page, map and booking page. Kitchen, dining and collection hours can differ. Include the next known exception, rather than checking only a normal week.

Check that phone links contain the correct number and directions lead to the right location. An embedded map should not be the only readable address. For a hidden entrance, add brief directions and a current photo you own. Guests should still find and contact you when an external map service does not load.

Result: Guests can locate and contact the restaurant without resolving contradictory information.

6. Keep the task intact when switching languages

Switch languages on a menu or reservation page. The switch should lead to the corresponding content. Record both the starting language and the page reached after the switch. Translated navigation and footers alone do not make a menu or enquiry understandable. Include error messages, confirmations and handoffs to external providers in the review.

Ask your technical support to check reciprocal language-page relationships. Google's guidance on localized versions explains hreflang. It does not replace maintained translations or guarantee a search position.

Result: Guests can continue their task after switching languages; gaps are recorded for each language.

7. Check keyboard access, readability and forms

Use the keyboard to navigate, open menus and reach booking fields. Focus should remain visible, and users should not become trapped in a menu. W3C explains keyboard access as part of accessible use.

Enlarge text and inspect labels, contrast and useful error messages. Essential information should not exist only as an image. The W3C preliminary checks help with this first look; they are not a full conformance evaluation.

Result: Each usability barrier has an affected page and a clear description of its effect on a guest task.

8. Check loading on the pages that matter

Try the homepage, menu and booking journey over a mobile connection. Inspect large images, videos and embedded services when they delay the start of a task. Watch for shifting content: a moving button can cause an unintended tap.

PageSpeed Insights distinguishes simulated lab tests from real-user field data. Field data may be unavailable or cover the whole site rather than one page. Record the URL, device and measurement type. A single score does not establish extra reservations or revenue.

Result: You have identified the problem and measurement basis; missing field data is not recorded as zero.

9. Check search access and restaurant data

With technical support, check that important pages are public and available for indexing. Use Search Console for individual URLs. Google's technical requirements are prerequisites, not a guarantee of indexing.

Structured data for the restaurant's name, location, menu and hours should match visible content. Google's LocalBusiness documentation covers restaurant information and menu URLs. Valid markup does not guarantee a rich search result. Do not copy reviews or location details that belong to another business.

Result: Record search access, index status and data conflicts separately, without promising rankings.

10. Assign responsibility for data and upkeep

Check that the site and embedded resources use HTTPS. Mozilla's TLS documentation explains encrypted transport. A certificate alone does not establish system-wide security or lawful data processing.

If you use consent management, inspect the states before a choice, after refusal and after acceptance. Access requiring consent should follow the relevant consent; the DSK guidance explains its timing. Which services require it needs separate assessment. A banner or privacy link does not prove full legal compliance.

Assign owners for menus, hours, provider links and technical failures. We recommend brief regular reviews and another after changes. This is a working routine, not a statutory inspection interval.

Result: Data questions and maintenance tasks have owners; unresolved issues remain visible.

Worksheet for your next steps

Add a status, finding, responsible role and deadline to each row. Fix wrong locations, old menus and blocked booking journeys first, followed by other usability and loading issues. Treat design as a task where it creates an observable problem with navigation or use.

No.	Check	Evidence to record
1	Guest tasks	Starting point and expected destination
2	Mobile view	Device and observed barrier
3	Menu	Approved version and maintenance owner
4	Reservations and orders	Destination, branch and confirmed test scope
5	Contact and hours	Matched details and next exception
6	Languages	Corresponding page and translation gap
7	Usability	Specific keyboard, text or form finding
8	Loading	URL, measurement type and observed problem
9	Search	Index status and checked restaurant data
10	Data and upkeep	Open question, owner and deadline

Frequently asked questions

Does my restaurant need a new website?

Not automatically. A broken link or old menu can often be fixed in the existing system. A rebuild becomes a reasoned option when that system cannot reliably support or maintain important guest tasks.

Is an automated Website-Check enough?

Our Website-Check provides a technical starting point. Its overall score is an OzyCore assessment, not an official Google ranking. Menu, branch and reservation details still need a manual review. An automated check confirms neither a real completed transaction nor full accessibility or legal compliance.

How can I tell whether something improved?

First repeat the affected guest task. Then compare suitable periods of equal length and actual confirmed reservations or orders. A click is not a completed booking or order. Account for advertising, holidays and consent coverage in your measurement. A simultaneous increase does not establish cause and effect.

Start with a specific list of problems

Begin with the Website-Check and add your manual findings. For related journeys, read our guides to Google Business Profiles for restaurants and delivery platforms and your own ordering channel. Our online ordering system service explains support for the ordering journey.

Sources checked: 21 October 2026. The linked original documents support technical and platform-specific statements. The sequence, worksheet and priorities are OzyCore Studio recommendations. No client results or case studies are used as evidence of performance.

Restaurant website checklist 2026: ten checks from a guest's perspective

Contents