Structured data

What structured data really is, beyond the definition

Structured data is a contract you offer a machine: here is the content of this page, already parsed, in a format nobody has to reverse-engineer. The visible HTML shows a name, a date and a score. The markup says author, datePublished, aggregateRating. Google stops inferring roles from layout heuristics and reads labels instead. Every practical consequence in this entry follows from that single mechanism.

Most guides muddle two senses of the term. In data engineering, structured data means anything that fits a predefined schema in rows and columns: a SQL table, a CSV export, a spreadsheet. In search, structured data means a narrower practice: annotating an HTML page with a shared vocabulary so a crawler extracts entities and properties rather than raw tokens. Same underlying idea, very different scale, and only the second one is under your control from a CMS.

Google's own introduction to the subject is still the cleanest starting point for anyone onboarding a client team:

What structured data is not: a ranking factor. Google Search Central has repeated this for years and nothing in the 2026 documentation updates changed it. Markup buys eligibility for a display feature and a cleaner read of the entities on a page. It does not lift a URL through the organic results. When a vendor tells you schema improves positions, what they are actually measuring is the correlation between sites disciplined enough to ship valid markup and sites disciplined enough to do everything else properly.

The vocabulary itself is not Google's. It comes from the vocabulary jointly maintained by Google, Microsoft, Yahoo and Yandex, whose v30.0 release landed on 19 March 2026 and added classes such as Credential and Error, properties like floorLevel for LocalBusiness and Residence, and jobDuration for JobPosting. Search engines consume a subset of that vocabulary. The gap between what schema.org defines and what Google actually renders is where most wasted implementation effort lives.

Structured vs unstructured data: the distinction that matters for search

Unstructured data is the default state of the web: prose, images, PDFs, video, anything a machine has to interpret before it can act on it. Structured data is information already bound to a schema, so a system can query, filter and join it without an interpretation step. A product description in a paragraph is unstructured. The same product with price, priceCurrency and availability as named properties is structured, and a shopping surface can act on it directly.

This short explainer covers the general distinction if you need something to hand to a non-technical stakeholder:

The operational consequence for search is a matter of cost and confidence. A language model or a classical extraction pipeline can pull an author name out of prose, but with a confidence score and a failure rate. Read it from a typed property and the extraction is deterministic. That is why markup matters most on the information a search engine would otherwise have to guess: publication and modification dates, author identity, price, stock status, geographic coordinates, event times. It matters least on the parts already obvious from the text. Marking up your body copy as articleBody changes nothing, because the crawler already had the body copy.

And yes, a spreadsheet counts as structured data in the database sense while being irrelevant to SEO. That question sits in the top of every SERP on this topic because two audiences share one keyword. Keep the two apart in your own analysis and half the confusion evaporates.

What Google still rewards in 2026, after two years of pruning

The single most important fact about structured data right now is that Google is shrinking the surface, not expanding it. FAQ rich results were removed from Google Search on 7 May 2026, with a deprecation notice added to the FAQPage documentation the following day. Practice Problem markup got its deprecation notice on 5 November 2025 and its documentation was pulled on 6 January 2026, with reporting removed from Search Console, the Rich Results Test and the search appearance filters starting in January 2026. Seven further types, including course info, estimated salary, learning video, special announcement and vehicle listing, left the documentation in September 2025 as part of a simplification pass. Google also clarified in November 2025 that Dataset markup feeds Dataset Search only, not regular Search.

Read that list as a pattern rather than a set of incidents. Google keeps the types that describe stable commercial or editorial entities and drops the ones that were mostly a self-declaration channel, which is precisely where publishers gamed the format hardest. Question and answer markup on ordinary pages was abused for years to occupy SERP real estate, and it is gone. Meanwhile Google added supported properties for DiscussionForum and QAPage on 24 March 2026, published preferred image guidance on 2 March 2026 clarifying that both schema.org image markup and og:image feed thumbnail selection in Search and Discover, and added hasAdultConsideration to Product and merchant listings on 20 May 2026. Growth is happening on commerce, forums and media selection, not on decorative annotation.

So the 2026 core set is short: Organization with a complete sameAs array, Article or BlogPosting for editorial, BreadcrumbList for hierarchy, Product for commerce, LocalBusiness where there is a physical location. That is the backbone. If your implementation plan runs past that list before those five are flawless, the priorities are inverted.

Structured data and AI search: correlation, not a lever

