UK restaurant website statistics 2026.

Executive summary

The general web plumbing on UK restaurant websites is roughly as good as the web as a whole. The part that is specific to a restaurant, the part that tells Google and a hungry guest what the place is, what it serves and how to book, is mostly missing.

1. Almost one in five listed websites was gone or broken. 179 of the 1,000 domains (17.9%) no longer resolved, could not be reached or returned an error.
2. The general basics are at web-average levels. 69% of loaded homepages had a meta description and 95.4% a mobile viewport, close to the 67.2% and 95.2% the Web Almanac 2025 found across all mobile pages.
3. The restaurant layer is missing. 77.1% had no usable Restaurant structured data. Of the 212 sites that had a restaurant-type block, only 26.9% included the menu and 36.3% the cuisine.
4. Menus are hard to read. 21.9% of homepages linked to no menu at all and 10.4% linked straight to a PDF. Of the menu pages that were web pages, only 32.5% showed at least three prices as text, and 3% carried menu structured data.
5. Booking and ordering leave the site. 25.6% had no booking link, 18.4% sent guests to another company's site to book and 13.4% sent ordering to a delivery marketplace.
6. The details a guest needs on a phone are patchy. 54.7% had no tap-to-call link, 45.3% showed opening hours in the page text, and 9.2% mentioned allergens on the homepage.
7. Speed and JavaScript are not the main problem. In a lab test, 9.4% of homepages took longer than 2.5 seconds to show their largest element, and rendering JavaScript changed the structured data result for only 2.1% of sites without it.
8. The typical site has five fixable gaps. The median homepage had 5 issues flagged. 1.2% had none, and 16.8% had all five core basics.

Why restaurant websites matter in 2026

The UK had 108,500 enterprises in restaurants and mobile food service in 2026, according to the ONS UK Business Counts, up from 102,450 in 2024. 84,270 of them, about 77.7%, employed fewer than ten people. Those are the businesses this study is about: independent restaurants where the owner is also the person who has to keep the website right.

Their guests are on phones and on Google. Ofcom's Online Nation 2025 report, published on 10 December 2025, found that smartphones accounted for 77% of the time UK online adults spent online on the average day, that 82% of UK online adults used Google Search in the month, and that the Google Maps smartphone app reached 77% of adults. A restaurant's own website is one tap away from the map listing, and one tap away from every alternative.

The alternatives charge for it. Uber Eats' UK merchant pricing page lists a 30% fee on delivery orders, 13% on pickup and self-delivery orders, and an initial fee of £650 excluding VAT. A guest who is unable to find the menu, book or order on the restaurant's own site does not stop wanting dinner. The guest goes somewhere that makes it easy, and that place either takes a cut or takes the booking.

A website can be live at a working link and still be absent from Google. A leftover noindex, a canonical that points elsewhere or a page that nothing links to can each leave an important page undiscovered or excluded, and missing restaurant data leaves Google to guess what the business is. The owner who checks the site in a browser sees nothing wrong.

How the study was done

Sample. A seeded random draw (seed 20261011) of 1,000 independent restaurants from TableSpark's August 2026 list of UK restaurants, built from OpenStreetMap entries tagged as restaurants that carry a website, across 106 UK areas. Chain signals were excluded, each domain was counted once, and links to social profiles and marketplaces were removed.

First pass, 11 October 2026. Each homepage was checked with the engine behind TableSpark's free restaurant website checker: the HTML as delivered without running JavaScript, the robots.txt file and the sitemap. The engine runs 16 core checks in three groups, reach, understand and act, plus a few conditional checks that appear only when they find a problem, such as a marketplace ordering link, and gives a score out of 100.

Second pass, 12 October 2026. Each of the 755 homepages that loaded was read again in more detail. The pass recorded which properties a restaurant structured data block carried, followed the menu link one step to see what the guest gets, and rendered the page in a headless Chromium browser at phone size to measure what JavaScript adds and how fast the largest element appeared. 753 homepages could be read in detail and 746 rendered.

Reporting. Percentages are shares of the 755 homepages that loaded unless a different base is given. Every share in the data appendix carries a 95% confidence interval; for a share near 50% of 755 sites, the interval is about plus or minus 3.6 percentage points. Results are reported as aggregates. No restaurant, domain or platform is named.

Full paper. The method, the statistical tests and the anonymised site-level data are published as a research preprint: Zheng, K. (2026), Zenodo, doi:10.5281/zenodo.23306547. This white paper presents its findings for restaurant owners.

Almost one in five listed websites was gone or broken

