Knowledge Graph Navigator

Structured Data for SEO: How Search Engines & LLMs Use It

Structured data, in the web sense, is machine-readable markup embedded in a page that states what the page’s content means: which strings are names, which are prices, which are dates, and which real-world thing the page is about. It is the on-page layer of a knowledge graph. Each block of markup contributes statements about an entity, and a search engine that crawls millions of such pages is assembling those statements into a graph it already holds. Almost all of it uses the schema.org vocabulary.

What qualifies as structured data

The everyday definition in search is narrow: markup on a page, using a shared vocabulary, that identifies entities and their properties. A Product block naming a price, a Person block naming a job title, an Event block naming a start date.

The broader definition in data engineering is anything with an explicit schema, including database tables, CSV files and API responses. The overlap is not accidental: what makes markup structured is the same thing that makes a table structured, which is that a machine knows in advance what each field means rather than guessing from context.

Three things on a page are often mistaken for structured data. Meta tags such as description and robots carry instructions and summaries, not entity statements. HTML semantics such as <article> and <time> describe document structure, and <time datetime="..."> is machine-readable, but neither identifies an entity. Open Graph tags describe how a URL should be presented when shared, using a small fixed set of properties covered in Open Graph protocol; they are not part of the schema.org model.

Underneath the markup layer is the general data model of the semantic web: every statement is a triple of subject, predicate and object, described in triples: subject, predicate, object and standardized as RDF. Structured data on a page is RDF that happens to travel inside HTML.

The three syntaxes

Schema.org can be written into a page three ways, and all three produce the same statements.

JSON-LD puts the data in a <script type="application/ld+json"> block, separate from the visible HTML. Google recommends it. Because the markup is one contiguous object rather than a set of attributes threaded through a template, it can be generated from page data, reviewed as a unit, and changed without touching presentation.

Microdata uses HTML attributes (itemscope, itemtype, itemprop) attached to the elements that already display the content. Its appeal is that markup and visible text cannot drift apart, since they are the same nodes.

RDFa also uses attributes (vocab, typeof, property) and is the most general of the three, since it can express any RDF vocabulary rather than being oriented around one. It is more common in publishing and government data than in commercial SEO.

The same fact in all three:

<!-- JSON-LD -->
<script type="application/ld+json">
{ "@context": "https://schema.org", "@type": "Person", "name": "Marie Curie" }
</script>

<!-- Microdata -->
<div itemscope itemtype="https://schema.org/Person">
  <span itemprop="name">Marie Curie</span>
</div>

<!-- RDFa -->
<div vocab="https://schema.org/" typeof="Person">
  <span property="name">Marie Curie</span>
</div>

Mixing syntaxes on one page is legal and consumers merge the results, which is how sites end up with two conflicting descriptions of one organization. The trade-offs are compared in full in JSON-LD vs Microdata vs RDFa, and the wider set of formats and query languages, including SPARQL, OWL, SHACL and the line-delimited JSONL format used for bulk data exchange, is indexed at languages and formats.

What Google actually does with it

Google’s documentation describes two uses, and conflating them causes most of the confusion in this area.

The first is rich results. Google defines a set of search features, each tied to a specific type and a list of required and recommended properties: product listings, recipes, breadcrumbs, job postings, events, videos and others. Correct markup for one of those features makes a page eligible for that appearance. Google states explicitly that it does not guarantee a rich result will appear, and that the appearance may depend on the query, the device and its own quality assessments.

The second is understanding the page. Structured data tells Google what the page is about and which entities it names, which is a different job from producing a visual feature. This is where sameAs, @id, founder, parentOrganization and similar properties do their work: they never change how a result looks and they do contribute to entity resolution.

What structured data is not is a ranking factor. Google’s own guidance is that markup makes content eligible for features and helps it understand a page; it does not promise a position change. The observable effects that practitioners do report, higher click-through from a richer result, or a brand’s details appearing correctly in a panel, come through those two documented mechanisms rather than through a direct scoring input.

