Structured data that actually gets picked up: what Google does with it, and what it ignores

Structured data gets treated as an SEO checkbox more often than it gets understood. Add some JSON-LD, tick the box, move on. That approach tends to produce markup that is technically present and functionally useless, because it doesn't match what's on the page, or it uses the wrong schema type for the content, or it misses the specific fields Google needs to build a rich result.

The gap between what schema markup does and what people assume it does is where most implementations go wrong, so it's worth being precise about both.

Schema doesn't improve rankings directly

Clear this one up first: adding JSON-LD is not a ranking factor in the way page speed or content quality are. What it does is make a page eligible for rich results. Star ratings, FAQ accordions, breadcrumb trails, article cards. Those rich results tend to improve click-through rate, which is a real, measurable traffic gain, but the mechanism is different from ranking higher for the same query.

It must match the visible page exactly

Google's structured data guidelines are explicit about this, and enforcement has only grown stricter: the content in your JSON-LD has to reflect what a visitor can see on the page. FAQPage markup listing questions and answers that never appear as visible text is a policy violation, not a grey area, and it can get the markup ignored or the page penalized. The safest pattern generates the schema from the same data source that renders the visible content, so the two can never drift apart.

Use the specific type, not the closest generic one

A common failure mode is reaching for a generic type, `Thing` or a loosely-matched `CreativeWork`, when a specific one exists and unlocks a real rich result. A blog post should usually be `Article` or `BlogPosting`, not just `WebPage`. A services business should use `Service` for individual offerings instead of burying everything inside one `Organization` block. The more specific and correct the type, the more of Google's supported rich-result features the page becomes eligible for.

One entity, one @id, reused everywhere

Sites that repeat a full `Organization` object on every page, worded slightly differently each time, make it harder for Google to connect the dots into a single entity. Give your core entities (the organization, the website) a stable `@id`, then reference that `@id` from every other schema block: article authorship, service listings, breadcrumbs. One consistent entity comes through far more clearly that way than from a similar-but-not-identical block repeated on every template.

{
  "@type": "Article",
  "headline": "...",
  "author": { "@id": "https://example.com/#org" },
  "publisher": { "@id": "https://example.com/#org" }
}

Validate against the rich-result test, not just a JSON linter

• Valid JSON syntax is necessary and nowhere near sufficient. A schema.org type used with the wrong required fields parses fine and still gets ignored.
• Run every template through Google's Rich Results Test, which checks against the specific fields each rich result requires.
• Re-check after any template refactor. A field silently dropped during a redesign invalidates markup that used to work.
• Check the Enhancements reports in Search Console periodically. Google flags markup that stops validating in production, often long after the change that broke it.

Combine related entities with @graph instead of duplicating them

Sooner or later a page needs more than one schema type: an Article with an author, who is also the Organization publishing the site, which also owns the breadcrumb trail. Stacking separate script blocks one after another works. It also lets them drift out of sync as templates change independently. A single @graph array inside one script block, with each entity keyed by its own @id and referencing the others by @id instead of repeating their fields, keeps the whole page's structured data as one coherent object instead of several that happen to sit near each other.

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "@id": "https://example.com/#org", "name": "..." },
    { "@type": "WebSite", "@id": "https://example.com/#website", "publisher": { "@id": "https://example.com/#org" } },
    { "@type": "Article", "author": { "@id": "https://example.com/#org" } }
  ]
}

The failures that don't throw an error anywhere

Most broken structured data never announces itself. A CMS plugin and a hand-added script tag both injecting an Organization block on the same page produce two competing, slightly different descriptions of the same entity, and nothing about the page fails to render. A schema block generated at build time and never regenerated after a content edit keeps validating against fields that no longer match the page, so the JSON stays syntactically perfect while the contract it makes with the page quietly breaks. Schema on a page carrying a noindex tag is never evaluated for rich results at all, however correct it is, because Google never gets far enough to consider it.

• Two sources, a plugin and hand-authored code, both emitting the same entity type on one page.
• A schema block built once at deploy time that isn't regenerated when the underlying content changes.
• Correct markup on a page that's noindexed, redirected, or blocked by robots.txt, where nothing ever evaluates it.
• A mismatch between the page's visible price or currency and the schema's own fields. Both look valid on their own; together they are a policy issue.

What happens when Google decides to ignore your markup

Invalid or mismatched structured data does not usually get the page penalised. The ordinary outcome is that Google falls back to a standard result and the rich-result feature never appears. Markup that looks like an attempt to manipulate results is the exception: fabricated review scores, FAQ answers invisible on the page. That gets treated as a policy violation and can trigger a manual action against the whole site, not just a lost rich result on one page. Keep the distinction in mind before treating every validation warning as equally urgent. A missing optional field is a lost opportunity. A fabricated rating is a risk.

Structured data is a contract: you're telling Google exactly what a piece of content is. The moment the markup and the page disagree, the safest response for a search engine is to ignore it.

Does adding JSON-LD structured data improve search rankings?

Not directly. Structured data isn't a ranking factor the way page speed or content quality are. What it does is make a page eligible for rich results like star ratings, FAQ accordions and breadcrumb trails, which tend to improve click-through rate at whatever position the page already ranks. It only works if the markup exactly matches the visible page content.