Structured Data in 2026: Which Schema Still Moves the Needle

What structured data actually does in 2026 (and what it does not)

Structured data in 2026 does two things: it makes a page eligible for the rich result types Google still shows, and it gives search engines and AI systems an unambiguous statement of what an entity is. It does not raise rankings by itself, and it has never been a ranking factor. Every claim beyond those two is either a side effect of the first (a rich result wins more clicks at the same position) or a misreading of a correlation study.

That framing matters because the rich-result landscape shrank sharply between 2023 and 2025. Google removed FAQ rich results for most sites in August 2023, retired HowTo on desktop the same year, dropped the Sitelinks search box, and deprecated several video and product enhancements. What survived is the markup tied to real transactions or real entities: Product with price and availability, Organization with verifiable identifiers, Article for news and blog surfaces, LocalBusiness, Event, JobPosting, Recipe, Review snippets on eligible types, BreadcrumbList and VideoObject. Google's own structured data gallery is the only authoritative list, and it is worth checking against every quarter because deprecations are announced quietly.

The second job — entity clarity — has grown as the first has shrunk. Google's systems, AI Overviews and third-party assistants all lean on unambiguous entity signals to decide which page represents which organisation, product or person. A correct Organization node with a stable @id, a Person node for the author with sameAs links, and Article markup that references both is the difference between being an anonymous page and being a known source. That is not a rich result; it is the plumbing under E-E-A-T.

The data confirms how much of the web still treats markup as decoration. HTTP Archive's 2024 crawl found JSON-LD on 41% of pages, but the dominant types are WebSite (12.7%), Organization (7.2%) and BreadcrumbList (5.7%). Product appears on under 1% of pages and Article on a fraction of that. In other words, the boilerplate everyone's CMS emits is common; the markup that earns a visible result is rare, and therefore still a competitive lever.

The schema types that still earn a visible result

Six families of markup still produce a visible change in Google's results in 2026: Product (with Offer, price, availability and aggregateRating), Organization and LocalBusiness (knowledge panels and local packs), Article and NewsArticle (Top Stories, Discover eligibility and headline/thumbnail treatment), VideoObject (video thumbnails and key moments), Event and JobPosting (dedicated search experiences), and Review/AggregateRating on eligible parent types. BreadcrumbList changes the URL line under a result rather than adding a feature, but it is the cheapest markup on this list and it works on every page type.

Everything else is a judgement call. FAQPage still validates and Google still documents it, but rich results are restricted to authoritative government and health sites, so on a commercial page its value is entity clarity and AI-readability rather than SERP real estate. HowTo is gone. Speakable is limited to news publishers. Course, Dataset, Software Application and Special Announcement have narrow eligibility. If a client asks for markup that is not in the gallery, we implement it only when it costs nothing and describes something true — never because a plugin offered it.

The priority column is not theoretical. When we rebuilt the technical foundation for a B2B SaaS client, the organic growth came from architecture and content, and the schema work was deliberately minimal: a single Organization node, clean Article markup on the blog and BreadcrumbList everywhere. Nothing more exotic was needed, and nothing more exotic would have been attributable to a number we could isolate.

What we learned implementing VideoObject and Organization on our own site

The most useful evidence we have is our own. renhaoseo.com runs a single Organization node, a Person node for the founder, Article markup output once through Yoast, FAQPage and BreadcrumbList inline in article bodies, and VideoObject on the pages that embed our YouTube explainers. Three lessons came out of auditing that stack across 900 URLs in September 2026, and each generalises.

First, duplication is the most common structured data defect on real sites, and it is invisible in a validator. Nineteen of our older articles carried two Article nodes — one from the SEO plugin and one hand-written into the body — with different authors, dates and headlines. Each node validated on its own. Together they told Google two contradictory stories about the same URL. We deleted the hand-written copies and now enforce a single-source rule: Article, WebPage, Organization and BreadcrumbList come from one filter, and article templates may only add FAQPage. Our technical SEO checklist now has a line for this because it is that common.

