LUCENTCOMMERCEGET A FREE STORE AUDITFREE AUDIT

AEO · GEO · SEO · CONTENT · 7 MAY 2026 · 6 MIN READ

Writing FAQs that answer engines will quote

Google stopped showing FAQ rich results, which removes the bad reason to write them and leaves the good one. A quotable answer is self-contained, specific and forty words long.

A search result and the page behind it

Write each answer so it can be lifted out of the page and still be true. That means one question per heading in the words a buyer would use, a first sentence that answers it completely without depending on the paragraph above, roughly 40 to 60 words of specifics, and a named source for anything that sounds like a fact. The structured data matters less than it used to — Google has stopped showing FAQ rich results and removed the documentation for them — so the payoff now is extraction by answer engines and by buyers skimming, both of which reward the same writing. Mark it up anyway, because the markup is cheap and Google Search is not the only thing reading your page.

IN SHORT

  • Google has removed its FAQ structured data documentation, stating the FAQ rich result is no longer shown in Search — so FAQ markup is no longer a route to a richer blue-link result.
  • The markup is still worth keeping: it costs nothing to emit and Search is not the only system parsing a page.
  • An answer is quotable when it survives being separated from its page — no "as mentioned above", no pronoun whose subject is in the previous section.
  • Forty to sixty words is the working length: long enough to be specific, short enough to be lifted whole.
  • Answer the question in the first sentence and qualify afterwards, not the other way round.
  • Google's own guidance on FAQ content was that it must be visible on the page and not duplicated across pages; both remain good practice regardless of the rich result.
  • The best source of questions is your support inbox and your sales calls, not a keyword tool — real questions carry the phrasing people actually use.

The rich result is gone, and that is clarifying

For a few years, FAQ schema had an obvious commercial motive: the expanding accordion under your search result, taking up space competitors could not have. That ended in stages. Google narrowed the feature to well-known authoritative government and health sites, then stopped showing it, then removed the documentation entirely, noting that the FAQ rich result is no longer shown in Search results.

This is good news for anyone who writes honestly. It removes the incentive that produced the worst FAQs on the internet — the ones with eleven questions nobody asked, written to fill a schema block, sitting at the bottom of a page in a collapsed accordion no human ever opened. The remaining reasons to write an FAQ are that a buyer has a question and that a machine summarising your page needs a clean answer to lift. Both reward the same thing.

Keep emitting the markup. It is a few lines, it costs nothing at runtime, and Google Search is not the only system parsing your pages. What should change is the writing, and what should stop is treating the number of FAQ blocks on a site as a metric.

What makes an answer quotable

Answer engines do not quote pages, they quote passages. The test for every answer you write is whether it still works when someone removes it from the page and shows it to a stranger. Most FAQ answers fail that test in the first four words.

  • Answer in sentence one, qualify in sentence two. "It depends on your catalogue size" is not an opening, it is a hedge. Open with the answer you would give if forced to pick, then explain when it is wrong.
  • No page-dependent references. "As above", "this approach", "the second option" — each one makes the passage useless the moment it is lifted. Name the thing again.
  • Forty to sixty words. Under thirty and the answer is usually a definition rather than an answer. Over eighty and it gets truncated, or summarised by something that has less context than you do.
  • One question per question. "How much does it cost and how long does it take?" has two answers and will be quoted badly. Split it.
  • Use the buyer's noun, not yours. If customers say "postage" and you say "delivery charges", the question should say postage. Internal vocabulary is the most common reason a good answer never matches a real query.
  • Attribute every number. "Shopify documents a limit of X" is quotable and checkable. "Up to 80% faster" is neither, and an unsourced figure is the fastest way to be excluded by a system that checks.
  • Be willing to say no. "No, you probably do not need this" is more likely to be quoted than a paragraph of balance, because it is a complete answer to the question asked.

Where the questions come from

The difference between an FAQ block that earns citations and one that fills space is almost entirely in question selection, and the good sources are unglamorous.

