A developer spends a sprint adding schema markup across the site. Organization, WebSite, WebPage, BreadcrumbList, Article, Person, Service, and a few more. Everything validates. Three months later the search results look exactly the same as before, and somebody asks whether the markup is broken.
It is not broken. Most of it was never capable of changing what the listing looks like, and that was knowable in advance in about two minutes.
Which schema types produce a visible rich result?
A short list, and it is much shorter than the vocabulary. Products, reviews and ratings, recipes, events, videos, job postings, breadcrumbs, and a handful of others are rendered into something you can see. Most types are not.
The schema.org vocabulary describes hundreds of things. Search engines choose which of those descriptions to turn into a search feature, and that choice is made independently of the vocabulary. A type being valid, well-formed, and genuinely accurate does not put it on the list.
How do you check before building anything?
Run the markup — or a competitor's page that already has it — through Google's Rich Results Test. The test reports only the types that are eligible for a rich result, which makes its silence informative.
This is the mechanism worth internalizing. If you paste a page into the Rich Results Test and it reports "no items detected" while the Schema Markup Validator reads the same markup happily, you have your answer: the markup is fine and the type produces nothing visible. Two tools, two minutes, and the sprint gets planned differently.
The second check is Search Console. Its enhancement reports appear for types that can produce a result on your site, so the list of reports in your own account is a site-specific answer rather than a general one.
The Rich Results Test only recognizes types that can produce a rich result. When it detects nothing on a page whose markup validates elsewhere, that silence is the answer — and it costs two minutes to get, rather than a sprint.
What does the rest of the markup do, then?
It describes. That has value, and the value is not visible on the results page, which is why it gets argued about.
Organization markup helps tie a site to a business entity. Breadcrumb markup changes what the URL line shows. Article markup states an author, a publication date, and a publisher in a form that does not depend on parsing the page layout correctly. None of that redraws your listing, and all of it makes the page easier to interpret — including by systems that read pages without rendering them, which is an argument that has grown stronger rather than weaker.
The honest framing is that structured data does two different jobs. One earns a feature. The other earns comprehension. Both are worth doing; only one of them shows up in a screenshot, and confusing the two is how a team concludes schema does not work.
Which types are worth the developer time?
It depends entirely on what the site publishes, which is why a generic implementation list is the wrong artifact.
| Markup | Can change the listing | Worth it when |
|---|---|---|
| Product | Yes — price, availability, ratings | You sell things directly |
| Review and rating | Yes — stars on the listing | You have genuine first-party reviews |
| Recipe | Yes — image, time, ratings | You publish recipes |
| Event | Yes — dates and location | You host or list events |
| Video | Yes — thumbnail and key moments | Video is on the page and central to it |
| Job posting | Yes — a dedicated listing surface | You post jobs |
| Breadcrumb | Yes — the path above the title | Always; it is cheap and sitewide |
| Organization | No | Always; entity clarity, once, sitewide |
| Article | No, on its own | Publishing regularly; author and date clarity |
| Service, WebPage, Person | No | Low cost only; no listing change to expect |
The top rows are eligibility, not a promise — which is the next problem.
Why does valid markup still not show anything?
Because eligibility and display are separate decisions. Valid markup qualifies a page to be shown differently; whether it is shown that way is decided per query, per device, and per page.
Four causes cover nearly all of it. The markup describes something the page does not visibly contain, which is the most common and the most correctable. The page is not considered strong enough for the feature. The query does not call for that presentation — the same page can show stars for one search and not another. Or the type's rules changed, which has happened repeatedly: FAQ markup and how-to markup both had their search appearance scaled back substantially, and sites that had built around them lost the display without losing the markup.
Marking up content that is not on the page. Ratings no visitor can see, an FAQ section that exists only in the markup, a price in the markup and a different one on screen — all of it validates, and all of it is a policy violation rather than a clever shortcut.
Does more markup help?
No. Adding types a page does not warrant produces no additional benefit and adds a maintenance surface that breaks quietly when the template changes.
The failure mode is specific. Markup drifts out of sync with the page — a price changes in the database and not in the product schema, an event date passes, a review schema keeps an aggregate rating for reviews that were removed. Each stale item is worse than no markup, because the page now makes a claim that is checkably false.
Every type you add is something that has to stay true. That is the real cost, and it is ongoing rather than one-time.
What order should you implement in?
Cheapest-permanent first, then the one type that matches what you publish, then stop.
- Organization and breadcrumbs. Sitewide, implemented once, rarely need changing.
- The type that matches your content. Products for a store, events for a venue, jobs for a careers site. One type, generated from the same data the page renders from.
- Article markup if you publish regularly, for author and date clarity rather than for appearance.
- Everything else only when a specific question makes it worth the maintenance.
The second item carries a condition that matters more than the markup itself: generate it from the page's own data source. Hand-written structured data is the version that goes stale, because it is maintained by memory.
How will you know it worked?
Through Search Console, comparing the same pages before and after — and the number to watch is click-through rate rather than position.
A rich result changes how a listing looks, not where it sits. A team that measures a schema project by rankings will usually conclude it did nothing, because ranking is not what it was supposed to move. The enhancement report tells you what is eligible and what is failing validation; the performance report, filtered to the affected pages, tells you whether more people clicked once the listing changed.
Before the next schema ticket gets written, run the pages through the Rich Results Test and find out which of the proposed types the test even acknowledges. The ones it ignores may still be worth adding for comprehension — but they should be scoped as a data quality project and not as something that will change what anyone sees in organic search.