Introduction
Schema markup is code that tells search engines what a page is about, who published it and how its parts connect. It uses the Schema.org vocabulary, usually written as JSON-LD. Done well, it removes guesswork for crawlers. Done badly, it adds noise.
It does not guarantee higher rankings, featured snippets or AI citations. Google is clear on that. What it does is describe real content in a form machines can read. For some page types, it also makes a page eligible for a specific search feature.
This guide covers entity-based markup, @id, @graph, rich-result eligibility, AI search and validation. It includes three working JSON-LD examples. Treat them as starting points, not code to paste blindly.
Table of Contents
What Schema Markup Actually Does for SEO
Schema markup describes your content in a shared language. It helps search engines read a page more accurately. It does not act as a ranking lever.
Schema.org Vocabulary, Structured Data Formats and Google Features
Schema.org is a shared vocabulary. It defines types such as Article and Service, plus the properties that describe them. JSON-LD is one way to write that vocabulary into a page. Microdata and RDFa are others. Google recommends JSON-LD, and it is easier to maintain because it sits apart from your HTML.
A type existing in Schema.org does not mean Google shows a rich result for it. The vocabulary is huge. Google’s supported features are a much shorter list.
Semantic Context, Search Eligibility and Ranking Claims
Structured data tells a machine what a page and its entities are. This is an article. That person wrote it. This organisation published it. That is a semantic description.
Rich-result eligibility is a separate matter. It depends on Google’s documented requirements for each feature. Ranking is separate again, and Google does not present structured data as a shortcut.
So accuracy beats volume. Five correct properties that match the visible page are worth more than thirty padded ones.
Schema Markup’s Role in Google Search, Rich Results and AI Search
Valid markup and search features are not the same thing. Schema can help Google understand a page. Google’s systems still decide what to show.
Google-Supported Rich Results and Eligibility Requirements
Markup can be perfectly valid and still earn nothing. Eligibility depends on the feature’s own rules. Article, Breadcrumb and Product are all supported in some form. Check Google’s current list of supported structured data types before you plan any work, because that list changes.
Featured Snippets Depend on Content Selection
Schema does not trigger featured snippets. Google’s systems pick them from page content. Clear answer passages help, as do descriptive headings. Lists and tables also give those systems something tidy to lift. Write the page for the reader and the snippet usually follows, or it doesn’t.
AI Overviews and AI Mode Use Existing SEO Fundamentals
Google says AI Overviews and AI Mode have no extra technical requirements. They also need no special schema markup. A page must be crawlable, indexed and useful. Structured data should match what visitors can see. That is the whole brief.
If you want help applying those basics, our AI search optimisation work starts there too.
Schema’s Role Across Search Outcomes
Area | Schema’s role |
Google Search understanding | Direct. Describes the page and its entities. |
Rich-result eligibility | Direct, but only for supported features that meet Google’s rules. |
Featured snippets | None. Google selects page content. |
AI Overviews | No special markup required. Depends on Google’s systems. |
AI Mode | No special markup required. Depends on Google’s systems. |
Rankings | No guaranteed effect. |
Entity understanding | Descriptive. Helps state what an entity is. Recognition is not promised. |
Click-through rate (CTR) | Measure it. Do not assume a change. |
Conversions | Measure it. Many other factors apply. |
Building an Entity-First Schema Strategy
Start with what is really on the page, then mark that up. This is entity SEO in practice, and it supports a wider content strategy.
Identify the Main Entities on Each Page
List the things a page is genuinely about. A service page has a service and a provider. A blog post has an article, an author and a publisher. A shop page has a product. A branch page has a physical location.
If an entity isn’t visible or relevant on the page, leave it out.
Map Relationships Across the Website
Relationships carry the real meaning. An author wrote an article. A publisher released it. A service belongs to a provider. These links should mirror how the business actually works.
One coherent set of links beats five unrelated types stacked on one URL. Stacking looks thorough. It tells a machine very little.
Align Entity Markup with URLs and Site Architecture
Your structured data should agree with your site. Use canonical URLs in your markup. Make sure internal links point where the schema says they do. Reuse the same entity references across pages, and build them into page templates.
This gives you consistency. It does not promise rankings or entity recognition.
Connecting Entities with @id and @graph
Two JSON-LD features turn loose objects into a connected set. They are @id and @graph.
Use Stable Identifiers for Reusable Entities
An @id gives an entity a fixed identifier. Other markup can then point to it instead of repeating the details. Pick one URL-style identifier per entity and never change it. An organisation might look like this:
json
{ “@id”: “https://example.co.uk/#organisation” }
An article or service on any page can reuse that reference as its publisher or provider.
Organise Related Entities with @graph
@graph groups several entity descriptions in one JSON-LD block. The @id values link them together, so nothing sits alone. Here is a compact example for an article page:
json
{
“@context”: “https://schema.org”,
“@graph”: [
{
“@type”: “Organisation”,
“@id”: “https://example.co.uk/#organisation”,
“name”: “Example Agency”,
“url”: “https://example.co.uk/”
},
{
“@type”: “Person”,
“@id”: “https://example.co.uk/team/jane-smith/#person”,
“name”: “Jane Smith”,
“worksFor”: { “@id”: “https://example.co.uk/#organisation” }
},
{
“@type”: “BlogPosting”,
“@id”: “https://example.co.uk/blog/schema-guide/#article”,
“headline”: “Schema Markup Guide”,
“datePublished”: “2026-03-04”,
“dateModified”: “2026-09-18”,
“mainEntityOfPage”: “https://example.co.uk/blog/schema-guide/”,
“author”: { “@id”: “https://example.co.uk/team/jane-smith/#person” },
“publisher”: { “@id”: “https://example.co.uk/#organisation” }
}
]
}
Prevent Duplicate and Conflicting Entity Definitions
Conflicts are common. A theme outputs one organisation ID. A plugin outputs another. Someone then pastes a third by hand. The same business now has three descriptions.
View the rendered source and search for “@type”. Count how many times each entity appears. Keep one definition, align every reference to its @id, and switch off the duplicate source. Check canonical URLs that match your IDs too.
Selecting and Implementing Schema for Different Page Types
Choose markup from the page’s content and purpose. Don’t choose it from a list of types you’d like to use.
Article Pages with Blog Posting, Person and Organisation
The graph above is the pattern. Some properties describe the article itself. These are headline, datePublished, dateModified and mainEntityOfPage. Others point to people and organisations, namely authors and publishers.
Keep dates honest. Change dateModified only when the content really changes. A fresh date on an untouched page is an easy mistake and an easy one to spot.
Service Pages with Service and Organisation
A service entity connects to the organisation that provides it:
json
{
“@context”: “https://schema.org”,
“@type”: “Service”,
“@id”: “https://example.co.uk/services/boiler-repair/#service”,
“name”: “Boiler Repair”,
“url”: “https://example.co.uk/services/boiler-repair/”,
“provider”: { “@id”: “https://example.co.uk/#organisation” },
“areaServed”: { “@type”: “City”, “name”: “Leicester” }
}
Here, name states the service, provider names who offers it, areaServed sets the area, and url points to the page. This describes the service in Schema.org terms. It is not a standalone Google rich-result opportunity.
Product Pages with Product, Offer and Genuine Review Data
json
{
“@context”: “https://schema.org”,
“@type”: “Product”,
“name”: “Oak Desk Organiser”,
“image”: “https://example.co.uk/images/organiser.jpg”,
“offers”: {
“@type”: “Offer”,
“price”: “34.00”,
“priceCurrency”: “GBP”,
“availability”: “https://schema.org/InStock”
},
“aggregateRating”: {
“@type”: “AggregateRating”,
“ratingValue”: “4.6”,
“reviewCount”: “112”
}
}
Price and currency must match the page. Availability must reflect real stock. Ratings must come from genuine reviews, visible where Google requires it. Google also separates merchant product pages from editorial reviews, so read its policy for yours. If you run a shop, our e-commerce SEO team sees these errors often.
Supporting Schema Types and Feature-Specific Requirements
BreadcrumbList suits pages with a clear hierarchy. The organisation belongs on the page that properly describes the business. LocalBusiness fits a real, physical location. Pick each type for the content in front of you.
One change matters for 2026. Google stopped showing FAQ rich results on 7 May 2026 and removed its documentation in June 2026. So don’t use FAQPage to chase Google FAQ rich results. This may change again, so check Google’s current documentation.
Validating, Deploying and Troubleshooting Schema Markup
Test before release and after it. Passing a test is a good sign, not a promise.
Check Syntax, Vocabulary and Google Feature Eligibility
The Schema.org Validator checks syntax and vocabulary. It tells you whether your JSON-LD is well-formed and uses real types. It says nothing about Google features.
Google’s Rich Results Test checks eligibility for supported features. URL Inspection in Search Console shows how Google sees a specific live page. None of them can confirm a rich result will appear. A pass means the markup is eligible.
Resolve Common Implementation Errors
Most faults fall into a few groups:
- Duplicate markup: find every source in the rendered HTML and remove the extras.
- Conflicting identifiers: pick one @id per entity and update every reference.
- Invalid values: fix the property format flagged in the test, such as dates or prices.
- Wrong publication dates: compare them with the visible page.
- Canonical mismatches: make markup URLs match the canonical tag.
- Blocked images: confirm Google can crawl each image URL.
- Content mismatches: edit the markup or the page so they agree.
A technical SEO audit will usually surface several of these at once.
Test Changes Before Rolling Them Out Across the Website
Test a handful of representative URLs first. Check the rendered page, not just your template. Review any markup your CMS generates alongside your own.
After release, watch Search Console for new errors. Inspect pages again whenever a template or script changes. A plugin update can quietly rewrite your output.
Measuring and Maintaining Schema at Scale
Measure what happened. Don’t assume schema caused it.
Establish a Baseline for Eligibility and Search Performance
Before you change anything, record the current state. Note markup validity and the relevant enhancement reports. List the search appearances you currently have. Save existing organic performance too. Without a baseline, any later comparison is guesswork.
Assess CTR and Conversions Without Assuming Causation
Look at impressions, clicks and CTR in Google Search Console. Add conversions where you have the data. Then ask what else moved. Content edits, ranking shifts, seasonal demand and changes in how results look can all affect the numbers. Only after ruling those out should you credit the schema, and even then say “likely”, not “proved”.
Maintain Consistency Across Templates and Content Updates
Give every template an owner. Add a schema check to your release routine. Audit on a schedule. Review markup after CMS updates, site migrations and any change to products or services. The schema that was right a year ago can be wrong today.
Conclusion
Good schema describes real entities, visible content and meaningful relationships. It isn’t about adding as much markup as possible.
Connected JSON-LD, sensible type selection, proper validation and steady measurement all work together. None of them guarantees a result, and that is fine. Accurate markup is a solid foundation.
If you want a second pair of eyes on your structured data, our SEO services include technical SEO consultancy. We’re happy to look.
Frequently Asked Questions
Do I need a special schema for AI Overviews or AI Mode?
No. Google says there are no extra technical or schema requirements for either.
Should I still add FAQPage markup?
Not to win Google FAQ rich results. Google stopped showing them on 7 May 2026. It is fine as a plain description if it matches visible content.
Which format should I use?
JSON-LD. Google recommends it, and it is easier to maintain than Microdata or RDFa.
How often should structured data be checked?
Review it after website migrations, CMS updates, template changes and significant content updates. Regular checks help identify invalid properties, outdated information and conflicts between different implementations.
What happens when structured data does not match the visible page?
Google requires structured data to represent the page’s actual content accurately. Inaccurate or misleading information can make a page ineligible for rich results. Update the code so it reflects the information visitors can see.
