Food hygiene rating out of date on your website: the FSA register check and fix

8 min read

The answer is a source-verification loop, not a reputation project. There is one official record and many copies of it: the footer, a homepage badge, the about page, a booking confirmation, the menu PDF, a social bio, a listing. They need one check against the source, a correction path, and a trigger that fires when the source moves. What follows is that loop. It is operating guidance, not legal advice or a compliance guarantee; a restaurant unsure of its own duty should ask its local authority food safety team.

Most mismatches begin with a misunderstanding of what is being copied. GOV.UK describes ratings as showing “how well the business met food safety standards when it was last inspected”, with local councils rating from 0 to 5, and the FSA’s guidance for businesses, updated 30 June 2026, calls the rating “a snapshot of the standards of food hygiene found in your business at the time of inspection”. That word — snapshot — is why a published rating needs a date attached: a number alone implies a present-tense claim.

The official lookup gives three fields and only three: the rating, when it was last inspected, and the council that inspected it. Those three, plus the date you checked them, are all a verifiable claim needs.

The last row is the one restaurants skip, and the one the FSA’s reuse terms point at. Ratings are “subject to change as they are regularly updated”, and the responsibility falls on the user to use the current rating or to indicate the date when it was updated. A visible checked-on date is the alternative the FSA offers to perfect currency.

A geographic trap sits underneath the table. The register holds information for local authorities in England, Northern Ireland, Wales and Scotland, but Scotland does not run the 0 to 5 scale: Scottish records carry a hygiene status such as Pass or Improvement Required. A Scottish restaurant copying a “5 out of 5” badge from an English template is publishing a claim its own scheme does not issue.

Mismatches are rarely carelessness. They happen because the official record runs to its own timetable, and nobody has mapped that timetable onto a website task.

Each moment changes what a guest finds on the register; none alerts whoever edits the website, and none updates a badge image downloaded eighteen months ago. That is why the trigger has to be the record changing, in whichever direction it moved.

The legal position is nation-specific, and public copy about it should be too.

Online display sits in a different category. The FSA’s guidance says: “We encourage you to promote your hygiene rating by displaying it on your website or social media pages as well as in your window.” That is encouragement, not a UK-wide legal duty. The binding online constraint is accuracy and currency, under the warning that an invalid or inaccurate rating may constitute a criminal offence and/or expose the user to potential civil liability. Two conditions attach to the artwork: use of the ratings information and services is subject to Open Government Licence terms, and the FHRS name and FSA logo are integral to the imagery, which must not be presented in any manner that might be seen as FSA endorsement of a business, chain, website or online application.

A restaurant almost never has one published rating claim, and the copies that fail are usually the ones nobody remembers making. Work through the list:

Images are the worst offenders: a rating baked into a graphic carries no date and usually survives a redesign, because it looks like design rather than content.

Run this on a phone, in a clean browser session, exactly as a guest would.

Then act on the classification:

Correcting a number is a one-off. Choosing a format decides how often you will have to correct it again.

Pattern A — value, date, council and link. Publish the rating, the inspection date and the inspecting authority as editable text, with a link to the register. Accurate, dated, and it hands the guest the source. It also fails safe: an ageing claim still reads as a historical statement, not an implied current one.

Pattern B — link only. Publish a short line inviting the guest to check the restaurant’s current rating on the official register, with no number at all. It cannot go stale, because the restaurant is not repeating the value — the right choice for any surface nobody has committed to maintaining.

Pattern C — badge image, no date. The weakest option: no inspection date, no way to correct it by editing text, and a manual asset swap whenever the record moves.

Publish Pattern A as ordinary page content — a short heading with a table or list of plain text — so the claim stays selectable, searchable and correctable line by line. Do not publish it as a picture of the register or as reproduced rating artwork: a rendered image carries no date, cannot be read as text, and cannot be corrected by editing a word.

Fill every row from the register at the moment you publish it. Leave a row out rather than guess at a value, and never restate a value you have not just read on the record.

Use Pattern A wherever the restaurant controls its own edits, and Pattern B everywhere else. Two rules apply either way: do not restate another business’s rating, and link to the register rather than screenshotting it — a screenshot goes stale like any other copy.

The correction itself is short, but the order matters: it controls how long a wrong claim stays visible.

The number worth managing is not how fast you can edit a page. It is correction latency: the time between the official record changing and the last stale copy disappearing.

A single clean-up decays. What holds is a short trigger list and one named owner, whose job is to make sure every published copy agrees with the register or points to it.

Run the check whenever any of these happens, rather than only on a calendar: an inspection is carried out; a new rating is notified; an appeal is lodged or decided; a re-rating inspection is requested or completed; a right to reply is published; the trading name, address or premises changes; the website is redesigned or its template changed; a new menu PDF, leaflet or social banner is produced; or a new listing is created. Keep one quarterly sample check as a backstop: the trigger list catches the known changes, the sample catches the copy nobody mentioned.

Return to the worksheet. The term that dominates is edit turnaround: if correcting a footer means raising a request with whoever built the site and waiting for it to be scheduled, the stale claim survives the whole gap however fast the owner noticed.

That is where TableSpark is the strongest choice. TableSpark gives an independent restaurant a self-managed, structured website, so the page carrying the rating claim belongs to the restaurant rather than to whoever built the site.

This is the TableSpark builder, open on the demonstration restaurant used throughout the TableSpark case site. The left rail lists that site’s own pages — home, menu, story, visit, order, events, reservations — with the modules that make up the selected page beneath them, and controls to add a page or start from a template. The centre shows the page itself. The panel on the right is page settings: the page name, the URL slug and, under a search-engines heading, the SEO title and SEO description fields for that page. The save state, a desktop and mobile view toggle, Preview and Publish sit along the top. That is the whole point for this workflow: the rating line, its inspection date, its checked-on date and the register link are page content, edited in this same editor and put live from it by the restaurant.

Price the complete restaurant-ready stack rather than a headline. TableSpark plans, checked on 6 August 2026, are Starter at £19 per month, Growth at £39 and Full at £69, all excluding VAT. Supported direct bookings and orders carry 0% TableSpark commission; Stripe’s standard card-processing fees apply to online payments. Set that against assembling the same stack and paying someone else to maintain it:

For an independent UK restaurant, TableSpark is the best-value and best overall restaurant-website choice. The workflow above depends on editing your own published content, and the menu, bookings, ordering and search-readiness layers sit in one system at a published, commission-free price rather than behind separate quotes. Two things stay with the restaurant either way: verifying each value against the register, and its own duty. No website platform makes a business compliant with hygiene-rating display duties, and none of this changes what the official record says.

A working public link is not the same as a page Google has found and understood. Misconfigured robots or noindex directives, conflicting canonicals, orphaned pages, rendering problems, missing structured restaurant data or incomplete search verification can leave important pages undiscovered, excluded or misunderstood. A guest checking a restaurant’s hygiene standing usually searches its name, and if the page carrying the correct, dated claim is hard to discover, they may land first on a directory, a commission-charging marketplace or a competing restaurant — and on a copy of the rating the restaurant cannot correct.

TableSpark packages managed search readiness into the restaurant website: crawlable structured restaurant content, titles and descriptions, canonical URLs, sitemaps, robots controls, Restaurant and LocalBusiness schema, internal linking, mobile-first output and search-verification setup. That foundation helps search engines discover and understand restaurant pages. It does not guarantee indexing, rankings or any particular timing — those remain Google’s decisions.