Of the 1,000 domains, 755 loaded with a normal page. 89 domains no longer resolved at all, 34 were unreachable or timed out, and 56 returned an error status instead of a page. A further 61 turned the checker away with a firewall challenge and 5 were invalid addresses; those 66 were excluded from every percentage, because a site that blocks automated visitors may still work for a guest.

That leaves 179 domains, 17.9% of the sample, that were gone, unreachable or broken when the check ran. OpenStreetMap listings can be out of date, so some of those restaurants may have moved address. For the guest holding the listing, the result is the same: the link they were given does not work, and the next tap is a directory or a competitor.

The general basics are at web-average levels

On the generic parts of a web page, independent restaurant homepages were close to the web as a whole. The HTTP Archive's Web Almanac 2025 measured mobile pages across the web; restaurant homepages in this study sat near its figures, and ahead on some.

• 69% of loaded homepages had a meta description, against 67.2% of mobile pages in the Web Almanac 2025.
• 77.9% named a canonical address, against 67%.
• 95.4% declared a mobile viewport, against 95.2%.
• 64.6% had a main heading, against 70%.
• 0.8% carried a noindex rule, against 2.4%.
• 59.6% carried structured data of some kind, against 41% of pages in the Web Almanac 2024.

The two studies count different things, all mobile pages against restaurant homepages, so the comparison is a guide, not a ranking. The point it makes is plain enough: restaurant sites are not unusually badly built. The gaps that matter are the ones a general website template does not fill on its own.

The restaurant layer is missing

Restaurant structured data is a short block of code that states, in a form search engines read directly, that the page belongs to a restaurant, with its name, address, telephone number, opening hours, cuisine and menu. Google's guidance on local business data lists name and address as required, and menu, servesCuisine, openingHoursSpecification and telephone among the recommended properties.

• 77.1% of loaded homepages had no usable Restaurant structured data.
• 71.9% had no restaurant-type block at all, and a further 5.2% had one missing the name or the address.
• 13.8% had a complete block with name, address, telephone, hours, cuisine and menu.

Most of the structured data that was present described something else. The most common types were WebSite (51.9% of homepages read in detail), WebPage (28.2%) and Organization (24.7%), the kind of block a general website template adds by default. Restaurant itself appeared on 15.8%, and LocalBusiness on 12%.

Even where a restaurant-type block existed, it usually stopped at the basics. Of the 212 homepages that had one, 85.8% gave the name and 82.1% the address, but 66% gave a telephone number, 65.6% opening hours, 36.3% the cuisine and 26.9% the menu. Only 35.4% said whether the restaurant accepts reservations.

Google can still work out a lot from the page text and from the business profile, and structured data does not guarantee any particular result. A restaurant that leaves it out, or fills in only the name, is leaving Google to guess the details that guests search for: the cuisine, the menu and the hours.

Menus are hard to read

The menu is the page guests most want, and the one most often made hard to use. Following each homepage's menu link one step showed four routes.

• 21.9% of homepages had no menu link the study could find.
• 10.4% linked straight to a PDF.
• 4.5% sent the menu link to another website, often an ordering or delivery service.
• 63.2% linked to a menu page on the restaurant's own site.

The menu pages themselves were often a wrapper for something else. Of the 471 menu pages that could be read, only 32.5% showed at least three prices written with a £ sign in the page text. 45.2% linked to a PDF from the menu page, and 3% carried menu structured data.

Google can index PDFs, so a PDF menu is not invisible. It is a file that has to be downloaded, zoomed and scrolled on a small screen, and one more document to replace every time a price changes. A menu shown as a picture, or as prices without text, gives a guest searching for a dish or a dietary need nothing to find.

Allergen information was rare on the first page a guest sees: 9.2% of homepages mentioned allergens at all.

Booking and ordering leave the site

• 25.6% of loaded homepages had no booking link at all.
• 18.4% sent guests to another company's website to book.
• 13.4% sent ordering to a delivery marketplace.
• 12.6% both took bookings on their own site and carried usable Restaurant data.

Each external link moves the moment of decision off the restaurant's own site and takes the guest's details with it. On a marketplace, the restaurant is one listing among many, and the fee is taken from every order: the 30% delivery fee on Uber Eats' UK merchant pricing page is the published example.

The details a guest needs on a phone are patchy

Almost every site had the basic mobile setting in place: 4.6% had no mobile viewport. The trouble was in the details a guest looks for while walking.

• 54.7% had no tap-to-call link in the page as delivered, and 47.9% still had none after JavaScript ran.
• 45.3% showed opening hours in the homepage text.
• 73% showed a UK postcode, and 71.4% a phone number, in the homepage text.
• 39.6% linked to a map.
• 5.9% were wider than a phone screen, so the guest has to scroll sideways.

