Structured data for SEO: the 5 schemas that actually matter in 2026

In brief: structured data refers to markup based on the schema.org vocabulary, which translates a page's content into a language that Google and conversational engines can understand unambiguously. Five schemas are enough to cover most of a site's needs in 2026: Organization, Article or BlogPosting, FAQPage, Product and BreadcrumbList, though none of them guarantees a rich result in search listings.

What is structured data in SEO?

Structured data for SEO is markup based on the schema.org vocabulary that helps a search engine, or a generative artificial intelligence, precisely understand what a piece of content represents: a product, a recipe, an event, an article. This definition fits in a single sentence and holds true regardless of the technical format chosen for implementation.

Schema.org is a standardised vocabulary used to explicitly describe a website's content. Rather than letting an algorithm guess from the visible text that a page is about a pair of shoes, the code directly tells it that this is a Product, complete with a name, a price and availability. The same logic applies to a blog post: the Article or BlogPosting tag specifies the author, the publication date and the main image, without a human reader seeing any difference on screen.

Let's take a concrete example. A typical e-commerce product page displays a name, a photo, a price and customer reviews. By adding Product markup in JSON-LD, you explicitly tell Google the value of each field: the price becomes usable data, as does the average rating. This changes nothing for what a visitor sees, but it gives the machine a more reliable reading than a simple analysis of the text.

One point deserves clarification before going further: Google never guarantees the display of a rich result, even when the implementation is technically flawless. Markup gives the engine the means to understand, and potentially to display an enriched presentation. It doesn't oblige it to do so.

How structured data works: vocabulary, formats and documentation

All the foundations of structured data come from schema.org. This shared repository defines entity types (Organization, Product, Event, Recipe) and their properties (name, price, author), independently of the engine that will subsequently consume them. Google, Bing, but also conversational engines such as ChatGPT or Gemini when they draw on web data, all read this same vocabulary.

The 3 accepted formats: JSON-LD, microdata, RDFa

There are 3 recognised structured data formats for implementing the schema.org vocabulary on a web page: JSON-LD, microdata and RDFa. JSON-LD is inserted as a separate block of code, typically in the page header, without touching the visible HTML. Microdata is integrated directly into existing HTML tags, via attributes such as itemscope and itemprop. RDFa works on a similar principle, with its own attribute syntax.

In practice, Google recommends the JSON-LD format among these three functional formats, and it's also the most widely used choice among technical teams. A JSON-LD block can be generated, tested and maintained independently of the HTML template: a design change doesn't require reworking the markup, unlike microdata embedded within the page structure.

Why schema.org remains the common reference

The schema.org vocabulary was created in 2011 by Google, Microsoft, Yahoo and Yandex, who came together to standardise a common language for describing web content. Fifteen years on, this foundation hasn't changed: it's still the reference used, whether the data is subsequently consumed by a traditional search engine or by a generative artificial intelligence system synthesising an answer from multiple sources.

Understanding structured data for Google SEO means distinguishing three clearly separate layers: the common vocabulary (schema.org), the implementation format (JSON-LD, microdata or RDFa), and the end consumer, with Google being just one of the engines and AIs that read this markup. One nuance matters: Google's documentation only lists the structured data valid for its own search engine. A schema can exist within the schema.org vocabulary without appearing in that documentation, simply because Google doesn't use it for its rich results, even though another engine might well be interested in it.

• The vocabulary: schema.org, common to all engines.

• The formats: JSON-LD, microdata, RDFa, making 3 available formats.

• The recommended format: JSON-LD, for its ease of maintenance.

• The documentation: Google's only covers its own engine, not the full range of possible uses.

Good to know

Google recommends the JSON-LD format among the three available structured data formats. It completely separates semantic markup from the visual template, which simplifies technical audits and future updates.

The 5 structured data schemas that truly matter in 2026

Schema.org lists several hundred different types. The choice of the five schemas presented here is not arbitrary: the selection criteria are the genuine usefulness for rich results on one hand, and readability by generative artificial intelligences on the other. Exhaustiveness serves no purpose if most of the listed types never apply to an ordinary site.

Organization: establishing brand identity

The Organization schema identifies a company, its contact details, its logo and its social profiles. It serves as the foundation for the knowledge panel Google can display for a brand, and it also helps conversational engines associate a brand name with a verifiable entity rather than a simple string of characters.

• name: the organisation's official name

• logo: a representative image

• sameAs: links to official social profiles and directories

• contactPoint: verifiable contact details

Article or BlogPosting: structuring editorial content

This schema tags editorial content: its title, author, publication date and main image. It helps an engine identify who wrote what and when, a trust signal that is increasingly scrutinised as automatically generated content proliferates.

• headline: the article's title

• author: the author, ideally linked to a Person schema

• datePublished and dateModified: the publication and update dates

• image: the content's main illustration

FAQPage: making questions and answers usable

The FAQPage schema structures a series of questions and answers present on the page. It allows an engine to extract or directly rephrase a short answer, which makes it a format particularly closely followed by teams working on visibility within AI-generated responses.

• mainEntity: the list of questions covered

• Question / name: the exact wording of each question

• acceptedAnswer / text: the associated answer, written to stand on its own

Product: equipping e-commerce product pages

The Product schema covers the name, image, price, availability and average rating of a product. It has historically been one of the most profitable schemas in e-commerce, as it determines whether the price and star rating can potentially be displayed directly beneath a result.

