The JSON-LD Mistakes That Are Quietly Costing You Rich Results in 2026

Most sites running JSON-LD today would fail a basic sanity check: paste their structured data into a validator and see what actually comes out. Not "is it optimized." Just: does it parse. Does it point to one entity or three conflicting ones. Is it markup for a rich result Google still gives out.

Schema has become a checkbox — a plugin gets installed, a template gets copied from a blog post, and everyone assumes it's working because nothing on the page visibly changed. Structured data failures are invisible by design. There's no broken layout to notice. There's just a Knowledge Graph that never quite understands who you are, and rich results that never show up, and nobody debugging it because nothing looks wrong.

What JSON-LD is actually doing in 2026

Two different jobs get lumped under "schema markup," and conflating them is where a lot of wasted effort starts.

The first job is rich results: the visual enhancements in the SERP — star ratings, price ranges, event dates, job listings, breadcrumbs, video thumbnails. A narrow set of @types qualify, and Google changes that set without much warning.

The second job is entity clarity: telling Google who you are, what you're part of, and how your pages relate to each other. Organization, WebSite, Person, and WebPage mostly do this job. They rarely produce a visible snippet on their own, but they're what the Knowledge Panel, sitelinks search box, and brand disambiguation draw from.

Most of the schema mistakes worth fixing fall into one of three buckets, and none of them are subtle once you know where to look.

Mistake 1: Broken JSON from template escaping

This is the most common failure and the least visible. It happens at the seam between your CMS and your <script type="application/ld+json"> tag.

A review quote with a stray double quote inside it. A product description pasted from a spec sheet with a raw line break in the middle. Any of these, dropped into a JSON-LD template via naive string concatenation instead of proper serialization, produces something like this:

{
  "@type": "Product",
  "name": "Editor's Choice Desk Lamp",
  "description": "The reviewer called it "the best lamp under $50""
}

That unescaped inner double quote breaks the JSON parser at exactly that point. Google's Rich Results Test will flag it as invalid — but that test usually gets run once, at launch, against a hand-picked URL. Nobody re-runs it against the 400 product pages that ship six months later with a new copywriter's punctuation habits.

The fix isn't complicated: never hand-build the JSON string. Build the object in your templating language and serialize it properly (JSON.stringify in JS, json_encode in PHP, the equivalent in whatever renders your pages) so escaping is handled by code that knows what JSON is, not by a template author who doesn't. Then validate the rendered HTML — the actual response a crawler sees — not the template source. A template can look perfect and still ship broken JSON for any string with a special character in it.

Mistake 2: Duplicate Organization entities with no shared @id

This one shows up almost every time a site has been through a redesign, a CMS migration, or more than one SEO plugin at the same time.

The theme emits an Organization block in the footer. A plugin emits another one on every page, with a slightly different logo and sameAs list. A developer added a third, by hand, on the homepage, two years ago, for a schema markup test that never got cleaned up. None of them share an @id.

To Google, three Organization objects with no shared identifier don't read as "one business described three times." They read as ambiguous — possibly three different entities, possibly duplicate signals that cancel each other out. That ambiguity is exactly what entity markup is supposed to prevent.

The fix is a single canonical @id, minted once and referenced everywhere:

{
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Co",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png",
  "sameAs": ["https://www.linkedin.com/company/example"]
}

Every other page then references that @id instead of restating the object — a WebSite's publisher, an Article's author or publisher, a WebPage's isPartOf. One entity, one set of facts, referenced consistently. This is graph modeling, not decoration, and it's the difference between Google merging your signals and Google hedging on which version of you to trust.

Mistake 3: Schema types that stopped earning anything

Google narrowed FAQ rich results in August 2023 to a small set of government and health sites, then removed the feature from Search entirely — that carve-out is gone too. FAQPage markup is still copy-pasted into template libraries and CMS plugins as a default best practice, and plenty of B2B and e-commerce sites are still shipping it, getting nothing for it, and in some cases exposing themselves to a real risk: if the marked-up FAQ text doesn't match what's visibly on the page, that's a structured data guideline violation, not just wasted markup. HowTo rich results are gone the same way — removed from mobile in 2023, then desktop, with no surface where the type still earns a visible result.

The pattern to watch for isn't just "this type is deprecated." It's markup that was copied from a template three years ago and never revisited against what the type currently does. Schema.org vocabulary is stable; Google's willingness to render any given type as a rich result is not, and it changes on a timeline nobody sends you a notification for.

What still earns a rich result

The list that reliably pays off in 2026: Product with real price, availability, and AggregateRating sourced from genuine reviews of that specific product (Google's review-snippet policy explicitly prohibits self-serving reviews — a business reviewing its own product — so the reviews need to be real customer reviews, not manufactured ones); BreadcrumbList; VideoObject; JobPosting; Event; Recipe; and SoftwareApplication with a valid applicationCategory. Alongside those, Organization and WebSite with a clean, deduplicated @id structure keep doing their quieter job of entity clarity and sitelinks search box eligibility, even without a visible snippet of their own.

A minimal audit worth running quarterly

• Validate the rendered HTML response, not the template file — escaping bugs only show up post-render.
• Grep your codebase for every place Organization or WebSite gets emitted. If it's more than one, consolidate behind a shared @id.
• Cross-check every @type you ship against Google's current structured data documentation, not the blog post you copied it from.
• Check Search Console's Enhancements reports monthly — a spike in "Invalid JSON-LD" or "Missing field" errors is usually a deploy, not a Google policy change.
• Confirm every marked-up claim (a review score, an FAQ answer, a price) is visible on the page in the same form. Markup that isn't backed by visible content is a guideline violation waiting to be noticed.

Bottom line

Structured data is infrastructure, not decoration — it fails the way infrastructure fails: silently, until an audit or a manual action surfaces it. The sites that get rich results in 2026 aren't the ones with the most schema. They're the ones whose JSON actually parses, whose entities resolve to one @id, and whose markup matches what a person sees on the page.

If you want that checked properly — rendered output, not template source — our SEO team runs structured data validation as a standard part of every technical audit, alongside the crawlability and Core Web Vitals work that usually turns out to be sitting right next to it.