Get Townsmith

Common schema mistakes on local and location pages (and how to check yours)

The most common local schema mistakes are: using Organization instead of the specific LocalBusiness subtype, marking up FAQ or review content that is not visible on the page, schema counts that do not match what the page actually shows, identical schema copied across every generated location page, and an areaServed that claims more coverage than the business has. Each one is checkable in minutes with Google’s Rich Results Test and the Schema Markup Validator. None of them affects your ranking directly, but the invisible and mismatched-content cases can cost you rich-result eligibility through a structured-data manual action.

This is an audit checklist scoped to local and location pages, the kind a careful agency runs before signing off a build. It does not re-explain how to write a LocalBusiness schema graph from scratch, and it does not re-cover the writing problems on generated pages, which the duplicate content on location pages guide already handles. It stays on one thing: the structured-data errors that show up again and again when a site has tens or hundreds of area pages, and the exact validation step for each.

Policy figures current as of 14 August 2026. Re-check Google’s documentation before relying on any rich-result behaviour, because it changes.

What counts as a schema mistake on a local page?

A schema mistake here is not a syntax error. Validators catch those for you. The mistakes that matter on local pages are the ones that pass validation but still misrepresent the page: the markup is technically well-formed, yet it describes the page as something it is not, whether that is the wrong business type, content the visitor never actually sees, or a service area the business does not really cover. Google’s structured-data policies are blunt about this. “Your structured data must be a true representation of the page content,” and “Don’t mark up content that is not visible to readers of the page” (Google Search Central, structured data general guidelines, accessed 14 August 2026).

The reason these slip through at scale is that location pages are usually generated from one template. A single wrong decision in the template repeats itself across forty pages. So the audit below is written to be run once against the template and once against a sample of live pages, not page by page.

The six mistakes, with the fix and the check for each

1. Using Organization instead of a LocalBusiness subtype

Many plugins default to Organization for the whole site. For a business that serves customers in person or travels to them, the correct type is LocalBusiness or, better, the specific subtype: Plumber, Electrician, HVACBusiness, RoofingContractor. A boiler repair firm declared as a generic Organization is throwing away the local signal it most needs.

Fix: declare one node of the most specific applicable LocalBusiness subtype, with your real name, base address and contact details. Do not create a separate business node per area.

Check: open the page in the Schema Markup Validator (validator.schema.org) and read the @type on your main business node. If it says Organization or LocalBusiness where a subtype exists for your trade, switch it.

2. Marking up content that is not visible on the page

This is the one with teeth. Common versions on local pages: an FAQPage block listing questions and answers that never appear in the body, a Review or AggregateRating for testimonials that are not actually on the page, opening hours in schema that the page never states. Google’s policy treats this as a content violation, and “If your page contains a structured data issue, it can result in a manual action,” which means the page “loses eligibility for appearance as a rich result” (Google Search Central, structured data general guidelines, accessed 14 August 2026).

Fix: only mark up what a visitor can read. If the FAQ answers are not in the visible text, either add them as real text or remove the markup.

Check: paste the page URL into the Rich Results Test (search.google.com/test/rich-results), then read every value it parses back and confirm each one appears as text on the rendered page. If a value is in the schema but not on the page, that is the mistake.

3. Adding self-serving Review or AggregateRating markup

A close relative of mistake two, and worth its own line because it is so tempting. Putting star ratings about your own business into your own page’s schema does nothing useful. Google states that “If the entity that’s being reviewed controls the reviews about itself, their pages that use LocalBusiness or any other type of Organization structured data are ineligible for star review feature” (Google Search Central, review snippet documentation, accessed 14 August 2026). The full reasoning, and what you can legitimately mark up instead, is in the Review schema for local business guide.

Fix: remove self-serving Review and AggregateRating from your own pages. Star ratings in search come from third-party platforms such as Google Business Profile, Yelp and Trustpilot, and from Product markup, not from a business rating itself.

Check: in the Schema Markup Validator, look for any aggregateRating or review attached to your own LocalBusiness node. If it is there, delete it.

4. Schema counts that do not match the page

A subtler version of the visibility problem. The schema says four services and the page lists two. The schema lists six FAQ entries and the page shows three. The markup claims an image the page does not embed. Counts that do not match are still mismatched content, and they read as careless to both validators and reviewers.

Fix: generate schema from the same source as the visible content so the two can never drift apart. If the page renders three FAQ items, the markup should contain exactly three.

Check: in the Rich Results Test, count the items inside each repeated property and compare against what the page displays. A quick way to catch a whole template at once is to spot-check three pages: if one is off, the template is off.

5. Identical schema copied across every location page

This is the failure mode programmatic location pages risk most. Every area page carries the exact same Service and areaServed block, naming the same town, because the template hard-coded one example and never substituted the real place. Uckfield’s page says it serves Uckfield, and so does the Lewes page, and so does every other. The schema then contradicts the page it sits on.

Fix: the per-page schema must vary with the page. Each area page is best described as a Service that references your single business node and names the place that page is about in areaServed, so the markup mirrors the truth: same business, same service, different area. This is the pattern set out in the LocalBusiness schema guide under its “Service plus areaServed is the local pair” section.

Check: validate two different area pages and compare the areaServed values. If Lewes and Uckfield report the same place, the substitution is broken. While you are there, confirm the page text and the schema name the same town, because mismatched place names are the duplicate problem and the visibility problem at once.

