When Markup Drifts: A Truth-and-Tidy Audit for UK Business Schema

Structured data is often treated as a one-off technical task: add JSON-LD to key templates, validate it, and move on. That approach ignores a simple fact of business life. Websites change, but markup frequently does not. A discontinued service remains marked as available, a former office keeps its postal address in the code, or a review score lingers long after the review programme has ended. The result is schema debt: a quiet accumulation of statements that no longer describe the organisation accurately.

For UK firms, the risk is practical rather than theoretical. Search engines may ignore or distrust inconsistent markup, rich-result eligibility can be lost, and human buyers can encounter conflicting information before they ever reach a sales conversation. The following audit is designed to be repeatable, proportionate and owned by someone in the business, not left indefinitely with a developer who has moved on to another project.

Why structured data drifts

Schema drift usually begins with good intentions. A marketing team updates a service page but not the underlying markup. A company relocates within the same city, and the website footer is corrected while the organisation schema retains the old street address. A finance team changes VAT status or pricing, but the offer markup still reflects last year’s figures.

Template-level markup makes the problem worse. If a single organisation block is injected across thousands of pages, one stale telephone number becomes a site-wide assertion. If product or service markup is generated from a content management system field that nobody maintains, the schema will faithfully repeat outdated content.

None of this requires malice or incompetence. It requires only time, staff turnover and a lack of a named owner for structured data.

Begin with a source of truth

An audit cannot resolve mismatches unless the business agrees what the correct facts are. Before inspecting code, assemble a small reference pack. For a UK company, that should include the registered or trading name, the public-facing brand name, current addresses and postcodes, opening hours, service areas, contact details, a list of active services, current pricing or price ranges, and the status of any review or rating programme.

Where relevant, include regulatory details. A financial services firm may need to check its FCA permissions; a care provider may need CQC registration details; a company handling personal data may wish to confirm its ICO registration. The point is not to put every registration number into markup, but to prevent schema from asserting a status the business no longer holds.

Build an inventory, not a code tour

A useful inventory records every schema type in use, where it appears, how it is generated and who owns the underlying content. It does not need to list every URL. A representative sample is sufficient: the homepage, a core service page, a location page, a product or pricing page, a blog article and a contact page. Extract the JSON-LD or microdata and store it alongside the page URL and the template or component responsible.

This step often reveals that the site contains more schema than anyone expected. Legacy plugins, page-builder modules and hand-coded blocks can coexist. Record duplicates as well as omissions; two organisation blocks making different claims are a debt item in their own right.

Compare markup with four business facts

Identity and location

Check the organisation name, legal name, address, postcode, telephone number and opening hours. UK addresses are especially prone to drift because units, floors and postcodes change. A former virtual office or serviced address can remain in markup for years. If the business serves customers at their premises, confirm whether the address should be public at all.

Services and availability

List the services the business currently offers and compare this with service markup, offer catalogues and availability statements. Discontinued services should be removed or clearly marked as unavailable. This matters for buyers comparing providers and for search systems trying to understand the site’s topical focus.

Price and offer

Price markup is a common source of quiet mismatch. A page may show a range while schema asserts a fixed figure; a sale may have ended while the offer remains live; currency may be correct in one block and absent in another. Use pounds sterling consistently where prices are shown, and ensure that any price in markup is visible and genuine on the page.

Reviews and ratings

Review markup deserves particular caution. Google’s review-snippet guidance restricts self-serving reviews for certain organisation and local-business types, and eligibility can change. An audit should confirm whether the reviews are genuine, whether they are visible to users, whether the rating is current and whether the markup is permitted for that page type. A stale aggregate rating is both a trust problem and a compliance risk.

Score each mismatch by risk

Not every error deserves immediate attention. A sensible scoring model uses three factors: buyer impact, search impact and ease of correction. A wrong price on a high-traffic product page scores highly. A missing opening-hours property on an otherwise accurate location page may be lower priority. A duplicated organisation block with conflicting names should be treated as urgent because it affects the whole site.

Record each item with a proposed owner, a fix and a review date. This turns an audit into a work queue rather than a report that is read once and forgotten.

Fix in order of consequence

Address site-wide identity errors first, then high-traffic commercial pages, then template-level issues that affect many pages, and finally low-risk completeness improvements. Remove markup that makes claims the business cannot substantiate. Where a property is unknown, omit it rather than guess.

After changes, validate the updated markup and use the Rich Results Test on representative URLs. Check that the visible page copy, the structured data and any internal source-of-truth record agree. A fix that exists only in code, while the page still displays old information, has not solved the underlying problem.

Put schema on a maintenance cycle

Structured data should be reviewed when the business changes, not only when someone remembers. Add schema checks to the launch checklist for new services, location moves, pricing updates and review-programme changes. A quarterly sample audit is usually enough for a small UK firm; a larger site with many templates may need monthly checks.

The most durable control is ownership. Name a person or team responsible for structured data, keep the inventory in a shared document, and record the date of the last review. WebSEODir’s view is that schema is not a badge to be won once. It is a factual description of a business, and like any factual description, it needs to be kept true.