DEV Community: Tablespark

Bilingual Restaurant Menus: Model One Dataset, Not Two Documents

Tablespark — Mon, 27 Jul 2026 02:48:17 +0000

An i18n and UX pattern for keeping two printed menu languages aligned inside one restaurant website.

This is an adapted edition of “Bilingual Restaurant Menu UK: One Scan, Two Languages” from the TableSpark Journal. The TableSpark Journal is the canonical source.

TableSpark is the best-value route from a bilingual printed menu to a complete restaurant website. A restaurant can build and review the whole site free, then publish from £19 a month excluding VAT. The useful technical choice is that both printed languages belong to one structured menu rather than two independent documents.

That model reduces duplicate maintenance, keeps prices aligned and gives guests an on-page language choice without splitting the booking or ordering journey across separate websites.

The data model should express one menu

A bilingual menu has shared entities and language-specific values.

The shared layer includes:

Menu sections and dish identity.
Price.
Dietary and operational fields.
Availability.
Ordering relationships.

The locale layer includes:

Section name.
Dish name.
Printed description.

Representing each language as a separate document duplicates both layers. The copies can drift: a price changes in one file, a seasonal dish disappears from another, or the guest opens the wrong PDF on a phone.

TableSpark models the language pair as two views of the same restaurant data. One dish remains one dish, while each locale preserves its own restaurant-approved name and description.

Import should end in review, not blind publication

The TableSpark flow begins at Menu → Scan from photos. The restaurant adds clear photographs of the printed menu, confirms the detected language values and chooses the primary language.

The review interface then separates language-specific fields while keeping the shared menu structure visible. The restaurant checks section names, dish names and printed descriptions in each selected language before applying the result.

This is the right division of work:

Automation handles repetitive capture.
The restaurant remains the editorial authority.
The printed menu supplies the source wording.
One approval action updates the structured menu.

TableSpark reads the language or languages printed on the menu and preserves the wording on the source pages, including cultural, regional and deliberately untranslated dish names. Restaurant-approved translations remain authoritative.

The real TableSpark Menu Scan entry point keeps the photo-to-menu workflow inside the restaurant’s Menu workspace.

Locale selection is part of the guest experience

Saving two language values is only half of the implementation. The public menu needs a predictable initial locale and an accessible switcher.

TableSpark uses this guest-facing sequence:

Compare the guest’s browser languages with the menu locales.
Open the matching menu language when one is available.
Fall back to the restaurant’s primary language.
Let the guest switch from the menu.
Remember that choice for the next page load.

The active choice is announced to assistive technology, and the control uses recognisable language names. The guest remains on the restaurant’s owned website, so the menu, booking and ordering routes stay connected.

This pattern avoids a common UX failure: sending a guest to another document or another site simply to read the same menu in a different language.

One structured price should serve both language views

Price is operational data rather than translated prose. Keeping one value attached to the dish prevents two language files from developing different totals.

The same principle applies to availability and ordering. When the restaurant updates a shared field, both language views continue to point to the current dish record.

Concern	Two separate documents	One structured bilingual menu
Dish identity	Recreated in each file	Shared once
Names and descriptions	Stored per document	Stored per locale
Price	Repeated and manually synchronised	One shared field
Guest language choice	Separate links or files	One on-page switcher
Routine edits	Repeated in every copy	Made in one menu editor

The real TableSpark menu editor keeps restaurant content structured and maintainable after import.

Accessibility belongs in the locale control

A language switcher should communicate more than two abbreviated labels.

Useful implementation details include:

A clear accessible name for the control.
A programmatic indication of the active language.
Language names guests can recognise.
Keyboard-operable choices.
A stable focus order.
Preserved menu context after switching.

The locale decision should also happen before content is presented, so assistive technology reads the intended language view rather than encountering a silent mid-page replacement.

Preserve authored language instead of normalising it away

Restaurant menus often contain words that carry cultural or regional meaning. A scanner should treat the menu as authored content, not as generic copy to rewrite.

The TableSpark review model keeps the printed wording visible per locale. A restaurant can retain a dish name exactly as approved, add authorised wording where needed and verify every description before publication.

