Nadia Mohamed

Technical SEO

How to Create Rich Snippets with JSON-LD

By · · 14 min read

How do you create a rich snippet?

You create a rich snippet by adding structured data — machine-readable markup that describes the page’s content — in a format Google can parse, then confirming the page qualifies for one of the rich result types Google still supports. In practice that means writing a JSON-LD block, dropping it in the page’s <head>, filling in the properties Google requires for the type you’re targeting (Article, Breadcrumb, Product, Review), and validating the result in the Rich Results Test. The markup makes your page eligible for the enhanced display; it does not force it. Google decides at query time whether to show the rich result, and it only shows types that are still live — which as of 2026 no longer includes FAQ or HowTo.

I do both sides of this — I write the code and I do the SEO — and rich snippets are the place where those two jobs meet most directly. The markup is a small, self-contained engineering task with a precise contract: get the required properties right, keep them consistent with what’s on the page, and the page becomes eligible. Get them wrong, or mark up something the deprecation notices already killed, and you ship dead code that will never render. This guide is the build itself — the format to use, the type-by-type JSON-LD with the properties Google actually requires, how to validate, and the two rich result types that quietly disappeared and are no longer worth writing. (For whether rich snippets are worth the effort at all — what they do and don’t do for rankings and clicks — see Do Rich Snippets Actually Help SEO?.)

(“Rich snippet” is the older informal term; Google’s current documentation calls these rich results. I use both here because the search query is still “rich snippets,” but everything below targets what Google now calls rich results.)

TL;DR — Key takeaways

The rich result types you can actually create in 2026

Before writing a line of markup, check that the type you want still exists. Google maintains a gallery of the structured data features Search supports. As of 2026 the supported list includes Article, Breadcrumb, Carousel, Course list, Dataset, Discussion forum, Education Q&A, Employer aggregate rating, Event, Image metadata, Job posting, Local business, Math solver, Movie, Organization, Product, Profile page, Q&A, Recipe, Review snippet, Software app, Speakable, Subscription and paywalled content, Vacation rental, and Video.

Two former staples are conspicuously absent: FAQ and HowTo. Both once produced prominent rich results, both were widely implemented, and both are now dead — which is exactly why checking the gallery first matters. Implementing a deprecated type is the most common way to waste an afternoon on markup that can never render.

For most content sites, the types worth the effort are a short list: Article for editorial and blog content, Breadcrumb for site hierarchy, and — for e-commerce or review content — Product and Review snippet. The rest are niche. The four below cover the overwhelming majority of real rich snippet work.

Pick JSON-LD, and put it in the head

Google supports three structured data formats, but it does not treat them equally. Its documentation lists three formats: JSON-LD (marked Recommended), Microdata, and RDFa. The recommendation is explicit — in Google’s words, “Google recommends using JSON-LD for structured data if your site’s setup allows it, as it’s the easiest solution for website owners to implement and maintain at scale (in other words, less prone to user errors).”

The practical reason is separation. JSON-LD is a single <script type="application/ld+json"> block that sits apart from your HTML, so the markup never has to interleave with your template’s visible elements the way Microdata and RDFa attributes do. That makes it easier to generate programmatically, easier to diff in code review, and far less likely to break when the surrounding markup changes.

Place the block in the document <head> — Google reads JSON-LD from both the <head> and the <body>, but the head is the cleanest, most reliable location:

<head>
  <title>How to Create Rich Snippets with JSON-LD</title>
  <script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    "headline": "How to Create Rich Snippets with JSON-LD"
  }
  </script>
</head>

One rule governs everything that follows, and it is the one people break most often. Google’s guidelines state: “Don’t create blank or empty pages just to hold structured data, and don’t add structured data about information that is not visible to the user, even if the information is accurate.” Every property you declare must correspond to something a human can see on the rendered page. Mark up a rating the page doesn’t display, or a price that isn’t shown, and you are not optimizing — you are creating a mismatch that makes the page ineligible.

The build, type by type

Each example below is the JSON payload that goes inside the <script type="application/ld+json"> block shown above. I’ve kept each one to its required and most useful properties so the contract is visible.

Article and BlogPosting

Article markup is the workhorse for editorial content. The eligible types are Article, NewsArticle, and BlogPosting — pick whichever best describes the page; BlogPosting is the natural fit for a blog.

Here is the detail most guides get wrong: Google’s Article documentation states there are no required properties — “There are no required properties; instead, add the properties that apply to your content.” What it does list are recommended properties, and in practice you should treat them as mandatory because they’re what feed the result: author, datePublished, dateModified, headline, and image.

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How to Create Rich Snippets with JSON-LD",
  "image": "https://example.com/images/rich-snippets.jpg",
  "datePublished": "2026-07-27T08:00:00+00:00",
  "dateModified": "2026-07-27T08:00:00+00:00",
  "author": {
    "@type": "Person",
    "name": "Jane Doe",
    "url": "https://example.com/about/"
  }
}

