RETURN_TO_BLOG
Updated: AI & SEO 12 min

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.

Schema typeRich result status (2025–2026)Notes
Article / BlogPostingActiveheadline, image, author, datePublished/dateModified, publisher
Product + Offer + ReviewActivestars, price, availability; product reviews OK
BreadcrumbListActive — desktop onlysince January 2025 Google no longer shows breadcrumbs on mobile
Event / Recipe / VideoObjectActiverequire a full set of properties (e.g. Event: name, startDate, location)
JobPostingActive (Google Jobs)standalone "Estimated Salary" retired June 2025
Organization / LocalBusiness / PersonNo standalone rich resultfeed the logo, Knowledge Panel, entity understanding
FAQPageRetiredrich result heavily restricted in 2023, report removed in 2026 — you can keep the markup, but no star result
HowToRetired (2023)the rich result no longer shows
Course ("Course Info" card)Retired June 2025the "Course List" carousel still works
WebSite + SearchAction (sitelinks search box)Retired November 2024the markup doesn't hurt, but won't produce a search box

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.

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).

JSON-LD — personal brand / service business
{  "@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 `@id`s 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:

/// AUTHOR
Paweł Wiszniewski – AI & Web Engineer

Paweł Wiszniewski

SEO & GEO Specialist & AI Engineer

SEO/GEO specialist (10 years) and AI engineer (3 years). I build search visibility, AI systems and automations that reduce costs and improve operational efficiency.

Signal received?

Terminate
Silence

Initiate protocol. Establish connection. Let's build something loud.

> WAITING_FOR_INPUT...