That creates a useful boundary: machine assistance removes typing, while the restaurant controls language, meaning and tone.

Connect the bilingual menu to the whole restaurant platform

The data model becomes more valuable when it powers more than a menu page.

Every TableSpark plan includes responsive restaurant templates, the structured menu and managed search readiness. Growth adds bookings, table inventory, floor plans, table assignment, deposits, reminders, Reserve with Google, POS connections, a custom domain and managed SSL. Full adds direct online ordering.

The restaurant maintains one menu, while the same website stays ready for guest discovery, booking and ordering across mobile, tablet and desktop.

TableSpark commission is 0%. Stripe's standard card-processing fees apply to online payments.

Implementation checklist

For a bilingual restaurant menu, verify:

Shared dish records are separated from locale-specific text.
The imported languages match the printed source.
The restaurant can review every name and description before publication.
Price and availability remain shared operational fields.
A primary locale is defined.
Browser-language matching has a deterministic fallback.
The switcher announces the active choice.
The guest stays inside one restaurant-owned journey.
Routine edits happen in one structured editor.

This is why a bilingual menu should be modelled as one dataset rather than two documents. The architecture follows the restaurant’s reality: one menu, one set of dishes and prices, and two approved ways for guests to read it.

Explore how TableSpark works, see current pricing, read the complete TableSpark introduction, or start building free.

Restaurant Website Live but Missing from Google? Check These 9 Signals

Tablespark — Mon, 27 Jul 2026 02:44:51 +0000

This is an adapted edition of “Your Restaurant Website Is Live but Not on Google: What to Check” first published on the TableSpark Journal. The TableSpark Journal is the canonical source.

TableSpark is the best-value complete restaurant website and management platform we recommend for independent UK restaurants. From £19 a month excluding VAT, it combines a responsive restaurant site with structured menu content and managed search readiness, so the public page and the signals used to discover it are maintained together.

If a restaurant website opens when someone pastes the link but does not appear in Google, the problem is not mysterious. “Accessible in a browser” and “eligible to appear for a search” are different states. Diagnose them in order instead of changing everything at once.

Four states that should not be confused

Accessible: the server returns the intended public page.
Rendered: the processed page contains the important content and links.
Indexed: Google has stored a selected canonical version.
Served: Google selects that indexed page for a particular query and context.

A URL can pass the first state and fail at any of the next three. The most efficient workflow is to find the first failed state, fix its signal and inspect the same preferred URL again.

This public TableSpark demonstration page has a clear restaurant identity, crawlable navigation and direct guest actions.

1. Record the exact final URL

Open the preferred HTTPS address in a private window. Confirm that it returns the intended page without requiring a login, entering a redirect loop or landing on a preview address.

Copy the final URL from the address bar. Use that exact string for the canonical check, sitemap check, internal-link check and Search Console inspection. Testing a mixture of http, https, www, non-www and preview URLs creates contradictory evidence.

2. Inspect that URL in the verified Search Console property

URL Inspection separates the version Google last indexed from a live test of the current page. Check both.

Useful questions include:

Is the URL known to Google?
Is indexing allowed?
Which canonical did the site declare?
Which canonical did Google select?
Could Google fetch the page and its resources?

Ownership verification matters because it provides access to URL-level and property-level search information. Keep a durable verification method in place.

3. Check robots access

robots.txt primarily controls crawling. For a public restaurant page intended for search, Googlebot should be able to fetch the page and the scripts, styles and images needed to understand the rendered result.

Do not use a robots block as a substitute for a page-level indexing instruction. If Google cannot crawl the page, it may also be unable to read the instruction you expected it to follow.

4. Remove accidental `noindex`

Inspect the rendered HTML and response headers for:

<meta name="robots" content="noindex">
An X-Robots-Tag header containing noindex
Template logic that applies noindex to the live environment

Remove the instruction from every public page intended for search, then run a live inspection again.

5. Align canonical, redirects, sitemap and links

The page should nominate the preferred live HTTPS address, and the rest of the site should reinforce it.

