On 7 May 2026, Google quietly added a deprecation notice to its FAQ structured data documentation. Within a day my feeds were full of two opposite takes: schema is dead, and schema matters more than ever for AI search. Both are wrong, and if you act on either one you will waste time.
Here is what actually happened. Google removed the FAQ rich result, the expandable question and answer panel that used to sit under your listing. It did not remove FAQPage from the schema vocabulary. Those are two different things, and the difference decides what you should do this week.
This is a pattern, not a one-off. Google has been pruning its rich result portfolio for three years now, and most schema guides you will find online still recommend types that stopped producing any visible result years ago. I have written this guide from the current documentation rather than from habit, so you can see exactly what still earns you something, what quietly does nothing, and what to put on your site this month.
We will cover what schema markup actually is, what Google has removed and when, which types still work in 2026, the honest answer on whether schema helps you get cited by AI, how to write your first JSON-LD block, which types your specific kind of site needs, and how to validate it without breaking anything.
What is schema markup, exactly?
Schema markup is code you add to a page that tells search engines what your content means, not just what it says. Your page might contain the text “4.8 stars” and “$49”. A human knows that is a rating and a price. A machine sees two strings. Structured data removes the guesswork by labelling them explicitly.
Three terms get used interchangeably and they should not be. Schema.org is the vocabulary, a shared dictionary of types and properties maintained collaboratively by Google, Microsoft, Yahoo and Yandex. You can browse the entire vocabulary at schema.org. Structured data is the markup you actually write on your page using that vocabulary. Rich results are what Google may choose to display because of it: star ratings, prices, breadcrumb trails, video thumbnails.
That last distinction is the one that saves you from awkward client conversations. You control your markup completely. You do not control whether Google shows a rich result. Correct markup earns you eligibility, and Google decides the rest based on content quality, page relevance and whether it thinks a rich result serves the user for that query. I never promise a client rich results. I promise correct, valid markup that makes them eligible.
There are three formats you can write structured data in: JSON-LD, Microdata and RDFa. In practice, use JSON-LD. It is the format Google recommends, it sits in a single script block instead of being tangled through your HTML, and it is far easier to maintain. I have not written Microdata for a client in years and I would not start now.
How do search engines actually use it?
When a crawler fetches your page, it reads your visible content and tries to work out what the page is about using language processing. That works reasonably well and it is getting better, but it is still interpretation. Structured data short-circuits the interpretation by handing over the facts directly, in a format with no ambiguity in it.
Think about a page for a training course. The visible text might mention a name, a date, a price and an instructor, scattered across paragraphs and a sidebar. A search engine has to infer which number is the price and which date is the start date rather than the publication date. With structured data you simply state it. That is the whole mechanism, and it explains why schema helps most on pages with lots of specific facts, and helps least on a general essay where there is not much to label.
Why should you still bother with schema in 2026?
Fair question after reading that deprecation list. If Google keeps removing features, why invest in the ones that are left? I have three reasons, and none of them is a promise about rankings.
It is one of the few things you fully control
Most of SEO is influence rather than control. You cannot decide your rankings, you cannot force a backlink, you cannot make Google show a rich result. But you can decide, today, exactly what your markup says. It is deterministic work with a clear finish line, and in a discipline full of waiting and guessing, that is genuinely valuable. You implement it, you validate it, it is done, and it keeps working without further attention.
It builds your entity, not just your listing
Rich results are the visible payoff, but they are not the only one. Organization markup tells Google who publishes this site, what the brand is called, where it lives and which profiles belong to it. That feeds the entity understanding behind knowledge panels and brand recognition. It is slow, unglamorous groundwork, and it is the kind of thing that makes every later signal land more cleanly because the search engine is confident about who you are.
The cost is small and it does not decay
A proper schema implementation on a normal content site is a few hours of work, once. Compare that to the ongoing cost of content production or link building. Once it ships correctly it keeps running with almost no maintenance, other than keeping values in step with the page. Very little else in SEO has that shape. Even after the deprecations, the remaining types cover the things most businesses actually publish, so the ratio of effort to return stays good.
A realistic expectation Think of schema as removing friction rather than adding force. It will not push a weak page up the rankings. It makes a page that already deserves to rank easier to display well and harder to misread. That is worth a few hours. It is not worth a six-month project.
What did Google actually remove, and when?
This is the section most guides get wrong, because they were written once and never updated. Here is the real sequence.
In August 2023, Google restricted FAQ rich results to well-known, authoritative government and health sites. Everyone else lost them at that point, which is why the May 2026 change had close to zero real-world impact for most commercial sites. They had already been gone for nearly three years.
In September 2023, HowTo rich results were deprecated on desktop, after earlier limits on mobile. They no longer appear on any surface, and the HowTo documentation has been removed from Google Search Central entirely. This one is settled, not pending, yet I still see 2026-dated blog posts recommending HowTo markup for rich results.
On 12 June 2025, Google retired seven structured data types in a single pass: Book Actions, Course Info, Claim Review, Estimated Salary, Learning Video, Special Announcement and Vehicle Listing. Google’s stated reason was that these were not commonly used in Search and no longer added enough value for users. There is one reversal worth knowing: in November 2025 Google removed the deprecation notice from Book Actions, because a Search feature still uses that markup.
Then on 7 May 2026, FAQ rich results stopped appearing in Google Search, ending even the narrow government and health eligibility. Two dates follow from that. In June 2026 the FAQ search appearance filter, the Search Console rich result report and Rich Results Test support are removed. In August 2026 the FAQ field disappears from the Search Console API, so any dashboard or export pulling that field will return nothing after that point. If your team runs automated reporting, that is a real calendar item.
What this does not mean FAQPage is still a valid schema type. Google has said unused structured data does not cause problems for Search, and its own documentation notes the markup can stay in place. You do not need an emergency project to strip FAQ schema off your site. You just need to stop expecting a SERP feature from it.
Which schema types still earn rich results in 2026?
Here is the practical split. The left side is where your effort pays off with something visible. The right side is markup that remains valid and parseable but produces no rich result.
The types that continue to produce rich results cover most of what a normal business actually publishes. Article and NewsArticle for content. Product and merchant listings for ecommerce. Review snippets for ratings. BreadcrumbList for the navigation path that replaces the raw URL in your listing. Video, Event, Recipe, LocalBusiness, Organization and JobPosting for their respective use cases.
Of these, BreadcrumbList is the one I would implement first on almost any site. It is trivial to add, it rarely breaks, and it replaces an ugly URL string in your search listing with a readable path. It also reinforces the site structure signals I wrote about in my technical SEO checklist, so it does double duty.
Article schema is the other one I would not skip on a content site. It carries your author, your publish and modified dates, your headline and your image. Those are exactly the fields that support author and freshness signals, which is where structured data meets the credibility work I cover in my guide to building E-E-A-T into your content. Marking up a real named author with a Person type, linked to their genuine profiles, is a small technical act that supports a much larger trust story.
Start with BreadcrumbList
If you implement exactly one type this week, make it this one. BreadcrumbList replaces the raw URL in your search listing with a readable path, so instead of a long string of slashes a searcher sees your site’s structure laid out in words. It is quick to add, it applies site-wide, and it almost never breaks because the data it describes rarely changes. It also makes your architecture explicit to crawlers, which reinforces the internal linking work that sits at the heart of any technical foundation.
Then Article, if you publish content
Article schema is where your author, headline, image and dates live. Those fields matter beyond the rich result, because they are how you state plainly who wrote this and when it was last updated. Freshness and authorship are both things search engines care about, and leaving them to be inferred from a byline in your theme is a missed opportunity. Mark the author up as a Person with a real name and a URL that resolves to a genuine profile page.
Product, if you sell anything
For ecommerce this is the highest value markup available, full stop. Price, availability and rating appearing directly in the listing changes how a result looks against competitors who have not bothered. The catch is that Product markup has strict requirements and it goes stale fast, because prices and stock change. Generate it dynamically from the same data that renders the page, never by hand, or you will end up advertising a price you no longer charge.
| Schema type | What it does for you | Status in 2026 |
|---|---|---|
| Article | Carries headline, author, image and dates. The backbone of any content site. | Active |
| BreadcrumbList | Shows a readable navigation path instead of a raw URL in your listing. | Active |
| Product and merchant listing | Price, availability and rating in the listing. The highest value type for ecommerce. | Active |
| Review snippet | Star ratings on eligible pages. | Active |
| Organization | Tells Google who publishes the site. Supports your knowledge panel and brand entity. | Active |
| LocalBusiness | Address, hours and contact details for physical locations. | Active |
| Video, Event, Recipe, JobPosting | Type-specific enhancements where the content genuinely fits. | Active |
| FAQPage | No rich result since May 2026. Still valid markup, still parsed. | No visual result |
| HowTo | No rich result since 2023. Documentation removed. | No visual result |
Does schema markup help you get cited by AI search?
This is where I want to be careful, because the honest answer is less exciting than what you will read elsewhere, and getting it wrong wastes your budget.
Google’s own guidance on its AI features says there is no special schema markup required for AI Overviews or AI Mode. It does say that any structured data you use should match the visible content on the page. So the direct claim, add FAQ schema and you will get cited by AI, is not supported by Google’s documentation. Anyone selling you that is guessing.
What is defensible is the indirect case. Structured data makes your content unambiguous to any machine that parses it. When your markup states plainly that this is an article, by this named author, published on this date, about this topic, you remove interpretation errors. Other engines and retrieval systems that crawl the open web can read that markup too, and clarity has never hurt. But that is a reasonable expectation, not a measured ranking mechanism, and I will not dress it up as one.
The practical takeaway is that schema is worth doing for its own reasons, and it sits alongside rather than inside your AI visibility work. The things that genuinely drive AI citations are covered in my guide to generative engine optimization, and the strategic difference between the two disciplines is the subject of my breakdown of SEO versus GEO. Schema supports both. It replaces neither.
How I put it to clients Do schema because it earns rich results, clarifies your entity, and costs a few hours. Do not do schema because someone promised it would get you into ChatGPT. Those are different projects with different evidence behind them.
How do you write your first JSON-LD block?
Every piece of structured data follows the same shape, so once you can read one, you can read all of them.
Here is a complete Article block for a blog post. Paste it into the page, inside a script tag, and change the values to match what is actually on the page.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Schema Markup Is Not Dead",
"image": "https://example.com/cover.png",
"author": {
"@type": "Person",
"name": "Admonq",
"url": "https://example.com/about/"
},
"publisher": {
"@type": "Organization",
"name": "Admonq",
"logo": {
"@type": "ImageObject",
"url": "https://example.com/logo.png"
}
},
"datePublished": "2026-07-23",
"dateModified": "2026-07-23"
}
</script>
Read it top to bottom. @context declares you are using the schema.org vocabulary, and it is the same line every time. @type says what the thing is. Everything after that is properties, the facts about it. Notice that author does not hold a plain string, it holds another typed object, a Person. That nesting is how schema expresses relationships, and it is why a Person with a name and a URL is far more useful than the text “by Admonq”.
You can place the script block anywhere in the page, head or body. Google reads it either way. If you want the full rules on formats and quality requirements, Google publishes them in its general structured data guidelines, which is the document I check whenever something is ambiguous.
The one rule that matters more than the rest
Every value in your markup must correspond to something a reader can actually see on the page. Google’s guidelines are explicit that you should not mark up content that is not visible to readers. If your JSON-LD describes an author, the page must show that author. If it claims a 4.8 rating, those reviews must be on the page.
This is not a technicality. Marking up invisible or invented content is the single fastest route to a structured data manual action, and it is exactly the abuse pattern that got FAQ rich results killed in the first place. Publishers bolted FAQ markup onto pages that were not really Q and A content, because the reward sat on that side of the choice. Google eventually removed the reward.
Which schema does your site actually need?
You do not need most of the vocabulary. You need the handful of types that describe what you publish. Marking up everything you can is a common beginner instinct and it creates maintenance debt for nothing.
If you run a blog or content site, implement Organization once at site level, Article on every post, BreadcrumbList across the site, and a Person type for each author. That combination covers you completely, and it is what I have on the Admonq blog.
If you run an ecommerce store, Product is your highest value type by a distance, with merchant listing fields for price and availability, review snippets where you have genuine reviews, and BreadcrumbList for category paths. Get Product right before you touch anything else.
If you are a local business, LocalBusiness carries your address, opening hours and contact details, and it pairs with Organization. If you host events, add Event. This is the schema work that most directly supports being found in local search.
If you are SaaS or B2B, Organization and Article do most of the work, with SoftwareApplication for product pages and JobPosting if you are hiring. Your content strategy should drive which article topics get built out, which is a planning question I cover in my guide to keyword research.
How do you add schema markup in WordPress?
Three routes, and the right one depends on how much control you need.
An SEO plugin. Yoast, Rank Math and similar plugins generate Organization, Article and BreadcrumbList schema automatically once you fill in your site details. For most content sites this is genuinely enough, and it is what I recommend to clients who do not have development support. The trade-off is limited control over edge cases.
A dedicated schema plugin. If you need types your SEO plugin does not handle well, a purpose-built schema plugin gives you granular control per post type. Useful for ecommerce and for sites with unusual content.
Manual JSON-LD. Paste the script block directly into the page, or into your theme template so it generates dynamically. This gives you complete control and no plugin overhead. It is what I do when a client needs something specific and correct.
Whichever route you take, check for duplicates. The most common WordPress schema bug I find is two plugins both outputting Organization markup, so the page ships conflicting blocks. Validate the rendered page, not your intentions.
How do you validate and monitor structured data?
Use two tools, because they answer different questions. Google’s Rich Results Test tells you whether your markup makes the page eligible for a rich result in Google specifically. The Schema Markup Validator at schema.org tells you whether your markup is valid schema, regardless of what Google chooses to display. A page can be perfectly valid schema and still show nothing in Google, which is exactly the FAQPage situation now.
After that, monitoring lives in Search Console. The enhancement reports flag errors and warnings on the types Google actively tracks, and that list has contracted a lot since 2022, so do not treat the section as a complete registry of what you have implemented. Check it monthly, alongside the crawl and index checks in your regular audit routine. If you want to speed this up across a large site, several of the platforms in my roundup of AI SEO tools will crawl and validate markup in bulk.
Read the enhancement reports for what they are
One nuance worth knowing, because it confuses people. The Enhancements section in Search Console only covers the subset of types Google has built dedicated reporting for. It is not a full registry of everything you have implemented, and that subset has shrunk considerably as features were retired. So if you implement a type and never see a matching report appear, that is not automatically a sign your markup is broken. Validate with the testing tools first, then use Search Console for ongoing error monitoring on the types it does track.
Schema markup mistakes I see constantly
Marking up invisible content. The cardinal sin, and the one Google explicitly warns against. If a reader cannot see it, do not mark it up.
Implementing retired types and expecting results. Adding HowTo markup in 2026 hoping for a rich result, because a guide from 2021 said to. Check the current documentation before you build anything.
Duplicate or conflicting blocks. Two plugins, or a plugin plus a manual block, both declaring Organization. Validate the rendered output.
Blocking the pages that carry your markup. Google’s guidelines are clear that you must not block structured data pages with robots.txt or noindex. If a crawler cannot reach the page, the markup on it is irrelevant. This is a crawlability problem wearing a schema costume, and it belongs in the wider audit process I set out in the technical SEO checklist.
Letting markup drift from content. You update a price or an author and the JSON-LD still says the old value. Change the schema in the same edit as the visible content, every time.
Treating schema as a ranking lever. Google has said repeatedly that structured data is not a ranking factor. It affects how your result can be displayed, not where it sits. If you implement schema expecting to move from position six to position three, you will be disappointed.
Schema markup FAQ
Should I remove FAQ schema from my pages now?
No, there is no urgency. Google has said unused structured data does not cause problems for Search, and its documentation notes the markup can stay. What you should do is stop adding it to new pages expecting a SERP feature, and update any reporting that pulls the FAQ field from the Search Console API before support ends in August 2026.
Is schema markup a ranking factor?
No. Google has been consistent on this. Structured data determines whether your listing is eligible for enhanced display, and rich results can lift click-through rate, which is a real commercial benefit. But the markup itself does not push you up the rankings.
JSON-LD, Microdata or RDFa?
JSON-LD. It is the format Google recommends, it lives in one self-contained block rather than being woven through your HTML, and it is far easier to maintain and validate. There is no practical reason to start a new implementation in Microdata.
How long until schema shows an effect?
Google has to recrawl the page before anything changes, so allow days to a few weeks depending on how often your site is crawled. If the markup validates but no rich result appears after several weeks, the likely answer is that the page is eligible but Google is choosing not to show one for those queries, which is entirely its call.
Do I need schema on every single page?
No. Put Organization at site level, BreadcrumbList across the site, and then the type that matches each page’s actual content. Pages that do not fit a type do not need one. Forcing markup onto pages just to have it is how you end up with mismatched content and a manual action.
Can schema markup get my site penalised?
Yes, if you misuse it. Marking up content that is not visible on the page, or describing things that are not really there, can trigger a structured data manual action, which removes your rich result eligibility until you fix it and request a review. Accurate markup that matches your page carries essentially no risk. The danger comes from trying to game it, not from implementing it.
Should I use a plugin or write it by hand?
Use a plugin if you run a standard content site and want Organization, Article and breadcrumbs handled without development work. Write it by hand when you need a type your plugin does not support properly, or when you want precise control over the output. Either way, validate the rendered page afterwards, because the most common problem is not bad code, it is two sources generating conflicting blocks.
Does schema markup slow my site down?
Not meaningfully. A JSON-LD block is a small amount of text with no rendering cost and no blocking behaviour, so it will not affect your Core Web Vitals. Heavy schema plugins can add overhead through their own scripts and database queries, so if performance matters to you, that is where to look, not at the markup itself.
Want your schema implemented properly?
At Admonq we audit structured data, strip out the retired markup that is doing nothing, and implement the types that actually earn results for your kind of site. If you would rather have it done right the first time, let us take a look. Get a structured data audit
Schema markup is in a quieter phase than it was five years ago. Google has cut away the features that were being gamed and kept the ones that describe real things accurately. That is a good outcome. The work now is smaller, more honest, and more durable: mark up what your page genuinely contains, keep it matched to what readers see, and let it do its job in the background while your content does the rest.