JSON-LD for SEO: Schema Types That Earn Rich Results in 2026

In 2026, the JSON-LD types that still earn visible Google rich results are a short list: Product (with offers and a genuine aggregateRating), Review, Event, Article with author and publisher, and BreadcrumbList. That is it for the types most sites can actually ship. FAQPage lost its Google rich result in May 2026, and HowTo stopped showing long before that. More important than any type is the one rule Google enforces on all of them: structured data must describe what is actually on the page, and nothing else. Eligible is not the same as guaranteed, and every type in this guide is worth less than the accuracy of the markup behind it.

If you need the foundations first, our JSON-LD guide covers what JSON-LD is and why Google reads it. This piece is the practical companion: what each rich result looks like, the honest caveats, and how to emit, validate, and generate the markup at scale.

The rule that governs every type: mark up what is actually on the page

Google’s general structured data guidelines are blunt: the markup “must be a true representation of the page content,” you should not “mark up content that is not visible to readers of the page,” and fake reviews or ratings “not by actual users may result in manual action.” A manual action means the page loses eligibility to appear as a rich result, which Google is careful to say does not change how the page ranks in normal web search. In other words, the penalty is specific and it targets exactly the thing you added structured data for.

This one rule decides most outcomes in 2026. The product page with a rating someone typed into the JSON-LD but not into the page gets its stars taken away or never gets them. The event page marked up after the date has passed gets nothing. Structured data is a promise that a machine can verify the page’s claims; the moment the markup says more than the page shows, the feature is gone. Everything below assumes the rule is followed first.

Product: the type with the most ways to display

Product markup has the deepest toolbox in 2026. Google’s Product documentation splits it into two classes: product snippets for pages where people cannot buy directly (editorial reviews can carry pros and cons), and merchant listings for pages where a customer can purchase, which can carry apparel sizing, shipping, and return policy detail. Both can surface price, availability, ratings, and shipping information in the result, including in Google Images and Lens.

A compact, valid Product block looks like this:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Atlas G10 mesh office chair",
  "image": "https://www.example.com/atlas-g10.jpg",
  "description": "Ergonomic mesh chair with adjustable lumbar support.",
  "offers": {
    "@type": "Offer",
    "url": "https://www.example.com/atlas-g10",
    "price": "249.00",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "312"
  }
}

The caveats are where the value is. The price and availability must match the price on the page, and when you run a sale, the price in the markup must change too: Google’s docs explain sale prices can be bounded with priceValidUntil, and a feature like a price-drop tag is computed by Google observing your price change over time, “not guaranteed to be shown.” Ratings require real customer reviews visible on the page; if the page has no reviews, the aggregateRating block makes the markup a lie and a manual action target. And Google is explicit that “result enhancements are shown at the discretion of each experience, and may change over time,” the standing reminder that eligibility never equals display. Google also recommends adding merchant return-policy markup nested under your Organization so shopping surfaces understand the terms.

Review and AggregateRating: the star snippet is earned, not added

The review snippet is the little star row under a result, and it remains one of the more visible rich results. Per Google’s Search Gallery, review snippets are documented for Book, Recipe, Movie, Product, Software App, and Local business, and Google’s review snippet page extends that to types like Game, MusicRecording, and MediaObject.

Two rules decide eligibility, and both are about honesty. First, the self-serving review restriction: a site marking up reviews about its own product or service does not qualify. Google’s docs note that Local business and Organization markup is only for “sites that capture reviews about other local businesses,” with a pointer to the guidelines on self-serving reviews. Your customers’ reviews of your product belong on your review platform, not in stars you award yourself. Second, the reviews behind an aggregateRating must be real user reviews visible on the page, with a ratingValue and reviewCount that match them. For an aggregate rating the snippet cannot display without the average, so a bare block usually means nothing shows. In July 2026 Google added a new review snippet guideline on fake and undisclosed incentivized reviews, so the enforcement direction is clear.

Event: the richest result most sites ignore

Event markup feeds the event experience in Search and Maps: an interactive card with your logo, the event description, date and time, and a link where people buy tickets. Google’s Event documentation cites Eventbrite’s reported 100% increase in typical year-over-year traffic from Google Search after integrating. The block needs name, a startDate with the correct timezone (Google’s docs stress local time for the venue), a location or an online mode, an image, an eventStatus, and an offer whose URL points at the ticket page.

A 30-minute walkthrough from NSDA’s Digital Marketing Level-4 course builds Event markup in JSON-LD from scratch and shows how the pieces fit, from location to offers:

The honest caveat: Event rich results go to events that are public, in the future, and accurately described. Google’s structured data guidelines say it will not show a rich result for time-sensitive content that is no longer relevant, so a canceled event should carry eventStatus: https://schema.org/EventCancelled and stale events should be removed or updated, not left marked up.

Article: the byline that feeds the news and knowledge surfaces