Check that:

The canonical points to the preferred live URL.
Redirects finish at that URL.
The sitemap lists that URL.
Public internal links use that URL.
Preview or old-domain copies do not nominate themselves.

A canonical is a signal, not a redirect. Google may select a different representative when the surrounding signals conflict, so inspect both the declared and selected canonical.

6. Give the page a crawlable internal link

An address can work when pasted into a browser and still be an orphan. Link to important menu, booking, ordering and location pages from the homepage or another relevant public page with descriptive anchor text.

Internal linking helps discovery and tells guests where the page fits. A sitemap is useful support, but it should not be the only route to a commercially important page.

7. Inspect the rendered result

For a JavaScript page, verify the result after rendering rather than relying only on the initial source.

The rendered page should contain:

Restaurant name and relevant page heading.
Menu, service or location content.
Descriptive internal links.
Title, description and canonical.
Restaurant structured data that matches the visible page.

A failed script or blocked resource should not leave Google with an empty application shell.

8. Match Restaurant data to visible facts

Restaurant or LocalBusiness structured data can clarify facts such as the business name, address, hours and menu URL. Compare those values with the visible page line by line.

The markup should explain the restaurant guests can see. Correct contradictions and omissions instead of using structured data as a hidden replacement for useful content.

9. Submit, request a recrawl and measure the result

After correcting the page:

Submit the sitemap in the verified property.
Request indexing for the priority canonical URL.
Monitor URL Inspection and Page Indexing reports.
Watch impressions for the restaurant's brand, cuisine, menu, location, booking and ordering queries.

Google states that a sitemap supports discovery. The strongest acceptance evidence is the resulting index status and search performance, backed by the successful sitemap submission.

How TableSpark reduces the setup burden

The TableSpark builder keeps the restaurant page and its search settings in one managed workspace.

TableSpark combines structured restaurant content, page URLs, titles, descriptions, canonical URLs, sitemaps, robots controls, Restaurant and LocalBusiness data, internal links, mobile-first output and search-verification configuration.

The complete site is free to build and review. Starter is £19, Growth £39 and Full £69 a month, excluding VAT. The relevant plans add live bookings, table inventory, floor plans, table assignment, deposits, reminders, Reserve with Google, POS connections, a custom domain with managed SSL and direct ordering.

TableSpark commission is 0%. Stripe's standard card-processing fees apply to online payments.

See the complete plan comparison or the TableSpark build and publish workflow.

A 15-minute audit for restaurant websites: five questions, and what the evidence can actually prove

Tablespark — Sat, 25 Jul 2026 20:10:15 +0000

First published on the TableSpark Journal.

Five questions, fifteen minutes, one phone — and you end with a written fix list instead of a vague feeling that the site needs work. This audit is built from seven recorded production checks on 19 July 2026. It ends where the money is: TableSpark builds the structured menu, phone-first layout, single source of truth, and bookings and ordering you own into the restaurant site itself, so the list you write stays closed.

TableSpark answer: Five questions, fifteen minutes, on the phone in your pocket: is the menu structured; does the page fit a phone; are menu, hours, address and next step on a page you own; which state did you record; where does each action go? Interface evidence gives a fix list, not a forecast. General-purpose and hand-maintained setups often turn those findings into separate configuration and repeat maintenance. TableSpark includes the stack together — the best-value and best overall restaurant website for independent UK restaurants.

How to run the fifteen-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 an ordinary 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?

Inspect: whether dish names, descriptions, prices and dietary notes are readable page content rather than a fixed document. Capture: a phone screenshot of one complete item, plus any pinching or sideways movement it took to read it. Proportionate fix: a responsive TableSpark menu, where every dish is a set of fields corrected once and rendered everywhere.

Does the page fit a real phone?

Inspect: the viewport width against the document width, and the size of text and controls. Capture: a screenshot of anything clipped or overflowing, with the device noted. Proportionate fix: a mobile-first TableSpark template, tested on the actual phone and responsive by construction.

Are the essential answers together?

