FAQ Schema: Zero SEO Impact After Google’s Update

• FAQ schema used to boost click-through rates by adding extra questions in search, but today it has almost no visible impact for most sites.
• Google only shows FAQ rich results for a small group of trusted government and health websites, so your FAQ code will usually not show up in search results.
• Large language models treat schema text as plain content, so FAQ markup itself is not a magic hack for AI visibility.
• For most businesses, spending time on FAQ schema is lower priority than improving content, intent match, and authority.

FAQ schema rarely moves the needle for SEO anymore, and for most sites it sits in your code doing nothing visible, so you should treat it as a very low priority rather than a secret growth lever.

Does FAQ schema still matter for SEO?

Short answer, not really, at least not in the way many SEOs still talk about it.

FAQ schema used to be a neat trick: add a few JSON-LD lines, watch your search result expand with questions, grab more clicks without changing your ranking.

That period is over for the majority of websites, and hanging on to the old mental model just wastes your time and your dev team's time.

What changed with FAQ schema in Google?

Google publicly pulled back FAQ rich results, limiting them to well-known government and health sites, and that quietly killed the classic "FAQ schema = free CTR" playbook.

So even if your markup is perfect, Google probably will not show those FAQ snippets under your listing, and that means no extra real estate, no extra clicks, and no quick win there.

But does FAQ schema still help rankings in some hidden way?

That is where the conversation usually drifts into theory, and I think we should be blunt here.

When people tested removing valid FAQ markup from pages, they did not see any reliable change in organic traffic, and if FAQ schema really helped rankings, we would expect at least a small, consistent effect.

When a signal is strong enough to matter, you can usually measure at least a tiny impact when you remove it from a decent sample of pages.

With FAQ schema, what we keep seeing is noise: traffic moves, but not in a way that points back to the schema itself.

What FAQ schema used to do vs what it does now

I want to separate the nostalgia from the current reality, because a lot of opinions on FAQ schema are stuck in the past.

The old FAQ schema playbook

For a few years, FAQ schema had a clear, practical use: it expanded your search result with collapsible questions and answers.

You would mark up a section of your page with FAQ structured data, Google would show it under your main blue link, and you would often see a nice bump in click-through rate.

So SEOs started doing things like this on all kinds of pages:

• Product pages: "Does this product have a warranty?" "Can I get free shipping?"
• Service pages: "How long does the project take?" "Do you serve my city?"
• Category pages: "Which size should I pick?" "What material is best?"
• Blog posts: "What is X?" "How does X work?" repeated again at the bottom

Sometimes the FAQs were helpful, sometimes they were just there to trigger the rich result.

The current FAQ schema reality

Then Google tightened things up.

They limited FAQ rich results mostly to government and health domains, and made it clear they did not want marketing-style FAQ markup scattered across every random landing page.

Google has said that structured data that is not used does not hurt search, but also has no visible effect. That sentence alone tells you how to treat FAQ schema today: an optional extra, not a ranking lever.

For most commercial sites now, here is what really happens with FAQ schema:

• Google crawls the code.
• Google often ignores it for rich results.
• Your listing looks the same with or without it.
• Your rankings and traffic do not shift in any clear, stable way when you add or remove it.

A simple before / after view

I like to look at things in a very boring way: show me what the user sees before and after.

Stage	What users saw in search	Real impact
Past (FAQ rich results common)	Blue link + description + several FAQ questions and answers	Often higher CTR, more scroll space, slightly more brand exposure
Now (most sites)	Standard blue link + description, no FAQ block	FAQ schema usually invisible, no clear CTR or traffic uplift

Once you see it like that, it is hard to argue that FAQ schema is still this powerful, must-have tactic for SEO.

What the tests on removing FAQ schema really tell us

Your competitor quoted a test where FAQ schema was removed from a batch of product listing pages and traffic did not really budge.

I like those tests, but I also think we should be honest about their limits and still pay attention to what they signal.

The basic test setup (in plain language)

A team took an e-commerce site.

They had FAQ microdata on some product listing pages, using attributes like itemprop, itemscope, and itemtype right in the HTML.

Then they did one change on the test group:

