Schema Markup: Which Types Earn Something and Which Are Decoration
Schema markup sorts into three piles: types that change the result, types that only feed understanding, and types that do nothing. Only mark up what a visitor can actually see.
On This Page
A developer adds four hundred lines of JSON-LD across the templates, the validator turns green, everybody screenshots it, and then the team waits for something to happen in the search results. Nothing happens. That is the ordinary outcome, and it is not a fault in the implementation. Most of what was marked up was never capable of changing anything a person sees.
Schema markup is worth doing. It is simply worth doing for narrower reasons than the pitch suggests. The useful move is to sort every type you are considering into three piles: it changes the result, it feeds understanding, or it does nothing at all. Once the piles exist, the argument about what to implement takes about ten minutes.
One rule governs all three piles, and it is the rule people break first: never mark up something a visitor cannot see on the page. Everything else here follows from that, including the parts that will annoy anyone who has been adding ratings to a page with no ratings on it. If you want the wider context for where structured data sits in a technical programme, technical SEO is the discipline it belongs to, not content marketing.
Three piles, and only one of them shows up
Pile one changes what the listing looks like. A price appears, a star rating appears, a set of dates appears, the URL turns into a readable trail. These are the types with a visible payoff, and they are tied to specific kinds of content that search engines have built dedicated formats for.
Pile two changes nothing you can screenshot. It helps a machine work out what this page is, who published it, what it relates to, and which real-world entity the site belongs to. There is no rich result to point at. There is a slow accumulation of clarity, which matters more now that answers get assembled from sources rather than merely listed.
Pile three is inherited. It arrives with a plugin, a theme, or an agency template, it validates cleanly, and it has never done a single thing for the site. Some of it was retired years ago. Some of it never earned anything in the first place. All of it costs bytes, review time, and the credibility of the rest of your markup.
| Type | Pile | What it can earn | Condition |
|---|---|---|---|
| Product | Changes the result | Price, availability and rating shown in the listing | A real product page with that data visible on it |
| BreadcrumbList | Changes the result | A readable trail in place of a raw URL | It matches the breadcrumb the visitor can see |
| Event, Recipe, JobPosting | Changes the result | Dedicated formats, filters and date displays | You genuinely publish that kind of thing |
| Organization | Feeds understanding | Entity resolution, logo, verified profile links | The details are identical everywhere else you appear |
| Article | Feeds understanding | Clear authorship, headline and publication dates | Author and dates are visible on the page itself |
| LocalBusiness | Feeds understanding | Corroboration of place, hours and service area | It matches your business profile exactly |
| FAQPage | Mostly does nothing now | Rich results narrowed to a small set of sites | Emit it for clarity, not for appearance |
| Sitelinks search box | Does nothing | Retired as a search feature | Delete it and reclaim the bytes |
| WebPage on every page | Does nothing | Nothing a visitor will ever see | Skip it unless it carries real relationships |
The visibility rule, and why it is not negotiable
Structured data is a description of a page, offered by the page, and read by something that can check. The whole arrangement runs on the assumption that the description is true. Mark up a rating the page does not display, an author nobody is credited as, or a price that is not the price, and you have not gamed anything. You have written a claim that is trivially falsifiable by the same system you are making it to.
What counts as visible
- Rendered in the page a visitor loads. Not in a comment, not in a hidden container, not injected only for crawlers.
- Reachable without an interaction that hides the content. An accordion is fine, because the text is in the document and expands on click. A tab that fetches its content on demand is a different case, so check it.
- Worded the same way. If the marked-up question and the on-page question differ, one of them is wrong, and a reviewer will assume it is the invisible one.
- Current. A price updated in the template and not in the markup is a mismatch that gets caught automatically, at scale, without anyone reporting you.
What happens when you break it
Usually nothing dramatic. The markup is ignored, quietly, and the effort is wasted. Occasionally it is worse: a manual action against structured data, which removes rich result eligibility from the whole site and takes a reconsideration request to lift. That is a slow, embarrassing way to lose something you already had.
The most common version of this failure is self-serving reviews. A business adds an aggregate rating to its own homepage, describing itself, with no visible reviews anywhere on the page. Reviews about your own organisation, published by your own organisation, sit outside what the feature was built for, and this is one of the few structured-data mistakes genuinely worth losing sleep over.
If you would not be comfortable with a reviewer opening the page and asking “show me where it says that”, do not mark it up. That single test removes most risky structured data before anyone writes a line of it.
The types that change what people see
Product, the strongest of the lot
Product markup does the most visible work available to an ordinary business. Price, currency, availability and, where they legitimately exist, ratings can appear directly in the listing, which changes the decision a person makes before they have clicked anything. Get the availability field right and keep it synchronised with stock, because a listing advertising something you cannot sell is worse than a plain one. This is the part of e-commerce SEO where the markup and the merchandising are genuinely the same job.
BreadcrumbList, the cheapest win on the list
BreadcrumbList replaces a raw URL with a readable path in the result. It takes an hour to implement once, applies to every page on the site, carries no risk provided your breadcrumbs are honest, and is one of the few types where the on-page component and the markup can be generated from exactly the same object. Do it early, then stop thinking about it.
Event, Recipe, JobPosting and their neighbours
These have dedicated result formats because the content type is distinct and the data is structured by nature. If you publish events, mark up events. If you do not, there is nothing here for you, and inventing a reason to use one of these types is how sites end up with markup describing pages that are not what the markup says they are.
The types that feed understanding
Organization: one place, one version, no drift
Organization markup exists to answer a single question: which real thing is this website about? Name, logo, URL, and the profile links that connect the site to accounts you actually control. It earns nothing you can screenshot, and it is still worth writing carefully, because every other assertion about your business hangs off it. Emit it once, from the layout, with a stable identifier that the other types on the page can reference.
Consistency matters more than completeness here. The same legal name, the same logo file, the same profile links, everywhere the organisation appears. Drift between what the site says and what a business profile says is a corroboration problem, and corroboration is the entire mechanism this type takes part in.
For a business with one location and no shopfront, the same reasoning extends to place data, which is a longer conversation covered in local SEO without a storefront. The short version: mark up an address only where the address is genuinely published and genuinely yours.
Article: useful, undramatic, easy to get wrong
Article markup states the headline, the author, the publication date and the modification date. It rarely produces a visible change for an ordinary publisher, and it does clarify authorship and freshness for anything reading the page programmatically. The failure mode is boring and widespread: a modification date updated by a template on every deployment, so every article claims to have been revised today. That is a false statement made automatically, thousands of times, and it teaches a machine to ignore your dates entirely.
Author is the other half. An author property naming a person with no page, no biography and no other work on the site describes nothing at all. The markup is downstream of the editorial decision, which is the argument made in E-E-A-T without the mysticism: publish the evidence first, then describe it. Describing evidence you have not published is the whole problem in miniature.
Structured data describes a page. It does not improve one. When the description is more flattering than the page, the markup becomes a liability.
The types that do nothing, and the ones that stopped
FAQPage is the instructive case, because it used to be the most rewarding type available. Any page could carry a set of questions and answers and gain extra vertical space in the result. Predictably, everything acquired an FAQ section, including pages where questions made no sense. The feature was then narrowed to a small set of authoritative government and health sites, and the extra space vanished for everybody else.
We still emit FAQPage on pages with real, visible FAQs. Not for the appearance, which is gone, but because a marked-up question and answer pair is unusually easy for a machine to lift, attribute and reuse. That is a different bet from the old one, and it is worth taking only where the questions genuinely exist on the page a visitor loads.
The rest of pile three is easier. Sitelinks search box markup was retired and can be deleted. Generic WebPage objects asserting that a page is a page carry no information. Duplicated Organization blocks emitted by three different plugins are a conflict rather than a signal. Speakable and similar niche properties belong to a small set of publishers, and the honest answer for most sites is that they are not one of them.
What schema markup for SEO is actually buying you now
The old case was rich results. That case narrows every year, because features get retired when they are abused, and abuse is what happens to every feature with a visible reward attached to it.
The current case is machine-readability of claims. Answers are increasingly assembled rather than listed, and assembly needs unambiguous statements: this is the organisation, this is the author, this is the price, this was published on this date and revised on that one. Structured data does not make those statements true. It makes true statements legible, which is a smaller job and a genuinely useful one.
That reframing changes what you measure. Impressions on a rich result are a thin measure when the result format has been withdrawn. What holds up better is whether your pages are cited accurately, and whether the facts about your business agree wherever they appear. Setting expectations for that kind of measurement is its own problem, which we have covered in reporting SEO progress before the rankings move.
Implementing it so it survives the next redesign
Most structured data rots because it was written as a separate artefact from the page it describes. Two copies of the same fact will diverge. The only reliable fix is to stop keeping two copies.
- Generate it from the data the page renders. One source, two outputs. If the title comes from a field, the markup reads that field rather than a duplicate string in a plugin setting.
- Emit one graph per page. A single JSON-LD block of linked nodes beats four separate blocks that repeat the organisation three times and disagree once.
- Use stable identifiers. Give the organisation and the site canonical identifiers, then reference them instead of restating everything on every page.
- Keep the dates honest. Publication and modification dates in ISO format, sourced from real content edits, never from the deployment timestamp.
- Use absolute, canonical URLs. Including the trailing-slash convention your site actually serves, so the markup and the canonical tag never point at two different addresses.
- Test the template, not the page. Validate one representative page per template and put it on the release checklist. Page-by-page checking does not scale and does not get done.
All six are easier when the content model is properly typed in the first place, which is the argument for fields that survive the next redesign. A page assembled from named fields can be described accurately. A page that is one large rich-text blob cannot, and no amount of markup fixes that.
Validation, and what a validator will not tell you
A validator checks syntax and required properties. It cannot tell you whether the rating is real, whether the author exists, whether the price matches the checkout, or whether the type suits the page. Green means well-formed, not true. This distinction is why audits so often list “add structured data” as a finding without first asking whether the site has anything to say.
It is worth reading any audit you were handed with that in mind, which our parent company covers directly in how to read an audit you were sold. A list of missing schema types is a tool output. A recommendation is what happens after somebody decides which of them your pages could honestly support.
That gap between output and recommendation is what reporting tools exist to close. Software such as Prooflin resolves raw findings into severities, priorities and reviewable reports, which is the difference between a scan result and a plan somebody can work through on a Tuesday morning.
Before writing any new markup, view the source of five representative pages and list every JSON-LD block already there. Most sites accumulate two or three sources of structured data from plugins and themes, contradicting each other about the organisation name. Removing the conflicts is usually worth more than whatever you were about to add.
Where we would start, and when to stop
The order is short. Organization once, BreadcrumbList everywhere, and the one type your pages genuinely are. Product for a shop. Article for a publication. Event for a venue. Then stop, and spend the remaining effort on the page itself, which is what the markup was describing all along.
The honest concession: for a small site with a handful of pages and no products, the realistic gain from structured data is modest. It is still worth an afternoon, because it is cheap and it makes your facts legible, but it will not rescue thin pages or a site nobody links to. Anyone selling it as a growth lever is selling you an afternoon of work as a strategy.
A useful stopping condition: when the next type you would add describes something the page does not visibly contain, you are finished. Everything past that point is either invention or decoration, and both eventually cost more than they returned. If you would like someone to look at what your templates already assert before you add more, an SEO audit is the right shape of engagement, and you can send us the site if you want a second opinion on what is worth keeping.
Common questions.
Does schema markup improve rankings?
Not directly. Structured data is not a ranking factor in its own right; it describes a page so that a search engine can present or reuse it more precisely. The indirect benefit is real but narrow: eligibility for certain result formats, clearer entity and authorship signals, and fewer ambiguities about prices, dates and relationships. A page that ranks poorly on merit will not be rescued by markup.
Which schema types are worth adding to an ordinary business website?
Organization emitted once from the layout, and BreadcrumbList on every page that shows a visible breadcrumb. Add Article on editorial content where the author and dates are genuinely displayed, and Product on real product pages where price and availability appear. Anything beyond that should be justified by content the site actually publishes, such as events, recipes or job listings.
Is FAQPage schema still worth adding?
It is worth adding only where the questions and answers are genuinely visible on the page. The rich result was narrowed to a small set of authoritative government and health sites, so most publishers gain no extra space in the listing. What remains valuable is machine-readability: a clearly marked question and answer pair is easy for automated systems to lift, attribute and reuse.
Should structured data be JSON-LD or microdata?
JSON-LD, in almost every case. It sits in a single script block, it can be generated from the same data your templates already hold, and it survives a redesign because it is not woven through the HTML. Microdata and RDFa remain valid, but they tie the description to the markup structure, so a front-end change can quietly break the data along with the layout.
Can incorrect schema markup hurt a website?
Yes, in two ways. Most commonly it is simply ignored, so the work is wasted and the site gains nothing at all. Less often, markup describing content the page does not contain can attract a manual action against structured data, which removes rich result eligibility across the site until it is fixed and reviewed. Self-serving reviews about your own business are the usual cause.
Do we need Article schema on every blog post?
It is worth having, provided the values are true. The common mistake is a modification date driven by the deployment pipeline, so every post claims to have been updated today. Set publication and modification dates from real content edits, name an author who has a genuine presence on the site, and keep the headline identical to the one a visitor actually reads.
Facing this in your
own business?
Tell us where you’re headed — we’ll map the shortest honest route.