This is where honest analysis diverges hardest from vendor content. The figure everyone quotes is BrightEdge's 2025 finding that pages combining structured data with FAQ blocks saw a 44% increase in AI search citations. It is a correlation drawn from a vendor dataset, and it has been challenged. Ahrefs ran the closer thing to a controlled test, studying roughly 1,885 pages that added JSON-LD between August 2025 and March 2026, and found no statistically significant causal lift in AI Mode or ChatGPT citations, alongside a modest 4.6% decrease for Google AI Overviews on already-cited pages. Their conclusion, which matches what we see in audits, is that schema behaves as a trust and discovery signal rather than a switch that turns on citations. None of this makes AI visibility work pointless, only markup the wrong lever for it: making a brand's entities legible to AI answer engines is earned through citations and off-page authority signals, not through a denser JSON-LD block.

What did change is who gets cited at all. Ahrefs' February 2026 analysis of 863,000 SERPs and around 4 million AI Overview URLs found that only 38% of cited pages still rank in the organic top ten, down from 76% in mid-2025. ConvertMate's 2026 GEO benchmark, aggregating BrightEdge, Semrush and HubSpot datasets, reports that 83% of AI Overview citations come from outside the organic top ten and that 61% of cited pages carry structured data markup. Note the shape of that second number: a majority of cited pages have markup, which tells you it is table stakes among serious publishers, not that markup caused the citation. The cost of being absent is real, and Search Engine Land's September 2025 controlled experiment saw only the well-marked-up version make it into an AI Overview. The upside of adding more of it to a page that already has the basics is close to zero.

The revenue side deserves a mention too, because it reframes the effort. SearchLab's 2026 summary puts the organic CTR drop on AI Overview queries at roughly 18 to 25% on average, with Seer Interactive's 3,119-query dataset showing a fall from 1.76% to 0.61% when an AI Overview is present. Markup does not recover those clicks. Off-page work does, which is why we treat schema as hygiene at the publisher level across the 50 owned French editorial media we run in-house, and treat visibility itself as a separate budget line with a catalogue of media you can browse and filter without an account.

Implementing JSON-LD cleanly, and testing it properly

Google's recommended format is the JSON-LD syntax injected in a script tag, and there is no serious argument for microdata or RDFa on a new build in 2026. JSON-LD sits outside the DOM content, survives template refactors, and can be generated server-side without touching markup. This walkthrough is the right level for the developer who will actually ship it:

A complete BlogPosting object, which is roughly what an editorial page needs and nothing more, looks like this:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Structured data in 2026",
  "datePublished": "2026-07-22",
  "dateModified": "2026-07-22",
  "author": {
    "@type": "Person",
    "name": "Marie Dupont",
    "url": "https://example.fr/auteurs/marie-dupont/"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example",
    "url": "https://example.fr/"
  },
  "image": ["https://example.fr/img/cover.jpg"],
  "mainEntityOfPage": "https://example.fr/blog/structured-data/"
}
</script>

Two validators, two different questions. The Rich Results Test answers whether Google will render a feature from this page, and it is the only one whose verdict maps to a SERP outcome. The Schema.org Markup Validator answers whether the graph is syntactically valid and correctly typed, including for types Google ignores. A page can pass the second and fail the first, which confuses teams constantly. Run both, and treat the Search Console enhancement reports as the only source that reflects what Google actually parsed at scale on your live site.

On WordPress, Yoast SEO and comparable plugins emit a connected graph by default, with the Organization and WebSite nodes wired to each Article node through @id references. That output is generally sound and worth keeping. The failure mode is layering a second manual JSON-LD block on top, producing two Organization entities with conflicting names on the same URL. Extend the plugin graph through its filters, do not compete with it.

Where implementations go wrong in the field

Incompleteness is the dominant failure. An Article object missing a valid author, a Product missing price or availability, a LocalBusiness missing address: the object parses, gets stored, and produces no display feature at all. There is no partial credit in this system, and audit tooling that reports a count of pages carrying markup rather than a count of pages carrying valid and complete markup will mislead you for months.

Second: markup that contradicts the page. Reviews declared in JSON-LD but absent from the rendered HTML, a dateModified bumped on every deploy while the text has not changed since 2023, a price in the schema that differs from the price in the template because they come from different sources. Google's guidelines require the marked-up information to be visible and accurate, and mismatches are exactly what manual structured data actions target.

Third: the wrong type. Every property in schema.org can be attached to almost anything, so nothing stops a team from declaring a category listing page as a Product, or wrapping a services page in Article. It validates. It also gives the entity graph a wrong statement about what your page is, at the moment when AI surfaces are leaning on those statements to ground answers.

Fourth, and specific to anyone running acquisition campaigns: the schema on placements you do not own. When you commission content on third-party media, the author node, the publication date and the publisher identity on that page are set by the host, not by you. A placement on a site whose Article markup has no author and no dateModified is a weaker entity association than the same link on a properly marked-up media, even at identical authority metrics. It is a criterion worth adding to your qualification grid alongside what each placement actually costs, because it separates real editorial operations from thin publishing shells at no extra cost to check.