Images were often unlabelled for screen readers and search engines. 40.2% of all images on the homepages had no alt text, and 76.8% of homepages with images had at least one without it. Only 31.9% declared the page as British English.

Speed and JavaScript are not the main problem

Speed is the gap most owners worry about, and in this study it was the smallest. Rendered once at phone size on a fast connection, the median homepage showed its largest element in 0.57 seconds. 9.4% took longer than 2.5 seconds, the threshold web.dev sets for a good Largest Contentful Paint, and 2% took longer than 4 seconds. These are single lab measurements, not the field data Google collects from real visitors on real networks, so a guest on one bar of signal will wait longer.

JavaScript did not change the main findings either. Google can render JavaScript, so text or data added by scripts may still be read. After rendering, 25.4% of the homepages that had fewer than 120 words as delivered reached 120 words, and only 2.1% of homepages without restaurant structured data gained it. The missing restaurant layer is missing from the page, not hidden behind a script.

The typical site has five fixable gaps

The checker runs 16 core checks on every homepage, plus conditional checks that appear only when they find a problem. The median site had 5 issues flagged, and the middle half had between 3 and 6. 1.2% had none, and 18.9% had 7 or more.

The study also counted a homepage as having the core basics if it had all five of these: usable Restaurant structured data, a sitemap the checker could read, no noindex rule, a mobile viewport, and a menu link or menu text on the homepage. Only 16.8% of the 755 loaded homepages had all five.

The checker's score out of 100 tells the same story more gently. The median was 81, and the middle half of sites scored between 76 and 86. A score in the 80s looks reassuring, and that is the trap. Most sites pass the checks that are easy to see, such as HTTPS and a mobile layout, and fail the ones nobody sees: the structured data, the description, the sitemap, the menu as text. The site looks finished to the owner, so nobody looks again.

Where the gaps differ: London, regions and cuisines

The sample held 267 loaded homepages in London and 488 elsewhere in the UK. Their average scores were close, 81 and 80, but the gaps were different.

London sites were better on the technical basics and far more likely to hand the booking to someone else: 29.2% sent guests to another company's site to book, more than twice the share outside London. Outside London, the bigger risk is the technical gap: almost one in four sites had no sitemap the checker could read, and a third had no description.

Cuisine is a rough grouping, taken from the OpenStreetMap listing, and the groups below are the six with at least 25 loaded homepages. Small groups move a lot with a few sites, so read these as patterns, not league tables.

Chinese restaurants were the most likely to have no booking link, 57.5%, and also had the most missing sitemaps of the six (37.5%). Japanese and pizza restaurants leaned hardest on marketplaces, at 32.1% and 28%. Structured data was missing across every cuisine, from 75% to 82.8%.

The same was true by website platform. Among the platforms the checker could identify on at least 30 homepages, the share without usable Restaurant structured data ran from 36.8% to 88.7%. No general website platform in the sample had solved it for restaurants by default. Building a site on a general builder gets a page online. It does not, on this evidence, get the restaurant described to search engines.

Action plan for restaurant owners

The order below follows the damage. A gap that stops Google seeing the page outranks one that only makes it harder to read.

The fastest way to see where one site stands is to run it through the free website checker. It takes about ten seconds, needs no sign-up, and lists each of the 16 checks with a plain fix for anything it finds. The full list of what a restaurant site should carry is in the restaurant website checklist, and the search side is covered in restaurant SEO in the UK and getting a restaurant website on Google.

Method and limits

The limits matter, and most of them point the same way: the study may miss things a site does have.

• Homepage first. The first pass read the homepage only. The second pass followed the menu link one step; booking pages and other pages were not read.
• HTML as delivered, then rendered. The first pass did not run JavaScript. The second pass rendered each page once in headless Chromium at phone size, which is closer to what Google sees but is not Google's own renderer.
• Lab speed. Load times come from one run on a fast connection, not from field data, and understate what a guest on a slow network waits.
• Firewalls excluded. 61 sites that turned the checker away were left out, and they may be in better or worse shape than the rest.
• Listings can be out of date. A domain that no longer resolves may belong to a restaurant that has moved address, or closed.
• Text patterns are approximate. Prices, opening hours, postcodes and allergen mentions were found by pattern matching, which can miss unusual formats.
• Benchmarks count different things. The Web Almanac measures all mobile pages on the web; this study measures independent restaurant homepages.

No individual restaurant is named in this report, and none will be. The figures are aggregates only. Anyone is welcome to cite them with a link to this page.

Data appendix

Every share below is of the loaded homepages unless the base says otherwise, with a 95% Wilson confidence interval. The restaurant block rows are shares of the 212 homepages that had one. The anonymised site-level data, the codebook and the analysis code are in the Zenodo deposit.