Structured data, plainly: what it does and what it does not

Structured data attracts more magical thinking than any other part of technical SEO. It is sold as a ranking lever, blamed for mysterious losses, and bolted onto pages in types that do not describe their content, in the hope that looking machine-readable is itself a benefit.

What it actually is: a block of JSON in your page that states, unambiguously, what the page is about and what the entities on it are. That is a narrow and real benefit, and it is worth doing properly for exactly that reason.

What it is, concretely

Google recommends JSON-LD, embedded in a <script type="application/ld+json"> tag. Nothing is rendered; it is a parallel, explicit statement of what the human-readable page says implicitly.

json

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://bizupllc.com/#organization",
  "name": "Bizup LLC",
  "url": "https://bizupllc.com",
  "foundingDate": "2013",
  "areaServed": { "@type": "City", "name": "Seattle" },
  "sameAs": [
    "https://www.linkedin.com/company/…",
    "https://www.google.com/maps/place/…"
  ]
}

The @id is the part people omit and the part that does the work: a stable identifier other nodes on the site can reference instead of repeating the organisation's details.

Three rules govern everything below. The markup must describe content that is actually on the page. It must not contradict the visible page. And the type you choose must genuinely be what the thing is — a page about a service is a Service, not a Product, however much you would like the review stars.

What it does

Makes eligibility for rich results possible. Not guaranteed — eligible. Google decides whether to show them.
Removes ambiguity about identity. A sameAs array pointing at your real profiles, consistently, is how a machine reconciles the several hundred mentions of your name across the web into one entity.
Makes relationships explicit. That this post has that author, that this service is offered by that organisation, that this page sits at that point in a hierarchy. Inferring those from HTML is error-prone; stating them is not.
Gives extraction a reliable anchor. Prices, dates, addresses, opening hours and authorship are the fields most often parsed wrongly from prose, and the ones a retrieval system most wants to be certain about.

What it does not do

It is not a ranking factor. Google has been consistent that structured data helps it understand a page and makes rich results possible; it does not boost position on its own.
It does not force a citation. Anyone selling schema as the key to AI visibility is overstating it well past the evidence. It removes ambiguity cheaply. That is the claim.
It does not fix a page that does not say anything. Markup describing thin content describes thin content accurately.
It does not substitute for crawlable HTML. If your content is assembled client-side and the retriever receives an empty shell, perfect JSON-LD describes a page the retriever cannot read.

What is worth emitting

Everywhere

One Organization node with a stable @id, your real name, your sameAs profiles, and — for a business with a physical presence — the LocalBusiness subtype that actually fits, with address, geo, areaServed and openingHours. Plus a WebSite node. Emit these once, from one place in your codebase, and reference them by @id everywhere else.

Articles and posts

A BlogPosting with headline, datePublished, dateModified and an author that references a real entity rather than a bare string. Dates must match what the page visibly shows — a mismatch between visible and marked-up dates is worse than omitting the dates, because it is a contradiction rather than a gap.

Services and pricing

A Service node, with provider pointing at your organisation @id. Add an Offer only if a price is genuinely on the page. Marking up a price you do not display is the most common way sites end up with markup that contradicts their own content.

A BreadcrumbList on anything nested. Low effort, well supported, and it is the one type that still reliably changes how your result looks.

json

{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "Website speed optimization",
  "serviceType": "Web performance engineering",
  "provider": { "@id": "https://bizupllc.com/#organization" },
  "areaServed": { "@type": "City", "name": "Seattle" }
}

The provider reference, rather than a duplicated organisation block, is what keeps a site's markup consistent as it grows.

What Google has retired or narrowed

Worth knowing, because a lot of advice still in circulation predates these changes:

FAQ rich results. In August 2023 Google narrowed FAQ rich results to well-known authoritative government and health sites. FAQPage markup is still valid and still useful for machine comprehension — it will simply not produce the accordion in the search result for a commercial site.
HowTo rich results. Reduced in the same announcement and since removed from Google's search-gallery documentation. The type remains valid schema.org; the search feature is gone.
Self-serving review stars. Google does not show review rich results for reviews a business collects about itself on its own site. AggregateRating still has value for on-page conversion and machine comprehension, but stars in the search result come from your Google Business Profile, which is where review effort should go.

None of this makes the markup wrong. It makes the reason for the markup different — comprehension rather than a visual feature — and if your case for emitting it was the feature, you should know the feature is gone.

One source of truth

The most common failure mode in a mature site is not missing markup, it is three generations of it. A plugin emitting one Organization block, a theme emitting another with a different name, and a hand-pasted snippet in the footer with an old address. Now the page contradicts itself, and inconsistency about identity is the one thing structured data exists to prevent.

Generate it from typed code in one place, one node per concept, referenced by @id. Then audit for duplicates after installing anything that touches your head tag.

How to validate it

Schema.org's own validator for syntax and vocabulary correctness — whether your JSON-LD is valid schema.org at all.
Google's Rich Results Test for whether Google specifically recognises it and considers the page eligible for a feature. The two tools answer different questions and disagree routinely.
Search Console's enhancement reports for errors at scale, across templates, on URLs you did not think to check.
Your own eyes, on the rendered HTML. Fetch the page with curl and confirm the block is in the response rather than injected later by a script.

Then stop. Structured data is a half-day of work done properly and a permanent low-grade distraction done obsessively. Get the identity right, describe each page as what it is, keep it consistent, and spend the remaining attention on the content itself — which is still what determines whether anybody cites you. How to get cited in AI search covers the rest of that picture, and our AI search optimization service is where we do it.