HygieneScout is built entirely on publicly available government data. This page explains where the data comes from, how we process it, and the engineering decisions that make the site work at scale.
All food hygiene rating data on HygieneScout comes from the Food Standards Agency (FSA) FHRS API at api.ratings.food.gov.uk. This is the same underlying data displayed on the official ratings.food.gov.uk website, published by the FSA under the Open Government Licence v3.0.
The API exposes data from approximately 390 local food enforcement authorities across England, Wales, and Northern Ireland. Each authority publishes ratings for food businesses within their geographic area. Scotland uses the separate Food Hygiene Information Scheme (FHIS) and also publishes through the same API, though with different data fields.
The API is unauthenticated and publicly accessible. We request data at version 2 of the API, which exposes inspection sub-scores (Hygiene, Structural, and Confidence in Management) alongside the overall rating. Not all local authorities provide sub-scores, so these fields are null for a portion of establishments.
We run a full synchronisation against the FSA API every day at 3am UTC. The sync iterates all ~390 local authorities, fetches their current establishment data, and compares it against what we have stored. When a rating changes, we capture a snapshot recording the old and new rating, the date, and the authority.
The sync uses paginated requests with a page size of 5,000 establishments per call, with a 200ms delay between API calls as a courtesy to the FSA servers. A full sync across all authorities typically completes in two to three hours and processes around 608,000 establishment records.
After establishment data is updated, the sync recomputes aggregated statistics: average ratings and establishment counts for each town and council, London borough totals, and chain-level statistics. These aggregates are what power the rankings, town pages, and council pages.
The FSA's own website only shows the current rating for each establishment. There is no official history, no way to see what a restaurant was rated before its most recent inspection, and no data on whether a business is trending up or down.
HygieneScout addresses this by capturing a snapshot every time we detect a rating change during the daily sync. When an establishment's rating updates from, say, 3 to 5, we record both values with a timestamp. Over time, this builds a timeline of rating history for each business, something that does not exist anywhere else, including the FSA's own systems.
This history powers several features: the rating timeline on individual establishment pages, the recently changed feed, the most improved and most declined rankings, and email alerts when a business you are watching receives a new rating.
The dataset grows daily. The longer HygieneScout runs, the richer the history becomes. Businesses that were inspected before we launched do not have pre-launch history, but every change since we went live is captured.
In England, Wales, and Northern Ireland, the Food Hygiene Rating Scheme (FHRS) rates food businesses from 0 to 5:
The overall rating is produced from three inspection sub-scores: Hygiene (0–25), Structural (0–25), and Confidence in Management (0–30). In each category, a lower score indicates fewer issues. These are combined through a matrix to produce the final 0–5 rating. A lower sub-score is better, which is counterintuitive; HygieneScout inverts these scores visually on establishment pages so that longer bars indicate better performance.
See our guide to food hygiene scores for a detailed explanation of what each area measures.
Scotland uses a different system: the Food Hygiene Information Scheme (FHIS). Instead of a 0–5 scale, businesses receive a Pass or Improvement Required result. We display Scottish establishments with their FHIS rating and exclude them from all numeric averages and rankings to avoid misleading comparisons. Scottish local authorities appear in the council browser with their FHIS label.
For more on why Scotland uses a different system and what that means for consumers, see our guide to Scotland's food hygiene system.
The FSA API does not include a canonical town name for each establishment. Address data is inconsistent: some records have a useful town name in the address fields, others have street names, flat numbers, or nothing useful at all.
To assign each establishment to a town, we use the Office for National Statistics Postcode Directory (ONSPD), which maps UK postcodes to canonical place names. For each establishment's postcode, we look up the Built-Up Area name from ONSPD. If that is not available, we fall back to the Parish name, and if that is also not available, we apply heuristics to the address fields.
The address heuristics include a guard that rejects any town candidate starting with a digit (these are street addresses, not place names) and a guard that converts any result of "London" to the specific borough name for that establishment. This second guard is important: without it, all London establishments would collapse into a single "london" town, which conflicts with the London borough pages.
Town names are stored in title case using proper English conventions: small conjunctions and prepositions (on, in, by, and) are lowercased, and irregular names (Weston-super-Mare, Sutton Coldfield, Abergavenny) are handled correctly.
The FSA API has no concept of chains or brands. A McDonald's in Manchester and a McDonald's in Bristol are just two separate establishments with similar names. To power the chain pages, we maintain a curated list of 49 major UK food chains with ILIKE pattern matching rules that identify their locations by business name.
Each chain is defined by one or more SQL patterns. For example, a chain might match any business name containing "McDonald" or "McDonalds". These patterns are applied during the daily sync to compute chain-level statistics: establishment count, average rating, rating distribution, and the towns where the chain operates.
The chain list is maintained manually. We add chains when they have a meaningful number of UK locations and when the name patterns are distinctive enough to match reliably without false positives. Chains with ambiguous names (where a pattern might match unrelated businesses) are excluded.
London is handled differently to other towns. The 33 London boroughs are treated as the primary geographic unit for London establishments, not a single "London" town. Each borough has its own page under /london/[borough-slug]/, and the main London page shows aggregate statistics across all 33 boroughs.
London aggregate statistics are recomputed during each daily sync by summing the establishment counts and computing weighted averages across all 33 borough local authorities. This means the London overview page always reflects current data even though no individual "London" town exists in the database.
We use the Office for National Statistics Postcode Directory (ONSPD) to map postcodes to canonical town names, ensuring establishments are grouped under the correct location. The ONSPD contains approximately 2.7 million UK postcodes with associated place names, local authority codes, regions, and countries.
The ONSPD is published by the ONS under the Open Government Licence v3.0 and is updated quarterly. We import new versions as they are released to keep postcode-to-town mappings current, particularly for new postcodes in recently developed areas.
FSA data is published under the Open Government Licence v3.0. This allows free use, adaptation, and redistribution of the data with appropriate attribution. HygieneScout attributes the Food Standards Agency on every page where FSA data is displayed.
HygieneScout generates contextual summaries on town and establishment pages. These insights are computed from FSA data and are not independently verified or endorsed by the FSA. Town insights include rating percentages, the most common and best-performing business types, recent inspection activity, and 30-day trend data from our rating history snapshots.
Insights highlight positive or neutral metrics. They do not make negative judgements about specific areas or businesses beyond what is directly stated in the underlying data.
The search feature uses PostgreSQL's trigram extension (pg_trgm) for fuzzy matching, along with a tsvector full-text search index. This allows searches to return relevant results even with partial names, typos, or variations in how a business name is written. Search covers business names and postcodes.
The search API also suggests postcode districts and town names when a postcode-like query is entered, making it easier to navigate to a specific area rather than a specific business.
For the most authoritative and up-to-date information, contact the relevant local authority directly or consult the FSA ratings website.