How do you keep schema markup accurate over time?
Validate with the Rich Results Test and the Schema Markup Validator, then check Search Console monthly. Markup rots — a number changes, hours change for a holiday, a service is dropped — and stale structured data is a live inaccuracy rather than a dormant one.
Use JSON-LD, in the head
There are three syntaxes; only one is worth using. JSON-LD sits in a script tag, separate from your markup, so changing the design does not break the data. Microdata and RDFa interleave attributes through your HTML and break constantly.
<script type="application/ld+json">{ ... }</script>
Start with the business itself
For a local business, LocalBusiness — or a more specific subtype like Plumber, Dentist, Attorney — is the foundation:
{
"@context": "https://schema.org",
"@type": "Plumber",
"name": "Example Plumbing",
"url": "https://example.com",
"telephone": "+1-281-555-0100",
"address": {
"@type": "PostalAddress",
"streetAddress": "123 Example Rd",
"addressLocality": "Sugar Land",
"addressRegion": "TX",
"postalCode": "77478",
"addressCountry": "US"
},
"openingHoursSpecification": [...],
"areaServed": ["Sugar Land", "Missouri City", "Stafford"],
"sameAs": ["https://www.facebook.com/...", "https://www.yelp.com/biz/..."]
}
Every value must match what is on the page and what is on your Google Business Profile. Inconsistent addresses across sources is one of the most common local problems, and schema makes the inconsistency machine-readable.
Then add types per page
- Service on each service page, linked to the business via
provider - BreadcrumbList on anything below the top level
- FAQPage where you have visible questions and answers
- Article or
BlogPostingon posts, with a real author - Product with
Offeronly where you sell a product with a price
Do not add types speculatively. Markup describing something the page does not contain is worse than no markup.
Connect them into one graph
Rather than several disconnected blocks, give each entity an @id and reference it:
{"@context":"https://schema.org","@graph":[
{"@type":"Plumber","@id":"https://example.com/#business", ...},
{"@type":"WebSite","@id":"https://example.com/#website","publisher":{"@id":"https://example.com/#business"}},
{"@type":"Service","provider":{"@id":"https://example.com/#business"}}
]}
This is what turns a pile of facts into a description a machine can reason about — and it is the part most sites skip.
Review markup deserves a warning
Self-serving review markup — ratings you host about yourself — is restricted, and inventing ratings you do not have is straightforwardly dishonest. Leave aggregate ratings to platforms that collect them.
Verify, then keep verifying
Validate with the Rich Results Test and the Schema Markup Validator, then check Search Console monthly. Markup rots — a phone number changes, hours change for a holiday, a service is dropped — and stale structured data is a live inaccuracy rather than a dormant one.
Frequently asked questions
Which schema syntax should I use?
JSON-LD. It sits in its own script tag, separate from your markup, so redesigns do not break it. Microdata and RDFa interleave attributes through the HTML and break constantly.
What should I mark up first?
The business itself, using LocalBusiness or a more specific subtype, with name, URL, telephone, full postal address, hours, areas served and sameAs links. Every value must match the page and your Google Business Profile.
What is the @id graph approach?
Giving each entity a stable @id and referencing it from the others, so the business, website and services are linked rather than sitting as disconnected blocks. It is the step most sites skip.
Can I add review stars to my own site?
Self-serving review markup is restricted, and inventing ratings you do not have is dishonest. Leave aggregate ratings to the platforms that actually collect them.
How often should I check schema?
Monthly. Markup rots — numbers change, hours change, services get dropped — and stale structured data is an active inaccuracy that machines are reading.