What schema does, and what it does not
Structured data is code that states your facts in a form a machine reads without guessing: that you are a business of a particular type, where you operate, what you offer, what it costs, and what questions you answer.
It does not make you rank. Google says plainly that no markup guarantees a rich result or an AI Overview citation. What it does is remove ambiguity, which makes your information safer for a machine to reuse. In a world where systems must decide whether they can state something about you confidently, that is worth more than it used to be — but it is a clarifier, not a lever.
The types a local service business needs
| Put it on | Key properties | |
|---|---|---|
| LocalBusiness | The organisation, declared once and referenced everywhere | name, address, telephone, openingHours, areaServed, url |
| A specific subtype | Instead of LocalBusiness where one fits — Plumber, Dentist, Electrician | Same properties; the type itself carries the meaning |
| Service | Each individual service page | name, serviceType, provider, areaServed, description |
| FAQPage | Pages with genuine visible question-and-answer content | mainEntity, Question, acceptedAnswer |
| BreadcrumbList | Every page below the top level | itemListElement with position, name, item |
| AggregateRating | Only where real ratings are shown on the page | ratingValue, reviewCount |
Always prefer the most specific type that genuinely fits. ‘Plumber’ tells a machine more than ‘LocalBusiness’, in exactly the way a specific Business Profile category outperforms a broad one.
Declare the business once, reference it everywhere
The most common mistake is repeating full LocalBusiness markup on every page. Twenty pages each asserting a slightly different version of the same business is precisely the ambiguity you were trying to remove.
Declare the organisation once with a stable @id, then point at it:
{
"@context": "https://schema.org",
"@type": "Plumber",
"@id": "https://example.co.uk/#organization",
"name": "Example Plumbing",
"url": "https://example.co.uk/",
"telephone": "+441202000000",
"address": {
"@type": "PostalAddress",
"streetAddress": "1 Example Road",
"addressLocality": "Poole",
"addressRegion": "Dorset",
"postalCode": "BH15 1AA",
"addressCountry": "GB"
},
"areaServed": ["Poole", "Bournemouth", "Christchurch"],
"openingHoursSpecification": [{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday"],
"opens": "08:00", "closes": "17:30"
}]
}Then each service page describes only what is offered, and names the provider by reference:
{
"@context": "https://schema.org",
"@type": "Service",
"serviceType": "Boiler servicing",
"provider": { "@id": "https://example.co.uk/#organization" },
"areaServed": "Poole",
"description": "Annual boiler service, typically two hours, from \u00a390."
}That pattern keeps one authoritative statement of who you are, and lets every page add what it knows without contradicting the others. It is the schema equivalent of entity consistency, and it works for the same reason.
Getting it wrong
- Marking up what is not on the page. Invisible markup breaches Google’s guidelines and can earn a manual action. If a visitor cannot see it, do not declare it.
- Inventing ratings. AggregateRating without genuine, displayed reviews is among the more commonly actioned abuses, and it is trivially detectable.
- Contradicting your own listings. Schema that disagrees with your Business Profile actively damages the corroboration it was meant to support.
- Duplicate keys. When markup is generated programmatically it is easy to emit the same property twice. A parser keeps the last one and discards the first silently, so the markup validates cleanly while saying something you did not intend. We have caught exactly that on our own pages — a second
areaServedquietly overwrote the correct one. - Treating it as a substitute. Markup describes what exists. It cannot manufacture authority, reviews or relevance.
How to validate it
Use both of these, because they catch different things and a page can pass one while failing the other:
- Google’s Rich Results Test tells you whether Google can parse it and whether it qualifies for any rich result. It is the one that matters commercially.
- The Schema.org validator tells you whether the markup is actually correct. It flags misused properties that Google silently ignores.
Two habits worth adopting. Validate the rendered page rather than the template, because generated markup is where errors appear. And re-check after any site migration — schema is quietly lost in redesigns more often than almost anything else.
Does schema help with AI search?
Indirectly, and less than vendors imply. No markup gets you cited. What it does is make your facts unambiguous, so a system deciding whether it can state your opening hours confidently has a clean answer rather than an inference from prose.
In the order of things that affect AI visibility, schema sits below crawler access, entity consistency and genuine reviews — and above almost everything else. Worth doing properly, not worth doing instead of the others.