{ "@context": "https://schema.org", "@type": "Product", "name": "Chaussure de randonnée Trailblazer", "image": "https://exemple.com/images/trailblazer.jpg", "description": "Chaussure de randonnée imperméable, semelle Vibram.", "sku": "TRB-042", "offers": { "@type": "Offer", "priceCurrency": "EUR", "price": "129.90", "availability": "https://schema.org/InStock" }, "aggregateRating": { "@type": "AggregateRating", "ratingValue": "4.6", "reviewCount": "312" } }

BreadcrumbList: clarifying the site's structure

The BreadcrumbList schema describes a page's breadcrumb trail, that is, its position within the site's structure. It helps an engine understand the content hierarchy and, where applicable, display this path in condensed form within results rather than the raw URL.

• itemListElement: the ordered list of levels

• position: the rank of each level within the hierarchy

• name and item: the label and URL of each step

This table should not be read as a promise. Even for these 5 priority schemas, rich display remains at the discretion of Google's algorithm, which evaluates relevance, overall page quality and markup compliance before deciding anything.

The key figure

According to a case study published by Google, Rotten Tomatoes recorded a 25% higher click-through rate on pages where structured data had been added, following a rollout across 100,000 pages. Nestlé, for its part, measured an 82% higher click-through rate for pages that actually appeared as rich results, compared with those that did not. These two figures illustrate potential observed in specific cases, not a guarantee transferable to any site.

What I observe in the field is that brands who invest in a complete Organization schema, with all their social profiles filled in via sameAs, achieve entity recognition from Google noticeably faster than those who settle for spelling out their name on their About page. Nicolas Gomez

How to test and validate your structured data

Three tools are enough to cover the essentials of the verification process, from unit testing to large-scale monitoring.

Google's Rich Results Test remains the starting point: you paste in a URL or a code snippet, and the tool indicates whether the page is eligible for one or more rich results, detailing the recognised properties and any errors. It's the most direct structured data test for a one-off check before going live.

The Schema Markup Validator, available at validator.schema.org, checks the markup's compliance with the schema.org vocabulary, regardless of whether Google actually uses it. It's the tool to favour when you want to validate a schema that isn't part of Google's official documentation but could still be useful for other search engines.

For an overview of a site with several hundred or thousand pages, the Search Console Enhancements report remains useful: however, it changed its classification in 2024-2025, with warnings no longer displayed at the top level. Items are now grouped into two categories, valid and invalid, instead of the previous three (valid, warning, error), schema by schema. This is where you'll spot, for example, that a product template is generating an identical error across thousands of listings following a theme change.

In all cases, priority goes to blocking errors, those that prevent Google from recognising the schema. Simple warnings, often linked to recommended but non-mandatory properties, can wait for a future iteration without urgency.

Point of caution

A successful test on a sample page does not guarantee that the entire site is correctly marked up. Google structured data errors often appear after a template change, when a developer modifies a variable without realising it feeds into a JSON-LD block.

Structured, unstructured and semi-structured data: what's the difference?

Distinguishing structured data from unstructured data is the foundation of any thinking on this subject. Structured data is organised according to a fixed, predictable schema, like a row in a database or schema.org markup: each value occupies a predetermined place. Unstructured data comes as free text, image or video, with no predefined organisation. Between the two, semi-structured data uses a format like JSON or XML, partially organised, without imposing a schema as rigid as a relational database.

A concrete example for each category helps clarify things. A customer record in a spreadsheet, with fixed columns (name, email, sign-up date), illustrates structured data. A blog post written in free text, before any markup, illustrates unstructured data. A JSON file exported from an application, with keys varying by record, illustrates semi-structured data.

The SEO markup described in this article is a specific case of structured data, applied particularly to a website's content to make it readable by machines. Understanding this distinction also helps gauge the scale of the work: a site written in free text for ten years doesn't become structured overnight; it has to be marked up progressively, schema by schema.

Common pitfalls and implementation best practices

Most errors observed in the field aren't a matter of syntax, but a mismatch between what the markup states and what a visitor actually sees.

• Never mark up content that's absent from the visible page: an average rating or a price stated in JSON-LD but nowhere to be found on screen breaches Google's guidelines and risks a manual action.

• Prefer 5 well-implemented schemas over 20 sloppy ones: markup that's never updated is useless, and can even cause confusion.

• Update the markup after every redesign: a template change often silently breaks a JSON-LD block that was working perfectly the day before.

• Retest after every deployment, not just at initial launch: a CMS update or a modified plugin is enough to introduce a regression.

• Document the schemas used, their properties and their location in the code, to prevent a future developer from removing a JSON-LD block thinking it's dead code.

What costs the most isn't implementing a schema, it's forgetting about it. FAQPage markup set up once and never checked again, while three of the questions it contains no longer match the current offering, serves neither the visitor nor the search engine reading it. Nicolas Gomez

Adopting these 5 schemas isn't a disproportionate effort: a few hours are enough for a medium-sized site, compared with several weeks if you try to cover the entire schema.org vocabulary. What really takes time is keeping this markup alive, aligned with content that evolves, and checked after every technical change. This overview reflects practices observed in 2026, a landscape that keeps shifting in step with Google's updates and the growing appetite of conversational search engines for reliable data.