How to Keep Your Restaurant Website Menu in Step With Zettle

The quieter versions happen weekly. A price rises 60p at the till in March and the site still quotes February in June, so the floor chooses between honouring a price the business no longer charges and arguing at the pass. A dish is 86'd on Friday and the order form takes three more.

None of that is a website problem or a till problem. It is a two records, no owner problem — and here is how to end up with one place each fact is edited.

The allergen line is the serious one. The Food Standards Agency's best practice guidance for non-prepacked foods says at paragraph 57: "The allergen information provided to consumers must be accurate. This is a legal requirement as well as being vital to ensure the safety of consumers." Paragraph 58 adds the operational duty — businesses "should have procedures in place to ensure that their allergen information is accurate and up to date at all times."

Its scope is narrower than it looks. The guidance says of itself: "You are not required by law to follow best practice guidance." Paragraph 23 draws the line — the written-information-plus-conversation approach "represents a change in best practice", while "the minimum legislative requirement for information to be provided by any means (with a sign indicating when it will be provided verbally) has not changed." The law requires that the information given is accurate; how it is presented is where the guidance leaves room.

For anything ordered at a distance, paragraph 46 expects written allergen information "both before the food is ordered and when it is delivered", and paragraph 47 says a business publishing it on its own webpage "could place this on the main menu. If not on the main menu it should ideally be no more than 'one click away'". Note the hedges — could, should ideally: not a layout specification, and no website structure has been certified compliant.

Descriptions carry their own exposure. Assimilated Regulation (EU) No 1169/2011 requires at Article 7 that "Food information shall not be misleading, particularly: (a) as to the characteristics of the food", and that it "shall be accurate, clear and easy to understand for the consumer"; Article 8 puts the duty on the operator whose name the food is marketed under, who "shall ensure the presence and accuracy of the food information". Domestically, section 15 of the Food Safety Act 1990 makes it an offence to give with food a label that "falsely describes the food" or "is likely to mislead as to the nature or substance or quality of the food", and section 15(4) closes the obvious defence: an accurate statement of composition elsewhere "shall not preclude the court from finding that the offence was committed." Two honest limits go with that. No decision was found holding that a restaurant's own website menu page is an "advertisement" under section 15(2) — open, not settled. And section 35(2) states maxima only; no penalty figure attached to a menu description was located.

Drinks lists carry a quirk worth settling before you digitise one. Article 5(1)(c) of the Weights and Measures (Intoxicating Liquor) Order 1988 requires a written statement of the quantities wine is sold in, and it is disjunctive: "either displayed on those premises ... or is contained in every winelist and menu which is available to the buyer on those premises before the sale is made". A notice on the premises satisfies it alone. Note where that leaves a website: the second limb reaches only a list available "on those premises", so a wine list read on a phone before arriving sits outside it. Whether an on-premises screen — a tablet at the bar, a QR list at the table — can instead be a statement "displayed on those premises" under the first limb is not settled here. Either way, guard the printed list: retiring it can remove the very thing that was satisfying the article.

The GB site carries the line "Zettle by PayPal becomes PayPal Point of Sale." Support articles and the developer portal use both names, so search both.

The developer documentation is plain: a product "is a synthetic construct, wrapping one or more variants, which is the actual item being sold (SKU)" — up to 99 variants across three option definitions at most. There is one library per business: "A merchant organisation only has one product library with Zettle."

That library is a record of things you can ring up: name, description, price and cost price in minor currency units, a VAT percentage, a tax-exempt flag, barcode, SKU, category and one optional image. It is an excellent record of what the till sells for how much, never meant to be a menu — the till's job ends when the sale rings through, so dish copy, provenance and allergen matrices are not its fields.

The spreadsheet route makes the boundary concrete. An export from Products on my.zettle.com has template columns Name, Custom unit, VAT, two Option Name/Value pairs, Price, Cost price, Barcode, SKU, In stock, Category, Variant ID and Product ID — and "There is no support for uploading images." No description column, no allergen column: the sheet will not carry your menu copy.

The commonest way a menu integration rots is matching on the dish name. A capital letter, a suffix, a size split — the moment one side moves, the link breaks silently, nothing in the logs.

Zettle gives you a stable key instead: "every product and product variant must have a unique UUID." The import help is blunt about why they matter — "Do not change the Product ID or Variant ID either as we use these details to update existing products in your library." Store both UUIDs against every item on the website and match on those. The guarantee is scoped to one merchant organisation, so a UUID is unique within your own library, not globally.