Second, VideoObject only pays for itself when the video is genuinely the page's subject or a substantial section of it. We embed two founder explainers on the home page and describe them with name, description, thumbnailUrl, uploadDate, duration and embedUrl. The point is only partly the thumbnail: the markup gives Google a second E-E-A-T signal — a real person on camera, marked up as the same Person node that authors the articles — attached to the same Organization @id. We do not add VideoObject to pages with a decorative clip, because markup describing a video that is not the page's subject is noise at best and misleading at worst.

Third, wrappers matter. A template change in September silently stripped the <script type="application/ld+json"> tags from eleven category pages, so the JSON rendered as garbled visible text at the top of each page for every visitor and every crawler until a routine crawl caught it. The fix took an hour; the lesson is that structured data has to be monitored in the rendered HTML, not just tested at deploy, because a validator run at launch cannot see a template regression.

Entity markup: Organization, Person and the @id discipline

The single highest-leverage structured data decision in 2026 is giving your organisation one stable identifier and pointing everything else at it. That means an Organization node with an @id such as https://example.com/#organization, emitted once on every page, carrying name, url, logo, sameAs (your verified social and directory profiles), contactPoint and a postal address if you have a real one. Every Article's publisher, every WebPage's about, every Product's brand then references that @id instead of restating the details.

Do the same for people. An author who exists as a Person node — with an @id, a jobTitle, an image and sameAs links to a LinkedIn and YouTube profile — is an entity Google can connect across pages and across the web. An author who is a text string in a byline is not. We moved our own Article author and reviewedBy fields from a brand name to the founder's Person node during the September audit, and we now treat an author page as a ProfilePage rather than a generic WebPage. Google's guidance on ProfilePage markup is explicit that this is how it identifies creators.

The data-driven argument for this is straightforward. Google's quality systems evaluate sites, not just pages, and the May 2026 core update made site-level quality tiering more visible. Entity markup does not make content better, but it makes it attributable. When two pages answer the same question and one is attributable to a named organisation with a verifiable founder, consistent identifiers and a real address, the attributable page has an easier case for the higher tier. For AI Overviews and assistant citations, where the source list is short, attributability decides who gets named.

• One Organization node, one @id, emitted on every page; no per-page restatement of the same details.
• Person nodes for every author and reviewer, each with an @id, image, jobTitle and sameAs; authors as ProfilePage.
• Article.author and Article.publisher point at those @ids; Article.image points at a real image on the page.
• sameAs only for profiles you control and that carry the same name and logo — mismatches weaken the entity rather than strengthen it.
• Address and contactPoint only if they are real and match the footer; fabricated NAP data is worse than none.

Product, Review and Merchant markup for commerce

For any site that sells, Product markup with a complete Offer is still the highest-ROI structured data there is: it is what puts a price, availability and star rating under your listing, and it feeds Google Merchant Center's free product listings. The elements that matter are price with priceCurrency, availability as a schema.org URL, a sku or gtin that matches your feed, shippingDetails and hasMerchantReturnPolicy for the merchant listing experience, and aggregateRating only where the reviews are real and the review count is honest.

Two mistakes cost commerce sites their snippets more than any other. The first is self-serving reviews: marking up your own testimonials with Review or aggregateRating on an Organization or LocalBusiness page has been against Google's guidelines since 2019, and it still triggers manual actions. Reviews belong on Product, Book, Recipe, Movie and a handful of other types, and they must be collected from users. We rebuilt our own testimonial section as anonymised result cards with no Review markup at all for exactly this reason: a manual action is a far larger risk than a missing star rating on a page that was never eligible for one.

The second is markup that disagrees with the visible page. If the snippet says in stock and the page says sold out, or the marked-up price is the pre-discount figure while the button shows the sale price, the enhancement is dropped and the page can be flagged. The fix is architectural: generate Product markup from the same data source that renders the page, never from a separate plugin field a merchandiser has to remember to update. When we audit an ecommerce site, we sample fifty product URLs and compare the JSON-LD values to the rendered DOM; a mismatch rate above 5% means the markup is being maintained by hand and will decay.

