Restaurant Website Design and QR Menus: 2026 Guide

A restaurant website earns its keep when it does four things: serves the menu as a fast HTML page instead of a PDF, carries allergen and calorie information in a legible form, keeps ordering or booking on your own domain, and feeds your Google Business Profile. In the National Restaurant Association's 2026 survey, 70% of consumers said they would order and pay through a restaurant's own website if it were offered.

That number is the whole argument for owning the channel. The same survey puts the figure for a restaurant's own mobile app at 74% and for a self-service kiosk at 68%, so the website sits inside the band of things diners already expect to work.

What most restaurant website guides skip is the regulated part. In England, calorie information has to appear on the online menu, not just the one on the table. Across Great Britain, written allergen information is now the regulator's documented expectation. Both requirements land on the page a developer builds, which is why they belong in a design brief rather than in a compliance folder.

Table of Contents

• Why the website comes before the QR code
• What a restaurant website has to contain
• Allergen and calorie rules that land on your menu page
• QR menus done right: an HTML page, not a PDF
• A speed budget for the menu page
• Direct ordering and bookings versus marketplaces
• Structured data and your Google Business Profile
• Food photography standards
• Accessibility, languages and a printable fallback
• Build order, timeline and budget
• Frequently Asked Questions

Why the website comes before the QR code

Most operators do this in the wrong order. They generate a QR code, point it at a PDF, and leave the website for later. The result is one menu living in three places with three different prices: the code on the table, the marketplace listing, and the Google profile.

Reverse it. Menu data lives in one place, and that place is your site. The QR code, the marketplace feed and the map listing all point at that single source. When you raise a price, you change it once.

Diner behaviour backs the same structure. The National Restaurant Association's 2026 State of the Restaurant Industry report found that 77% of delivery customers, 66% of takeout customers and 65% of drive-thru customers say the availability of technology for ordering and paying matters when they choose a restaurant. On the operator side, 8 in 10 say technology gives them a competitive advantage, and roughly 6 in 10 planned investment in customer-facing technology for 2026.

A restaurant website carries four jobs, and they are not equally weighted:

The menu page is the most visited and the most neglected of the four. It is where the guest who is comparing prices, checking allergens or still undecided ends up; anyone who reaches your booking form has already read it. So that is where this guide puts its weight.

What a restaurant website has to contain

Six pages cover most independent operations, and a restaurant website rarely needs more: home, menu, order or book, location and hours, about, and contact. Multi-site businesses add one location page per venue. Adding pages beyond that returns less than improving the menu page does.

One thing a restaurant website does not do is replace a marketplace. A delivery platform shows you to someone who has never heard of you; your own site serves someone already looking for you. Those are different demands. The site's real return is converting a platform customer into a direct customer on the second order.

Content order matters more than page count. Put the menu one click from the home page, not behind a "Dine with us" submenu. Put the address, the opening hours and the phone number in crawlable text, not inside an image. Put the booking or ordering action in a fixed position on mobile so it survives scrolling through 40 dishes. Our website content preparation guide sets out the order to collect this material in.

Allergen and calorie rules that land on your menu page

Two separate obligations apply to menus in Great Britain, and both of them reach the online menu on your restaurant website.

Calories. The Calorie Labelling (Out of Home Sector) (England) Regulations 2021 came into force on 6 April 2022 and apply to businesses with 250 or more employees. The Department of Health and Social Care's implementation guidance sets out what has to be shown: energy content in kilocalories, a reference to the portion size, and the statement that adults need around 2000 kcal a day.

Three details in that guidance matter to whoever builds the page:

• The information must appear at every point of choice. If customers choose from a menu on the premises, a display case and an online menu, all three need it.
• The requirement extends to food sold on a website or mobile application, including third-party delivery apps. The business responsible for the website or app — the guidance calls it the remote provider — must display the calorie information regardless of its own size.
• The information must be "easily visible, clearly legible, and not in any way hidden or obscured by other written or pictorial matter". That rules out a tooltip, a collapsed accordion or grey 11px type.

For distance selling, the guidance points at Article 14(2) of assimilated Regulation (EU) No. 1169/2011: calorie information has to be available to the customer when the food is delivered, which in practice means a labelled menu in the bag or stickers on containers. Non-compliance can bring an improvement notice.

Allergens. Food businesses already have to tell customers if any of the 14 regulated allergens are used as an ingredient. What changed is how. The Food Standards Agency published Allergen Information for Non-Prepacked Foods Best Practice on 24 February 2025, applying to England, Northern Ireland and Wales. Its position is that allergen information should be available in writing and supported by a conversation with staff.

The FSA is honest about legal status: the minimum legislative requirement — that information may be provided by any means, with a sign saying when it will be given verbally — has not changed. But the documented expectation has, and the guidance is specific about digital delivery:

