Structured data describes a page’s content in a standardised vocabulary that search engines can read. Done right, it unlocks rich results — review stars, breadcrumbs, expandable questions — without changing anything the visitor sees. This guide covers the JSON-LD format, the Schema.org types that actually matter, and how to deploy and monitor them.
What structured data is
Structured data is markup that annotates a page’s content to make its meaning explicit: “this is an article”, “its author is so-and-so”, “it was published on this date”. The reference vocabulary is Schema.org, maintained by a consortium of Google, Microsoft, Yahoo and Yandex. The markup does not change the display: it speaks to machines, not the reader.
The stake is visibility. Search engines use these annotations to build rich results that are larger and more clickable. They are not a direct ranking factor, but the gain in surface area and click-through rate is measurable — an effect to track in your Search Console reports.
JSON-LD, Microdata, RDFa: which to choose
Three syntaxes express the same vocabulary. JSON-LD has won out because it separates markup from HTML: a self-contained script block that is simpler to generate, inject and maintain.
| Format | Where it lives | Maintenance | Recommendation |
|---|---|---|---|
| JSON-LD | A standalone <script> block | Simple, decoupled from HTML | Google’s recommended format |
| Microdata | Attributes in the visible HTML | Coupled to markup, verbose | Legacy, migrate away |
| RDFa | Attributes in the HTML | Powerful but complex | Specific cases |
The Schema.org types that matter
The vocabulary has hundreds of types, but a handful covers most needs of a professional site.
| Type | Use | Possible rich result |
|---|---|---|
Article / NewsArticle | Editorial content | Large thumbnail, date, author |
Product + Offer | Product page | Price, availability, reviews |
FAQPage | Questions and answers | Accordion expanded under the link |
BreadcrumbList | Breadcrumb trail | Navigation path shown |
Organization / LocalBusiness | Identity, contact details | Knowledge panel, opening hours |
Two principles guide the choice: only mark up what is visible on the page, and favour types that actually trigger an enriched display for the business at hand.
Writing a correct JSON-LD block
A JSON-LD block goes in the <head> or the <body>, inside a script tag with a dedicated type. Here is a complete example for an article:
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Structured data with JSON-LD",
"datePublished": "2026-09-08",
"dateModified": "2026-09-08",
"author": { "@type": "Person", "name": "Simon Janvier" },
"publisher": {
"@type": "Organization",
"name": "Mail Studio",
"logo": { "@type": "ImageObject", "url": "https://www.mail-studio.com/logo.png" }
},
"image": "https://www.mail-studio.com/cover.jpg"
}The block is then declared in the page, alone in its tag:
<script type="application/ld+json">
{ "@context": "https://schema.org", "@type": "Article", "headline": "..." }
</script>A few rules avoid most errors: ISO 8601 dates, absolute URLs, and strict consistency between the marked-up values and the displayed content.
Structured data changes nothing the reader sees; it changes how the page appears in search results.
Generate and inject markup without repeating yourself
Few sites write their JSON-LD by hand, page by page. Three approaches coexist depending on the stack:
- Server-side generation: the template produces the block from the page’s data (title, date, author). This is the most reliable approach, because there is a single source of truth.
- CMS extension: on WordPress, SEO plugins automatically emit
Article,BreadcrumbListandOrganization. Convenient, but audit it: defaults sometimes mark up useless types. - Tag manager: injecting JSON-LD via a tag manager is possible, but depends on the engine rendering JavaScript — less robust than server-side rendering.
Whatever the method, one principle rules: a single source of truth. A datePublished that contradicts the displayed date is a negative signal, not a detail.
The mistakes that make markup fail
Most structured data that engines ignore is ignored for repetitive reasons, easy to fix once spotted. Knowing them saves real time at deployment.
- Missing required properties. Every type mandates required properties: a
Productwithout a validnameorofferswill open no rich result. The Rich Results Test lists exactly what is missing. - Values that contradict the page. A marked-up price that differs from the displayed one, an average rating with no visible reviews: signals that trigger a manual action rather than a visibility bonus.
- Competing blocks. A theme, an SEO plugin and a tag manager each emitting their own
Organizationproduce contradictory duplicates. A single source must generate each type. - Unlinked entities. Linking objects with
@idavoids re-declaring the organisation or author from page to page and helps engines consolidate the site graph. - Non-compliant images. Several types recommend high-resolution images in specific ratios; a missing or too-small image URL deprives the article of its large thumbnail.
- Content loaded in JavaScript. If the marked-up data only exists after a script runs, the crawler must be able to see it at render time, otherwise the markup describes a page it cannot perceive.
A single document can legitimately combine types: an article that answers frequent questions carries both Article and FAQPage. Nesting is allowed, provided each added type maps to content that is actually present, or the signal is diluted. None of these mistakes is fatal: all are caught before going live, as soon as testing becomes a systematic step of deployment.
Deploy, test and monitor
Before going live, Google’s Rich Results Test validates the syntax and flags missing properties. Once in production, Search Console’s “Enhancements” report tracks markup indexing, warnings and errors by type.
Monitoring then joins overall site management: rich results are read in the same dashboards as traffic and Core Web Vitals, alongside which they form the technical foundation of SEO.
Watch out. Marking up content absent from the page, inflating reviews or declaring an invisible FAQ exposes you to a manual action for “structured data spam”. Markup must always faithfully reflect what is actually visible.
Key takeaways
- Structured data annotates content for engines; it unlocks rich results without changing the display.
- JSON-LD is the recommended format: decoupled from HTML, simple to generate and maintain.
- Focus on a few useful types (Article, Product, FAQPage, BreadcrumbList, Organization) and mark up only what is visible.
- Validate with the Rich Results Test, then monitor Search Console’s “Enhancements” report.
On my own media sites, Article and BreadcrumbList markup did more for visibility than many flashier optimisations. My advice: start small, one clean, tested type, rather than a pile of approximate schemas Google will eventually ignore. Consistency beats completeness. — Simon Janvier
Primary source: Google’s structured data documentation and the reference vocabulary at Schema.org.