Article markup (Article, NewsArticle, or BlogPosting) does not require any properties at all, which makes it the lowest-cost type on this list. Google’s Article documentation says it helps Google “show better title text, images, and date information” in results and on Google News, and unlike Product or Review it has no strict required set. The type you choose matters: NewsArticle for news, BlogPosting for blog posts, plain Article for documentation and evergreen pieces.

The part worth doing properly is authorship. Google’s author best practices ask for the author as a Person with a name and a url pointing to a page that identifies them, and the publisher (for news, your organization) alongside. That is the block that earns a recognizable byline in results and that AI answer engines can attribute. When every article on the site has the same anonymous author object, the markup is technically fine and practically useless.

FAQPage and HowTo: the 2026 honesty clause

Two types on every agency’s checklist no longer earn Google rich results, and the dates are verifiable. Google deprecated the FAQ rich result feature in May 2026 and removed its documentation in June 2026. FAQPage markup can still be read by other search engines and AI answer engines, so keeping it is not wrong, but it no longer produces the expandable FAQ search feature. HowTo went earlier: Google retired HowTo rich results a couple of years back, and the old documentation URL now forwards to a deprecation notice in the Search Central updates feed. If a vendor is selling you either of these as a 2026 rich-results strategy, that is the tell.

BreadcrumbList: cheap, safe, and everywhere

Breadcrumb markup is the quiet winner: Google’s Breadcrumb documentation notes the feature is available on desktop in all regions and languages, so coverage is the widest of anything on this list. It replaces the URL under your result with a trail, such as Books › Science Fiction › Award Winners, which is more informative for the searcher and more legible for you. A valid block is a BreadcrumbList of ListItems, each with a position, a name, and an item URL pointing at a real page. The trail should match the breadcrumbs a visitor sees on the page; there is no upside in marking a trail the page does not show.

One entity per page: the pattern that keeps JSON-LD valid

Google supports multiple items on a page, nested or as separate blocks. The pattern that validates cleanly at scale is one main entity per page with everything else nested under it: Product carries offers, aggregateRating, and review; Article carries author and publisher; Event carries offers and organizer. One @type per page, one unambiguous subject, and every nested value traceable to visible text.

Google’s intro to structured data makes the same point about completeness: “it is more important to supply fewer but complete and accurate recommended properties rather than trying to provide every possible recommended property with less complete, badly-formed, or inaccurate data.” An Article with no properties except headline, author, and datePublished beats the same page stuffed with every schema.org field the generator could reach for.

Validate before you ship: two tools, one workflow

The workflow has two steps. First paste the URL or the code into Google’s Rich Results Test, which tells you which features the page could be eligible for and flags critical errors; Google recommends fixing critical errors and treating flagged non-critical issues as quality improvements rather than blockers. Then run the same code through the schema.org validator to confirm the markup parses against the vocabulary. After deployment, watch the Rich results report in Search Console to see which pages actually gain features, and check the Manual Actions report if a page ever loses them. If you deploy a template change, re-test a sample URL rather than assuming nothing broke.

Generate from templates and inject at the edge

Hand-writing JSON-LD on a ten-thousand-page site does not scale, and it is precisely how markup rots. The disciplined approach is templates: one per page type, with the title, URL, dates, price, and rating filled from the same data the page renders from. If the template reads the price from the product database, the markup and the page cannot disagree; if you regenerate a product block with the page’s real review count, the accuracy rule is enforced by construction.

Templates still require deploying to every template of every page type, which is where the edge comes in. Rather than maintaining JSON-LD inside each page’s CMS template, a Cloudflare Worker stands in front of the site and injects the completed block before </head> on the response:

export default {
  async fetch(request) {
    const response = await fetch(request);
    const html = await response.text();

    const jsonLd = {
      "@context": "https://schema.org",
      "@type": "Article",
      "headline": "JSON-LD for SEO: Schema Types That Earn Rich Results in 2026",
      "author": { "@type": "Organization", "name": "SEOEdgeAI" },
      "datePublished": "2026-09-11"
    };

    const script =
      `<script type="application/ld+json">${JSON.stringify(jsonLd)}</script>`;

    const updated = html.replace("</head>", script + "</head>");

    return new Response(updated, {
      status: response.status,
      headers: response.headers
    });
  }
};

In production, the block is built per-request from the page’s own data, which is how the accuracy rule survives at scale: the values come from the real content, never from a lookup the visitor cannot see. That single-Worker pattern is the same one we cover at length in technical SEO automation and the mechanism behind SEOEdgeAI, which rewrites and injects structured data on Cloudflare sites in about two seconds.

The 2026 scorecard is short: Product, Review, Event, Article, and BreadcrumbList earn features; FAQPage and HowTo no longer do; and every one of them is only as good as its truthfulness. Mark up what a visitor can verify on the page, validate it with the Rich Results Test and the schema.org validator, generate it from the same data that renders the page, and inject it consistently, and the markup earns what it can. The first rule is the hardest and the only one Google will enforce on your behalf.