Why schema markup still matters in 2026
Structured data used to be a rich-results play. You added markup, you got stars or expandable questions or a recipe card, and the payoff was measurable in click-through rate. That bargain has weakened — Google has withdrawn or restricted several of the rich result types that motivated adoption, most notably FAQ results, which since 2023 have been limited to well-known government and health sites.
Yet structured data matters more in 2026 than it did in 2021, for a different reason. Prose is ambiguous. A page saying "from ₹45,000, typically delivered in six weeks" requires interpretation. A JSON-LD block stating a currency, an amount, and an offer does not. As more of the reading is done by machines — search systems, AI assistants, agents comparing options — the value of stating facts unambiguously goes up, whatever the visual result.
Which schema types still earn their place
Not every schema type is worth the maintenance. These are the ones that consistently repay it.
Organization
The foundation. Name, URL, logo, address, contact points, and sameAs links to your verified social profiles. This is how a search system resolves the many mentions of your business into one entity. Get the sameAs list right and keep it current — a link to an abandoned or renamed profile weakens the association rather than strengthening it.
WebSite
Pairs with Organization and carries your site-level identity. Small, stable, and worth having.
Article or BlogPosting
Author, publisher, publication date, modification date, and headline. The dates matter more than people expect: AI systems weight recency, and content with no machine-readable date is harder to place in time.
Product and Offer
Essential for anything transactional, and the single most common place we find incomplete implementations — markup that includes a price but omits priceCurrency, or omits availability entirely. For agents comparing options, availability and currency are not optional details; they are the comparison. This connects directly to the readiness questions in agentic commerce.
LocalBusiness
If you have a physical location or serve a defined area, this plus a properly maintained Google Business Profile is the backbone of local visibility.
BreadcrumbList
Still produces the breadcrumb trail in results, still cheap, still useful for communicating site structure.
FAQPage
No longer a rich-result play for most sites, and still worth keeping. Question-and-answer pairs are the format AI systems extract most cleanly, and a page that states its questions in structured form is easier to quote accurately than one that buries them in prose.
The schema mistakes that actually hurt
Broken @id references
The most damaging and least visible. If your Organization, WebSite, and WebPage entities reference each other by @id, those identifiers are load-bearing. Change one, duplicate one across pages, or typo one during a migration, and the graph stops resolving into a single coherent entity — each page starts describing an organisation unrelated to the others.
The reason this is dangerous rather than merely bad is that it validates cleanly. Testing tools check syntax, not whether your identifiers resolve. Nothing appears wrong until entity recognition quietly degrades over months.
Markup that describes content the page does not have
FAQ schema for questions that are not on the page, review ratings that appear nowhere in the visible content, prices that differ from the displayed price. This is the category that draws manual actions for spammy structured data, and it is usually done without any intent to deceive — someone adds markup from a template and never checks it against the page.
Hand-written JSON-LD that drifts
Structured data written by hand and pasted into a template will eventually contradict the page. Prices change, dates change, a service is renamed. Generate schema from the same source of truth that renders the content, so the two cannot disagree.
Multiple disconnected script blocks
Several separate JSON-LD blocks describing overlapping entities, with no relationships between them, forces a parser to guess which Organization is the real one. A single @graph with explicit relationships is both cleaner and more likely to be interpreted the way you intend.
How to check your structured data properly
Validation tools tell you whether your JSON parses and whether required fields are present. They do not tell you whether it is true, whether the identifiers resolve, or whether it matches what a visitor sees.
A real check has four steps: run the Rich Results Test and the Schema.org validator to catch syntax and required-field problems; open the page and confirm every marked-up fact appears in the visible content; trace every @id reference to a node that actually exists in the graph; and inspect a rendered page in production rather than a staging build, because client-side injection frequently means the markup a crawler receives differs from what you wrote.
Where schema sits in the priority list
Structured data is a multiplier, not a foundation. On a site with thin content, unclear positioning, or serious technical problems, schema will not rescue anything — it will accurately describe a page nobody wants. On a site with genuinely useful content, it removes ambiguity and makes that content easier to surface, quote, and compare.
So do it after the content and the technical basics are sound, and before you start on more exotic optimisation. It pairs with the code-level work in how layout and code quality affect rankings and with the citation work in tracking brand visibility in AI search. If you suspect your graph is quietly broken — which it often is after a redesign or a CMS migration — we will audit it.