I audited a site last year with 4,100 pages and perfectly valid schema on every single one. Article type, headline, image, datePublished, author as a plain text string. Zero errors in every validator.
It was also completely useless. Nothing in that markup told a machine what the company did, who the author was, what products they sold, how the pages related to each other, or why anyone should believe them. It was schema as compliance theater.
Structured data stopped being about rich snippets a while ago. Its real job now is entity resolution: telling machines what things exist in your business and how they connect. Almost nobody implements it that way.
The three tiers, and where you probably stopped
Tier one, decoration. Article, BreadcrumbList, WebSite with SearchAction. Produces some visual rich results. Nearly universal. Nearly worthless as differentiation because everyone has it.
Tier two, description. Product with full attributes, FAQPage where questions genuinely exist, HowTo with real steps, Event, Recipe, JobPosting. Drives specific SERP features. Maybe a third of sites do this properly.
Tier three, identity. Organization and Person nodes with sameAs, connected by @id references across the whole site, so every page points back to the same canonical entity. Fewer than one site in twenty does this. It is also the tier that matters most now, for the reasons I laid out in entity SEO and knowledge panels.
The @id graph is the whole trick
Most implementations treat each page's JSON-LD as an island. Page A says the author is "Pierre Subeh." Page B says the author is "Pierre Subeh." A machine sees two strings and has to guess they are the same person.
Instead, define your entities once at stable URIs and reference them everywhere.
Create a Person node at https://yoursite.com/#pierre with name, jobTitle, image, description, worksFor pointing at your Organization node, and sameAs pointing at every profile that genuinely exists and is genuinely yours. Create the Organization node at https://yoursite.com/#organization. Then every article on the site sets "author": {"@id": "https://yoursite.com/#pierre"} rather than repeating a string.
Now four thousand pages resolve to one person and one company. That is a graph, not a pile of tags, and it is the difference between a machine guessing and a machine knowing.
The sameAs rule I enforce: only list profiles that are active, accurate, and that link back to you where possible. A sameAs pointing at an abandoned account with a different bio actively hurts, because it introduces contradiction into the thing you are trying to make unambiguous.
Types worth implementing that almost nobody does
Service and offers, for agencies and consultancies. If you sell services, Product schema is wrong and Service is right, with areaServed, provider referencing your Organization @id, and hasOfferCatalog listing what you actually do. This is how a machine learns that you do technical SEO in Florida rather than inferring it from paragraph text.
About and mentions. Two of the most underused properties in the vocabulary. about declares the primary topic of a page as an entity, not a keyword. mentions declares secondary entities. Pointing these at Wikipedia or Wikidata URIs disambiguates aggressively. An article about Apple Music becomes unmistakably about the streaming service rather than fruit or the record label.
SpeakableSpecification. Marks the passages of a page that are suitable to be read aloud. Whatever its original voice search purpose, declaring which two or three passages are the summary of your page is a useful hint about what to extract. Related to the ideas in voice search optimization, though the application has broadened.
ImageObject with creditText and license. Matters more than people think for anyone whose images get reused. It attaches attribution to your assets at the data layer.
Course, Dataset, SoftwareApplication. Category specific, but if you publish any of these and describe them only in prose, you are leaving a structured description on the table.
Where implementations break
Markup that disagrees with the page. Schema claiming a 4.8 rating from 200 reviews on a page displaying eleven reviews. This is the fastest way to get all your rich results suppressed and it happens constantly through plugin defaults.
Schema injected after render. If your markup is added by a tag manager or a client side script, assume some crawlers never see it. Server render it.
Orphan FAQ blocks. FAQPage schema for questions that do not appear visibly on the page. Also, three FAQ items bolted onto every page because a plugin does it automatically. Both patterns get ignored at best.
Multiple contradictory blocks. Theme adds one, SEO plugin adds another, a page builder adds a third. Now three Organization nodes disagree about your phone number. I find this on roughly half the WordPress audits I run. Consolidate to one source of truth.
Never validating after launch. Ship it, validate it, then validate again in three months, because a plugin update will silently change it.
Build the initial block with a schema markup generator if you want a clean starting point, then hand edit the @id wiring, because no generator does the graph part for you.
How I sequence a real implementation
Week one: define the Organization and Person nodes at stable @ids. Get the sameAs list right. Put them on every page, ideally through the template.
Week two: correct types on money pages. Service or Product with complete attributes. Kill any markup that contradicts visible content.
Week three: add about and mentions with authoritative URIs to the twenty pages that matter most. Not all four thousand. The top twenty.
Week four: internal consistency pass. One block per page, server rendered, validated, no duplicate entities.
Then leave it alone and re-audit quarterly. Structured data is infrastructure, not a campaign.
What it will and will not do
It will not rescue thin content. I have never seen schema rank a page that deserved nothing. If the content is weak, fix the content first, using the standards in content that ranks and converts.
It will make you legible. In a world where retrieval systems have to decide fast whether you are a real entity that plausibly knows a thing, legibility is a compounding advantage. It is also the substrate under everything in the technical SEO checklist that deals with how machines interpret rather than access your site.
The one thing to do this week
Open your homepage source, find your JSON-LD, and answer one question: does it contain a single Organization node with a stable @id that the rest of your site references?
If the answer is no, that is a two hour fix with a longer half life than anything else on your SEO backlog. Every page you have already published and every page you publish for the next five years inherits the benefit. I cannot think of another technical task with that ratio.