For a few years, FAQ schema markup was the cheapest SERP win available. Add a handful of questions to a page, wrap them in FAQPage markup, and your listing expanded into a stack of collapsible answers that pushed competitors down the screen. Agencies built entire content templates around it.
That stopped in August 2023. Google announced it was sharply reducing FAQ rich results, limiting them to what it described as well-known, authoritative government and health websites. Everyone else lost the display. The markup still validates, the schema still parses, and the SERP treatment is gone. Any guide that does not say this up front is selling you 2021 advice.
What Google actually changed
The change was a display decision, not a deprecation of the vocabulary. FAQPage remains a valid schema.org type and Google still documents it. What changed is who qualifies for the visual treatment.
Google’s stated rationale was that FAQ rich results had become cluttered and less useful — largely because SEOs added FAQ sections to pages that did not need them, purely to win vertical space. The same announcement reduced HowTo rich results, which were later removed from desktop and then retired as a search feature entirely.
The practical result: if you run a commercial blog, an ecommerce store, a SaaS site, or a local business, adding FAQ markup today will pass every validator and produce no visible change in search. That is not a bug in your implementation. It is the current behavior.
Who still gets FAQ rich results
Google’s language was “well-known, authoritative government and health websites.” In observed results that means national health services, government agencies, major medical institutions, and comparable public-sector bodies.
There is no application process and no property you can add to qualify. Eligibility is a judgment Google makes about the site as a whole, and it is not something a small or mid-sized commercial site can engineer. If you are reading this to figure out how to get back into the feature, the honest answer is that you probably cannot.
Should you implement it anyway
There is a reasonable case for shipping it, and a better case for not bothering. Both are worth understanding.
The case for: FAQPage markup describes your content accurately for machines. Question-and-answer pairs in structured form are legible to any system parsing your page, including AI assistants and answer engines that consume structured data. It costs almost nothing on a template you already maintain, and if Google ever loosens the restriction, you are already there.
The case against: it adds page weight and a maintenance surface for a feature you cannot access. Worse, it encourages a bad content habit — bolting a generic FAQ section onto pages that do not need one because the markup requires visible questions. Those sections are usually thin, repetitive, and written for a SERP feature rather than a reader.
The sensible middle: if your page genuinely has an FAQ section that helps visitors, mark it up. If you are adding the FAQ section in order to add the markup, stop.
One more consideration decides it for a lot of teams. If you are working through a backlog of technical fixes with limited developer time, FAQ markup should be near the bottom of the list. A supported type on a template that reaches thousands of pages returns more than a deprecated feature on a handful of posts, and the opportunity cost is the real argument here, not the markup itself.
The rule that has not relaxed
Reduced display did not reduce the compliance requirements. FAQ markup must correspond to questions and answers that are visible on the page. Marking up questions that exist only in the JSON-LD is a structured data spam violation.
Google’s guidance is specific for this type. The content must be genuine FAQ content — a question with a single answer, not a form of user-generated Q&A with multiple competing answers, which belongs under QAPage instead. Do not use FAQPage for advertising, and do not mark up questions unrelated to the page. The penalty for structured data spam is loss of rich result eligibility across the entire site, not just on the offending URL, which is a real cost for markup that was never going to display anything.
How to write it correctly if you do ship it
The structure is simple. One FAQPage per page, containing Question entries, each with a single acceptedAnswer:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "How long does shipping take?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Standard orders ship within two business days and arrive in three to five days."
}
},
{
"@type": "Question",
"name": "Do you ship internationally?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Yes, to 34 countries. International delivery takes seven to fourteen days."
}
}
]
}
</script>Place it in the <head> or <body> — Google reads JSON-LD from both, so choose whichever your templates make easier to maintain. The answer text may contain basic HTML such as links and lists, but keep it close to the visible wording. Use one FAQPage block per page; multiple blocks on one URL cause more confusion than they solve.
Better places to spend the same effort
If the goal behind FAQ markup was more SERP space, redirect the effort to types Google still displays:
- Product — price, availability, and rating in the listing. The most visible change available to an ecommerce site.
- BreadcrumbList — a readable hierarchy instead of a raw URL string. Cheap, sitewide, and it works on almost any structured site.
- Event — dates, venue, and ticket status, with access to the events search experience.
- VideoObject — thumbnails, duration, and key moments, increasingly relevant as video blends into standard results.
- Recipe and JobPosting — non-negotiable entry tickets for their respective search surfaces.
Review markup is supported too, with a hard restriction: you cannot publish review or rating markup about your own business or your own products on your own site. That rule catches a lot of well-meaning implementations.
Validating and monitoring
The Structured Data Testing Tool was retired, so ignore any tutorial that points there. Use Google’s Rich Results Test to check eligibility for supported features — for FAQ markup on a non-qualifying site it will typically parse the markup while offering no eligible enhancement, which is the expected outcome. Use the schema.org validator to confirm syntax against the full vocabulary. Then watch Search Console’s Enhancements reports, which show how Google treats your live pages at scale with per-feature error counts and example URLs.
Search Console reporting lags by days to weeks depending on crawl frequency. Use it to confirm outcomes over time, not to test a change you deployed an hour ago.
The wider lesson
FAQ markup is a case study in building strategy on a SERP feature rather than on the underlying page. Everyone who added FAQ sections purely for the display lost that value overnight and was left with thin content they now maintain for nothing. The sites that added FAQs because visitors actually asked those questions lost a snippet and kept a useful page.
Structured data is worth doing on the types Google supports, on pages that are technically healthy to begin with. SEO Rocket’s technical audits cover that foundation — quick scans of roughly 25 pages or deep full-site crawls verified past 900 pages, with the real titles, URLs, and H1 text attached to each issue, plus PageSpeed and Core Web Vitals from real-user field data. It will not generate schema for you. Whether FAQ markup belongs on a page is a judgment call, and after 2023, the honest default answer is usually no.