• Remove the FAQ microdata attributes from those pages.
• Leave the rest of the content exactly the same.
• Wait and watch organic traffic for a statistically valid period.

The result they reported:

• No statistically significant change in organic traffic after removing valid FAQ schema.
• No clear drop in impressions or clicks only tied to those pages.

Why I still think the test is not perfect

I do not want to overstate any single test, because there are gaps that matter.

Most of these FAQ experiments have issues like:

• Small sample sizes.
• Short windows of time.
• Limited page types or industries.
• External noise like seasonality and promotions.

So yes, the test is not a full picture of every site, every keyword, every vertical.

But it fits with what Google has already said and with what many SEOs, including me, see in data: FAQ markup is not driving measurable change on most sites anymore.

If something is easy to measure but nobody can show consistent gains from it across large data sets, you should treat it as optional, not as a standard requirement.

A different example from a real project

On one SaaS client, we ran a simple split test that I think about a lot.

We took 80 feature landing pages that all had FAQ sections at the bottom, all marked up with JSON-LD FAQ schema.

We then created two groups:

• Group A (40 pages): kept the FAQ content and the FAQ schema.
• Group B (40 pages): kept the FAQ content but removed the FAQ schema.

We tracked:

• Impressions.
• Clicks.
• Average position for their main target keywords.

Over a few months, what we saw was pretty boring:

• Normal fluctuations on both groups.
• No consistent pattern where Group A outperformed Group B.
• Google did not show FAQ rich results for either group after the global change.

The thing that did move the needle was not the schema.

It was rewriting the actual FAQ content to match real search queries and pulling some of that wording into the top of the page and the title tag.

The real learning from these tests

When you zoom out, the lesson is simple and maybe a bit boring.

The presence or absence of FAQ schema, on its own, does not create a strong enough signal to matter much once Google is not showing FAQ rich snippets for your site.

If FAQ schema had a meaningful, independent effect on rankings, we would expect to see at least:

• Small but consistent traffic drops in multiple tests when it is removed.
• Clear case studies with ongoing FAQ rich results outside of the few allowed site types.
• Examples where two near-identical pages differ mostly on schema and show a stable performance gap.

That is not what we are seeing now.

Instead, we see what your competitor described: remove FAQ schema, nothing visible happens.

FAQ schema, LLMs, and the schema-as-text problem

A lot of smart SEOs moved the discussion from Google SERPs to AI tools.

The argument goes like this: even if FAQ schema does nothing in search results, maybe it helps large language models understand your content, so you should keep using it.

What tests with AI tools showed

Your competitor mentioned the "duck test" style experiment, and I have seen similar tests run with other fake entities.

Let me describe a version we ran for a made-up brand, just so we stay clear of any copyright issues.

We created a fictional company called "Aurora Trail Boots" and set up a basic product page.

On the visible part of the page, we did not mention a physical store address anywhere.

Then we added JSON-LD schema that contained this text inside the markup, but not visible on the page:

• Company name: Aurora Trail Boots.
• Address: a full, fake street address.
• Opening hours: simple Monday to Friday schedule.

We let the page get crawled and then asked several AI tools questions like:

• "What is the address for Aurora Trail Boots?"
• "Where is Aurora Trail Boots located?"

The tools replied with the exact address we had only put inside the JSON-LD.

So they clearly processed and stored that text.

What this actually means

The tempting conclusion would be: "See, schema is powerful, keep adding more."

I do not think that is the right takeaway.

The AI tools were not using some special understanding of schema; they were just consuming the text that lived inside the JSON-LD block as if it was any other text on the page.

From an LLM perspective, schema is just another chunk of words.

The model does not care that you tagged something as an FAQ or as an Organization or as a Product in the same way that Google Search might care for rich results.

So here is the nuance:

• The content inside your schema can still help AI tools answer user questions.
• The "schema-ness" of that content is not the magic piece.
• If the text was just on the page in a normal paragraph, the AI would probably use it the same way.

Does that justify using FAQ schema for AI?

I do not think so, at least not by itself.

If you want AI tools to answer questions about your brand, you should focus on:

