Structured data: what it does, what it does not, and where it pays off

Structured data is one of the few parts of SEO with an actual specification, a validator and vendor documentation. That makes it unusually easy to get right — and unusually easy to over-claim.

What it is, concretely

Schema.org is a shared vocabulary of types and properties — Organization, Service, Article, Person, FAQPage and several hundred more. JSON-LD is the format search engines prefer for expressing it: a block of JSON in a script tag, describing the things on the page without touching the visible markup.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Ltd",
  "url": "https://example.com",
  "email": "hello@example.com",
  "areaServed": { "@type": "Place", "name": "Worldwide (remote)" }
}
</script>

That is the whole idea. You are stating facts about the page in a form that does not require a parser to infer them from prose.

What Google's documentation says it does

• It helps Google understand the content of the page.
• It makes the page eligible for rich results — the enhanced listings with ratings, prices, breadcrumbs, FAQs and so on.
• Eligibility is explicitly not a guarantee: Google states that adding markup does not mean a rich result will be shown.
• The markup must describe content that is visible to the user. Describing things that are not on the page is a spam policy violation and can attract a manual action.

Notice what is absent from that list: any claim that markup improves ranking position. Google has consistently framed structured data as an understanding-and-presentation mechanism rather than a ranking signal. Rich results can lift click-through by taking more space and answering more of the question in the listing — which is a real effect with a different cause.

Why it matters beyond Google

This is the part that changed with AI search. Structured data is just facts in a standard format, and anything parsing your page can read it — assistants, aggregators, browsers, internal tools. When your address, your service list, your author and your publication date are stated explicitly, no system has to infer them from a sentence and get it wrong.

No provider has published "we weight schema.org markup when selecting citations", and this article is not going to imply that they do. The defensible version is narrower and still worth acting on: explicit machine-readable facts are cheaper to consume correctly than facts buried in prose, and the cost of adding them is one afternoon.

The types worth doing for a services business

How to check it, in order

1. 01Rich Results Test — takes a URL or a snippet, tells you which Google features the markup qualifies for.
2. 02Schema Markup Validator — validates against the schema.org vocabulary itself, independent of Google's feature list.
3. 03Search Console enhancement reports — the only view of errors on pages as actually crawled, at scale, over time.

Run the first two while building and the third a couple of weeks after shipping. Most structured data errors are typos in property names, and all three tools will name the property.

The limit

Markup is a description, not an argument. It can state that a page is an article by a named author on a given date; it cannot make a thin page substantial, and it cannot make a claim true. If the underlying page has nothing to say, the correct fix is upstream of the script tag.