Which Schema Types Actually Still Produce Rich Results in 2026

Google's current structured data documentation lists rich results for articles, breadcrumbs, courses, datasets, discussion forums, events, FAQs, job postings, videos, local businesses, movies, organizations, products, profiles, Q&As, recipes, reviews, software apps, and several more. But "listed as supported" and "actually worth your time" aren't the same question. And one entry on that list, FAQ, is a genuinely special case: the markup remains valid, but the visible rich result itself was retired for every site, including the government and health sites previously exempted, as of May 7, 2026.

Which schema types does Google still support in 2026?

Per Google's own Search Central documentation (last updated June 15, 2026), implementing structured data can make a page eligible for these result types:

This list changes over time. Google has retired specific types before (HowTo on mobile in 2023, several lower-usage types since) when usage data showed a feature wasn't adding meaningful value. Treat any static list, including this one, as a snapshot rather than a permanent reference, and check Google's documentation directly before building a long-term content strategy around a specific type.

What happened to FAQ schema?

This is the one genuinely confusing entry on the list, so it deserves precision. Google restricted FAQ rich results in August 2023 to "well-known, authoritative government and health websites." Everyone else stopped seeing the feature regularly from that point on. Then, as of May 7, 2026, Google removed the FAQ rich result entirely, for every site, including the government and health sites that had kept it since 2023. Search Console's FAQ reporting and the Rich Results Test's FAQ support were removed in June 2026, with Search Console API support following in August 2026.

What did not change: FAQPage remains a valid Schema.org type. Google's own guidance is explicit that unused or non-triggering structured data "does not cause problems for Search." The markup won't throw an error, won't trigger a manual action, and won't hurt rankings if it's left on a page. What ended is the visible SERP dropdown, not the schema type itself.

Is FAQ schema still worth using?

For the SERP dropdown specifically, no. That feature is gone for everyone. But that's a narrower question than "should I keep FAQ content on my page," and the answer to that one hasn't changed: genuinely useful Q&A content still helps readers, and marked-up FAQ content still gives AI systems and other machine readers an unambiguous question-answer structure to parse, even without a Google-rendered dropdown to show for it. Remove FAQ markup only if maintaining it has become real overhead for no visible benefit, not out of a belief that it's now doing harm, since there's no evidence it is.

A brief history of other retired rich results

FAQ and HowTo aren't isolated incidents. Google has been trimming this list steadily, and knowing the pattern matters more than memorizing any single removal, since the next one will follow the same shape.

The sitelinks search box, a search bar Google could show directly under a site's result, was removed globally starting November 21, 2024. Google's own announcement on the Search Central blog was direct about why: "It's been over ten years since we initially announced the sitelinks search box in Google Search, and over time, we've noticed that usage has dropped. With that, and to help simplify the search results, we'll be removing this visual element." Google's guidance at the time was the same as for FAQ: there's no need to remove the underlying structured data, since unsupported markup doesn't cause errors or ranking problems, it just stops rendering.

A larger batch followed on June 12, 2025, when Google's search product manager, Henry Hsu, announced the retirement of seven structured data types at once: Book Actions, Course Info, Claim Review, Estimated Salary, Learning Video, Special Announcement, and Vehicle Listing. Search Console's reports and the Rich Results Test's support for those seven were removed that September. The stated reasoning, consistent with every removal in this history: usage had dropped low enough that the feature wasn't adding meaningful value relative to the cost of maintaining it. Worth flagging since it complicates a clean narrative: Google reversed part of that decision for Book Actions in November 2025, restoring its documentation and confirming the markup still powers an active Search feature, which is a useful reminder that "retired" announcements aren't always final, and it's worth checking current documentation rather than an old removal notice before assuming a type is fully gone.

The consistent pattern across all of these: a type gets removed when Google's own usage data shows it isn't earning its visual real estate, the underlying schema.org markup is never declared invalid, and removal is explicitly stated not to affect rankings, since these visual features were never ranking inputs to begin with. Building a content strategy around a niche rich-result type that could plausibly follow the same path (something powering a small, specific visual element rather than broad content structure) carries a real maintenance risk worth weighing against the payoff.

The schema types worth prioritizing

Not every site needs every type on the list above. For most content and business sites, five types cover the large majority of practical value: Organization (homepage identity, sitelinks, and Knowledge Panel eligibility), Article or BlogPosting (author, publish date, and headline for blog and news content), Product (price, availability, and review stars for anything sold directly), LocalBusiness (map and local-pack eligibility for a physical location), and BreadcrumbList (near-universal, low-effort, applies to almost any interior page). Everything else on the full list is genuinely valuable for the specific content type it targets (recipes, events, job postings) but isn't worth implementing on a site that doesn't actually have that content.

Implementing the three highest-value types, with real markup