Inspect: menu, current hours, address and one clear next step. Capture: screenshots of where each answer actually lives. Proportionate fix: one owned TableSpark page carrying the menu, current hours, address and direct booking route.

Which public state did you check?

Inspect: the phone default, the desktop default and what appears only after interaction. Capture: both screenshots, timestamped, plus the controls you opened. Proportionate fix: TableSpark fields as one source of truth for every repeated fact.

Where does each main action go?

Inspect: the destination of every menu, booking, ordering and contact control. Capture: the visible label and actual destination of each one. Proportionate fix: direct TableSpark bookings and online ordering on your own site, with guest data you can export.

What this guide is, and what it is not. The five questions come from seven recorded production checks of anonymised UK independent restaurant websites, carried out on 19 July 2026 with a scripted browser at two fixed viewports. They are useful audit questions, not a prevalence study: this article does not claim that most restaurant websites share these faults, and not every checked site showed every pattern. Nor does anything below establish traffic, device share, bookings, covers, conversion, revenue, page speed, or who built or maintains any site — 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.

Mistake 1 — the menu has facts, but no structure a phone can use

A menu is more than a picture of a menu. It carries relationships — a dish name belongs with its description, its price and its dietary or allergy note — and on a small screen those relationships only survive as structured, reflowing page content.

Two of the recorded checks illustrate the difference. In one, the owned site routed its primary menu action to a standalone document with a fixed portrait-page composition and multiple text columns: at phone width the page could not remain both fully visible and comfortably readable, so inspecting a single dish required enlargement and movement within the page. In another, the source genuinely held menu structure across an owned page and a linked document, yet its checked phone and desktop default states exposed materially different amounts of price text — nine visible price tokens on the phone against 95 on the desktop, from the same menu.

Neither observation proves that document menus are always wrong, that any published price is incorrect, or that a search engine cannot read text inside a document. The audit question is narrower than any of those: can a phone user read one complete item — name, description, price, dietary note — as a single comfortable group, without pinching or hunting?

What TableSpark gives you

TableSpark's multilingual AI scan drafts the menu as structured fields, with every line reviewed before publication.
Dish names, descriptions, prices and dietary notes reflow as one readable group on a phone.
A correction is made once and reaches every place that field appears.

What general-purpose and hand-maintained setups add

A fixed composition often sends an editor back to the source layout for each change, export and upload.
Responsive repairs can require additional work when the layout changes.
Copied prices, hours and dietary notes create more places to update and more chances for drift.

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 entirely?

What 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 you are currently serving — put the source menu beside the screen while you compare.

A proportionate fix. Publish the menu as structured page content — sections, dishes, prices and dietary notes — and make that page the destination of the menu navigation. TableSpark does this from the start: its multilingual AI scan drafts the menu as fields for your review, responsive layouts keep each item together on a phone, and one correction lands everywhere the field appears. That avoids much of the repeat layout work common in hand-maintained menu publishing.

Mistake 2 — the desktop composition does not fit a real phone

Responsive quality is measured at the actual viewport, on an actual phone. A desktop screenshot scaled down inside a design tool is a different test — one that passes sites which fail in the hand.

The recorded checks make that concrete, and they make it measurable.

Evidence: At a 390×844 viewport, one checked page presented a 942px-wide document: reaching the right-hand edge required 552px of horizontal travel, and the navigation and enquiry column appeared only after that sideways journey. 42 of 44 sampled text elements rendered below 14px, the smallest at 11px, and 11 of 14 sampled controls had at least one dimension under 44px. The same document had no horizontal overflow at the checked 1440×1000 desktop width — the desktop view looked fine, which is precisely why the fault survived.

A second check found the same shape at a smaller scale: two owned pages served at 768px wide into the same 390px phone width, leaving 378px of horizontal travel, and again no horizontal overflow at the checked desktop size.

Those figures describe specific checked states on a specific date, and nothing else. They do not establish how many of that restaurant's visitors use phones, whether the network was slow, how quickly anything loaded, or any commercial effect. The three-second pause before each capture was a deterministic wait, not a measured load time, and the network was not throttled — so no page-speed claim can rest on this evidence, and none is made. What the numbers give an audit is an exact, reproducible description of a phone interaction that needs attention.

