Schema markup is a way of labelling the information on a page so that a machine can understand what it means rather than only what it says. A page might contain the text "Open until 7:30 PM"; schema is how you say, in a form a machine can parse, that this is a business, these are its opening hours, and this is its address.
It is invisible to visitors. It sits in the page source, almost always as a block of JSON-LD, and it exists entirely for search engines, AI assistants and any other system reading your site programmatically.
The question most businesses actually have is whether it is worth the effort, and the honest answer has changed in the last two years.
What it does and does not do
Schema is not a ranking factor in the way people hope. Adding it to a page does not, by itself, move that page up the results. Anyone selling schema implementation as a ranking service is misrepresenting it.
What it does is make your page eligible for rich results: the star ratings, the FAQ dropdowns, the recipe cards, the event listings and the product price and availability shown directly in the search results. Those do not change your position, and they substantially change how many people click the position you already have.
It also removes ambiguity. A search engine reading an unlabelled page infers what things mean and sometimes infers wrongly. Schema removes the guesswork, which matters most for the facts you cannot afford to have wrong: your address, your hours, your phone number, what you sell and what it costs.
The second-order effect is that clear structured data tends to correlate with pages that are well organised generally, and those do rank better. But the schema is a symptom there rather than a cause.
The types worth implementing
There are hundreds of schema types and most businesses need a handful. Implementing the rest is effort with no return.
| Type | Who needs it | What it earns |
|---|---|---|
| Organization / LocalBusiness | Every business | Knowledge panel accuracy, local relevance |
| BreadcrumbList | Any site with sections | Cleaner result paths instead of raw URLs |
| FAQPage | Pages answering real questions | Expanded results, and quotable answers |
| Product | eCommerce | Price, availability and ratings in results |
| Article / BlogPosting | Anyone publishing | Eligibility in news and discovery surfaces |
| Service | Service businesses | Clarity on what you offer and where |
| Review / AggregateRating | Businesses with genuine reviews | Star ratings, where policy permits |
A warning on review markup
Marking up reviews that are not genuine first-hand customer feedback breaches Google policy and risks a manual action that removes rich results across your whole site. It is far more damaging than having no review markup at all. Only mark up reviews you can evidence.
Why it matters more now than it did
The case for schema used to rest almost entirely on rich results, which made it a modest optimisation. That has changed with how people search.
A growing share of queries are now answered rather than listed. Someone asks an assistant a question in plain language and receives a composed answer, sometimes with sources and sometimes without. Whether your business appears in that answer depends on whether the system could understand what you are, what you do and where.
Those systems work from crawled text and structured data. They do not interpret a capability statement in a PDF, cannot read a price embedded in an image, and cannot infer opening hours from a graphic. A business whose key facts exist only in unstructured form is significantly less likely to be surfaced.
That makes schema less about earning a star rating and more about being legible at all in a channel that is growing. It is the same work with a different and larger justification.
Getting it wrong
Bad schema is worse than none, and the failure modes are consistent.
The most common is markup that does not match the visible page. Schema claiming a rating, a price or an event that a human reader cannot find on the page is a policy violation, and Google both ignores it and may penalise it. The rule is simple: mark up what is actually there.
The second is stale data. Schema is frequently implemented once and never touched, so it goes on declaring an old phone number, superseded prices or hours that changed two years ago. Because it is invisible to visitors, nobody notices, and the wrong data is the version machines trust.
The third is duplication and conflict, usually from a plugin generating one set of markup while a theme generates another, leaving two contradictory descriptions of the same business on the same page.
Validate after implementing and after any significant change, using Google Rich Results Test and the Schema.org validator. It takes minutes and catches almost all of this.
In practice
Key takeaways
- Schema is not a ranking factor. It makes you eligible for rich results and legible to machines.
- Most businesses need a handful of types: Organization, Breadcrumb, FAQ, and Product or Service.
- It matters more now because AI assistants answer questions from structured data rather than listing links.
- Markup must match what is visible on the page. Claiming what is not there is a policy violation.
- Invisible data goes stale unnoticed. Review it whenever hours, prices or contact details change.
- Never mark up reviews that are not genuine, verifiable customer feedback.
Frequently asked
Not directly. Adding schema does not move a page up the results. What it does is make the page eligible for rich results such as star ratings, FAQ dropdowns and product prices, which change how many people click the position you already hold. Anyone selling schema as a ranking service is misrepresenting what it does.
Organization or LocalBusiness for every business, BreadcrumbList for any site with sections, FAQPage where you genuinely answer questions, and then Product for eCommerce or Service for a service business. That covers almost all the available benefit. Implementing beyond that is effort with little return.
Yes, in two ways. Markup describing things not visible on the page is a policy violation and can trigger a manual action. And review markup for reviews that are not genuine first-hand customer feedback risks a manual action removing rich results site-wide, which is considerably worse than having no markup at all.
Because a growing share of queries are answered rather than listed, and those systems work from crawled text and structured data. They cannot read a price in an image, a capability statement in a PDF, or infer hours from a graphic. A business whose key facts exist only in unstructured form is much less likely to appear in a composed answer.