You can learn a surprising amount about a restaurant website in fifteen minutes — if you ask the right questions and write down exactly what you saw. This guide gives you five: is the menu structured, does the page fit a real phone, are the essential answers together, which public state did you check, and where does each action go?
A word on what this is and is not. The five questions come from seven recorded production checks of anonymised UK independent restaurant websites, carried out in July 2026. They are useful audit questions, not a prevalence study: we are not claiming most restaurant websites share these faults, and we draw no conclusions about anyone's traffic, bookings, conversion or revenue — interface evidence cannot support those claims. What it can support is a careful description of visible structure and recorded public states: a named viewport, a default state, a count you could reproduce. Audit the same way and you will end up with a short, honest fix list instead of a vague feeling that "the website needs work".
How to run the 15-minute audit
You need the phone in your pocket, a laptop or desktop, and somewhere to write notes. Before you start, agree one rule with yourself — every observation gets a record. For each thing you notice, capture:
- A screenshot of exactly what you saw, on the device you saw it on.
- The date and time — websites change; your evidence is a point-in-time check, not a permanent verdict.
- The device and state: which phone or screen size, which page, and which controls you opened first. A collapsed section you never expanded is a different finding from a missing one.
Then run the five questions in order, roughly three minutes each, phone pass first, in a normal browser, from the front page — the way a hungry person arrives. Resist fixing anything mid-audit; fixes are more proportionate once all five answers sit side by side.
- Is the menu structured? — What to inspect: names, descriptions, prices and dietary notes as readable page content. Evidence to capture: phone screenshot of one full item; any pinching or sideways movement. A proportionate fix: structured menu page; document as secondary download.
- Does the page fit a real phone? — What to inspect: viewport width vs document width; text and control sizes. Evidence to capture: screenshot of clipped content; device and page. A proportionate fix: a responsive layout tested on the actual phone.
- Are essential answers together? — What to inspect: menu, current hours, address, one clear next step. Evidence to capture: screenshots of where each answer actually lives. A proportionate fix: one owned page with the primary answers and deliberate handoffs.
- Which public state was checked? — What to inspect: phone default, desktop default, what appears only after interaction. Evidence to capture: both screenshots, timestamped, plus controls opened. A proportionate fix: one explicit source of truth per repeated fact.
- Where does each main action go? — What to inspect: destination of every menu, booking, ordering and contact control. Evidence to capture: visible label and actual destination of each control. A proportionate fix: label every handoff; choose deliberately what leaves your site.
Mistake 1: the menu has facts, but no structure a phone can use
A menu is more than a picture of a menu. It contains relationships — a dish name belongs with its description, price and dietary or allergy notes — and those relationships only survive on a small screen as structured, reflowing page content.
Two recorded checks illustrate the difference. One site routed its primary menu action to a fixed portrait document with multiple text columns: at phone width, the page could not remain both fully visible and comfortably readable, so inspecting a single dish required enlarging and moving around the page. Another carried genuine menu content across an owned page and a linked document, yet its checked phone and desktop defaults exposed materially different amounts of price text: nine visible price tokens on the phone against 95 on desktop, from the same menu.
Neither observation proves document menus are always wrong, or any published price incorrect. The audit question is narrower: can a phone user read one complete item — name, description, price, dietary note — as a single comfortable group, without pinching or hunting?
What to inspect. Open the menu from the main navigation on your phone, exactly as a guest would. Pick one dish and try to read its full record. Does the dietary and allergy information travel with the dish, or live somewhere else?
Evidence to capture. A phone screenshot of one complete menu item as it renders; any pinch, zoom or sideways movement it took to read; the date; and whether the checked menu matches the menu currently served — put the source menu beside the screen while you compare.
A proportionate fix. You need not abandon the designed document. Publish the same facts as structured page content — sections, dishes, prices, dietary notes — and let the document remain a download. Structured content reflows to any screen, is corrected in one place, and gives search engines and accessibility tools something reliable to read.
Mistake 2: the desktop composition doesn't fit a real phone
Responsive quality is measured at the actual viewport, on an actual phone. A desktop screenshot scaled down in a design tool is a different test — one that passes sites that fail in the hand.
The recorded checks make this concrete. One site presented a 942px-wide document inside a 390px phone viewport — reaching the right-hand edge required 552px of horizontal travel, and the navigation and enquiry column only appeared after that sideways journey; 42 of 44 sampled text elements rendered below 14px, and 11 of 14 sampled controls had a dimension under 44px. Another site served 768px-wide pages into the same 390px phone width, leaving 378px of horizontal travel. In both cases the identical documents had no horizontal overflow at the checked 1440px desktop width — the desktop view looked fine, which is precisely why the fault survived.
Those figures describe specific checked states on specific dates. They do not establish how many visitors use phones, whether the network was slow, or any commercial effect. What they give an audit is an exact, reproducible description of the phone interaction needing attention.
What to inspect. On your phone, load the homepage and menu page. Any sideways scrolling? Can you read body text without zooming, and tap each button without hitting its neighbour?
Evidence to capture. A screenshot of any clipped or overflowing state, with the device model noted; if you can, the viewport and document widths (browser inspection tools read both in seconds); which pages you tested, and when. Sampling real text and control sizes beats judging by appearance.
A proportionate fix. This is rarely a content problem; it is a layout problem. The page needs a genuine responsive treatment, tested on the phone itself, rather than a fixed desktop composition viewed through a small window. If your current setup cannot produce that, it is a reasonable moment to weigh alternatives; our guide to what a restaurant website costs in the UK sets out the realistic options and their prices.
Mistake 3: the essential answers are scattered across public surfaces
A guest deciding whether to visit has about four questions: what do you serve, are you open, where are you, and what do I do next? Each answer can legitimately live in more than one place. The mistake is when no single owned page answers all four and the guest must take an undocumented tour.
The recorded checks turned up three variations. In one, the checked public discovery routes centred practical updates and menu discovery on a social account, with no dedicated owned page surfacing menu, current hours and a clear next step together. In another, a forthcoming restaurant's owned page returned successfully at both phone and desktop sizes — and its entire visible body text was nine characters plus one outbound social link, with no menu, opening date, hours, address, enquiry route or booking path visible, even though current external sources supported a September 2026 opening window. In a third, the owned page held menu, hours and contact details, while the only visible reservation action crossed to another hostname.
None of this proves that any of those teams lacked a plan, or measures the value of the platforms involved. The audit question is: for each essential answer, where does the authoritative version live, and does your owned page either carry it or hand off to it clearly?
What to inspect. Play the guest. Starting from a phone search for your restaurant's name, try to answer all four questions, noting every surface you visit and every dead end.
Evidence to capture. A simple answer map — one row per question:
- What is on the menu? — Authoritative owned answer: structured menu page. Other helpful route: social preview or document download.
- Are you open now? — Authoritative owned answer: current opening information. Other helpful route: social post for exceptions.
- Where are you? — Authoritative owned answer: address and directions context. Other helpful route: external map application.
- What do I do next? — Authoritative owned answer: clear booking or enquiry explanation. Other helpful route: specialist reservation tool where needed.
A proportionate fix. The owned page need not replace every tool — it needs to make the primary answer and each handoff understandable, and to be the place you update first. Starting from very little? Our step-by-step guide to building a restaurant website assembles exactly these essentials in a sensible order.
Mistake 4: nobody records which public state was checked
This one is about how facts go stale — and how audits go wrong. Different public states answer the same question with different quality, and an observation is only trustworthy when you know which state produced it.
Three recorded examples. One homepage simultaneously carried a weekly opening-hours statement and a service notice saying collection and delivery only — two different operating modes on one page. The check recorded the visible contradiction and deliberately did not decide which was current, because the interface alone could not say. Another check found one menu page's phone and desktop defaults exposing the same 28 detected headings but nine versus 95 visible price tokens — and recorded, honestly, that no accordion was opened, so it could not claim any hidden item was unreachable. A third found a sparse owned teaser whose opening window was supported only by separate current sources, not by the page itself.
The lesson for your audit is a discipline: record the state before you draw the conclusion. The lesson for your website is its mirror image: when the same fact appears in several places, you need one explicit source of truth and a habit of updating it first.
What to inspect. Compare your phone and desktop defaults side by side. Find every place a time-sensitive fact appears — hours, service mode, seasonal notices — and check they agree. Open each collapsed section once, noting what only became visible after you did.
Evidence to capture. For each observation: date and time; device and viewport; the page; which controls you opened; what was visible before you opened them; the limits of your test. This small record stops an interface observation quietly inflating into a claim about a business or an outcome.
A proportionate fix. Reconcile contradictory statements the day you find them — a wrong answer is worse than a missing one. Then reduce the number of places each fact is maintained, ideally to one structured source that every page reads from.
Mistake 5: the main action leaves your site without explanation
Every main control — menu, book, order, contact — takes the guest somewhere. External platforms can be a legitimate destination, and a cross-site handoff is not automatically a defect. The mistake is a handoff that is unlabelled, unexamined, or simply unknown to the owner.
In one recorded check, the only visible reservation action at both viewports pointed from the owned page to a different hostname. The check could not even render the destination (the automated attempt failed with a protocol error), which is itself the point: the audit could characterise the handoff, but the guest's next step was outside the owned site's control. In another check, discovery ran almost entirely through a social route; in a third, the only outbound path on the owned page was a single social link, with no direct enquiry or booking route visible.
The recorded evidence does not establish anyone's platform fees, contract terms or destination quality. It supports a narrower, very practical exercise: an action map.
What to inspect and capture. List every main action control on your site. For each, record its visible label, its actual destination address, and what the guest should expect next. Then ask of each row: is the handoff explained, and is this journey deliberately sent off-site?
A proportionate fix. Label every handoff honestly. Keep the destinations that earn their place, and add a clear owned alternative where useful — a direct enquiry path costs little and belongs to you. If part of your motivation is what per-booking charges add up to across a busy service, our guide to cutting booking commission works through that decision without pretending platforms have no value. Measure actual performance only after a route is live and instrumented — never from the audit alone.
Turning your notes into a fix list
Fifteen minutes of disciplined looking usually produces a short, specific list. Order it by guest impact, not effort:
- 1. Contradictions first. Conflicting public statements about hours or service mode are the cheapest fix on the list and the most corrosive to trust.
- 2. The phone menu second. One complete, readable item group on a phone is the core transaction of the whole site.
- 3. The action map third. Make each main action's destination labelled and deliberate.
- 4. Layout work last. Structural responsive fixes take longest; scope them with your evidence in hand, so whoever does the work receives screenshots and measurements rather than adjectives.
Resist attaching a revenue forecast to any of it. This audit's honest promise is clarity, not conversion: knowing what your public surfaces actually say, on which devices, in which states.
Where TableSpark fits
TableSpark is one possible owned-site route, so read this section as product context rather than neutral advice. It is a restaurant website builder in which the menu is structured data from the start: sections, dishes, prices and dietary notes are fields rendered as responsive page content, so a price changed once updates everywhere it appears — which resolves mistakes one and four by construction. There are 50 complete templates across eight design worlds, each a finished site rather than a blank page.
The AI menu scan drafts a site from a photograph of your menu, and you review every line before anything is published. That review step matters: one recorded check saw a local text-recognition pass return a price as 1750 where the source read 17.50 — a dropped decimal in the OCR output, not the restaurant's menu, and exactly what a review exists to catch.
On the fifth question, TableSpark's position is deliberately modest. Reservations are direct booking enquiries into your own inbox and guest list — a person at the restaurant reviews and confirms them; not real-time table inventory or instant confirmation. Online ordering is in early access. For payments, the position is exactly this:
0% TableSpark commission · Stripe's standard card-processing fees apply.
TableSpark is free until you publish — build and review the whole site first; a plan starts only when you go live. Published plans are £19, £39 and £69 per month, excluding VAT — see pricing. If the audit has left you with a fix list your current setup cannot handle, start building free and publish only when you are ready.
Frequently asked questions
Do most UK restaurant websites make these five mistakes?
We do not know, and this guide deliberately does not claim it. The five questions come from seven recorded checks of individual sites — enough to show each pattern exists and is worth auditing for, not enough to say how common they are.
Is a PDF menu always wrong?
No. A document is a fine print artefact and a reasonable secondary download. The audit asks something narrower: can a phone user comfortably read a complete menu item, and are the menu's facts also available as structured page content you can correct in one place?
Does an external booking link mean I should drop the platform?
No. External platforms can provide discovery or operations you genuinely need. Record the handoff, understand what the destination does, and decide deliberately whether a clear owned route should exist alongside it.
Can this audit tell me I'll get more bookings if I fix these things?
No. Interface evidence cannot establish bookings, covers, conversion or revenue, and any audit that promises otherwise is overreaching. Define the outcomes you care about, publish the fix, and measure afterwards.
What should I fix first?
The cheapest, highest-trust fix is removing contradictory public statements. After that: the phone menu experience, then the action map, then structural layout work — in that order, because that is the order guests feel them.
How often should I repeat the audit?
Whenever something operational changes — menu, hours, service mode, booking arrangement — and otherwise once a season. Keep the old records; comparing two timestamped audits is how you notice quiet drift.
Method and evidence
The observations in this guide come from seven production checks of anonymised, independently screened UK restaurant websites, recorded on 19 July 2026 using a scripted browser (Chromium via Playwright) at two fixed viewports — 390×844 and 1440×1000 CSS pixels — in en-GB, Europe/London. Each check recorded the default public state, the controls opened, the measurements taken and, as importantly, what the evidence does not establish: nothing here supports claims about traffic, device share, bookings, conversion, revenue, page speed, or who built or maintains any site. Capture waits were deterministic pauses, not measured load times. Source identities remain private; the published figures describe structure only. The weekly examples behind this synthesis were concept redesigns, not client projects, and each record was independently approved before use here.