6. An areaServed that overstates coverage

The opposite of restraint. A one-van boiler firm in East Sussex lists fifty towns in areaServed, half of which it has never worked in. This is not a syntax problem, it is a truthfulness problem, and it produces thin pages for places the business cannot actually serve. It also undermines the local signal, because the markup no longer describes a real catchment.

Fix: let areaServed mirror the visible service-area text exactly, and keep both honest. Never invent a per-area street address or per-area phone number to prop up a place you do not really cover. If you genuinely add a town, the page and the schema should grow together.

Check: read the areaServed list in the validator against the service-area text on the page. Any place in the schema that is not in the visible text, or that the business cannot service, comes out.

Which tools should you validate with, and what should you ignore?

Two tools cover the local audit. The Rich Results Test (search.google.com/test/rich-results) shows what Google can parse and whether the page is eligible for a rich result. The Schema Markup Validator (validator.schema.org) shows the full graph, including types the Rich Results Test no longer reports on, so it is the one to use for checking @type, areaServed and node references.

What to ignore is as important. Do not spend effort chasing rich results that no longer exist. Google posted a note on 7 May 2026 that FAQ rich results were no longer appearing in Search, with the FAQ search appearance, the rich-result report and Rich Results Test support being dropped in June 2026 and Search Console API support removed in August 2026 (Search Engine Land, 7 May 2026). HowTo rich results were removed from desktop back in 2023. FAQ and HowTo markup are still valid Schema.org types and can help AI systems read your page, but they will not draw a SERP feature, so do not treat them as a rankings lever or panic when the test stops reporting them.

  • Use the Rich Results Test for eligibility and to read back parsed values against the visible page.
  • Use the Schema Markup Validator for the full graph: type, node references, areaServed, counts.
  • Do not chase FAQ or HowTo rich results. They were retired and the tools are dropping them.
  • There is no AI-only schema and no special markup that makes AI Overviews quote you. Accurate, visible structured data is the whole job.

The liftable agency checklist

Run this against the template once and a sample of live pages once.

  • The main business node uses the most specific LocalBusiness subtype for the trade, declared once for the whole site.
  • Every value in the schema appears as visible text on the rendered page.
  • No self-serving Review or AggregateRating sits on your own business node.
  • Repeated-item counts in schema match the counts shown on the page.
  • Two different area pages report two different areaServed values, each matching that page’s town.
  • areaServed lists only places the business genuinely covers, mirroring the visible service-area text.
  • No per-area fake street address or phone number anywhere in the graph.
  • Each page validates in the Rich Results Test and the Schema Markup Validator with no content mismatch.

How does Townsmith stop these mistakes happening at scale?

Most of these failures are not human carelessness, they are template drift: the markup and the visible content are produced separately, so over hundreds of generated pages they fall out of step. The Townsmith engine builds the schema from the same page data the visitor sees, server-side, so the two cannot diverge. Each area page is emitted as a Service referencing your one business node, with an areaServed that matches the town named on that page, plus a BreadcrumbList. The result is per-page, page-accurate schema rather than one block copied everywhere, which is what removes the duplicate-schema and count-mismatch mistakes across a whole portfolio.

The engine also scores each page from 0 to 100 and holds thin ones back rather than publishing them, so an overstated service area tends to surface as a low score before it ever ships. There is no claim here that any tool guarantees rankings or guarantees you avoid a manual action. The point is narrower and honest: consistent, accurate, visible schema is generated for you, so the mistakes in this checklist do not occur by accident. You can see how it is put together on the features page, and how the quality score works in the quality score documentation. The engine coexists with Rank Math, Yoast, AIOSEO and SEOPress, referencing the organisation node they publish rather than redeclaring it.

Once the schema is correct, the work shifts to watching how those pages perform. The guide to measuring location pages covers reading index coverage and the generative AI performance report in Search Console, which is where a schema problem usually shows up as lost rich-result eligibility.

Common questions about local schema mistakes

Does a structured-data error hurt my rankings?

Not directly. A structured-data manual action removes the page’s eligibility to appear as a rich result, but Google states it does not change how the page ranks in ordinary web search. The page can still rank, it just stops getting the enhanced appearance. The real cost of sloppy schema on local pages is usually the thin content that comes with overstated coverage, not a ranking penalty from the markup itself.

Can I keep FAQ schema on my location pages even though the rich result is gone?

Yes, as long as the questions and answers are visible text on the page. FAQPage is still a valid type and other systems, including AI search, may read it. What changed in 2026 is the Google SERP feature, not the markup’s validity. Just do not expect it to draw a rich result, and never mark up FAQ content that is not on the page.

Should every location page have its own LocalBusiness node?

No. There is one business, so there should be one LocalBusiness node. Each area page should be a Service that references that single node and names its own area in areaServed. Creating a separate business node per town, especially with a faked address, is exactly the pattern search engines read as manipulative.

Is there special schema that gets me into AI Overviews?

No. There is no AI-only schema type and no markup trick that makes an AI engine cite you. Structured data is not required for AI Overviews or AI Mode at all. Accurate, visible schema and clear, people-first content is the whole optimisation. Anything sold as an AI-schema shortcut is selling the same fundamentals under a new name.

Written by Stephen Evans. Sources: Google Search Central structured data general guidelines and review snippet documentation (accessed 14 August 2026), and Search Engine Land’s report on the FAQ rich-result removal (7 May 2026).