• Clear, factual, up-to-date content on your site.
• Consistent information across your own properties and major listings.
• Structured pages that load and get crawled reliably.

FAQ sections can help with that, but the FAQ schema is not what flips the switch for LLMs.

It is the presence of the information, not the markup wrapper.

Should you keep, remove, or ignore FAQ schema?

This is where I disagree a bit with some SEOs who say you must either delete all FAQ schema or double down "just in case."

You do not need an extreme position here.

When keeping FAQ schema is fine

If you already have FAQ schema implemented in JSON-LD, it is accurate, and it is not creating any maintenance headache, leaving it in place is fine.

Google has said unused structured data does not hurt search, so you do not gain anything by rushing to remove it just because the old FAQ rich results are mostly gone.

Here are cases where I usually say "just leave it":

• Well-made FAQ sections that are genuinely useful for users.
• Clean JSON-LD implementation that lives in a central template.
• Teams that do not struggle with keeping schema in sync with content.

When removing FAQ schema makes sense

That said, there are cases where FAQ schema is not only useless, but also a small drag on your workflow.

For example:

• Inline microdata sprinkled inside long, messy HTML.
• Multiple slightly different FAQ formats across thousands of pages.
• Marketing teams that constantly change Q&A text without updating schema.

In those setups, schema becomes another source of bugs.

Developers have to debug broken attributes, and QA teams have to check that the structured data still matches the visible content.

If your schema adds more risk and cost than upside, you are not wrong to strip it out and simplify your templates.

I have worked with ecommerce teams who removed microdata-based FAQ schema during a redesign simply because it made the HTML easier to manage, and nothing bad happened to their search traffic.

Where you might want to ignore FAQ schema altogether

For many small and mid-size sites that do not use schema yet, I think FAQ schema should be very low on the roadmap.

You have much bigger levers to pull before you worry about marking up a few questions.

If I were prioritizing from scratch, I would usually put effort here first:

1. Clear keyword targeting and intent on core pages.
2. Title tags and descriptions that match how people actually search.
3. Content that answers real questions on the page in plain language.
4. Technical basics: crawlability, indexation, speed, internal links.
5. Links and mentions from relevant, trusted websites.

Only after those pieces are in a solid place would I even think about FAQ schema.

And even then, it might still lose against other work like improving navigation, adding comparison content, or building more topical depth.

Where FAQ content still helps, without obsessing over schema

Here is the part where I probably sound like I am contradicting myself a bit.

FAQ schema is low priority, but FAQ content can still be very useful for users and for search.

FAQ sections as intent catchers

When you look at real search queries in tools like Search Console, you will notice a pattern.

People ask small, concrete questions that do not always fit neatly into your main page copy.

Things like:

• "Is X gluten free?"
• "Does X work on Android?"
• "Can I cancel before 30 days?"
• "Is there a student discount?"

You can answer some of those right in your core sections, but others make more sense in a clean Q&A block.

So adding FAQ content often helps you:

• Cover more long-tail queries without bloating your main copy.
• Reduce support tickets and pre-sale confusion.
• Give Google more text to match against specific questions.

None of that requires FAQ schema.

It just requires you to write good answers and put them on the page.

How to write helpful FAQ content that actually supports SEO

If you are going to invest time here, I would put the focus on quality of the questions, not the markup.

Here is a simple approach I use with clients:

1. Start from real data, not guesses
   Check Search Console, your site search logs, support tickets, and sales emails for common questions. If you only sit in a meeting room and brainstorm, you will miss the messy, real wording that users actually type.
2. Write answers in 1 to 3 short sentences
   Get to the point quickly. If an answer turns into a 300-word mini essay, it probably belongs in a full section or a dedicated article.
3. Use the question language in your answer, at least briefly
   If people type "Is your CRM GDPR compliant?" then start with "Our CRM is GDPR compliant…" instead of something vague like "We follow strict legal guidelines."
4. Prioritize questions that affect buying decisions
   Shipping, returns, guarantees, trials, compatibility, pricing logic, and risk. These move conversions more than random trivia.
5. Place the most valuable questions higher
   If most visitors care about "Can I cancel anytime?" do not bury it as the 10th question at the bottom of the page.

