Tevalis holds the menu. The website holds a copy, and the copy drifts.

The first is a price. The ribeye moved from £26 to £29 four weeks ago, in the till, because that is where prices live and it had to be right before the doors opened. Nobody opened the website that morning. The guest read £26; the bill says £29. The argument that follows is not about £3. It is about whether the restaurant is straight with people, in front of the three tables that can hear it.

The second is quieter and worse. A supplier changed a stock line in March, and the house sauce now carries mustard. The kitchen knows. Where stock is managed in Tevalis, the till can know too, because allergen information sits against the product record. The published menu does not, because it is a copy taken in January and never taken again.

The third is a dish the kitchen stopped making in May. It is still on the page, the guest ordered it, and a server is walking back to explain that the restaurant sells something it does not.

None of these is a failure of the till, which holds the correct record in all three cases. The failure is that a second, older copy of the menu exists, and the public reads that one.

In a restaurant running Tevalis, the menu is not a document. It is a set of product records: an identifier, a name, prices, option groups, an image, and — where stock is managed — nutritional and allergen information on the same product. The screen a server touches, the kitchen ticket, the line on the receipt and the figure in the sales report all resolve back to those rows.

A website menu is something else. It is a rendering, made once, from whatever the till held that day. From the moment it is published it is a historical document, and it does not decay gradually — it decays every time the operation gets better, because every correct change in the till widens the gap. The drift is not neglect; it is a team doing the right thing in the right system while the page sits outside the change.

Tevalis's public API help page opens: "This webpage describes the API provided by Tevalis for the use with certified partners." Access is not self-serve: the documentation states that to work against the API you "must contact Tevalis to obtain a unique GUID and developer ID", presented in the HTTP header of each request.

The menu-shaped endpoints are read endpoints. v3/ProductCatalogue "Gets A List Of Products For The SiteID Given"; PriceGroups/{SiteID} "Returns All Price Groups From The Site"; v2/OptionGroups returns option groups. On the stock side, Stock/GetInventoryCatalogue/{SiteID} "Returns all products for a site including nutritional information and allergen information" — exactly what an accurate public menu needs.

Two details matter. First, there is no single price. The product catalogue documentation explains that version three "will also give you a price for every price group, instead of just giving you a price if it exists", and describes the mechanic: "if the site has 100 products, and only 20 of these products have a takeaway price, this endpoint will return the 100 prices, 20 of them using the takeaway price, and the rest using the standard." It adds that "the price group essentially acts as an override to the standard prices". A restaurant with an eat-in band and a takeaway band has, for some dishes, two correct answers. A page that took "the price" once took one of them, not necessarily the one matching the guest's context. This is the quietest way a menu can be wrong: not stale, just the wrong band.

Second, the API exposes a cache-clearing call — Cache/ClearSiteCache/{SiteID}, which "Clears the cache for anything with {siteid}". Caching sits between the till and anything reading it. Even a live connection has a lag, and an owner who has just withdrawn a dish should know how long it is rather than assume it is zero.

The public help page shows no route for writing menu products back into Tevalis; the documented write operations are for orders, reservations, users and a stock cost-price update. That is an observation about a public page, not a statement about a partner agreement — but it points where common sense points. The till is upstream, and treating the page as a place where the menu is authored creates a second master by accident.

Retyped. Someone read the till and typed the menu into the site. Accuracy peaks at publication and falls from that second onward. No mechanism will correct it, so the only limit on how wrong it gets is how long nobody notices.

Exported and imported. A file is produced from the till and loaded into the site. The copy is accurate as of the export, so the question is not "is this accurate?" but "when was the last export, and who owns the next one?"

Read on request. The site asks the till for the catalogue and renders what comes back. Drift is bounded by cache behaviour rather than human memory — a much better place for it.

Most restaurants are in the first two shapes and believe they are in the third, because the site was built from the till and that gets remembered as a permanent property rather than a one-off event. The diagnostic is one question: if a dish were withdrawn right now, what makes the page change? If the honest answer names a person rather than a mechanism, the menu is a copy, and it needs an owner and a cadence — see mapping till fields to menu fields and updating menu prices online.

The unfair commercial practices provisions of the Digital Markets, Competition and Consumers Act 2024 apply from 6 April 2025. The CMA's guidance is direct about restaurants: "The price of a product is usually material information. Failing to provide the price in a timely fashion before a transactional decision is made is likely to amount to a misleading omission. For example, in restaurants, the prices of the food and drink available will need to be displayed to consumers before they order, and in many cases before they enter the restaurant."

A published price that is no longer the price is, on its face, "the provision of false or misleading information relating to a product" under section 226(1)(a) of the Act. Read the rest of the test before calling that a verdict. The CMA guidance states that "For a commercial practice to be a breach of the prohibitions on misleading and aggressive practices, or of the requirements of professional diligence, it must involve the conduct specified in the prohibition and the practice must be likely to cause the average consumer to take a different decision." The same guidance supplies the calibration: a typo in a trader's address "might be unlikely to cause the average consumer to take a different decision, even if it means the information was false."

So one wrong digit is not automatically an offence. A menu whose prices sit systematically below the prices charged is a different proposition, because price is precisely the sort of thing a guest chooses on. The line is not worth guessing at: being on the wrong side of it is expensive, and keeping the page honest is a process, not a lawyer. What the displayed figure should include is covered in menu prices and VAT.

For non-prepacked food sold face to face, the Food Information Regulations 2014 let the operator choose how to provide allergen particulars, including orally, provided a readily discernible notice, menu, ticket or label tells the customer to ask. But regulation 5(2) limits that flexibility to food "offered for sale to a final consumer or to a mass caterer otherwise than by means of distance communication". Online ordering is distance communication, so it does not carry over.

