Blog
Schema markup in 2026
Google's supported rich result types no longer include FAQ or HowTo. What that changes, what structured data is still worth implementing, and the mistakes that cause real harm.
Short answer
Which schema types still earn rich results in Google?
Google's structured data gallery currently lists 25 supported features, including Article, Breadcrumb, Local business, Organization, Product, Review snippet, Event, Job posting, Video, Software app, Q&A, Discussion forum, Profile page, Recipe, Dataset and Speakable. FAQ and HowTo no longer appear on that list. Markup for an unsupported type is not a penalty and is still read by other consumers, but it will not produce a rich result, and it should not be sold as if it will.
Updated
What Google currently supports
The authoritative list is Google's own structured data gallery, and it is worth checking rather than trusting any article, including this one, because the list changes. At the time of writing it holds 25 features: 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 notable absences from that list are FAQ and HowTo, both of which were widely implemented and widely recommended. Their removal is the main thing that has changed for most sites, and a great deal of published advice has not caught up.
What to do about FAQ markup you have already implemented
Nothing urgent. FAQPage markup that accurately describes questions and answers genuinely present on the page remains valid schema.org, carries no penalty, and is still parsed by consumers other than Google Search — including systems that assemble answers from page content. What it will not do is place an expanded FAQ block under your result.
The decision worth making is about expectations rather than code. If FAQ markup was implemented to win result real estate, that reason is gone and the effort should move elsewhere. If it was implemented because the page genuinely answers common questions and the markup describes that accurately, keeping it costs nothing and may still help machines parse the page. What is no longer defensible is quoting rich results as the deliverable.
The same reasoning applies to HowTo. And it applies in reverse to a bad habit that outlived its usefulness: pages that invented question-and-answer sections purely to carry FAQ markup. Those sections were often padding, and with the rich result gone there is no argument left for keeping them.
What is still worth implementing, in order
Organization and the site-level entity markup, because it is how a brand is identified across Google's systems and it is cheap to get right. Breadcrumb, because it changes how the URL displays in results and reinforces site structure. Local business, where there is a genuine physical location — this is the one with the most direct commercial consequence for a local business.
Then the type that matches what the page actually is: Product for products, Article for articles, Event for events, Job posting for vacancies, Video for video, Software app for applications. The principle is not which markup earns the most but which markup is true. Structured data describes a page; it does not upgrade it.
| Markup | Worth doing? | Why |
|---|---|---|
| Organization | Yes, first | Entity identification across Google surfaces; low effort |
| Breadcrumb | Yes | Changes result display; reinforces structure |
| Local business | Yes, if a real location exists | Direct local search consequence |
| Article | Yes, for editorial content | Supported; carries author and date signals |
| Product / Event / Job posting | Yes, where accurate | Supported and commercially meaningful |
| Review snippet | Only for genuine third-party reviews of the item | Self-serving review markup risks a manual action |
| FAQ / HowTo | No longer for rich results | Not on Google's supported list; keep only where accurate |
The mistakes that cause actual harm
Self-serving review markup is the serious one. Marking up your own aggregate rating for your own business or services, rather than genuine reviews of a specific item collected independently, is against Google's guidelines and is a documented cause of manual actions. The temptation is obvious, since stars in results raise click-through, and it is the single most common way a site earns a structured data penalty.
Marking up content that is not on the page is the second. Structured data must describe what a user sees. Prices, ratings, availability, dates and questions that exist only in the JSON-LD are a guidelines violation, and this most often happens accidentally — a template emits markup from a database field that the page no longer renders.
The quieter failure is markup that validates but is wrong: the same Organization node repeated with different identifiers on every page, Article markup on a category listing, Product markup on a page that is not a product, dates that do not correspond to any real change. These rarely produce a penalty and reliably produce nothing at all, which is why they persist for years.
Does structured data help with AI answers?
It is plausible and it is not established. Structured data makes a page easier for a machine to parse, which is a reasonable thing to want when the machines reading your page include language models. No platform publishes how much weight, if any, it carries in citation selection, and confident claims in either direction are not supported by anything public.
What is established is more basic and more important: assistant crawlers largely fetch HTML and do not execute JavaScript. Structured data injected client-side is invisible to them, and so is the rest of a client-rendered page. Server-rendering the content and the markup is the part that demonstrably matters; the markup's contribution on top of that is speculative.
How to check it is actually working
Validate with Google's Rich Results Test for eligibility and with the Schema Markup Validator for schema.org correctness — they answer different questions and a page can pass one and fail the other. Then check Search Console's enhancement reports over the following weeks, because that is where real eligibility and errors across the whole site appear rather than a single URL.
View the rendered HTML rather than relying on the validator's fetch, to confirm the markup is in the server response and not injected afterwards. And re-check after template changes: structured data breaks silently during redesigns more often than it breaks on the day it is written.