Which Schema Types Still Earn Something
Why the answer changed
Structured data was briefly a growth tactic: add markup, get a visually distinct result, collect the extra clicks. Several of those result types have since been narrowed or withdrawn, and the advice did not update, so teams still implement types that produce nothing visible and skip the ones that still do.
What has not changed is the quieter job markup does, which is stating who you are in a form a machine can read without inference. That earns no rich result and underpins everything that depends on being identifiable, which is why the two purposes are worth separating before deciding what to implement.
Rich result support has narrowed. Here is where markup still pays for itself.
Still valuable
Organization and LocalBusiness for entity clarity. Product for shopping surfaces. Breadcrumb for cleaner results. Article with author and dates for credibility. Review where it is genuine and visible.
These either produce visible results or remove ambiguity for machines, which is now a retrieval advantage.
Reduced but harmless
FAQ and HowTo markup lost most of their rich result display. They still help machines parse structure, so keep them where the content genuinely matches.
Do not add them to pages that are not really FAQs or procedures.
The rule that prevents trouble
Mark up only what a visitor can see on the page. Markup that describes something invisible is the fastest route to a manual action.
Which types still do something
Schema is often sold as a ranking factor, which it is not, and bought as a box to tick, which wastes it. What it does is make a claim machine-readable, and only some claims currently buy you anything visible. Product, review on a product, FAQ in some contexts, breadcrumb, event, recipe and job posting all still produce a result that looks different in a search result page. Most of the rest is documentation for a system that may or may not read it.
That is not an argument against the rest. Organization and Person markup earn nothing visible and do a great deal for entity resolution, which is the foundation everything else sits on. The distinction worth holding is between markup that changes an appearance and markup that states who you are; both are worth having and only one of them shows up in a screenshot.
In one table
| Type | Still earns something visible | Worth implementing |
|---|---|---|
| Product with price and availability | Yes | Essential on commerce |
| Breadcrumb | Yes | Cheap, universal |
| FAQPage | Sometimes, context dependent | Yes, where questions are genuinely on the page |
| Organization and Person | No | Yes, for entity resolution |
| Article with author | Indirectly | Yes, supports authorship signals |
| HowTo | Largely withdrawn | Low priority |
Marking up content that is not on the page
The quickest way to lose rich results entirely is to describe questions, reviews or prices in markup that a visitor cannot find in the page. It is treated as misrepresentation rather than as an error, and the remedy applies to the whole site rather than to the page. Generate the markup from the visible content so the two cannot drift, which is how it is done on this site.
Common questions
Is JSON-LD better than microdata?
Practically, yes: it is separable from the markup, easier to generate correctly and easier to validate. Both are read.
Can schema fix a thin page?
No. It describes a page; it does not add anything to it.
Should we mark up the same thing twice?
No. Duplicate nodes describing one entity with different identifiers create ambiguity rather than emphasis.
How do we know ours is valid?
Validate it in a build step rather than by hand, and assert that every page emits parseable JSON. Hand-checking a thousand pages does not happen.
