Google retired FAQ rich results on May 7, 2026. HowTo rich results have been gone since September 2023. Almost every JSON-LD structured data guide on page one of Google still tells you to implement both.
For a content site in 2026, exactly three schemas still produce visible rich results in search: Article, BreadcrumbList, and Organization. Everything else is either retired, e-commerce-specific, or invisible.
This is the developer’s guide for those three — the copy-paste @graph block that ties them together, the testing workflow most posts skip, and the four mistakes that quietly kill your markup after deploy.
What Actually Produces Rich Results in 2026
Three schemas. Article, BreadcrumbList, and Organization. FAQ and HowTo rich results were retired between 2023 and 2026 and no longer appear in Google search.
Quick timeline. HowTo rich results were dropped on mobile in August 2023 and on desktop the following month. FAQ rich results were officially removed on May 7, 2026 — the Search Console filter retires in June and API support ends in August. If you implement either expecting SERP enhancements, you’re shipping markup that validates and renders nothing.
What still produces visible output:
- Article powers top-stories carousels and article cards.
- BreadcrumbList replaces the URL string in your SERP listing with a structured hierarchy.
- Organization feeds the Knowledge Panel, sitelinks, and the entity record Google maintains about your site.
The case for bothering as the surface shrinks: pages with structured data are 2.3x more likely to appear in AI Overviews, and third-party studies report a +73% citation boost in LLM responses. AI Overviews now appear on roughly 48% of Google queries, up from 31% a year ago. Rich results were the old payoff. AI Overview and LLM citation is the next one, and structured data is the input that gets you in.
JSON-LD vs microdata vs RDFa? Google explicitly recommends JSON-LD. The other two are legacy. Don’t relitigate this.
Three schemas. The question is how you wire them up.
The @graph Pattern: Why You Want One Block, Not Three
Most tutorials show three separate <script type="application/ld+json"> tags — one per schema. That works. It also duplicates your publisher and author entities on every article page, which makes maintenance a chore and quietly bloats your HTML.
The fix is one script tag with a @graph array. Each entity inside gets a stable @id (a URI like https://solid-web.com/#organization), and other entities reference it by @id instead of inlining the full object.
Why bother? Google explicitly supports @graph cross-referencing, and it signals something the duplicated approach can’t: that this Article is published by this specific Organization that already exists in your structured data. It’s the same entity-resolution model behind the Knowledge Graph. Once you’ve referenced your Organization by @id, every Article on your site points to the same node — not to a near-copy of the same fields with slightly different values.
One gotcha: @id is just a string. It doesn’t have to resolve to a real URL. It only has to be stable and unique within your site. The convention is https://yourdomain.com/#entitytype, but https://example.com/orgs/42 would work identically.
The skeleton:
{
"@context": "https://schema.org",
"@graph": [
{ "@type": "Organization", "@id": "https://solid-web.com/#organization" },
{ "@type": "Person", "@id": "https://solid-web.com/#author/nico-brandt" },
{ "@type": "BlogPosting",
"publisher": { "@id": "https://solid-web.com/#organization" },
"author": { "@id": "https://solid-web.com/#author/nico-brandt" }
},
{ "@type": "BreadcrumbList" }
]
}
That’s the shape. Here’s the version you can actually ship.
The Copy-Paste @graph Block for a Content Site
One block, four entities, every cross-reference wired up. Drop this in a <script type="application/ld+json"> tag in your <head> and you have Article, BreadcrumbList, and Organization ready to validate.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://solid-web.com/#organization",
"name": "Solid Web",
"url": "https://solid-web.com",
"logo": {
"@type": "ImageObject",
"url": "https://solid-web.com/logo.png",
"width": 512,
"height": 512
},
"sameAs": [
"https://twitter.com/solidweb",
"https://github.com/solid-web"
]
},
{
"@type": "Person",
"@id": "https://solid-web.com/#author/nico-brandt",
"name": "Nico Brandt",
"url": "https://solid-web.com/authors/nico-brandt",
"sameAs": ["https://twitter.com/nicobrandt"]
},
{
"@type": "BlogPosting",
"@id": "https://solid-web.com/json-ld-structured-data-developer-guide/#article",
"headline": "JSON-LD Structured Data Guide: Only 3 Schemas Still Work in 2026",
"image": "https://solid-web.com/og/json-ld-guide.png",
"datePublished": "2026-05-31T08:00:00+00:00",
"dateModified": "2026-05-31T08:00:00+00:00",
"author": { "@id": "https://solid-web.com/#author/nico-brandt" },
"publisher": { "@id": "https://solid-web.com/#organization" },
"mainEntityOfPage": "https://solid-web.com/json-ld-structured-data-developer-guide/",
"articleSection": "tutorials"
},
{
"@type": "BreadcrumbList",
"itemListElement": [
{ "@type": "ListItem", "position": 1, "name": "Home", "item": "https://solid-web.com" },
{ "@type": "ListItem", "position": 2, "name": "Tutorials", "item": "https://solid-web.com/tutorials" },
{ "@type": "ListItem", "position": 3, "name": "JSON-LD Structured Data Guide" }
]
}
]
}
Three notes to make the field choices defensible.
Organization (your site-wide entity)
name, url, and logo are the load-bearing fields. logo should be an ImageObject with explicit dimensions — Google has been clearer about this requirement since 2024. The sameAs array lists authoritative profiles for the entity: your Twitter, GitHub, Crunchbase, Wikidata — anything that confirms “yes, this is the same organization.”
This block is identical on every page of your site. Put it in your shared layout. Don’t regenerate it per article.
BlogPosting with Author and Publisher refs
Article (and its subtype BlogPosting) has zero required properties per Google’s docs. That’s a trap. The recommended ones — headline, image, datePublished, dateModified, author, publisher, mainEntityOfPage — are what actually makes you eligible for top-stories carousels and article cards.
The two cross-references that matter: publisher and author reference the Organization and Person by @id, not by repeating their full objects. That’s the @graph payoff. Edit your bio once in the Person node and every article on your site updates.
articleSection is optional but cheap. Use your category slug.
BreadcrumbList (the easiest rich result to earn)
If you implement only one schema today, make it this one. BreadcrumbList replaces the URL in your SERP listing with a structured hierarchy, and the field requirements are trivial: an itemListElement array with at least two ListItem objects, each with position, name, and item (a URL).
The last item — the current page — can omit item since the URL is the page. Don’t link a breadcrumb to itself.
That’s the markup. Validating it before you push is where most teams stop bothering.
The Testing Workflow: 4 Tools, In This Order
Each tool catches what the previous one doesn’t.
1. JSON lint (jsonlint.com or jq locally). Run jq . your-schema.json first. The schema you just hand-edited has a trailing comma in it. Or a brace you didn’t close. If this fails, every validator downstream gives you cryptic errors pointing at the wrong line. Two seconds, catches 90% of the silly stuff.
2. Schema.org Validator (validator.schema.org). Catches what JSON lint can’t: invented properties (autohor instead of author), wrong @type values, structural problems with the Schema.org vocabulary itself. Schema.org Validator will tell you BlogPosting doesn’t have a wordCount property at the top level. Rich Results Test won’t.
3. Google Rich Results Test (search.google.com/test/rich-results). The only tool that tells you whether your markup is eligible for a specific rich result. Heads up: Schema.org Validator and Rich Results Test disagree fairly often, and that’s by design. One validates the vocabulary. The other validates Google’s eligibility rules. Pass both.
4. Search Console > Enhancements. The only tool that shows what Google actually saw on your live page after crawl. Lag is one to seven days. This is where you catch hardcoded drift — the dateModified stuck at January 2024 because someone hardcoded it for testing and forgot. Validators say the markup is syntactically perfect. Search Console reveals it’s a lie.
CI/CD bonus: JSON lint and the Schema.org Validator (which has a programmatic endpoint) both run cleanly in a GitHub Action. Make schema validation a required check on any PR that touches your structured-data templates. Catch the trailing comma at PR time, not after deploy. For the full list of checks to gate on before shipping, the web performance checklist covers 20 more.
The 4 Mistakes That Will Get Your Schema Ignored
The code validates. The tests pass. The schema still gets ignored. Here’s why.
1. Overclaiming. You marked up an aggregateRating on a page that doesn’t show the rating to users. Or a Person with a jobTitle that isn’t anywhere in the visible HTML. Google’s policy is explicit: schema must reflect what the user sees. Markup that contradicts the page gets ignored — and if you do it deliberately, can demote your pages.
2. Orphaned entities. You added a Person to your @graph and then forgot to reference it from anywhere. It validates fine. It does nothing. Every entity in your @graph should either be the main entity of the page or be cross-referenced via @id by something that is. If nothing references it, either wire it up or delete it.
3. Hardcoded drift. This is the one Search Console catches and validators don’t. The dateModified someone hardcoded for testing in 2024. The author.name still set to the original writer after the article was rewritten by a different person. The image URL that 404s because the asset was renamed. Templates rot. Schedule a Search Console review every quarter, not just at launch.
4. Implementing FAQPage or HowTo in 2026 expecting rich results. They validate. They render in your <head>. They produce nothing in SERP. Skip them for content sites. If you have a non-SERP reason to keep them — internal navigation, accessibility, AI parseability — fine. Just don’t expect a visual payoff.
The Short Version
So yes — half the JSON-LD guidance you’ll find this year is recommending dead schemas. The honest answer is short enough to paste into Slack.
For a content site in 2026, implement Article (BlogPosting), BreadcrumbList, and Organization in a single @graph block with @id cross-references. Test with JSON lint → Schema.org Validator → Rich Results Test → Search Console. Skip FAQPage and HowTo unless you have a non-SERP reason to keep them.
Why bother as the rich-result surface shrinks? Structured data is becoming the primary input for AI Overviews and LLM citation. Pages with it already show up 2.3x more often in AI Overviews. That trend isn’t reversing.
If you’re tightening up the rest of your site at the same time, the HTTP security headers guide is the next thing worth an afternoon.