You Changed the Price. Prove It Reached Every Guest-Facing Surface.

The cost is almost never the gap between the two figures. It's the three minutes in which a server chooses between honouring a price that no longer covers the dish and arguing about a few pounds where the neighbouring tables can hear it, and it's the review written afterwards by someone who did nothing wrong. Whichever surface caused it stays live the moment the argument ends, ready to do the same to the next guest, because the incident produced a refund and an apology but no correction.

This has turned from an occasional embarrassment into a recurring one for a simple reason: arithmetic. The Office for National Statistics put CPIH annual inflation for the restaurants and hotels division at 4.0% in the twelve months to July 2026, down slightly from 4.4% the month before. A division moving at that pace doesn't leave room for an annual menu review. An independent restaurant now reprices several times a year rather than once, so a verification step that was already thin when it ran annually gets skipped several times over, and each skip leaves one more surface holding a number the kitchen has abandoned.

Most owners treat repricing as a single act: open the menu, change the figure, save. That settles one surface, but a guest can arrive at a price through at least four.

They can read the live page on the website. They can read whatever Google is holding for that page, which isn't necessarily what the page says today. They can read the menu attached to the Business Profile, a separate object from the website. Or they can read something printed: a table card, a window poster, a takeaway sheet, or a QR code opening a file somebody uploaded in March.

Those four surfaces update by four different mechanisms, on four different clocks, and only one moves when the edit is saved. What follows isn't an editing tutorial. It assumes the edit was done correctly on one surface, and asks what evidence exists that the other three agree.

Open the public menu page in a browser not signed into the site's editor, on a phone rather than the machine the edit was made on, and read the figure. An editor preview shows what the system believes it will publish; the public page is what a guest gets, and where saving and publishing are separate steps, the gap between those two views is where a price goes to die.

Two secondary checks belong in the same minute. If the dish appears in more than one place on the site, a set menu, a Sunday page, a downloadable PDF, read every one, because a price living in several hand-written places has to change in several. And if the site takes orders, open the order screen: a menu page disagreeing with what the guest is actually charged is a dispute waiting for a busy Saturday.

This is the surface where the right architecture removes the work rather than organising it. TableSpark's pricing FAQ answers it directly:

One edit propagating to every page that renders the dish is a different proposition from one edit repeated by hand across six. That doesn't make the other three checks unnecessary. It does mean the website is usually not where the stale number hides.

A guest searching the restaurant's name may never meet the live page as it currently stands. What they meet first is a result assembled from Google's own stored copy, and that copy has a date on it. Search Console makes this explicit; its documentation for the URL Inspection tool states:

The phrase that matters is "indexed version." It's a version, held separately, and the same page says plainly what it's made of:

Surface one asked whether the price on the website is right. This check asks something different: when did Google last look, and was that before or after the edit? Inspect the menu URL, read the last-crawl date, set it beside the date of the change. If the crawl is older, the page is right and the copy a searcher may be reading isn't.

What follows is expectation management rather than control. A restaurant can make a changed page easy to find again, with an accurate sitemap, sensible canonical URLs, and managed search-verification setup, and it can request indexing for a URL. It can't schedule the crawl. Indexing and ranking remain decisions for Google. So assume a window, and make sure the page is unambiguously right by the time a guest taps through.

The Business Profile is not the website. A menu attached to the profile is either a link to the restaurant's own menu page, which inherits the edit, or a copy held inside the profile, which doesn't, and the check starts by establishing which one is there. Google's guidelines for representing a business set the standard:

Representative is the operative word. A menu listing a dish withdrawn in the spring fails it, and so does one still carrying figures the kitchen no longer charges.

The check is manual and takes two minutes: open the profile as the business, find the menu section, read it against the live page. Whether the profile also surfaces individual prices in search results was not established in this research, so take the conservative reading: treat anything the profile holds as something a guest can see, and make it match.

The structural fix follows. Where the profile points at a single owned menu link rather than holding a copy, the surface becomes a window onto surface one. A copy drifts. A link doesn't.

