Structured Data

Last updated 25 April 2026

Structured data is machine-readable metadata embedded in a webpage that explicitly declares the meaning of its content. It uses the schema.org vocabulary and is most commonly delivered as JSON-LD. Implemented correctly, structured data drives rich results, improves AI parsing, and reinforces topical signals.

This page covers structured data from a technical SEO angle. The on-page implementation guide lives at Schema Markup.

What structured data does

The HTML on a page describes how content should be displayed. Structured data describes what the content actually means. A <p> tag containing “Dr. Sarah Wilson” tells a browser to render the text in paragraph style; a Person schema with name “Dr. Sarah Wilson” and a knowsAbout array tells search engines that this string refers to a specific real person with declared expertise.

The benefits cascade through several systems:

Search engines use structured data to power rich results (FAQ accordions, recipe cards, product information, event details, video carousels).
AI engines use it to extract authoritative metadata about authors, dates, publishers, and content type.
Knowledge graphs use it to construct entity relationships across the web.
Voice assistants use it for spoken responses.

Implementation: JSON-LD as the standard

Three formats are valid for structured data: JSON-LD, Microdata, and RDFa. Use JSON-LD. It is Google’s recommended format, sits in a separate <script> block independent of HTML structure, and is significantly easier to maintain.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Structured Data",
  "datePublished": "2026-04-25",
  "author": {
    "@type": "Person",
    "@id": "https://example.com/#author"
  }
}
</script>

JSON-LD blocks can be placed in <head> or <body>. <head> is conventional. Multiple JSON-LD blocks per page are permitted; common pattern is one Article block, one BreadcrumbList block, plus any rich-result-specific blocks (FAQ, HowTo, Product).

Schema types by site type

Editorial / publication sites: Article (or NewsArticle, TechArticle), Person (for authors), Organization (for publisher), BreadcrumbList, FAQPage where applicable.

E-commerce: Product, Offer, AggregateRating, Review, BreadcrumbList, Organization. Optionally HowTo for product-related instruction pages.

Local businesses: LocalBusiness (or a subtype like Restaurant, Dentist, Plumber), PostalAddress, OpeningHoursSpecification, AggregateRating, Service.

SaaS / software: SoftwareApplication, Organization, AggregateRating, Review, BreadcrumbList, FAQPage on documentation.

Personal sites / portfolios: Person, CreativeWork (for projects), AboutPage, BreadcrumbList.

Recipe sites: Recipe (with ingredients, cookingMethod, nutrition), AggregateRating, Review.

Event sites: Event (with location, performer, offers), Place.

Video-heavy sites: VideoObject (with thumbnailUrl, uploadDate, duration), embedded on the page hosting the video.

The @id graph pattern

For sites with multiple schema entities (Person, Organization, WebSite), the most powerful pattern is to give each entity a stable @id and reference them across pages.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Person",
      "@id": "https://example.com/#person",
      "name": "Author Name"
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "author": { "@id": "https://example.com/#person" }
    },
    {
      "@type": "Article",
      "@id": "https://example.com/article/#article",
      "author": { "@id": "https://example.com/#person" },
      "isPartOf": { "@id": "https://example.com/#website" }
    }
  ]
}

This makes the entity graph explicit, which is exactly what AI systems and Google’s knowledge systems are trying to construct. The harder you make the graph for them to read, the better.

Validation

Two tools to use before shipping any schema change:

Schema Markup Validator. Validates against the schema.org specification. Catches structural errors.
Google Rich Results Test. Validates against Google’s specific requirements for rich result eligibility.

Both should pass. The Schema Markup Validator alone is not sufficient because Google has additional requirements (image sizes, required properties for specific rich results) that go beyond the base schema.org spec.

Common technical mistakes

Schema describing content not visible on the page. Adding FAQ schema for questions not actually shown to users is a guidelines violation that has resulted in manual actions. The general rule: if the user cannot see it, do not mark it up.

Conflicting @type values across blocks. A page with two competing Article schemas confuses parsers. Have one Article block per page.

Missing required properties. Each schema type has required properties (Article needs headline, Recipe needs name, Product needs name and image). Missing requireds make the schema invalid; Google ignores it entirely.

Using string IDs that aren’t URLs. @id should be a URL (URI). String IDs like "@id": "author-1" are invalid and don’t participate in graph relationships.

Schema only on some pages. Inconsistent application across the site fragments the entity graph. Apply schema systematically.

Stale dateModified. Auto-incrementing the dateModified on every build (a common mistake with static-site generators) destroys the freshness signal. Set it from the actual content modification date.

Maintenance and monitoring

Schema implementations drift. Field changes to schema types, framework upgrades that change rendering, and CMS template edits can all silently break schema. Monitoring approaches:

Search Console > Enhancements. Reports rich result eligibility and errors per schema type.
Periodic spot-checks. Run the Rich Results Test on a sample of important URLs quarterly.
Crawl-based audits. Screaming Frog and Sitebulb extract structured data from every URL during a crawl, surfacing missing or invalid schema across the site.

Frequently asked questions

Does structured data improve rankings directly? No. The indirect effects (rich results, better CTR, clearer topic signals, AI citation) move rankings.

How do I know which schema types my site is eligible for? Google’s search gallery lists current rich result types and their requirements. Not all schema types produce rich results; those that don’t still serve indexing and AI purposes.

Can structured data be added retrospectively to old content? Yes. Adding schema to existing pages is a frequent quick-win SEO project. Pages that previously had no schema often gain rich result eligibility within weeks of implementation.