Two author rules are easy to miss. Google specifies that in author.name you should “only specify the name of the author. Don’t add any other piece of information” — no title, no “By”, no credentials in that field. And author.url should point to a page that uniquely identifies the author — an About page, bio, or profile — which gives Google a disambiguation signal. The headline should match the page’s H1, and dateModified should move forward every time you meaningfully revise the content, because that is the freshness signal Search reads.

Breadcrumb markup tells Search where a page sits in your site hierarchy, and it renders as the path shown above the title in results. It is one of the most reliable rich results to earn because the contract is small and unambiguous.

Each entry in the trail is a ListItem, and Google requires three properties per item: position (1 begins the trail), name (the visible label), and item (the URL). There is one deliberate exception — “If the breadcrumb is the last item in the breadcrumb trail, item is not required. If item isn’t included for the last item, Google uses the URL of the containing page.”

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Guides",
      "item": "https://example.com/guides/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Rich snippets"
    }
  ]
}

Note the last item deliberately omits item — that’s the exception in action, not an error. The positions must be sequential and the labels should match the breadcrumb trail you actually render on the page.

Product

Product markup drives the price, availability, and star ratings that appear under shopping-related results. Google splits product markup into two experiences: product snippets, for pages where people can’t directly purchase, and merchant listings, for pages where customers can buy from you (which carry more detailed fields for shipping, returns, and sizing). For a review or comparison page, the product snippet is what you want.

The contract: Product.name is required, and you must include “either review or aggregateRating or offers” — at least one of the three. When you include an Offer, both price and priceCurrency (in three-letter ISO 4217 format) are required. When you include an AggregateRating, ratingValue plus at least one of ratingCount or reviewCount are required.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Trailmaster X4 Two-Person Tent",
  "image": "https://example.com/photos/trailmaster-x4.jpg",
  "offers": {
    "@type": "Offer",
    "price": 119.99,
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": 4.4,
    "reviewCount": 89
  }
}

The visibility rule bites hardest here. If your aggregateRating says 4.4 from 89 reviews, that rating and count must be visible on the page. Marking up ratings the page doesn’t show is a direct violation of Google’s guidelines and a fast way to get the snippet suppressed.

Review snippet

Review markup produces the star rating shown in results. It attaches to a range of types — including Book, Course, Event, Local Business, Movie, Product, Recipe, and Software App — either as a nested review on one of those, or as a standalone Review with an itemReviewed.

A single Review requires two things: an author, and a reviewRating whose ratingValue carries the numeric score. An AggregateRating requires ratingValue and at least one of ratingCount or reviewCount.

{
  "@type": "Review",
  "reviewRating": {
    "@type": "Rating",
    "ratingValue": 5
  },
  "author": {
    "@type": "Person",
    "name": "Alex Rivera"
  },
  "itemReviewed": {
    "@type": "Product",
    "name": "Trailmaster X4 Two-Person Tent"
  }
}

Two prohibitions matter and are enforced. Google states “Don’t aggregate reviews or ratings from other websites” — the ratings must be yours, collected on your own property. And self-serving reviews are out: if the entity being reviewed controls the reviews about itself, its pages using LocalBusiness or Organization markup are “ineligible for the star review feature.” You cannot star-rate your own business.

FAQ and HowTo — the deprecations you need to know

This section exists so you don’t write markup that is already dead.

HowTo produced step-by-step rich results and was heavily used by instructional content. Google removed it in September 2023, with the changelog stating the documentation was removed “as this rich result is no longer shown in search results, on both desktop and mobile devices.” The HowTo vocabulary still exists at schema.org, but it earns no rich result in Google Search.

FAQ had a longer decline. In 2023 Google restricted the FAQ rich result to “well-known, authoritative government and health websites” — cutting off nearly everyone. Then it deprecated the feature entirely: a deprecation notice went up in May 2026, stating “This feature will no longer appear in Google Search starting May 7, 2026,” and the documentation was removed the following month.

The nuance worth keeping: FAQPage schema still has value for other consumers — AI assistants and non-Google engines parse question-answer markup for their own extraction, which is a distinct discipline covered in structured data for AI search. But as a Google rich snippet play, FAQ and HowTo are both finished. Don’t build them expecting a rich result.

Validate before you ship

Never deploy structured data unverified. Two tools cover the two failure modes.