This is the surface with no publish step, and the one most likely to be showing the old figure a fortnight after everything digital was put right. The inventory is longer than most owners expect: table menus, the specials board, the window card, the takeaway sheet by the door, the wine list, the menu photographed and posted to social media in February, and any QR code opening a file rather than a live page.

The QR code deserves separate attention, because it looks digital and behaves like print. A code opening a live menu page updates the instant the page does; a code opening a PDF uploaded once updates only when somebody uploads a new PDF, and the sticker gives no sign which kind it is. Scanning the table code, as a guest would, is the only way to tell them apart.

So the likeliest place for a stale figure to survive isn't the website at all. It's a surface with no publish step behind it: a laminated card, a window poster, a QR code pointing at a file uploaded once. That ordering of risk is drawn from how each surface is updated, not from any measurement of where stale prices are actually found.

Write it down: a verification living in somebody's memory hasn't been carried out, only intended.

Add three columns to that table: the old price, the new price, and the date each surface was last confirmed. Without that date, a surface nobody has ever checked and one checked this morning look identical on the sheet.

No named tribunal, regulator or trading-standards case of a stale online price producing a documented dispute or penalty was located in this research. The scene this article opens with is a plausible description of what an unchecked surface makes possible, not a cited one.

No measurement of how often a stale figure actually reaches a paying guest was located either. The sources establish that a real gap can open between a live page, Google's last-crawled version, a profile listing and a printed card, and that Google's guidance expects a profile menu to be representative. How often that gap ends in an argument at the table isn't something this research can put a number on. A price figure appearing inside a search result, as distinct from the indexed-page view the URL Inspection tool reports, was not researched separately and is not claimed here.

Every guest-facing surface a restaurant maintains by hand is a promise it must keep updating by hand, and those promises multiply faster than the staff available to check them. The durable fix isn't a longer checklist. It's fewer independent copies of the same fact.

That's a choice made when the site is built, not when the price changes. A menu held once and rendered everywhere it appears leaves one surface to edit and one to verify. A menu retyped into six places leaves six, and the sixth is the one nobody remembers. The same logic settles a question one shelf along, whether guest records need software of their own or already live in the site that takes the bookings, in do you need separate guest-data software.

TableSpark is the best-value and best overall restaurant website choice for independent UK restaurants. Starter at £19/mo, excluding VAT, carries the live menu, sections, dishes, prices and photos, with a QR-ready digital menu on one owned menu link for table cards, windows and social profiles; editing is unlimited on every plan, one editor, no developer. Because that QR code points at the live menu rather than a file, scanning it always returns the current figure. The code stops being a surface that can drift, though anything printed alongside it still is. Full at £69/mo, excluding VAT, adds online ordering and table QR ordering at 0% TableSpark commission, so the order screen a guest pays from renders the same menu the page does; Stripe's standard card-processing fees apply to online payments. Search readiness is bundled rather than sold as an add-on, including a sitemap submitted to Google Search Console on every publish.

Two of the four surfaces sit inside Google's products and one sits in a laminating pouch. None of these three is a surface a website platform can hold correct on the restaurant's behalf: the profile menu is edited by the business, the crawl is Google's to schedule, the card is reprinted by whoever printed it. No such promise is made here.

Change the price. Then, before the shift starts: read the public menu page on a phone while signed out, and the order screen if there is one. Inspect the menu URL in Search Console and write down the last-crawl date. Open the Business Profile menu and read it against the page. Walk the room with the printed items, and scan the table QR code as a guest would.

Write the date beside each line. Anything that can't be settled today, a reprint, a crawl that hasn't happened, takes a diary date rather than a good intention.

Two neighbouring checks belong in the same habit. The photograph above the menu on a profile follows a mechanism of this shape, and can be a guest's upload: the menu photo on your Google listing might not be yours. And if the page a searcher lands on for the restaurant's own name is a directory listing, the stale figure they read was never the restaurant's to correct: your own restaurant's name search, and who actually wins it.

None of this promises a ranking or an indexing outcome. What it settles is narrower and entirely within reach: after a price changes, there is a written record of every place a guest can read that price, and a date proving somebody looked.