How to Write FAQ Content for a Chatbot That Actually Answers

A support team publishes forty help-centre articles, connects a chatbot to them, and watches it resolve 44% of conversations. The instinct is to blame the model. It is almost never the model. Published benchmarks put new deployments in roughly that same 40–50% band and mature, well-documented ones at 60–80%, and the variable separating the two is the writing.

Which is awkward, because most FAQ content was never written to be answered from. It was written for a page — for skimming, for reassurance, for a Google feature that no longer exists. Writing FAQ content for a chatbot is a different job with different constraints, and the good news is that it is a small job. Rewriting twenty answers properly moves the number more than any configuration change you can make.

The Google Change That Reframed the Whole Exercise

For years, FAQ sections were partly an SEO instrument. You marked them up with FAQPage schema, Google showed expandable questions under your result, and you got extra SERP real estate for what was often quite thin content.

That ended on 7 May 2026, when Google deprecated FAQ rich results entirely, finishing a withdrawal that began in 2023 when the feature was restricted to government and health sites. Search Console's FAQ report went in June and the API dropped it in August. FAQPage is still valid Schema.org markup and Google has said leaving it in place does no harm, so there is no cleanup to rush.

What changed is the audience. Nobody is rewarding you for the shape of the markup any more. The things that read your FAQ content at volume now are retrieval systems — your own chatbot, and the AI assistants people ask instead of searching. Both want the same thing, and it is not what a SERP box wanted.

What FAQ Content for a Chatbot Has to Do Differently

A chatbot does not read your FAQ page. It splits your content into passages, converts each one into a vector, and at question time retrieves the two or three passages that sit closest to the customer's phrasing. The answer it gives is composed from whatever came back. Everything follows from that.

	Written for a web page	Written for retrieval
Question phrasing	Branded and tidy — "Our Returns Policy"	The customer's words — "Can I return something after 30 days?"
Answer length	Whatever the layout allows	40–150 words, one subject
Context	Carried by the heading above it	Restated inside the answer
Cross-references	"See the section above"	Repeated in full
Conditions	Footnoted or implied	In the same paragraph as the rule
Tone	Persuasive	Declarative

The one that surprises people is context. Passage splitting is mechanical — SahayBot splits at roughly 200 words with a 40-word overlap — so a sentence beginning "This does not apply to orders placed before the 15th" can arrive at the model with no idea what "this" refers to. Anaphora, the linguists' term for pronouns pointing backwards, is the single most common reason a correctly written answer produces a wrong one. Retrieval research consistently finds that restoring the missing context to each passage is worth double-digit accuracy gains — a large return for deleting the word "it".

Six Rules, and the Rewrite Each One Implies

1. One question per answer. If an answer contains the word "also", it is probably two entries. Split them. Two focused passages both retrieve well; one combined passage retrieves cleanly for neither.

2. Write the question the way a customer types it. Your team says "subscription downgrade". Customers type "how do I go back to the cheaper plan". Use theirs, or both — a question line is cheap.

3. Answer in the first sentence. Not the background, not the empathy, not the policy rationale. "Yes, up to 30 days after delivery." Then the detail. A model composing from your passage will lead with what your passage leads with.

4. Name the subject in every answer. Replace "It takes 3–5 days" with "Standard delivery takes 3–5 business days." The second version survives being read alone; the first does not.

5. State conditions where the rule is stated. "Refunds are processed within seven working days" and "excluding subscription plans, which are pro-rata" belong in one passage. Separated, the bot will confidently give half the policy.

6. Spell out everything internal. "SKU 4421-B" and "the Tier 2 flow" mean nothing to a customer and nothing useful to a vector. Write the product name and describe the process.

A before-and-after showing all six at once. Before: "Returns — We want you to be happy with your purchase! Items may be returned in line with our policy. See Terms for exclusions." After: "Q: Can I return an item after 30 days? A: No. Returns must be requested within 30 days of delivery, with the item unused and in its original packaging. Sale items and personalised products cannot be returned. To start a return, use the Orders page in your account."

It is not better writing in a literary sense. It is better because a stranger can answer a question from it.

Five Ways a Well-Written Answer Still Fails

Content can clear every rule above and still break in production. The failures worth checking for specifically:

• Two answers that disagree. The commonest and the worst. An old article says refunds take seven days, a newer one says five, and nothing in the retrieval layer knows which is current — it will pick by similarity, not by date. Edit the original; never publish a correction alongside it.
• The answer lives in a screenshot. Image text is not indexed. If the only place the setting is named is inside a PNG, the bot cannot see it. Write the steps out, then keep the screenshot for humans.
• Pointer answers. "As mentioned above", "see the shipping section", "refer to our Terms". Each one retrieves perfectly and answers nothing.
• Undated facts that expire. Prices, limits, integrations and turnaround times all drift. If the answer contains a number that will change, it needs an owner, not just an author.
• Vagueness that is technically accurate. "Contact us for details" resolves nothing. The agent repeats it faithfully, the customer opens a ticket — the exact outcome the bot was bought to prevent.

Where the Missing Questions Already Are

You do not have to guess what to write. Two sources already hold the list.

The first is your inbox. Read the last hundred conversations and tally the subjects. The distribution is steeper than people expect: a handful of questions account for most of the volume, and those are the twenty answers to write first.

The second is the bot itself. Every conversation where it could not answer is a documented gap with a timestamp, and the analytics view groups them so patterns are visible rather than anecdotal. A question asked eleven times in a fortnight is not an edge case; it is a missing paragraph. This is the loop that turns a 44% resolution rate into a 65% one, and it runs on about twenty minutes a week — far cheaper than crawling more of your site in the hope that volume compensates for gaps. It does not. Between forty mediocre sources and fifteen current, well-written ones, take the fifteen.

Pair that with a fallback message that invites the question rather than closing the conversation, and the gaps surface faster, because people tell you what they wanted instead of leaving.

When Better FAQ Content Will Not Help

There is a category of question no amount of writing will fix.

Account-specific questions. "Where is my order?" has a different answer for every person asking, and no FAQ entry can hold it. That needs a system integration — a different product decision from a content one. Check what the agent can and cannot be connected to before promising it internally.

Anything requiring an action. Issuing a refund, changing a delivery address, cancelling a subscription. A retrieval bot explains; it does not execute. If the request is "do this for me", a better description of the process only tells the customer to do it themselves.

Policy that does not exist yet. If three people in your company would answer a question three different ways, the bot cannot be more decisive than the company is. Decide first, write second.

Contested or high-consequence matters. Medical, legal, regulatory or safety questions should route to a person by design, not because the content was thin.

Anything changing weekly. Live stock, current wait times, this week's promotion. Content that expires faster than you can maintain it will be wrong more often than it is right, and a wrong confident answer costs more trust than no answer.

The line is simple enough to state: if the answer is the same for everybody and stable for months, write it down. If it varies by person or changes by the week, build an integration or route it to a human.

That distinction is worth settling before you write anything — the sort of scoping NoCubical, the team behind SahayBot, does first on a support automation project. The writing is easy once the boundary is drawn.

Frequently Asked Questions