Jewellery is a useful test case because prices move with metal rates and stock is often one-of-a-kind. The organic sales growth in our jewellery case study came from category architecture and product content, but the product snippets only held because price and availability were generated from the inventory system on every render.

Article, FAQPage and video markup for content sites

Content sites should implement exactly three things on every editorial page — Article (or BlogPosting), BreadcrumbList and, if there is a video, VideoObject — and stop there unless a specific page qualifies for something more. Article markup should carry headline (matching the H1, not a keyword-stuffed variant), datePublished and dateModified that match the visible dates, author and publisher as @id references, and image pointing at a real 1200-pixel-wide image on the page. Google uses the image for Discover and Top Stories, so a page without a real image gets no thumbnail regardless of markup.

FAQPage deserves a plain assessment. Since August 2023 it produces rich results only for authoritative government and health sites, so on a commercial article it will not add expandable questions under your listing. It still has two uses. It describes the page's question-and-answer structure to AI systems that ingest schema.org types, and it forces the writer to produce short, self-contained answers, which is precisely the format AI Overviews and assistants quote. We keep FAQPage on our own articles for those reasons, with seven questions each, and we make sure the answers are visible on the page — hidden FAQ text is a guideline violation.

VideoObject is worth implementing wherever a video carries real content: name, description, thumbnailUrl, uploadDate, duration and either contentUrl or embedUrl, plus Clip or SeekToAction markup if you want key moments. For YouTube embeds, the thumbnail and duration are available from the video's public data; the mistake is describing a video the page does not actually embed, which Google treats as misleading. Video markup also pairs naturally with Person markup: a founder on camera, marked up as the video's author and linked to the Organization, is one of the few E-E-A-T signals a small firm can produce that a content farm cannot fake cheaply.

1. 1
   Pick one emitter per node type

   Decide whether the SEO plugin or your template owns Article, WebPage, Organization and BreadcrumbList. Delete every other source. Validate that each URL emits exactly one of each.
2. 2
   Anchor everything to @ids

   Create the Organization and Person nodes once, with stable @ids, and reference them from every Article and WebPage.
3. 3
   Generate commerce markup from live data

   Product price, availability and identifiers come from the same source that renders the page. Never a separate field.
4. 4
   Match markup to the visible page

   Headline = H1, dates = visible dates, image = real image, FAQ answers visible, video actually embedded.
5. 5
   Monitor the rendered HTML

   Crawl weekly for JSON-LD parse errors, missing script wrappers and duplicate node types. Search Console's enhancement reports lag by days.

Testing, monitoring and the failure modes we see most

The tools have not changed much: Google's Rich Results Test tells you eligibility, the Schema Markup Validator tells you syntactic validity, and Search Console's enhancement reports tell you what Google has actually processed across the site. What has changed is how we use them. Rich Results Test on a handful of pages is a launch check, not monitoring. Monitoring means a scheduled crawl that parses every JSON-LD block on every URL and alerts on four conditions: parse errors, more than one node of the same type, a node type that has been deprecated, and a mismatch between marked-up and visible values on a sample.

The failure modes are consistent across the sites we audit. Duplicate Article nodes from a plugin plus a theme; Organization repeated on every page with slightly different details; BreadcrumbList that does not match the visible breadcrumb; Product markup with a stale price; and — the one that hurts most — a template change that breaks the script wrapper or the JSON syntax site-wide. None of these show up as a ranking drop labelled "schema". They show up as a slow decline in click-through, a lost snippet, or an enhancement report that quietly goes from hundreds of valid items to zero.

The last practical question is what to remove. Retired types (HowTo, Sitelinks search box), FAQPage on pages where the questions are not visible, Review markup on your own testimonials, and any type describing something the page does not contain should go. Markup that is valid but useless is not harmless: it adds bytes, it adds maintenance, and when it drifts out of sync with the page it becomes a trust problem. A small, correct, monitored schema stack outperforms a large decorative one, and it is the version we deploy in our data-driven technical SEO service on every engagement.

Frequently asked questions