FAQ section: is it still useful for SEO, AI, and customers?

You add a FAQ section because AI likes them. That’s the advice every guide on AI visibility gives you, based on a syllogism that sounds airtight: models work on requests, FAQs are requests already answered, so FAQs are the format they prefer.

If you sell online or present services on your site, you probably already have that block of questions at the bottom of your pages, and it may date back to the years when the right markup was enough to get it displayed open under your link in the search results. Now it’s back in focus with a different promise, and the temptation is to lengthen it, or generate a new one for every product page.

Before you do that, you need to know who’s reading it. The search engine, a system that composes generative answers, and the customer about to buy all use those lines in very different ways, and the guides’ promises only hold up for one of the three.

What FAQs are

FAQs, short for frequently asked questions, are the answers to the questions a company, service, or community receives most often, collected and published so that anyone with the same doubt finds the answer without having to ask it. On the web the term refers both to a type of content and to how it’s written: a list of entries, each made up of a question and its answer.

The principle is the same as a customer service team answering the same email for the hundredth time. If you work with a support team, even a small one, you know the pattern: some requests come back every week worded only slightly differently (how much shipping costs, whether the product is compatible, how long you have to return it), and answering from scratch every time costs you time and costs the person writing a wait. Publishing the explanation once, where the customer can find it on their own, cuts both costs.

That origin also sets the standard for judging every entry. It holds up when it picks up a question someone actually asked you, more or less in their own words, so that anyone arriving with the same doubt recognizes it instantly; and it holds up when the answer closes the loop, saying what happens, under what conditions, and within what timeframe, without pointing to another page or a phone call. A question nobody ever asked, or an answer that leaves the uncertainty open, takes up space without doing the job FAQs exist for.

From Usenet to product pages

The format predates the web by a decade. Back in the early 1980s, on ARPANET mailing lists and Usenet newsgroups, every new subscriber asked the same questions the group had already answered dozens of times. Eventually, someone decided to collect the answers into a single message to repost periodically. Eugene Miya did this every month starting in 1983 for the space-related list. That same year, Jerry Schwarz announced a list of “questions not to ask,” and on November 1 he published the first Usenet FAQ, titled “Frequently Submitted Items.”

The move to businesses happened naturally. Early sites almost always had a standalone page, linked from the menu or footer, covering doubts about the whole catalog; the block at the bottom of individual product pages came later, with ecommerce, once it became clear that many uncertainties concern a specific product and need to be resolved right there, at the moment they come up. These are the two forms that most likely coexist on your site too.

FAQ page, FAQ section, FAQPage markup, and question-answer format

When someone suggests you “add an FAQ,” they rarely specify which type they mean. The same acronym covers distinct things, which you can have separately and which produce different results:

• The FAQ page. This is a dedicated URL, often called a help center, that collects questions valid across the whole site or catalog: shipping, payments, returns, account management. Visitors arrive here with a specific question already in mind.
• The FAQ section. This is a small block of entries placed on a specific page, almost always at the bottom, with questions tied to that product or service. Readers encounter it while they’re evaluating something, even though they arrived for another reason.
• FAQPage markup. This is a type of structured data: code invisible to visitors, written using schema.org vocabulary and usually in JSON-LD, that tells search engines a set of questions and answers exists and repeats them in a machine-readable form. It describes an existing block, it doesn’t replace it: the section can live without markup, while the code, under Google’s rules, always had to match visible content.
• The question-answer format. This is a way of writing that doesn’t need a dedicated block: a heading that states the doubt in the reader’s own words, followed immediately by an answer that appears in the first lines and makes sense even on its own. An H2 in your guide built this way follows this format even if no one calls it an FAQ, and it’s the structure that makes text easy for a generative engine to extract.

The distinction matters because each reader looks at a different object: for four years the search engine rewarded the markup, generative systems work on the text and therefore on the format, and people read the section.

What an FAQ section does for SEO

Ever since Google stopped showing FAQ rich results, the block of questions at the bottom of your page no longer gets special treatment. The engine reads it like any other paragraph, and its contribution to rankings comes down to one thing: how much information it adds beyond the text that precedes it.