Documented support versus mere ingestion

There is a third category that sits between “Google supports this” and “Google ignores this”, and naming it clearly prevents a lot of wasted effort.

Documented for a rich result. The type appears in Google’s structured data feature documentation, with required properties, eligibility criteria, and a report in Search Console. Product, Recipe, BreadcrumbList, JobPosting, Event, VideoObject and Organization are in this group. Errors here are actionable and measurable.

Read but not surfaced. Markup that is valid schema.org but outside the documented features. Google parses whole blocks rather than filtering to a whitelist, so these statements are available to it, and there is no way to verify from outside what it does with any individual one. A Person node with knowsAbout and alumniOf falls here. Publishing it is reasonable; expecting a report on it is not.

Not resolvable. Invented property names, misspellings, terms from a private vocabulary with no context declaration. These carry no meaning to any consumer and are simply dropped.

The honest position on the middle group is that it is inference. Google says structured data helps it understand a page and says it uses many sources to build its knowledge base. It does not publish a mapping from a given property to a given behaviour. Treating undocumented properties as a way to state facts accurately and consistently is sound; treating them as levers with known effects is not. The same caution applies to language models and AI search surfaces, discussed in knowledge graphs, AI search and LLMs.

A worked example: one page, one graph

A single page usually describes several entities at once. Giving each an @id and referencing rather than repeating them turns the page’s markup from a set of unrelated blocks into a small graph.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Institute",
      "url": "https://example.com/",
      "logo": "https://example.com/logo.png",
      "sameAs": "https://www.wikidata.org/wiki/Q00000"
    },
    {
      "@type": "Person",
      "@id": "https://example.com/authors/marie-dupont/#person",
      "name": "Marie Dupont",
      "url": "https://example.com/authors/marie-dupont/",
      "jobTitle": "Research Lead",
      "worksFor": { "@id": "https://example.com/#organization" }
    },
    {
      "@type": "Article",
      "@id": "https://example.com/blog/entity-resolution/#article",
      "headline": "How entity resolution works",
      "datePublished": "2026-04-02",
      "author": { "@id": "https://example.com/authors/marie-dupont/#person" },
      "publisher": { "@id": "https://example.com/#organization" },
      "mainEntityOfPage": "https://example.com/blog/entity-resolution/"
    }
  ]
}

Three nodes, four edges, and one external identifier. Every other page on the site can reference https://example.com/#organization by @id instead of restating the organization, so the site as a whole asserts one organization rather than one per page. That is the practical difference between having markup and having a graph, and it is the same principle as linked data applied at site scale.

Validation

Three tools answer three different questions, and running only one leaves a gap.

The Rich Results Test at search.google.com/test/rich-results reports whether Google can extract the markup and whether it qualifies for a rich result. It renders the page first, so it catches markup injected by JavaScript. It reports only on Google’s supported features, so silence about a property is not a verdict on it.

The Schema Markup Validator at validator.schema.org checks markup against the whole schema.org vocabulary. This is the tool that catches misspelled property names and properties used on types where they do not belong.

The JSON-LD Playground checks the JSON-LD layer itself, expanding and flattening a document and showing the resulting triples. It is the fastest way to see whether an @id reference actually resolved to the node it was meant to.

In production, Search Console’s enhancement reports are the only view of markup as Google sees it at scale, across every crawled URL rather than one at a time. Deeper coverage of all of these, along with generators, is in structured data testing tools.

Common failure modes

Markup that does not match visible content. A block claiming a price of 18.00 on a page showing 24.00, or a rating the page does not display. This is a policy violation as well as a data error, and Google’s structured data guidelines describe manual action as a possible outcome.

Marking up content that is not on the page. Adding an FAQPage block with questions that appear nowhere in the HTML, or a Review for reviews the site never collected, is the most common cause of a manual action in this area. The rule is that markup restates what a visitor can see, not what a publisher wishes were there.