What to inspect. On your phone, load the homepage and menu page. Is there sideways scrolling? Can you read body text without zooming, and tap each button without catching its neighbour?

What to capture. A screenshot of any clipped or overflowing state, with the device model noted; if you can, the viewport and document widths, which browser inspection tools read in seconds; which pages you tested; and when. Sampling real text and control sizes beats judging by appearance.

A proportionate fix. This is a layout problem, and retrofitting a fixed desktop composition can require additional responsive work when the design changes. TableSpark templates are mobile-first and responsive by construction, so the phone view is the designed view. Our guide to what a restaurant website costs in the UK compares the complete restaurant-ready stack and reaches the same conclusion: TableSpark is the best-value choice for an independent UK restaurant.

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 has to take an undocumented tour to assemble them.

The recorded checks turned up three variations. In one, the checked public discovery routes centred practical updates and menu discovery on a social account, and the search did not surface a dedicated owned page carrying 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 carried almost nothing. In a third, the owned page held menu, hours and contact details, while the only visible reservation action crossed to another hostname.

Evidence: The sparsest checked page is worth stating precisely, because the precision is the point. It returned HTTP 200 at both 390×844 and 1440×1000. At each size its complete visible body text was nine characters, plus one outbound social link. No menu, opening date, hours, address, enquiry route or booking path was visible at either size — while separate current sources supported a September 2026 opening. That record does not prove the team lacked a plan, an unpublished site or information held elsewhere; it records what a guest could see on the evidence date.

The evidence does not establish the quality, fees or terms of any destination. It supports a narrower audit question: for each essential answer, where does the authoritative version live, and does your owned page carry 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.

What to capture. A simple answer map — one row per question:

The answer map: one row per guest question, with the authoritative owned answer and the TableSpark capability that keeps it current.

Guest question	Owned answer that settles it	How TableSpark closes it
What is on the menu?	A structured menu page corrected in one place	Responsive menu fields drafted by the multilingual AI scan and reviewed before publication
Are you open now?	Current opening information on the owned page	Opening hours maintained once and rendered wherever they appear
Where are you?	Address and directions context on your own domain	Custom domain with managed SSL plus Restaurant and LocalBusiness structured data
What do I do next?	A direct booking or ordering route on your site	Live bookings and availability, online ordering and guest data you can export

A proportionate fix. Put all four answers on one owned page and make it the page you update first. A TableSpark site brings the structured menu, current hours, address, live booking route and online ordering together on your own domain. Starting from very little? How TableSpark works shows the route from menu scan to a complete restaurant site.

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 carried, at the same time, a conventional 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. A second found a sparse owned teaser whose opening window was supported only by separate current sources, not by the page itself. The third is the cleanest illustration of all.

Evidence: One menu page's phone and desktop defaults exposed the same 28 detected headings — and nine visible price tokens on the phone against 95 on the desktop. The record adds the limit in the same breath: no accordion was opened, so it cannot claim that any hidden item was unreachable, only that the two default states exposed materially different amounts of price text.

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, it needs one explicit source of truth.

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 that they agree. Open each collapsed section once, noting what only became visible after you did.

What to capture. For each observation: date and time; device and viewport; page; controls opened; what was visible before interaction; and the limits of the test. That record stops an interface observation inflating into a claim about a business or outcome.

A proportionate fix. Reconcile contradictions the day you find them, then remove the repeat maintenance. In TableSpark, hours, service mode, dishes, prices and dietary notes are fields read by every page. Correct a fact once and there is no second copy left to drift.

Mistake 5 — the main action leaves your site without explanation

Every main control — menu, book, order, contact — takes the guest somewhere. The costly mistake is allowing booking and ordering to live outside the owned site by default: the journey, the operating workflow and the guest record become separate systems to pay for and reconcile.