The practical consequence is a data model, not a disclaimer. Every dish needs an allergen field, and the menu template needs a style that separates allergen text from the rest of the description.

QR menus done right: an HTML page, not a PDF

Most QR menus still resolve to a PDF. That choice costs more than it saves:

1. Forced zooming. A page laid out for A4 does not read on a 390px screen. The guest pinches to read every line.
2. Weight. Image-heavy menu PDFs pass 5 MB easily. On a busy restaurant's shared signal, that is a measurable wait.
3. Screen reader failure. Scanned or image-based PDFs have no text layer, so a guest using a screen reader cannot read your menu at all.
4. No search visibility. A PDF does little to make your dish names findable.
5. Update friction. Every price change means reopening a design file, exporting and re-uploading.
6. Styling drift. The allergen emphasis the FSA guidance asks for can be built in a PDF, but it has to be rebuilt by hand on every revision.

Publish the menu as a page on your restaurant website instead, in HTML. Category names as real headings, dishes as list items, allergens in their own style. The same page then works for a screen reader, for search, and for a single-point update.

Plan the data model before the layout. Each dish needs at least six fields: name, description, price, portion, allergen list, and calories per portion. Add an "is published" flag and you can hide a seasonal dish without deleting it. Those six fields then generate the page, the structured data and the printed copy from one source.

For the code itself, three rules:

• Use a dynamic QR code so you can change the destination later without reprinting every table stand.
• Do not print it small. Below roughly 2.5–3 cm per side, table-stand codes fail in low light and on older cameras.
• Put readable text next to it — a short URL, plus any standing message you are required to display. When a camera fails, the text saves the table.

Keep the menu URL short and permanent, something like /menu. Printed stands live for years; campaign URLs do not.

A speed budget for the menu page

The menu will be your highest-traffic page, and most of those visits arrive over weak cellular signal inside your dining room. Speed therefore ranks above decoration.

Google's Core Web Vitals thresholds give you numbers to design against. At the 75th percentile of page loads, measured separately for mobile and desktop, LCP should be under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1.

A workable budget for a menu page:

Two mistakes are expensive enough to name. The first is publishing 60 dishes with full-size photos on one page; no amount of tuning brings that page inside the thresholds on mobile. The second is handling category switching with a heavy client-side component, which is the usual reason a menu page misses the INP target.

The fix for both is structural: split categories into their own URLs and show at most two images above the fold. Our guide to speeding up a website covers the measurement and remediation loop in detail.

Direct ordering and bookings versus marketplaces

Marketplaces bring demand you do not have to earn. They also keep the customer record. A direct ordering page on your restaurant website does not flip that balance; it adds an option you control.

The 2026 industry data shows how mixed the picture is. Among limited-service operators, 62% offer delivery, and 38% let customers order both through a third-party service and directly. Among full-service operators, 40% offer delivery and 21% support both routes. Of operators who offer delivery, 69% say it creates more opportunities than challenges. The complaint recorded alongside those numbers is specific, and it is a web problem rather than a logistics one: operators say they cannot market to delivery customers because they do not own the data.

Three decisions shape a direct ordering flow that actually gets used:

• Narrow the scope. Launch with collection and takeaway. Measure demand before you build delivery.
• Shorten checkout. No forced account creation. Allow guest ordering with phone verification.
• Show the required information in the product card. Allergen and calorie data belongs where the dish is chosen, which also satisfies the point-of-choice and pre-order requirements described above.

Track three numbers monthly: direct orders, average basket, and the share of customers who order a second time. The third is the one a marketplace never shows you, and it is where the return on a restaurant website accumulates. When those numbers justify a dedicated app, our restaurant app guide works through the payback maths.

Bookings are lighter work. Date, time, party size and contact details are enough; a confirmation message plus a reminder cuts no-shows. The custom booking system guide covers the same logic in more depth, and the approach we use for accommodation is in the hotel website design guide.

Structured data and your Google Business Profile

A large share of restaurant searches starts on a map and ends there. So the site and the business listing have to corroborate each other.

Start with consistency: name, address, phone number and opening hours must be written identically on your site and in your listing. Then add markup.

According to Google's local business structured data documentation, the Restaurant type requires only two properties — name and address. The recommended list is where the restaurant-specific value sits:

Set expectations on one point: Google's restaurant carousel is limited access. The documentation says so plainly and routes interested publishers to a registration form. Marking up every individual dish does not produce an automatic dish carousel in search. Getting the menu property right and keeping the menu in HTML is the realistic win.

Feed all of it from one source. If menu data sits in a database, the page, the structured data and the QR destination are generated from the same records, so a price change updates all three. The wider principles are in our SEO-friendly web design guide.

Food photography standards

Food photography is the strongest persuasion tool on a restaurant website and also its largest performance risk. Managing both means setting standards once.

A minimum shoot list: one hero frame per category, individual frames for your six best-selling dishes, one room shot, one team shot. That set takes half a day and feeds the site, the map listing and your social accounts together.