Orphaned @id references. A publisher pointing at #organization when no node with that @id exists anywhere on the page produces a dangling reference. Consumers see a node with an identifier and no properties, and the intended relationship is lost. The failure is silent: the JSON is valid, the Rich Results Test may pass, and the graph is broken.

Inconsistent identifiers across pages. The same organization published as #organization on one template, #org on another, and as an inline object with no identifier on a third. Three identifiers means three entities, and any difference between them is a contradiction for the consumer to resolve.

Duplicate and conflicting blocks. A theme, a plugin and a hand-rolled snippet each emitting an Organization node with a different name or logo. Consumers merge everything on the page, so the result is one entity with three names.

Markup only present after client-side rendering. Google renders pages before extracting structured data, so injected markup can work, but it depends on the script executing during that render. Server-side rendering removes the dependency.

For developers

Generate markup from the page’s own data objects rather than from templates, so content and markup cannot diverge, and serialize with a JSON library instead of string concatenation. A literal </script> inside a string value terminates the block early, and a smart quote pasted from a document invalidates the JSON outright.

Because JSON-LD is an RDF serialization, the markup a site publishes for search engines is also a queryable dataset. Parsing a crawl of a site’s own JSON-LD into a graph and running SPARQL over it answers questions no SEO tool will: which pages assert an author who has no Person node, which @id references resolve nowhere, how many distinct organization names the site publishes. For sites large enough that markup is generated by several systems, a SHACL shape per template turns those checks into a build-time test.

For SEOs

Sequence the work by what is verifiable. Start with the types Google documents for the templates that matter, satisfy their required properties, and clear the errors in Search Console. That part has a feedback loop.

Then move to entity description, which does not: one stable @id per important entity, reused site-wide, and sameAs pointing at identifiers that already exist elsewhere, such as a Wikidata Q-ID or an official profile. This is the layer that connects a site’s own statements to a search engine’s graph, described further in what is an entity and entity SEO.

Audit for contradiction more often than for coverage. A site with modest markup that says one consistent thing about itself is in better shape than a site with extensive markup that says three.

Related pages

FAQ

What is structured data in SEO?

Structured data in SEO is markup added to a page, almost always schema.org vocabulary written as JSON-LD, that tells search engines what the content means: which text is a product name, which is a price, which entity the page is about. It makes pages eligible for rich results and helps search engines identify the entities involved.

Is structured data a ranking factor?

No. Google’s guidance is that structured data makes a page eligible for rich results and helps search engines understand the content, not that it raises rankings. Reported gains usually come from a more prominent result attracting more clicks, or from a brand’s entity details being resolved correctly, rather than from a direct scoring change.

Which structured data format should be used?

JSON-LD, for most sites. All three formats express the same statements, so the difference is maintenance: JSON-LD sits in one block that can be generated from page data and reviewed independently of the HTML, and Google recommends it. Microdata still suits cases where markup must stay attached to editor-managed content.

How is structured data validated?

Use the Rich Results Test to see whether Google can extract the markup and whether it qualifies for a supported feature, and the Schema Markup Validator to check it against the whole schema.org vocabulary, which catches misspelled or misplaced properties. Search Console’s enhancement reports show how the markup behaves across every crawled URL.

Sources and further reading

  • Google Search Central, Introduction to structured data markup: https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data
  • Google Search Central, structured data general guidelines: https://developers.google.com/search/docs/appearance/structured-data/sd-policies
  • Google Search Central, search gallery of structured data features: https://developers.google.com/search/docs/appearance/structured-data/search-gallery
  • schema.org, Getting started: https://schema.org/docs/gs.html
  • W3C, JSON-LD 1.1: https://www.w3.org/TR/json-ld11/
  • W3C, HTML Microdata: https://html.spec.whatwg.org/multipage/microdata.html
  • W3C, RDFa Lite 1.1: https://www.w3.org/TR/rdfa-lite/
  • Schema Markup Validator: https://validator.schema.org/

Powered by CookieAdmin