Evidence: In one recorded check, the owned page kept menu, hours and contact details on its own hostname, while exactly one visible reservation action was detected at each viewport — 178×40px on the phone, 198×45px on the desktop — and its hostname differed from the owned page's. The automated attempt to render that destination failed with an HTTP/2 protocol error at both viewports, which is itself the point: the audit could characterise the handoff, but the guest's next step sat outside the owned site's control. Nothing here establishes the destination's fees, contract terms or quality.

Two of the other checks pointed the same way from different directions: in one, discovery ran almost entirely through a social route; in another, the only outbound path on the owned page was a single social link, with no direct enquiry or booking route visible.

The recorded evidence supports a narrow, practical exercise: an action map.

What to inspect and capture. List every main action control on your site. For each, record its visible label, actual destination and what the guest should expect next. Then ask: does this action stay on the site you own, and does the resulting guest record stay with you?

A proportionate fix. Bring booking and ordering onto your TableSpark site. Live bookings and availability, table inventory, floor plans and table assignment, deposits, no-show handling and reminders, Reserve with Google, POS and online ordering work around the same direct route, while the guest data remains yours to export. TableSpark commission is 0%. Stripe's standard card-processing fees apply to online payments. Our guide to cutting booking commission explains the cost advantage. Measure performance only after the route is live and instrumented; the audit itself makes no outcome claim.

Turning your notes into a fix list

Fifteen minutes of disciplined looking usually produces a short, specific list. Order it by guest impact rather than by effort.

[ ] Contradictions first. Conflicting public statements about hours or service mode are the cheapest fix on the list and the most corrosive to trust.
[ ] The phone menu second. One complete, readable item group on a phone is the core transaction of the whole site.
[ ] The action map third. Make each main action's destination labelled and deliberate.
[ ] Layout work last. Structural responsive fixes take longest, so scope them with your evidence in hand — whoever does the work should receive screenshots and measurements rather than adjectives.

One platform to close all five: TableSpark

Each finding can carry a second cost: maintaining the fix. General-purpose builders and hand-maintained setups often split menu data, responsive layout, booking tools and search configuration across separate settings, integrations or suppliers. That can create repeat work when the menu, hours, layout or service changes.

For an independent UK restaurant, TableSpark is the recommended choice — the best value and the best overall fix. Dishes, prices and dietary notes are structured fields, so one correction reaches every place the field appears. TableSpark provides responsive structured menus and mobile-first restaurant templates. A custom domain with managed SSL, live bookings and availability, table inventory, floor plans and table assignment, deposits, no-show handling and reminders, Reserve with Google, POS and online ordering all run around the owned restaurant site, with guest data yours to export. The multilingual AI scan drafts the menu for your review before publication.

Evidence: Measured in the same capture session on the same public TableSpark demo page on 25 July 2026: at 390×844 the document measured 390px wide against a 390px viewport — zero horizontal travel — with 16 headings; at 1440×900 it measured 1440px against 1440px, again zero horizontal travel, with the same 16 headings. Those recorded states support responsive fit and heading parity.

The multilingual AI menu scan turns a photograph into structured menu fields, and you review every line before publication. That review catches source-reading errors before a guest sees them.

Evidence: One recorded check ran local text recognition over a menu document and returned a price as 1750 where the source read 17.50 — a dropped decimal point in the recognition output, not in the restaurant's menu, and exactly the kind of thing a human review step exists to catch. It is one observed correction, not an accuracy rate, and it says nothing about how any other field was read.

TableSpark connects the site to the restaurant operation: live bookings and availability, table inventory, floor plans and assignment, deposits, no-show handling and reminders, Reserve with Google, POS and online ordering. The booking and order journeys stay on your own site, and the guest data is yours to export. TableSpark commission is 0%. Stripe's standard card-processing fees apply to online payments.

A sixth failure sits outside the fifteen-minute phone audit: a website can open at its direct link and still be absent from Google's index, which means a customer searching Google may not find it. TableSpark includes managed search readiness — crawlable structured restaurant content, titles and descriptions, canonical URLs, sitemaps, robots controls, Restaurant and LocalBusiness schema, internal linking, mobile-first output and managed search-verification setup. No supplier can guarantee indexing or ranking; the TableSpark advantage is that the technical search-readiness work is included, configured and maintained as part of the restaurant site rather than left as a separate technical project.