If it tackles questions the page body ignores, it expands the range of queries you can show up for. These are niche searches, phrased as questions about a specific detail (trade-in of old units, installation timing, who handles the paperwork for tax deductions), often written with the same words a customer would use on the phone. Those same questions also feed the “People also ask” boxes on Google, which pull a few lines from the sites that answer best. A standalone answer placed right under its question has exactly the format those boxes look for.

If instead it just condenses into three lines a topic already covered further up the page, it adds nothing. You won’t get penalized, but you won’t gain a new signal either. The full explanation already lives in the body of the page, so anyone who scrolls down just rereads a shorter version of what they’ve already read. The same applies, multiplied, to an identical block copied across the whole catalog, showing up unchanged on hundreds of URLs and distinguishing no product from the next.

Two technical checks round out the picture:

• Accordion answers. Keeping them collapsed until the user clicks is a design choice that causes no problems, as long as the text is already present in the HTML and only hidden. The mobile-first indexing documentation allows accordions and tabs, but makes clear that content loaded after an interaction isn’t retrieved: if your theme loads the answers only when clicked, those answers don’t exist at crawl time.
• FAQPage markup. It no longer produces effects in the SERP and causes no harm, so there’s no reason to rush to remove it or to add it where it’s missing. It becomes a problem when it stops matching the visible content, which happens when the JSON-LD is written by hand or generated by a separate plugin while the entries have since changed.

Why a well-built page duplicates its own FAQ section

The most redundant blocks often show up on the best-optimized pages. Whoever optimizes a page works the most-searched topics into the headings; whoever wrote FAQs back when the rich result still existed was drawing on the same queries, because those were the ones the rich result rewarded. Two lists built from the same source end up overlapping, and the overlap grows with the quality of the coverage: the more headings capture search demand, the more questions at the bottom turn into duplicates.

A concrete example: the page of an installer selling condensing boilers online with installation included. About twenty H2s and H3s phrased around what searchers actually wonder, from price to replacing the old unit, followed by ten questions marked up as FAQPage.

Seven out of ten entries just restate a heading, in several cases almost word for word. One describes how the technology works, information any competitor could publish identically. The remaining two, compliance and how long the job takes, touch on the terms of the offer and are the only ones that could have said something original. They’re also the vaguest: on the first, the text cites the decree without saying who issues the certification or when the customer gets it; on the second, it settles for “it depends on the type of job.”

On your own pages, the check takes a few minutes:

1. Match the section entries against the H2 and H3 headings, and flag the ones already answered above;
2. Among what’s left, separate general product knowledge from the conditions under which you sell it;
3. Reread the answers about conditions and check each one states a time frame, a cost, or a specific commitment.

What AI looks for in an FAQ

When you query ChatGPT, Perplexity, or AI Mode and the system pulls from the web, it generally doesn’t read pages start to finish. It breaks them into chunks, pulls the passages closest to the request, and recombines them into new text, often blending multiple sources. A passage gets picked when it answers a specific need directly and still makes sense on its own, without requiring any setup.

A well-built FAQ entry has these qualities built in: the question is stated in the words of whoever has it, the answer sits in the first lines, and it doesn’t depend on what comes before it. You get the same qualities, though, by phrasing an H2 from your page or guide as a question and answering it right underneath, with one added advantage: the passage then sits in a spot where the rest of the text backs it up and fills it out, rather than in a detached appendix.

Either way, though, it needs to answer a real need. An entry has value for a generative engine only if someone actually asks that question. An entry invented because it sounded plausible, or generated straight from the product name, becomes a well-formatted passage that no query ever comes looking for.

On markup, though, the public evidence doesn’t back up the promise. Ahrefs compared AI-answer citations for 1,885 pages that had structured data added to them against 4,000 pages left unchanged, and found no meaningful increase in ChatGPT or AI Mode, while citations in AI Overviews actually dropped 4.6%. The sample mixes different schema types and sites that were already heavily cited, so it doesn’t isolate the effect of FAQs specifically. Mark Williams-Cook ran an experiment on a made-up company, inserting a fake address only into a JSON-LD block that was deliberately invalid. ChatGPT and Perplexity reported it the same way they’d report any ordinary sentence, a sign the code was read as text, not as structure. Google’s documentation on its AI features states that no particular markup is needed to appear in AI Overviews and AI Mode. The one outlier is Microsoft: in 2025, Bing’s Fabrice Canel said schema helps Bing’s and Copilot’s models understand content, but he didn’t tie that to which sources get cited.

One thing nobody has measured is whether the same answer gets picked up more often from a block at the bottom of a page or from the body text. Still, deciding what to do with your own pages doesn’t require that answer: code doesn’t give the model anything the text doesn’t already contain, and the text is worth only what it resolves. Entries that address real questions, with self-contained answers, are useful material for a generative engine just as they are for a person. Entries that just repeat the page or answer questions nobody asks won’t improve your odds of being picked, no matter how many you add.

Taking the advice literally has a potential cost, too. The short format is easy to replicate, and some have taken it to the extreme with series of pages each dedicated to a single question: Lily Ray has classified these “FAQ farms” among the content models produced at scale that grow for a while and then collapse, and Danny Sullivan has asked people not to chop up text into bite-sized chunks built for language models. Ten entries generated from the product name and copied across the entire catalog reproduce the same pattern in miniature, right on your own site.

If the AI uses your answer without citing you

You’ve already seen that an extraction can send you no one, with the featured snippet, which pulled clicks away even from the page it was taken from. Generative answers widen the phenomenon: the text comes from a mix of multiple sources, and your name may end up in a link off to the side, inside the answer, or nowhere at all. Being used, being cited, and getting a visit are three different outcomes, and no form of presence converts into traffic on its own: that’s the logic of zero-click.

What you get out of it depends on what the entry describes. Take two examples from the same page: “How long does a condensing boiler last?” has an answer findable on dozens of sites, which the engine can reassemble even without you: if it pulls the answer and doesn’t name you, the reader gets the information and you get nothing. “Is removal of the old boiler included?”, with an answer saying it’s included in the price for installations in Lombardy, instead describes your offer, and separated from your name it loses all usefulness; to use it, the system has to say who provides that service, and anyone who wants to take advantage of it still has to come to you.

There’s no data on how many FAQ answers get reused anonymously, so this distinction is a line of reasoning, not a measurement. You can check it on your own entries by rereading each answer as if your site’s name weren’t there: the ones still useful to anyone are general knowledge, which an engine can use without giving you anything back; the ones that stop making sense are tied to your offer, and even when extracted they carry the reference to you along with them.

Who actually needs this: people about to buy

The reader FAQs were created for is also the one who gets the most out of them today: the person deciding whether to buy from you. When they land on a product page or a service page, they already have a rough idea of what they need, and the main text helps them confirm it with features, model comparisons, and price. Alongside these questions, though, they bring others that concern the purchase terms more than the product: whether installation is included, who takes away the old appliance, how many days pass between order and delivery, who pays for return shipping, whether the seller handles the paperwork for tax deductions.

These are side questions, because they sit next to the choice rather than inside it: the person asking them often already knows what they want and just has to decide who to buy it from. You can recognize them by what happens when the page stays silent. An email or a phone call comes in, and if the answer is slow, the customer may turn to a competitor who put that condition in writing. In an ecommerce site or a service business, these questions come up almost identically in support requests, often from people who haven’t paid yet.

A FAQ section makes sense, then, on pages that come before a purchase or a contact: the product page, a service page, a local business page, the pricing page of a subscription software, an offer landing page. You split the work with the support page. Conditions that apply to the whole catalog, like standard shipping times or the return procedure, stay there, and the section can link to them; conditions specific to a product or service, like an installation that’s included or an extended warranty, belong in the page’s own block, right where the uncertainty comes up.

The effect shows up mostly away from the SERP. When an entry resolves a doubt that used to end up with support, requests about that point drop, and the customer reaches the cart, or the contact form, with one less question.

Where the section ends and the text begins

Not every doubt a buyer has belongs in the section. Someone torn between a condensing boiler and a heat pump is still choosing the product, and answering them requires consumption data, home insulation, type of system: the reasoning the product page should already be developing. Squeezed into three lines at the bottom, it becomes shallow exactly where the reader needed depth. Its place is in the body, under a heading that frames the comparison in the words the reader themselves would use.

“Do you take away the old boiler?” belongs instead to the terms of the offer: the main text has no reason to stop and explain it, the answer fits in two sentences, and whoever is looking for it has usually already picked the model. The line runs here, with product choice in the text and the terms for buying it from you in the section. The exception is the one the installer example makes clear: if the page already covers a condition under its own heading, like “What’s included in installation”, the entry at the bottom is a duplicate even when the doubt is a side one.

In articles, FAQs flag a structure that needs rework

An article, a guide, or an in-depth piece tackles a knowledge problem, and the doubts it raises are part of the same reasoning. If the text resolves them, a closing block just repeats them in plainer words; if it doesn’t, the block collects what the structure failed to work in. In editorial content, side doubts all but disappear, because there are no purchase terms to clarify, and with them goes the main reason for having the section.

We’ve used them too. For a while we closed out our pillar pages, the reference guides that on some topics run up to twenty thousand words, with a block of questions meant as a hook to the key points, for readers who wouldn’t read the whole thing. We did it somewhat lazily, and it added nothing, not to reading time, not to clicks, and even less so after AI Overviews arrived, giving the same short answers right at the top of the SERP. We removed them and worked on the headings instead, because that’s where the real problem was: titles that didn’t clearly say what the reader would find below. If an article needs an FAQ section to work, something earlier probably went wrong.

How to find the right questions

Before writing or revising a section, the decisive step is separating questions someone actually asked you from ones that are merely plausible. Read at the bottom of the page, they look identical: “Is removal of the old boiler included?” looks the same whether dozens of customers wrote it or you imagined it while filling out the product page, and only the source tells you which one you’re looking at. To keep track, you can call confirmed any doubt that comes from traces left by people who reached your page or bought from you, and candidate everything else, until you’ve verified it.

The traces closest to a purchase are already sitting in your company:

• Support tickets on a product capture doubts in the customer’s own words, often before they’ve paid.
• Sales staff hear the objections that stop a purchase over the phone or in the store.
• Reviews contain what customers wish they’d known beforehand.

It’s the most reliable source, and also the narrowest, since it only records people who made it all the way to you, not those who bought elsewhere.

A second trace is left by people who search, and you read it in Search Console, the free tool Google uses to show you the searches your pages appear for. To isolate questions about a specific product:

1. open the performance report and filter by page using its URL;
2. add a query filter and choose the custom regular expression option;
3. paste this line, which keeps only searches opened with a question word:

^(come|cosa|cos'è|quant[aeio]|quando|dove|perch[eé]|qual|quale|quali|chi|che)(\s|$)

The filter misses two categories that matter: fragment-style searches, like “boiler removal used,” and closed-ended questions, like “do you remove the old boiler,” which are actually the most common form of secondary concerns. After the filtered list, go through the full list of queries for that URL too, looking for terms tied to your offer: removal, installation, delivery, warranty, returns.

With your site connected to a SEOZoom Project, the same work goes faster. In Keyword Explorer, the “Only question keywords” checkbox isolates queries phrased as questions and pairs each one with the main URL it ranks for; the Google FAQ section instead lists the questions that show up in the “People also ask” boxes for the keywords you rank for, along with the starting keyword, position, volume, and URL. These are questions the search engine considers related to that page: near candidates, which become entries once you find them again among the page’s queries or among customer requests.

On a single product page, you can make this comparison by hand. On a catalog of hundreds of products, each with its own FAQ block and its own changing conditions, repeating the same round of filters page by page turns into a second job, and you usually give it up right when you need it most. Having the questions already matched to the URL that receives them lets you review every section without rebuilding the list from scratch.

SEOZoom tools for widening the search

Besides the traces left on your own page, other tools on the platform show you the questions circulating around a topic, each from a different vantage point. They give you data to interpret, not verdicts: what you find this way stays a candidate, and it becomes an entry once you find it again among your customers’ requests or among the searches that lead to the page; otherwise, it can shape the main copy or another piece of content.

• Question Explorer. Start from a topic and get the questions that appear in the “People also ask” boxes, along with the wording and variants the engine uses to phrase related doubts. The volume next to each question adds up the volumes of the keywords in whose SERPs it appears: it measures the size of the territory where it’s shown, not how many people type it exactly that way.
• Editorial Assistant. While you’re working on a piece, the FAQ panel shows user questions on the topic, and the optimization suggestions flag the ones you haven’t covered yet. It’s a coverage signal: a doubt about the product belongs in the body text, while one about your offer’s conditions, if you find it in your own data, belongs in the section.
• AI Prompt Research. You write a request the way a person would phrase it to an AI assistant, and the tool reconstructs the searches a generative engine would break it into, the so-called query fan-out. For a boiler replacement, alongside the heat pump alternative you’ll see things like the permits tied to the work, disposal of the old unit, and choosing an installer. These are searches generated by the model and can contain outdated references, like a tax incentive from a year that’s already closed.
• Buyer Personas from AI Engine. Hypothetical customer profiles generated by AI, with needs and friction points that stop them before purchase. They help you picture a doubt no one has put into words for you yet, or a type of customer you’d overlooked; if that customer actually shows up on your product page, you’ll spot it in your own data before giving it a voice.

How you write and maintain the section

If the section already exists, start with a line-by-line review, with the page open next to the traces you’ve gathered: support requests about that product, queries for the page, questions the Project links to that URL. For each one, decide whether to keep it, move it into the main copy, or delete it, applying four checks in the order that eliminates the most entries:

1. It repeats a page heading. If an H2 or H3 already states the same doubt and the paragraph below it resolves it, the FAQ entry at the bottom is a duplicate: remove it, and leave the content where it is.
2. It’s about choosing a product. A question about which model, technology, or power level to pick serves someone who’s still comparing options, and that person looks for it in the body copy: if the text doesn’t cover it, move it there, under a heading that states it.
3. It doesn’t show up anywhere. If it doesn’t appear among customer requests or among the queries for the page, it stays a candidate even if a tool assigns it a high search volume, and for now it doesn’t go into the section.
4. The answer applies to anyone. If the question concerns a condition specific to your offer, but the answer could appear word for word on a competitor’s site, keep the entry and rewrite the answer.

There’s no right number of entries: three recurring doubts call for three entries, and a product page that gets no questions at all can skip the block entirely. The most useful order follows frequency, with the questions support receives most often at the top, since those are the ones readers look for first. The bottom of the page works for conditions that matter once the decision is nearly made; if a doubt blocks the purchase earlier on, like an installation cost that varies a lot by region, it’s better to place it near the price or the buy button.

The answer that contains a commitment

A secondary question has a good answer when it opens with a commitment from the seller: what’s included, by when, at what cost, with what proof for the customer. The difference is obvious in an entry built as an example, about removal of the old boiler.

Before: “Yes, we offer a removal service to ensure maximum convenience for our customers.”

After: “Yes, for installations we carry out ourselves, removal is included in the price: the technician takes out the old boiler on installation day, and the disposal certificate arrives by email within ten days.”

The first version confirms the service exists and says nothing about what the customer actually wants to know: whether it costs extra, when it happens, whether it applies to those who hire a different technician too. The second version limits it to the seller’s own installations, rules out extra costs, sets the day of the job, and promises a document with a deadline. Readers know exactly what to expect, and a competitor can’t copy it without changing it, because it describes a specific way of doing business.

Writing an answer like this requires knowing how the service actually works, and the people managing the pages often don’t: the right source is whoever handles installations or deliveries. For the same reason, an AI-generated text, however polished, tends to resemble the first draft, because the model knows the general topic but not the specifics of your offer, which is exactly what the answer needs to contain. And if no one in the company can give you a timeframe, the page can’t state one: the limit is in how the service is organized, not in the writing.

Every written commitment is a promise the page keeps making until someone updates it. That’s why you need to revisit the section whenever sales conditions change (a new installation area, a service that becomes paid, different delivery times) and whenever support starts getting a question it didn’t get before. Those same requests tell you whether the update worked: after you rewrite the answer about returns, calls about that issue should drop, and if they don’t, the entry still isn’t resolving the doubt.

Looked at this way, a FAQ section can shrink down to a handful of entries, or disappear entirely from pages that have never drawn a related question. The entries that remain describe the terms you sell under, with commitments customers can verify, and they’re also the only ones that keep their value when a generative engine picks them up, because they carry your name with them.