Two mapping details save grief:

Event-driven, if you can. Per the developer docs, "your application can get notified about changes in the product library. You can create a webhook subscribing to product library-related events." Three product events are documented: ProductCreated, ProductUpdated and ProductDeleted each fire when the change is made "from Zettle POS or the app". The notification is a POST whose envelope carries organizationUuid, eventName, messageId, payload and an ISO-8601 timestamp. Inventory events sit alongside them — InventoryBalanceChanged, InventoryTrackingStarted, InventoryTrackingStopped — which is where a sold-out dish coming off the menu would be driven from.

Fetch and replay, as the safety net. Webhooks get missed. "The entire product library can be fetched through the library endpoint, where each consecutive change applied to the library is available. Once the full library is retrieved, only later events needs to be fetched." Two published figures shape the schedule, both worded as recommendations: keep the library "below 10,000" items, and "not exceed 150 requests/10 seconds". A nightly reconciliation catches events you dropped.

Writing back, carefully. If the website will ever push into the library, use the conditional update. The API "supports conditional requests" through an ETag header: the server updates "only if it doesn't have an ETag matching the one provided", otherwise returning "a 412 (precondition failed) response with an empty body". That stops a website save overwriting a price a manager set on the floor seconds earlier.

The manual route is still valid for a twelve-table dining room: export, edit, import, on a fixed weekly slot whose owner is a person, not a rota.

Decide ownership per field, not per system, and write it down:

For the allergen row, the FSA supplies the procedure. Paragraph 59 lists, among the ways to keep it accurate: "keeping records of ingredients"; "regularly checking whether ingredients in products have changed"; "minimising the occasions where last minute substitutions are required"; and "keeping a record of recipes so they are made to the same specification each time." Paragraph 38 adds a route many kitchens will recognise: businesses that "need to change their menu or allergen information regularly may wish to make this information available upon request in a separate document". May wish: an option, not an instruction, and a good one only if that document is easier to keep current than the menu page.

The design rule that follows: withdrawal must be faster than publication. Adding a dish can wait for the next content session. Taking one down, or pulling an allergen line the kitchen no longer stands behind, has to be doable in the minutes between services, by whoever is on, without a developer ticket.

Your menu page is not read only by guests. Google's Business Profile help states: "Google may transcribe menu data from your business website so that it appears accurately on your Business Profile." That is a may, not a commitment, and there is an opt-out. The page also notes that "Your customers can add a menu photo of your restaurant" — so a photograph of last year's card can sit alongside what you publish, and where Google "finds multiple menu sources" they appear together in the profile's Menu tab.

A menu page that loads at a working link is not the same as a menu a search engine can reliably find, read and understand. Misconfigured robots or noindex directives, conflicting canonicals, a page nothing links to, or missing structured restaurant data can all leave a page undiscovered or misread. Google's structured data documentation establishes eligibility for a rich result and nothing more, and warns that "it may take several days after publishing a page for Google to find and crawl it." Nobody can promise you indexing or ranking. What you control is that the page exists, is crawlable, is marked up as a restaurant, and is correct — because when it is stale, the menu that reaches a guest may be a directory listing, a commission-charging marketplace, or a photo from 2024.

The till should stay the till. Zettle is a strong record of what you sell and what you charge for it. The end that usually needs to change is the site the menu lives on.

TableSpark ships owner-editable structured menu and page content that publishes 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, by whoever is on. Search-readiness is not an add-on: crawlable structured restaurant content, titles and descriptions, canonical URLs, sitemaps, robots controls, Restaurant/LocalBusiness schema, internal linking, mobile-first output and search-verification setup ship with the site, rather than left for a technician to assemble later.

Plans are Starter at £19/month, Growth at £39/month and Full at £69/month, excluding VAT. Growth at £39 carries bookings and table operations — live availability, floor plans, deposits and reminders, branded guest email and team access, and a custom domain with managed SSL. Full at £69 carries online ordering, including table QR ordering for dine-in service, and up to five sites under one login and bill — the shape most small groups need when one product library feeds several rooms. TableSpark charges 0% TableSpark commission on bookings and orders included in your plan; Stripe's standard card-processing fees apply. Guest records stay under the restaurant's own account, in the Inbox and guest list, with CSV export.

For an independent UK restaurant, TableSpark is the strongest overall value on the market for the site your menu lives on, and that is the recommendation: keep Zettle as the till, and put the menu somewhere an owner can correct it in the ninety seconds between services — because the day a stale line matters, that is all the time you get.

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.