Start with the support inbox. Sort a quarter of tickets by subject and the top ten recurring questions are your FAQ, already phrased in customers' own words, already prioritised by volume. Then sales calls: the objection a salesperson answers every week is a question thousands of people are asking search engines instead. Then Search Console, filtered to queries containing "how", "can", "does" and "what" — those are the questions your pages already half-answer.

What should not generate questions is a keyword tool used in isolation, and what should definitely not generate them is a prompt asking for twenty FAQs about a topic. Both produce plausible questions that no individual person has ever asked, and a page of those is exactly what Google's helpful content guidance describes as content made for search engines rather than people.

One more source worth the effort: ask an answer engine about your category and read what it says about you. If the summary is wrong or thin, the gap it reveals is the FAQ you are missing — and the phrasing it uses is a reasonable guess at how the question is being asked.

Where the block lives on the page

An FAQ that appears only in structured data is invisible to buyers and, under the guidance Google published while the feature existed, was not eligible anyway: the content had to be visible on the page. Visible, and preferably not buried. On the pages where this matters most — a product page, a service page, a delivery page — the questions are often the last thing a buyer reads before deciding, which is an odd thing to put below the footer links.

The practical constraint is usually production rather than judgement. If adding an FAQ to a page means a developer ticket, the FAQs will be written once at launch and never updated, and an FAQ that has not changed in two years is answering last year's questions. Make the block a theme section that merchandisers can add, reorder and edit themselves, with the schema emitted from the same data that renders the accordion. One source, two outputs, no drift between what the page says and what the markup claims.

That is the mundane reason a section library pays for itself here. The content problem — questions go stale, phrasing changes, new objections appear — is solved by whoever talks to customers being able to edit the block, and that is a build decision made months earlier.

The honest version

We keep FAQ markup on every service page on this site, and we would not claim it is why anything ranks. It is there because the questions are real, because the answers are the part of the page people actually read, and because structured, self-contained answers are the format every summarising system handles best. That combination was worth doing when the rich result existed and is worth doing now that it does not.

The thing to stop doing is volume. Six questions somebody genuinely asks beat twenty generated to fill a block, and the twenty carry a real risk: one wrong answer, confidently phrased, is exactly the passage a machine will lift and repeat. Write fewer, source them, and reread them when the product changes.

Questions this raises

Is FAQ schema still worth adding?

Yes, but not for the reason it used to be. Google has removed its FAQ structured data documentation and states the FAQ rich result is no longer shown, so it will not win you a richer search result. It remains cheap to emit and useful to every other system that parses your pages, so keep it and stop counting it as an SEO tactic.

How long should an FAQ answer be?

Around forty to sixty words. That is long enough to include a specific and a caveat, and short enough to be quoted whole rather than summarised by something with less context than you have. If an answer needs three hundred words, it is a section of the page, not an FAQ.

How many questions should an FAQ block have?

As many as people genuinely ask, which is usually five or six per page. Padding a block to hit a number produces questions nobody asked and answers nobody checked, and an unchecked answer is the one most likely to be quoted back at you.

Can the same FAQ appear on several pages?

Better not to. Google's guidance while the feature existed was explicit that FAQs should not be duplicated across pages, and the practical argument outlives the rich result: a question repeated on six pages gives a summarising system no reason to prefer any of them, and gives you six copies to update when the answer changes.

Should the FAQ be in an accordion?

An accordion is fine if the content is in the HTML rather than loaded on click — the requirement was always that the content be visible on the page. What matters more is position: on a page where the questions are the last objection before a decision, putting them below the footer links is a merchandising mistake, not a technical one.

Can I generate FAQs with an AI tool?

You can draft with one; you cannot source with one. The failure mode is plausible questions nobody asked and plausible figures nobody published, and both are worse than no FAQ at all. Take the questions from your support inbox and your sales calls, and check every number against a primary source before it goes on the page.

NEXT STEP

Free store audit

A senior Shopify engineer reviews your storefront, theme performance and checkout, then sends a prioritised list of fixes.