Schema.org Structured Data - The Complete Guide (2026)

Structured data is how you tell a search engine, explicitly, what your content is: that this is an article with a specific author and date, a product with a price, a business with an address, or a person with profiles across the web. You write it in JSON-LD - Google's recommended format - and it makes your page eligible for rich results (enhanced listings with stars, prices, breadcrumbs), while helping search engines and AI models understand the entities on the page. This guide explains what structured data really does, which types still work in 2025-2026 (and which Google has retired), what a correct JSON-LD graph looks like, and the mistakes to avoid.

Structured data (JSON-LD) makes a page eligible for rich results and helps search engines understand entities. I explain which schema types still work in 2025-2026 and which Google retired (FAQ, HowTo, sitelinks search box), what a correct JSON-LD graph looks like, and the mistakes to avoid.

Let me start with the sentence that will save you disappointment: structured data will not directly raise your Google ranking. It is not a ranking factor. So what does it do? It makes you *eligible* for features that genuinely lift CTR and visibility. Think of it as a ticket - it doesn't get you into the party, but without it you can't get in at all.

What structured data is and why JSON-LD

Structured data is a machine-readable description of content - entities (things) and the relationships between them - attached to a page so a search engine understands it beyond raw text. The shared vocabulary is Schema.org: an open taxonomy of types and properties, founded in 2011 by Google, Microsoft (Bing) and Yahoo!.

The same vocabulary can be written in three formats: JSON-LD (an object in a script tag, separate from the HTML), Microdata (attributes woven into visible markup), and RDFa. Google supports all three but recommends JSON-LD, because:

• it's the easiest to implement and maintain at scale;
• it's separate from the visible HTML - it doesn't break when the UI changes (Google admits sites break Microdata far more often, because it's embedded in the markup);
• it can be generated dynamically server-side.

Where to put it? In a script type="application/ld+json" block, in the head or the body - both are valid. The safest option is to embed it in server-rendered HTML; injecting via JavaScript or a tag manager works, but Googlebot only reads it after rendering, in a separate, deferred step.

Structured data → rich results. What it really gives you

Let's sort out the terms, because the confusion here is enormous:

• Rich result - any enhanced listing powered by structured data: review stars, a product card, breadcrumbs, a recipe card, a carousel.
• Rich snippet - the older term for extras *inside* a regular text result (stars, price under the blue link).
• Knowledge Panel - a panel describing an entity, powered by the Knowledge Graph. Technically *not* a rich result, and not created directly from a single page's schema, though structured data and entity signals can contribute to it.

And two rules that are easy to forget: eligibility is not a guarantee (correct markup, even one that passes Google's test, doesn't guarantee display - Google decides), and structured data helps understand entities and relationships, which feeds the Knowledge Graph and - indirectly - visibility in AI search.

Which types still work in 2025-2026 (and which Google retired)

This is the most important, most time-sensitive section. Google has cut a lot in recent years - and adding retired types "for the rich result" is now a waste of time.

The key practical trap: don't add FAQPage or HowTo hoping for a rich result that no longer appears. You may keep the markup (it helps with content understanding and AI), but don't count on an enhanced SERP listing.

And one rule that surprises businesses: "self-serving" reviews don't earn stars. If you put Review/AggregateRating about your own business on a LocalBusiness or Organization page, Google won't show stars (enforced since 2019). The exception is Product - product reviews still qualify for stars.

In an online store the most important types are Product, Offer and BreadcrumbList, consistent with the Merchant Center feed. Implementing them in store templates is part of my ecommerce SEO service.

What a correct JSON-LD graph looks like

The good pattern is a single `@graph` block with nodes linked by @id (the canonical URL with a fragment). You define site-wide entities (WebSite, Organization/ProfessionalService, Person) once, and pages (WebPage, BreadcrumbList) reference them by @id. You attach external profiles via sameAs (the strongest Knowledge Graph signal is Wikidata).

{  "@context": "https://schema.org",  "@graph": [    {      "@type": "ProfessionalService",      "@id": "https://example.com/#organization",      "name": "John Smith - SEO Consulting",      "url": "https://example.com/",      "telephone": "+1-555-123-4567",      "priceRange": "$$",      "founder": { "@id": "https://example.com/#person" },      "areaServed": "US",      "sameAs": ["https://www.linkedin.com/in/johnsmith"]    },    {      "@type": "Person",      "@id": "https://example.com/#person",      "name": "John Smith",      "jobTitle": "SEO Consultant",      "worksFor": { "@id": "https://example.com/#organization" },      "sameAs": ["https://www.wikidata.org/wiki/Q000000"]    },    {      "@type": "BreadcrumbList",      "@id": "https://example.com/services#breadcrumb",      "itemListElement": [        { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://example.com/" },        { "@type": "ListItem", "position": 2, "name": "Services" }      ]    }  ]}Pattern rules: consistent `@id` for the same entity across the whole site; relationships via references (`founder`, `worksFor`); the last `ListItem` in the breadcrumb has no `item` (it's the current page); dates and times always in ISO 8601 format.

Structured data and AI visibility (GEO)

Here you have to separate fact from marketing. Confirmed: Google has no separate technical requirements for AI Overviews beyond the page being indexed - schema is not a guaranteed route into AI answers. John Mueller consistently states that structured data doesn't directly affect ranking; its role is to enable features and help understand content, entities and relationships.

Speculative (and worth treating as such): the claim that models like ChatGPT or Perplexity *directly read* your JSON-LD is not confirmed by the providers - most AI engines consume the rendered content. Practical takeaway: structured data is good foundational practice for entity clarity and machine understanding, but don't promise yourself a direct jump in AI citations. I write more about this in SEO vs GEO and GEO in practice.

The most common mistakes (and how we audit schema in practice)

• Marking up content not visible on the page (or available only after login) - the leading cause of ineligibility, and in extreme cases a manual action. Google's rule is literal: don't mark up content the user can't see.
• Data mismatch - a price or rating in schema different from the page.
• Wrong or too-generic types (e.g. Thing instead of the proper type).
• Missing required fields - the item becomes ineligible (Error in Search Console).
• Duplicate or conflicting schema - solved with consistent @ids instead of redefining the same entity.
• Expecting retired rich results (FAQ, HowTo).

This isn't theory. Auditing this very site's structured data, we fixed exactly these things: PostalAddress without the required streetAddress, ImageObject without dimensions and a caption, Offer without price/priceCurrency, BlogPosting without author, and Course without description. Each of those gaps is a potential "Error" in Search Console and a lost rich-result eligibility.

Validation tools

• Google Rich Results Test - checks eligibility for rich results *supported by Google*. Tests a live URL or pasted code, renders the page, and shows detected types and errors.
• Schema Markup Validator (validator.schema.org) - validates general Schema.org syntax and vocabulary for all types; does *not* check Google rich-result eligibility.
• Search Console → Enhancements reports - per-type status (Error / Warning / Valid) based on the last crawl, with a "Validate Fix" button. This is the tool for monitoring at scale.

---

I implement and audit Schema.org structured data - from a full entity graph to fixing the errors that block rich results. Schema is also the foundation of knowledge graph engineering and Entity SEO. I break it all down in the SEO & GEO course. Get in touch - I'll start by auditing your current schema in the Rich Results Test and show you what's blocking enhanced listings.

Worth reading next:

• Image SEO in the AI era - Google Lens and graphics models cite
• Core Web Vitals - how to improve LCP, INP and CLS
• GEO - what it is and how it differs from SEO