Write the technical standards into the brief:

• Aspect ratio. 4:3 or 1:1 for dish cards, 16:9 for hero images. Mixed ratios shift the layout and push CLS up.
• Long edge. 1600px is enough. Anything larger is wasted on mobile.
• Format. WebP or AVIF, with JPEG as a fallback.
• Compression target. 80–120 KB for a dish card image.
• Alt text. The dish name and its distinguishing ingredient. Writing "food photo" wastes both the accessibility and the search benefit.
• Consistent light. Shoot the whole set with the same light and the same surface. A mixed set makes a menu look disorganised.

Resize and compress before upload. A 6 MB frame straight off the camera will take the menu page out of range on its own. If your upload pipeline does both steps automatically, whoever adds a dish in two years cannot break performance; if it does not, the first price change starts the decline.

Photographs are not mandatory on every dish. On a long menu, images only on the dishes you want to push both cut page weight and direct attention.

Accessibility, languages and a printable fallback

The FSA guidance already asks for an alternative route when allergen information is delivered digitally. Treating that as an accessibility requirement rather than a compliance checkbox gets you a better page.

Three checks go a long way:

• Contrast. WCAG 2.2 success criterion 1.4.3 requires a contrast ratio of at least 4.5:1 for normal text, dropping to 3:1 for large-scale text. Thin grey type on a dark background is the most common menu failure.
• Text resizing. When a guest doubles the browser text size, the menu has to stay readable. Fixed-height cards break this.
• Touch targets. Category tabs and quantity buttons need roughly 44px of tappable area.

The full checklist is in our web accessibility guide.

If you serve a tourist or multilingual area, translate descriptions rather than dish names: a guest searching for a dish by name will not find a translated version of it. Keep allergen data as language-independent codes in the data model so the stored value stays fixed while the displayed label changes per language. Mapping language versions correctly for search is covered in our multilingual website guide.

Finally, keep a printable copy of the menu. The written information that has to be available on request is easiest to satisfy with a printed page in service, and generating that page from the same data beats maintaining a second version.

Build order, timeline and budget

The most common failure in restaurant website projects is starting visual design before the menu data exists, and it is entirely avoidable. Without data, design becomes the aesthetics of empty boxes, and it falls apart when content arrives.

Do not reorder it. Shoot photography before the menu table is complete and you will need a second shoot for the dishes nobody listed. Write structured data before the menu page is final and the markup breaks when URLs change. Delays in these projects usually come from skipping the sequence, not from technical difficulty.

On cost, the variables are the state of your menu data and the scope of the ordering flow, not the page count. To see a range against your own scope, try our website cost calculator, and check your titles and descriptions with the SERP preview tool before launch.

A single-site operation finishes this plan in four weeks. Multi-site work adds location pages and per-venue pricing, which pushes it to about six.

Frequently Asked Questions

Are QR menus legally required?

No. QR codes are one permitted way to deliver information, not an obligation. What is required is that customers can access allergen information, and for large businesses in England, calorie information. You choose the medium; the FSA guidance simply asks that if you go digital, you also offer an alternative route and a backup.

Do calorie rules apply to my online menu as well?

In England, yes, if the business has 250 or more employees. The implementation guidance states that calorie information must appear at every point of choice, and that the requirement extends to food sold on a website or mobile application, including third-party delivery apps.

Where should allergen information sit on a restaurant website?

On the main menu if you can. The FSA guidance says that if it is not on the main menu it should ideally be no more than one click away, with a clear message and link so customers can find it. For online orders it should be available before the order is placed and again on delivery.

Is a PDF menu really worse than an HTML page?

Yes, measurably. A PDF forces zooming on mobile, often has no text layer for screen readers, loads slowly because of its file size, and requires a design file for every price change. An HTML menu serves the same data faster, in a searchable and updatable form.

How many pages does a restaurant website need?

A restaurant website of six pages is enough for most independents: home, menu, order or book, location and hours, about, and contact. Multi-site operators add a location page per venue. Beyond that, improving the menu page returns more than adding pages.

Do I need online ordering on day one?

No. Launching with the menu and bookings lets you measure demand before you commit to delivery operations. When you do add ordering, show allergen and calorie data inside the product card so the information appears at the point of choice.

How do I know whether my menu page is fast enough?

Measure on mobile and check three thresholds: LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1. If those hold at the 75th percentile of page loads, the page is in good shape.

Restaurant website decisions in 2026 are driven by two things at once: guests who read menus on a phone by default, and regulators who now treat the online menu as a point of choice. Both point at the same build — one source of menu data, a page that loads fast on a weak signal, and allergen and calorie fields designed in from the start rather than bolted on.

To get your menu into a structured table, map your own obligations and scope a menu page that holds to a speed budget, take a look at our web design service and get in touch with your current menu and site structure.