Reading a property list is one thing; seeing what a correct block actually looks like is another. Three of the five types above cover most of what a typical guide, product page, or local-business page needs. All three examples below follow Google's own current documentation for required and recommended properties, and all three use JSON-LD in a <script type="application/ld+json"> tag, which is Google's stated preferred format over Microdata or RDFa.

Article (or BlogPosting). Google's own documentation is unusual here: there are no strictly required properties, only recommended ones, but skipping the recommended set means skipping the information Google actually uses to build the rich result. A minimal correct block for a guide like this one:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Which Schema Types Actually Still Produce Rich Results in 2026",
  "image": ["https://example.com/images/schema-guide-1x1.jpg"],
  "datePublished": "2026-09-01T08:00:00+04:00",
  "dateModified": "2026-09-14T09:00:00+04:00",
  "author": [{ "@type": "Person", "name": "Kuraib Ali", "url": "https://kuraibseo.site/about" }]
}

headline, image, datePublished, dateModified, and author (with a name and, ideally, a url pointing to a page that identifies that author) are the properties Google's documentation recommends including whenever they apply. Google's own guidance for image recommends supplying multiple aspect ratios (16x9, 4x3, and 1x1) as an array when possible, since different surfaces crop differently.

LocalBusiness. This one does have two genuinely required properties per Google's documentation: name and address. Everything else is recommended but optional:

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Example Consulting Dubai",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Business Bay",
    "addressLocality": "Dubai",
    "addressCountry": "AE"
  },
  "telephone": "+971-4-000-0000",
  "priceRange": "$$$",
  "url": "https://example.com/",
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Sunday"],
      "opens": "09:00",
      "closes": "18:00"
    }
  ]
}

priceRange has to stay under 100 characters per Google's documentation (a symbol string like $$$ or a range like $10-15 both qualify), and url needs to be a working link to the specific location's own page, not a generic homepage, when a business has more than one location.

Product. Google's documentation splits this type into two tracks: product snippets (for pages that describe a product without a direct purchase) and merchant listings (for pages where the product can actually be bought), with merchant listings requiring more detail (shipping and return information among it). A page that sells directly needs, at minimum, a price and availability tied to an Offer:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Example Product Name",
  "image": "https://example.com/images/product.jpg",
  "offers": {
    "@type": "Offer",
    "price": "149.00",
    "priceCurrency": "AED",
    "availability": "https://schema.org/InStock",
    "url": "https://example.com/products/example-product"
  }
}

Leaving out price or availability doesn't produce a partial rich result, it produces none, since Google's documentation is explicit that missing required merchant-listing properties disqualify the whole block rather than degrading gracefully.

Validating structured data with Google's Rich Results Test

Writing correct-looking JSON-LD isn't the same as confirming Google can actually parse it. Google's Rich Results Test (search.google.com/test/rich-results) is the official tool for that check, and it does two things a manual read-through of the code can't: it renders the page the way Googlebot does, JavaScript included, and it checks the result against the specific eligibility criteria for each rich-result type, not just against valid schema.org syntax.

It accepts either a live URL or a pasted code snippet. For a URL, the tool fetches and renders the page itself; for a snippet, it checks the markup in isolation without page context, which is faster for iterating on a template before it's live. The output lists every structured data type it detected, which rich results (if any) that markup is eligible for, and separates hard errors (which block eligibility entirely) from warnings (recommended properties that are missing but won't disqualify the page on their own).

Two limitations worth knowing before treating a clean test result as the final word. First, passing the test confirms eligibility, not appearance: Google's own documentation is explicit that correct markup "does not guarantee" a rich result will actually show up in search results, since Google selects which features to display per query, device, and overall search experience. Second, the test validates against Google's current supported list, which this guide's first section already established is a moving target, so a type the tool doesn't flag as eligible for a rich result might simply be one Google no longer supports, not one that's incorrectly marked up. Run the test after any template change that touches structured data, and again periodically on a spot-check basis, since Google's supported list and property requirements both change over time without necessarily breaking the markup itself.

What schema type should I use for my site?

• Every site: Organization on the homepage, BreadcrumbList on interior pages.
• Blog or news content: Article/BlogPosting on every post.
• Selling anything directly: Product, matched exactly to what's visible on the page. Missing required properties like price or availability means no rich result at all, not a partial one.
• Physical location: LocalBusiness.
• Genuine Q&A content: FAQPage is still fine to keep for machine clarity, just don't expect a SERP dropdown from it anymore.

Whatever's implemented, validate it against what's actually visible on the page first. Google's own guidance is direct on this point: structured data must be a true representation of the page content, and mismatched or fabricated markup risks a manual action independent of any of the changes covered above.

Related: structured data isn't a ranking factor, canonical tags and canonicalization.