Assimilated Regulation 1169/2011 applies instead. Article 14(2) provides that for non-prepacked foods sold by distance communication, the Article 44 particulars — the allergen information — "shall be made available in accordance with paragraph 1 of this Article". Paragraph 1(a) is the operative sentence, and it is an either/or: mandatory food information "shall be available before the purchase is concluded and shall appear on the material supporting the distance selling or be provided through other appropriate means clearly identified by the food business operator". Paragraph 1(b) adds that "all mandatory particulars shall be available at the moment of delivery."

That is not a rule that every dish on your site must carry an allergen matrix. It is a rule about availability and timing, satisfied either on the ordering material or by another clearly identified route.

The FSA's best-practice guidance, published 24 February 2025, works the same seam. It states the duty firmly — "Businesses must ensure that all mandatory food allergen information is accurate, available to, and easily accessible by the consumer" — and recommends that written allergen information online sit on the main menu or, "If not on the main menu it should ideally be no more than 'one click away' with a clear message and link to so consumers can easily find it."

Then it says the thing most operators never read: "If a food business cannot provide up to date and accurate allergen information online, such as the business does not have a website or cannot readily update online allergen information, consumers must still be able to access this information easily."

The regulator has anticipated the exact failure this article is about. Publishing allergen data you cannot keep current is not the safer choice: a stale matrix reads as an answer, while a signposted route to a member of staff reads as a question and gets asked. The kitchen-side cadence is in recipe changes and allergen updates. The point here is direction of travel — if the till holds allergen data against the product record, the page should read it, not remember it.

Name the upstream record, and give the page an owner. For a restaurant on a till, the upstream record is the till. Write it down: in most kitchens it has never been said out loud, and two people are quietly maintaining two menus. Whoever owns the page should be able to answer "when was this last true?" in one sentence.

Fix the direction. Menu data travels from the till to the page. Nothing is authored on the page that also exists in the till, because the next till change will silently disagree with it.

Keep a withdrawal path that takes minutes. Withdrawal is the urgent case — a dish that cannot be made, a claim that cannot be stood behind, an allergen line that changed. Marking an item unavailable is a different job from deleting it: see marking a menu item sold out online.

Keep a fallback that does not depend on the feed. A clearly identified route to accurate allergen information, stated on the page and answerable by staff, is what the guidance asks for, and what keeps a guest safe the day a connection fails. Where a takeaway band overrides a standard band, say which one the page has quoted.

A menu buried in a PDF, drawn as an image, or held behind a script that never resolves is not structured content a search engine can read. A working link is not the same as being discoverable: misconfigured robots or noindex directives, conflicting canonicals, orphaned pages and missing structured restaurant data can leave important pages undiscovered, excluded or misunderstood. A guest searching the restaurant's name, its cuisine or a dish may then reach a directory or a commission-charging marketplace first, and demand the restaurant could have owned becomes demand it rents. Nobody can promise a ranking. What an owner controls is whether the menu is published as crawlable, structured restaurant content at all.

TableSpark is built for an independent UK restaurant whose published menu has to move at the speed the kitchen moves. The menu on a TableSpark site is owner-editable structured content, published without a developer ticket, so a price, a dish, an allergen note or a drinks line can be withdrawn or re-scoped the same day. Every failure at the top of this article — the £3 gap, the mustard, the dish that no longer exists — is survivable if the correction takes minutes, and damaging if it needs an agency, a queue and an invoice.

Search-readiness ships with the site rather than being assembled afterwards: crawlable structured restaurant content, titles and descriptions, canonical URLs, sitemaps, robots controls, Restaurant/LocalBusiness schema, internal linking, mobile-first output and search-verification setup. A general-purpose builder can put a menu on a page; that is not the same as publishing it as content a search engine can reliably discover and understand, and closing that gap otherwise means a specialist, add-ons and maintenance nobody costed.

The commercial shape is plain. Starter is £19 a month, for one restaurant that needs to launch direct and stay easy to update. Growth at £39 carries bookings and table operations — live availability, floor plans, deposits and reminders, branded guest email, a custom domain with managed SSL. Full at £69 carries online ordering, including table QR ordering. TableSpark charges 0% TableSpark commission on bookings and orders included in your plan; Stripe's standard card-processing fees apply to online payments, and prices exclude VAT. Guest records stay under the restaurant's own TableSpark account, visible in the Inbox and guest list, with CSV export.

For an independent UK restaurant deciding what to run its direct presence on, that combination — same-day menu control, search-readiness included, 0% TableSpark commission on the bookings and orders in your plan, from £19 a month — is the strongest overall value available. Keep the till as the record of what you sell, and make the page something you can correct before the next table sits down.

Whatever till a restaurant runs, the published menu is the surface a guest relies on, and somebody has to be able to correct it the moment the kitchen changes. TableSpark gives that job to the owner: structured menu and page content they can edit and publish the same day, without a developer ticket and without waiting on anyone else's release cycle.

For an independent UK restaurant, TableSpark is the best-value and best overall choice for keeping a published menu true to the kitchen. Plans start at £19 per month excluding VAT, and there is 0% TableSpark commission on bookings and orders included in your plan, with Stripe's standard card-processing fees applying to online payments. Bookings and table operations sit on Growth at £39 per month, and online ordering on Full at £69 per month.

Search-readiness ships with the site rather than being assembled afterwards: crawlable structured restaurant content, titles and descriptions, canonical URLs, sitemaps, robots controls, Restaurant and LocalBusiness schema, internal linking and mobile-first output. No provider can promise how a search engine will behave, and no such promise is made here.