The Rich Results Test is Google’s own tool — in its words, “an easy and useful tool for validating your structured data, and in some cases, previewing a feature in Google Search.” It answers the question that matters: does this page qualify for a rich result, and what would it look like? Run every block through it before it goes live, and run it again after any template change that touches the markup.

The Schema Markup Validator at validator.schema.org is Schema.org’s official tool for checking that your markup is valid schema.org vocabulary. Use it when you need to confirm the syntax and property names are correct independent of Google’s rich result rules — it catches typos and invalid types that the Rich Results Test may pass over if they don’t affect eligibility.

After deployment, monitor the rich result status reports in Search Console: they surface errors and warnings at the page level across your whole site, which is where you catch a template change that silently broke the markup on a thousand pages at once.

Common mistakes that stop rich snippets from showing

Almost every “my markup is valid but nothing shows” case I see is one of these.

  • The type is deprecated. You wrote FAQ or HowTo markup. It validates. It will never render. Check the supported-features gallery before building.

  • A required property is missing. A Product with no name, an Offer with a price but no priceCurrency, an AggregateRating with no rating count — each one makes the block ineligible with no obvious error in a browser.

  • The markup contradicts the visible page. A rating in the schema that isn’t shown on the page, a headline that doesn’t match the H1, a price the page doesn’t display. Google explicitly disallows marking up information not visible to the user.

  • Aggregated or self-serving reviews. Star ratings pulled from other sites, or a business rating itself, are both ineligible.

  • Treating eligibility as a guarantee. Correct, validated markup makes a page eligible. Google still decides at query time whether to show the rich result. Valid markup that never renders isn’t necessarily broken — Google may simply be choosing not to display it for that query.

Where this fits

Rich snippets are one surface of the broader structured-data layer. The build is mechanical once you know the contracts; the harder work is deciding which types are worth maintaining, keeping the markup consistent with the page as content changes, and validating after every template revision. That discipline sits inside a wider technical foundation — the same JSON-LD that earns a Google rich result is also read by AI engines for answer engine optimization, though the two use it for different purposes and reward different types.

If you’d rather have the structured-data layer designed, implemented, and monitored end-to-end than reconcile required-property contracts by hand, that’s part of what I do: GEO and technical SEO consulting covers schema, rich results, and the crawl-and-indexing interactions as one scope. And if you want to see how a specific page scores on the machine-readable signals AI engines use, the AEO Article Analyzer grades any article in under 30 seconds.

FAQ

What is the difference between a rich snippet and a rich result?

They refer to the same thing, and the terminology shifted. “Rich snippet” is the older, informal name for a search result enhanced with extra visual detail — stars, prices, breadcrumbs — pulled from structured data. Google’s current documentation uses “rich result” as the umbrella term for all of these enhanced appearances. If you’re searching for “rich snippets,” you’re looking for what Google now calls rich results; the implementation is identical.

Which structured data format should I use for rich snippets?

JSON-LD. Google recommends it over Microdata and RDFa because it’s the easiest to implement and maintain at scale and the least error-prone. It lives in a single <script type="application/ld+json"> block, usually in the page <head>, kept separate from your HTML — which makes it simpler to generate programmatically and to review.

Do rich snippets work for FAQ and HowTo content in 2026?

No. Google removed the HowTo rich result in September 2023 on both desktop and mobile, and the FAQ rich result stopped appearing on May 7, 2026. Writing FAQPage or HowTo markup will still validate, but it produces no rich result in Google Search. FAQ markup retains value for AI assistants and other engines, but not as a Google rich snippet.

What are the required properties for a Product rich snippet?

A product snippet requires a name and at least one of review, aggregateRating, or offers. If you include an Offer, both price and priceCurrency (three-letter ISO 4217) are required. If you include an AggregateRating, you need ratingValue plus at least one of ratingCount or reviewCount. Every value you mark up must also be visible on the page.

Why does my structured data validate but no rich snippet appears?

Valid markup makes a page eligible; it does not force Google to display a rich result. Common causes are a deprecated type (FAQ, HowTo), a missing required property, markup that contradicts the visible content, or reviews that are aggregated from other sites or self-serving. Even with everything correct, Google decides at query time whether to render the result — eligibility is the ceiling, not a guarantee.

How do I test rich snippets before publishing?

Run the block through Google’s Rich Results Test, which confirms rich result eligibility and can preview the appearance, and through the Schema Markup Validator for pure schema.org vocabulary correctness. After going live, monitor the rich result status reports in Search Console to catch template changes that break the markup site-wide.

Where this fits

Service GEO & Technical SEO Architecture Audit Read → More like this All Technical SEO articles Read → Talk to me Book a 30-min discovery call Read →