Technical SEO
Does schema markup help SEO?
A five-gate test for deciding whether structured data is likely to earn a useful search appearance and how to measure the result.
Schema markup can help search engine optimisation (SEO) by making an eligible page available for richer search appearances, but it isn’t a general organic ranking factor and can’t turn an unhelpful page into a strong result.
That distinction matters because schema projects are often sold through a chain of assumptions: valid code means a rich result, a rich result means more clicks and more clicks mean more business. Each step is possible, but none follows automatically from the one before it.
Google states that structured data by itself is not a generic ranking factor. It can help Google understand a page and make that page eligible for additional search experiences. Eligibility is an opportunity, not an outcome.
Use five gates to decide whether the work is likely to help:
- Does Google support a relevant search feature?
- Does the markup describe the visible page accurately?
- Is the implementation valid and accessible?
- Does the richer appearance actually show?
- Does that appearance improve a result that matters?
If a proposal can’t pass the first three gates before launch or explain how the last two will be measured afterwards, it isn’t a credible SEO case yet.
How structured data and schema markup work
What is structured data?
Structured data is a standardised way to label information so that software can identify what each part of a page means. For example, a recipe can label its ingredients, cooking time and nutrition rather than leaving a search engine to infer each detail from the page copy. The labels don’t change what a visitor sees on the page.
Google’s introduction to structured data describes these labels as explicit clues about a page’s meaning. The data is commonly added as JavaScript Object Notation for Linked Data (JSON-LD), a machine-readable block in the page code.
What is schema markup?
Schema markup is structured data that uses the shared vocabulary published by Schema.org. That vocabulary includes types such as Product, Event, Article and Organization, together with properties that describe each type. Product markup might label the product’s name, price and availability while the visible product page continues to serve visitors as normal.
The phrases ‘schema markup’ and ‘structured data’ are often used as if they mean the same thing. Schema markup is one widely used form of structured data, while a search engine decides which parts of the vocabulary it supports and how it may use them.
What are rich results?
Rich results are Google search listings with extra visual or interactive information that often comes from structured data. A supported product result might show a price, availability or review information that helps a searcher judge the page before clicking. Google’s search gallery lists the structured data features it currently supports for these appearances.
How the three checks differ
These three checks are related but separate:
- Schema.org validity asks whether the vocabulary and code are valid in the broader standard.
- Google rich result eligibility asks whether the page meets Google’s requirements for a supported Search feature.
- Search performance asks whether the feature appeared and changed impressions, clicks or a later business result.
A page can pass the first test without passing the second and can pass both without ever producing a visible rich result.
The five-gate test
Gate 1: a supported feature
A schema project passes the first gate only when Google supports a relevant search feature for the page. Start with the appearance you want rather than a schema type you’ve found.
Google supports structured data for particular features and page situations. A product page, recipe, event or job listing may have a documented Search feature. A normal service page may have perfectly valid Service markup in Schema.org without a corresponding Google rich result.
That doesn’t make the service markup false or useless to every system. However, it does mean that a promise of a Google rich result needs more evidence. The current Search gallery, rather than a plugin’s list of available types, is the source to check.
FAQ markup is a useful warning against treating a familiar schema type as a must-have. Google says FAQ rich results are limited to well-known authoritative government and health websites. For most other sites, valid FAQPage markup won’t create a regularly visible FAQ result, so a proposal needs a different benefit before the work can be justified.
Search features also change. Google began phasing out several lesser-used structured data displays in 2025 and later removed support for those types from its Search Console reporting tools. A feature that justified implementation two years ago may not justify continued maintenance now.
Before approving work, ask:
- Which current Google Search feature is the page meant to qualify for?
- Does the page fit the documented use case?
- Is the feature available for the relevant country, language and device?
- What will remain valuable if Google changes or removes the appearance?
If there’s no supported feature and no other named service that will use the data, stop calling the work a rich result project. Another service may still have a clear use for the labels, but that’s a different case.
Gate 2: an accurate match to the page
A schema project passes the second gate only when the markup accurately describes what a visitor can see. Adding a highly specific type doesn’t make the page itself more specific, useful or trustworthy.
Google’s general structured data guidelines require markup to represent the page’s main content and forbid hidden, irrelevant or misleading information. The page must also meet the rules for the particular feature.
This is where many template-based setups become risky. An online shop plugin may create Product markup on category pages, or a review tool may mark up ratings that aren’t shown to visitors. A sitewide template may copy the same organisation, author or page data into places where it no longer matches.
Ask the person doing the work to review a real sample from every affected template. They should compare the marked-up name, description, image, price, availability, rating, author or date with the visible page. Required properties need to be present, but completeness shouldn’t come at the expense of accuracy.
Fewer accurate properties are safer than a long block of invented or stale values.
Gate 3: a valid and accessible implementation
A schema project passes the third gate only when the markup is valid and Google can access it on the intended page. Test the code and the page delivery together.
Google recommends JSON-LD in most cases, although it accepts other formats too. The format matters less than whether the markup is complete, consistent and available when Google processes the page.
The person checking the work should use the Rich Results Test to check eligibility for Google-supported features. They should use the Schema Markup Validator when broader Schema.org validation is useful. The tools answer related but different questions.
A green result doesn’t prove that the page will receive a rich result. It shows that the tested code met the tool’s detectable requirements at that moment. Google’s guidelines explicitly say that a correct result in the test doesn’t guarantee a rich appearance.
Ask them to check delivery as well as syntax:
- Google’s crawler can access the page and any information needed to generate the markup.
- The redirect and indexing rules agree about the preferred web address.
- The structured data describes the final page rather than an old or alternate version.
- Server-rendered and JavaScript-generated versions don’t conflict.
- A representative sample from every template passes the appropriate test.
If the code changes through JavaScript, ask the person checking the work to compare the source and rendered output. The rendering audit sequence helps them separate an inaccessible resource or broken response from a genuine rendering fault.
Gate 4: an appearance that actually shows
A schema project passes the fourth gate only when the intended rich appearance is shown for real searches. Valid markup creates eligibility rather than a booking for a particular search layout.
Google selects the result format it considers useful for each search. It may show a normal text result even when the page meets the structured data guidelines. Appearance can vary by query, location, device and time.
After release, ask a specialist with Google Search Console access to use its page inspection tool and confirm that Google can process the live page. They should review any applicable rich result or enhancement report for errors across the template, then check the Performance report for the search appearance if Google provides a filter for it.
Don’t treat an occasional manual search as the main proof. Your own result can be influenced by location, device and search history, and the feature may appear for only a subset of queries.
Record the deployment date and keep examples of affected URLs. That gives later changes a reference point and makes it easier to distinguish a site release from a search feature change.
Gate 5: measurable value
A schema project passes the final gate only when the richer appearance improves an outcome worth having.
A rich result can make a listing more prominent or help a searcher judge its relevance before clicking. That may improve click-through rate (CTR), which is the share of views that lead to a click, but the result may instead answer more of the question on Google or have no clear effect.
Google recommends a before-and-after comparison using pages with enough Search Console history. Choose a stable group of pages, add the markup to a useful test set, confirm that Google found it and compare performance for several months. Avoid pages dominated by seasonality or a simultaneous redesign.
Track the chain rather than one headline number:
| Evidence | What it can tell you | What it can’t prove alone |
|---|---|---|
| Valid test result | The tested markup meets detectable requirements. | That Google will show a rich result. |
| Search Console enhancement report | Google found valid or invalid items at scale. | That a valid item appeared for a query. |
| Search appearance impressions | The measured appearance was shown. | That markup caused more rankings or demand. |
| Click-through rate | Click behaviour changed for those impressions. | That the change produced better enquiries or sales. |
| Analytics and conversion data | Visits led to recorded actions on the site. | That structured data was the only cause. |
If traffic is too low to support a useful comparison, say so. Keep the implementation correct and monitor it, but don’t turn a small movement into proof of return.
Does schema markup improve rankings?
Schema markup isn’t a ranking factor for organic search and shouldn’t be considered a general shortcut to higher positions. Google’s published answer is that structured data by itself isn’t a generic ranking factor.
Schema markup may still support better search performance through a different route. Accurate markup can help Google understand the page, qualify it for a supported appearance and make the result more useful or noticeable. The richer appearance may then change clicks, but the site needs evidence at each stage rather than treating these separate effects as one promise.
This is why a ranking report alone is a poor schema measurement plan. A position can change because content, links, competitors, search demand or Google’s systems changed. Start by checking whether the intended rich appearance was even available and shown.
Which schema markup should a website add first?
A website should add schema markup first where the page content, a supported search feature and a measurable purpose line up. Use four checks to set the order:
- The page already contains the information visibly and accurately.
- Google currently supports a relevant feature.
- The page type occurs often enough for implementation and maintenance to be worthwhile.
- The site has enough impressions or business value to measure or justify the work.
For many websites, breadcrumb, product, article, event, job or organisation information may be relevant, but the right choice depends on the real pages and Google’s current documentation. Don’t add every type a plugin offers.
Site owners should also separate baseline markup from an SEO experiment. Keeping organisation and page information consistent can be useful even when no special appearance is expected. A rich result project needs the additional promise, test and measurement plan.
Build an evidence brief before implementation
The five gates are easier to use when the target, affected pages, technical checks and measurement plan are recorded together. The separate schema markup evidence checklist expands each gate into questions for the person doing the work and keeps the answers available for later review.
Build your schema markup evidence brief Define the target feature, compare the evidence and export a record for implementation and review.The checklist doesn’t produce a score or promise a rich result. It helps you confirm which gate each piece of evidence supports, while the person implementing or checking the markup remains responsible for the technical work.
Treat schema as an eligibility system
Schema markup helps SEO when accurate and accessible data qualifies a suitable page for a useful search experience and that experience produces a measurable benefit. It doesn’t create a general ranking boost, guarantee a rich result or compensate for weak content.
Start with the supported feature, check that the page and markup match, then validate the live setup and measure whether the appearance is shown. The measured result should decide whether continued maintenance is worthwhile.
That five-gate test turns schema from a box-ticking exercise into a claim that can be checked.