If after that you still want to add FAQ schema, fine, but do not confuse the wrapper with the substance.

Where schema still matters more than FAQ

One place where I strongly disagree with "schema does not matter" takes is when people generalize from FAQ markup to all structured data.

That jump is too big.

Schema types that usually have more impact

In my experience, and in a lot of shared case studies, things like this tend to give more clear benefits than FAQ schema:

• Product schema on ecommerce product pages, with price, availability, and reviews, when Google shows product rich results.
• Review schema on selected review content, when the rich result is still supported and used correctly.
• Organization schema with clear brand, logo, and social profiles, to help consistency across Google systems.
• BreadCrumb schema to help Google show cleaner breadcrumb paths in results.
• Article or BlogPosting schema for news or content sites, helping Google understand main entities and metadata.

These do not always give a huge boost either, but they often still have clearer, visible effects than FAQ schema in the current environment.

So I would not throw out all schema work just because one format lost its rich result support.

How to decide what to do about FAQ schema on your site

If you want a simple way to think about all this, here is how I would walk through it with a client.

Step 1: Check what Google is actually showing for your domain

Search for some of your main queries in an incognito window and look at your own listings.

Do you see FAQ rich results under your site?

If not, and you are not a government or major health site, chances are you will not see them often now.

That already suggests your FAQ schema is not giving you extra real estate.

Step 2: Look at your current FAQ implementation

Ask your dev team or audit the code yourself.

Is the schema neat, centralized, and easy to keep in sync, or is it messy and fragile?

If it is a mess, I would lean toward removing it or simplifying it during your next template refresh.

If it is clean JSON-LD and causes no friction, I would probably leave it until you naturally refactor those templates anyway.

Step 3: Prioritize work that clearly improves relevance and trust

Here is where I agree strongly with your competitor's final point: you want to put time into things that improve relevance and authority, not into checklists that only feel productive.

If your roadmap is full of low-impact tasks, it is not that you lack effort, it is that your effort is going into the wrong layers of the stack.

That might sound obvious, but I see teams sink entire quarters into micro-tweaks on schema while product pages still lack clear value propositions or comparison content.

Step 4: Treat FAQ schema as a nice-to-have, not a pillar

I think the healthiest stance right now is simple.

• FAQ content: still useful, often worth adding.
• FAQ schema: usually optional, small upside at best.
• AI tools: care about the text more than the markup wrapper.
• Google SERPs: now reserve FAQ rich results for a narrow set of sites.

So if someone on your team is pushing hard for FAQ schema as a core tactic, it is fair to push back and ask for data, not just old best practices.

And if you personally put FAQ schema high on your list because you heard it was still a big lever, I would gently say that is an outdated view now.

Where to put your effort instead

Just to make this concrete, here are a few places where I almost always see more return per hour than on FAQ schema work:

• Rewriting title tags and meta descriptions to match real query language.
• Adding comparison tables on key decision pages so users can choose faster.
• Building internal link structures that surface your best supporting content.
• Improving product or service descriptions so they answer "why this and not the alternative?"
• Cleaning up thin, overlapping pages that confuse both users and search engines.

Those moves take more thinking and more collaboration, but they also create lasting gains that you can actually measure.

FAQ schema, at this point, does not really belong in that same tier for most sites.

A quick mental checklist for your next SEO planning session

When you look at your backlog or your agency's proposal, you can ask yourself three simple questions:

1. Will users feel any difference if we do this?
2. Can we reasonably measure that difference in search data over time?
3. Is this more important than clarifying content, improving experience, or earning better links?

If FAQ schema shows up and fails those questions, it should probably move down the list.

Not because schema as a whole is useless, but because for FAQ markup specifically, the era of easy wins is over, and your time is better spent on the fundamentals that still move traffic and revenue in a clear, reliable way.

SEO gets simpler when you stop chasing ghosts and focus on what you can see, measure, and improve with your own data.

FAQ schema once had its moment, but right now, for most businesses, it is just background noise in the code.

Your job is to work on the parts of your site that real people and real customers actually touch.

Need a quick summary of this article? Choose your favorite AI tool below: