Answer the question the page forgot
Describe the product, service or article in a few sentences. You get the questions people actually ask, in the order they ask them, each with a two-sentence answer that only uses what you supplied - plus the questions to write next and a copy of the FAQ schema ready for the page.
The AI FAQ Generator writes a set of frequently asked questions with answers for a product, a page or a service, with the number of questions and the tone you choose. The pairs are plain text, ready to place on a page or to mark up as FAQ structured data.
The FAQ is the only part of the page written for a stranger
Everything above the FAQ is written for somebody who is already interested: the headline promises, the features explain, the price asks for a decision. The FAQ is for the reader who is interested and stuck, and the question that stopped them is usually not the one the marketing team thought of.
It is also the part of the page that search engines quote. A short, direct answer to a real question is what turns into the box above the results, and what an assistant reads when somebody asks about your product without opening your site. That has made the FAQ the cheapest piece of search optimisation on a site and the one most often filled with questions nobody asked.
The giveaway is a question like \"Why choose us?\". It is not a question; it is a headline with a question mark. A real one is specific enough to be answered in two sentences and uncomfortable enough that somebody has typed it into a search box at eleven at night.
Three clusters, and only one of them gets written
A page's questions arrive in three moments: before the purchase, during use, and after something breaks. The first cluster is the one every page covers. The second is where support tickets are born and where a page saves the most money. The third is where trust is either kept or lost.
- Will it fit my desk?
- What is in the box?
- Is there a cheaper version?
- How long does it take to set up?
- Does it work offline?
- Can two people share it?
- What does the warranty cover?
- Can I replace the cable?
Most pages answer the first cluster and stop. The second cluster is where support tickets are born, and it is the one nobody writes.
The percentages are the point: the cluster with the fewest questions is the one with the highest cost per answer. A page that answers \"can I replace the cable?\" in one sentence removes an email, a refund and a review.
Where real questions come from
| Source | What it gives you | Ask it as | Where it belongs |
|---|---|---|---|
| Support inbox | the question that costs money every week | \"Can I ... ?\" | next to the feature it is about |
| Search suggestions | the phrasing people actually type | the words in the autocomplete | a dedicated FAQ section |
| Reviews of competitors | the objection before the purchase | \"Is it ... ?\" | above the price |
| Sales calls | the question nobody asks in writing | \"What happens if ... ?\" | the page, then the proposal |
| Your own returns | the promise that was misread | \"Does it ... ?\" | the product description first |
The right-hand column is the one that changes results. A question about delivery belongs next to the delivery estimate, not in a block at the bottom of the page; a question about a limitation belongs where the limitation is introduced. An FAQ that collects everything in one place is easier to write and worse to read, because it moves the answer away from the moment the doubt appears.
From a description to a block that answers
Describe the real thing
What it is, who it is for, what it costs, what it does not do. The answers can only be as specific as the description.
Pick five, not fifteen
Five questions get read. Fifteen become a wall, and the two that mattered are at the bottom. Use 8 or 10 for a help centre, not a product page.
Cut an answer that hedges
Two sentences: the answer, then the reason. If the answer needs a paragraph of context, the product description is missing something.
Take the schema
One button copies the FAQPage JSON-LD. Paste it once per page, and keep the visible answers and the schema identical.
Three things that make an FAQ useless
\"Why choose us?\", \"What makes us different?\", \"Ready to get started?\". None of these is a question a customer types. They exist because a template had five slots and the writer ran out of real ones. Delete them and the page gets shorter and more useful at the same time.
An FAQ answer is a statement about the product, and a customer can hold you to it: \"yes, it works with any printer\" becomes a return when it does not. The tool is instructed to use only what you supplied, which is why a description with real limits produces better answers than one written to sound good.
Structured data has to describe what a visitor can see. FAQ markup for questions that are not on the page, or for answers that were rewritten afterwards, is a penalty waiting for a manual review. Paste the schema after the answers are final, not before.
An FAQ that answers instead of decorating
Write the answer you would give on the phone
Picture the support call. Somebody asks whether the subscription works for two people, and the person on the phone says: yes, one subscription covers a household, but the second person needs their own login and sees the same projects. That is a complete answer - decision, condition, consequence - and it is twenty-eight words. Most FAQ answers are longer because they were written to sound careful, and shorter answers are read more.
The order matters more than the count
Put the question that decides the purchase first. If somebody leaves after the second question, they should have read the two that matter. The last question can be the niche one, because the reader who gets there has already decided.
Group by moment rather than by topic: before, during, after. A reader in the middle of setup does not want to pass four questions about pricing to reach the one about the cable.
Answer the limitation honestly
\"It does not work offline\" costs you one customer and saves you ten refunds. Every product has a limit, the reviews will name it, and a page that says it first is believed about everything else. This is also the answer that produces the most trust per word, because it is the one nobody expects from a marketing page.
One question, one page
If an answer needs three paragraphs, the question deserves its own article. Write the two-sentence version on the page and link to the guide: the reader who wants depth gets it, and the reader who wanted a yes or no is not made to scroll.
Keep the answers in one place
The FAQ is usually the only place where the same facts appear in prose, so it drifts first. When a price changes or a limit moves, the FAQ is the page that keeps the old version. Review it on the same schedule as the pricing page, not once a year.
Schema, without the tricks
Add FAQPage markup to the page that shows the questions, with the same wording. Do not mark up questions that exist only in the JSON, and do not put your whole product page in the FAQ schema hoping for a rich result: search engines have been rejecting that for years, and the rejection is manual.
Done properly, the markup helps two readers at once: the person scanning the page and the machine deciding whether your answer deserves to appear above the link.
What to measure
Look at the support inbox, not at the page views. An FAQ that removed three recurring questions from the inbox did its job even if nobody clicked it, because the people who would have written in found the answer on the page. The second signal is the search terms that bring people to the page: if they are questions you do not answer, the block is missing its own subject.
Five questions, two sentences each, reviewed twice a year. That is a small amount of work for the part of the page that decides whether a stranger trusts you enough to buy.
Questions about the questions
Will the answers invent policies?expand_more
How many questions should a product page have?expand_more
What is the FAQ schema for?expand_more
Can I use it for a service rather than a product?expand_more
Does it translate the questions?expand_more
Answer the five questions that cost you sales
Describe the page, take the answers and the schema, and put each answer where the doubt appears.
fact_checkQuick facts
- A useful FAQ answers the question people actually type, not the question the business would like to answer.
- Structured FAQ data must match the questions and answers visible on the page, so the markup and the page should be written together.
- Google builds a title link and a snippet from the page itself, and it may use a heading or a sentence from the body instead of the meta description.menu_bookGoogle Search Central
- FAQPage and HowTo structured data are only eligible for a rich result when the questions and steps are visible on the page itself.menu_bookGoogle Search Central
- A language model reads text in tokens, and one token is roughly four characters of English, so a 300-word answer is about 400 tokens.menu_bookOpenAI Cookbook
helpQuestions people ask
How do I write a good FAQ section?expand_more
How many questions should an FAQ have?expand_more
Does FAQ schema still help SEO?expand_more
hubWhat this page is about
- Answer engine optimisationopen_in_new
Writing a page so that a search engine or an AI assistant can lift one clear, sourced answer out of it instead of guessing.
- Large language modelopen_in_new
A model that predicts the next token of a text; the site sends the prompt to a hosted model and returns its answer.
- FAQ structured dataopen_in_new
Schema.org markup that lists questions and their answers, so a search engine can read them as a FAQ for a page.
library_booksOfficial sources cited on this page
- How Google generates titles and snippetsGoogle Search Central
- FAQPage structured dataGoogle Search Central
- HowTo structured dataGoogle Search Central
- How to count tokens with tiktokenOpenAI Cookbook
Keep going with the next tool
The tools in this group that do the next piece of the same work, all switched on right now.
Switched-off tools are not listed here: only what works right now.