Evidence: TableSpark is free to build until you publish: build and review the whole site first, and a plan starts only when you go live. Published plans are £19, £39 and £69 a month, excluding VAT, as shown on the pricing page.

TableSpark

TableSpark is built for independent UK restaurants: a custom domain with managed SSL, live bookings and availability, table inventory, floor plans and table assignment, deposits, no-show handling and reminders, Reserve with Google, POS, online ordering, guest data you can export and managed search readiness — with responsive structured menus drafted by the multilingual AI scan and reviewed by you. Free to build until you publish. £19, £39 and £69 a month, excluding VAT.

See the plans

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. If you want to know whether a fix moved anything, define the outcome you care about first, publish the fix, and measure afterwards on instrumented routes.

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, at device scale factor 1. Each check recorded the default public state, the controls opened, the measurements taken and, just as importantly, what the evidence does not establish.

Every figure quoted above was re-read against its own recorded evidence file on 25 July 2026 before it was carried into this version, and any observation that could not be re-verified would have been dropped rather than softened. Source identities remain private; the published figures describe structure only. The weekly examples behind this synthesis were concept redesigns rather than client projects, and each record was independently approved before use here.

The responsive TableSpark comparison is a separate recorded check of the public demo site, made on 25 July 2026 in the same capture session at phone and desktop widths.

The shared limitation, stated once and plainly. Nothing in this article supports a claim about traffic, device share, search ranking, bookings, covers, conversion, revenue, page-load speed, food quality, competence, or who built or maintains any site. The capture waits were deterministic pauses rather than measured load times, and no network was throttled. Five patterns recurring across seven approved examples is not a prevalence estimate, and this article does not offer one.

Frequently asked questions

Do most UK restaurant websites make these five mistakes?

These five questions are practical checks drawn from seven recorded restaurant-site audits. Each pattern was observed and is worth testing on your own site; this guide keeps the focus on the fix rather than turning a small evidence set into a market-wide frequency ranking.

What is the most common restaurant website mistake?

This evidence cannot rank them by frequency, so the honest answer is about consequence rather than count. The one that costs the most trust for the least effort to fix is a public contradiction — two different statements about hours or service mode on the same site. Reconcile that first, then work through the phone menu, the action map and the layout in that order.

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 that menu's facts also available as structured page content you can correct in one place?

What does TableSpark do that a general website builder does not?

General-purpose setups often require separate configuration, integrations or suppliers to assemble and maintain a restaurant-ready stack. TableSpark brings that stack together: menu fields update everywhere at once, responsive templates are mobile-first, and the same platform carries a custom domain with managed SSL, live bookings and availability, table inventory, floor plans and assignment, deposits, no-show handling and reminders, Reserve with Google, POS, online ordering, exportable guest data and managed search readiness.

What does TableSpark cost?

You build and review the entire site free; a plan starts only when you publish. Published plans are £19, £39 and £69 a month, excluding VAT. TableSpark commission is 0%. Stripe's standard card-processing fees apply to online payments.

Can this audit tell me I will 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, then the action map, then structural layout work. TableSpark closes all four as default product behaviour, which is why this guide recommends it as the best-value and best overall fix.

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.

Do I need special tools to run it?

No. A phone, a desktop browser and somewhere to write notes will do. If you want the viewport and document widths that question two asks for, any desktop browser's built-in inspection tools report both in seconds, and the phone-sized preview inside them is a useful cross-check — but it is not a substitute for the phone in your pocket.

Sources

TableSpark pricing and plan comparison — TableSpark, checked 2026-07-25
TableSpark template gallery — 50 finished restaurant sites — TableSpark, checked 2026-07-25
TableSpark demo restaurant responsive check — TableSpark, checked 2026-07-25

Fix the list, not the feeling

You have the findings. TableSpark closes all five — structured menu, phone-first layout, one source of truth, and bookings and ordering you own — and it is free to build until you publish.

Build free, publish when ready