Your FAQ Page Is Doing Two Jobs Badly

The FAQ page is the most underrated page on a business website and the one most often written in twenty minutes by someone guessing.

You can tell because of what is on it. "How long have you been in business?" "What areas do you serve?" "Do you offer free consultations?" These are not frequently asked questions. They are questions somebody imagined while filling a template, and nobody has asked any of them.

Meanwhile the questions your customers actually ask — the ones in your inbox every week, the ones that stall a deal for three days — are nowhere on the site.

An FAQ has two jobs, and most do neither well.

Job one: answer the question before it becomes a message. Every question answered on the page is a support ticket that does not happen and a deal that does not pause.

Job two: be the thing that gets quoted. A question-and-answer pair is the densest quotable structure on the web. It is a question with a self-contained answer directly under it — which is exactly the shape a machine extracting an answer is looking for.

Both jobs are served by the same fix, and the fix starts with where the questions come from.

Get the real questions

Do not brainstorm. Harvest. Four sources, in order of value.

Your inbox and your chats. Read the last hundred customer messages and tally what is actually being asked. This takes an afternoon and it is the single most useful content exercise available to most businesses. The answers will not be what you expect: the questions that dominate are usually about price, timing and what happens if something goes wrong.

Your sales conversations. The questions that get asked on calls, especially the ones that come up after a price is mentioned. Those are objections, and an objection answered in public is an objection you do not have to answer in private.

Your search data. Search Console shows the queries surfacing your pages, and a large share of them are phrased as questions. That is your market telling you what it wants to know, in its own words.

Your site search, if you have one. Especially the searches that returned nothing.

What you end up with is a list where the top items are uncomfortable. Good. The questions that feel awkward to answer publicly are the ones doing the most damage privately.

Answer the hard ones

An FAQ made only of easy questions signals that you are avoiding the hard ones, and readers notice.

The hard questions are usually four: what does it cost, what if it goes wrong, why are you more expensive than the alternative, and what happens if you disappear.

Our own site answers all four, and the answers are specific rather than reassuring. Prices are published: landing pages from $99, corporate sites from $299, stores from $499, platforms from $799. Payment is 50% to start, 50% when it is live and you are happy, and if we cannot get it right, you do not pay the balance. Support runs from 14 days on a landing page to 12 months on a web app, then $39 a month or nothing — take the code and go elsewhere.

Every one of those is a commitment rather than a sentiment, and that is what makes them useful in both jobs. A machine can quote "support runs 14 days on a landing page". It cannot quote "we're committed to customer satisfaction", and neither can a customer trying to justify you to their boss.

If you take nothing else from this: put the price answer on the page. The most common reason people do not ask is that asking means starting a sales conversation, and we have made that argument at length in publish your prices.

Write the answer to be extracted

Six rules. Each one serves both jobs at once.

Make the question the heading, phrased the way a customer phrases it. Not "Pricing structure" but "How much does a website cost?" The heading is the match signal, for a reader skimming and for a machine deciding what the section is about.

Answer in the first sentence. No preamble, no restating the question, no "great question". If the question is how long it takes, the first sentence has a duration in it.

Make the answer self-contained. It will be read without the question above it and without the page around it. "Three to five days" is not an answer out of context. "A landing page takes three to five days from the day content is ready" is.

One question per heading. Bundled answers — "How much does it cost and how long does it take?" — cannot be extracted cleanly and are harder to skim.

Give numbers, not adjectives. "$99" beats "affordable". "Within 24 hours" beats "quickly". A qualifier that cannot be checked is not an answer.

Say the limits. The answer to "can you do X?" is sometimes no, and a stated no is more credible than a hedge. We publish the things we will not build at all — gambling, betting, interest-based lending, adult content, alcohol, unsafe products — on our about page, and that refusal does more for trust than any capability list.

The full discipline behind this is in write the page a machine can quote; an FAQ is simply where it pays off fastest.

Put the FAQ where the question is asked

The dedicated FAQ page is the weakest placement, because it requires someone to have a question, notice the link, and go looking.

The strong placement is next to the thing the question is about. Pricing questions on the pricing page. Delivery questions on the service page. A product's returns question on the product page. The customer's question arrives at a specific moment, and an answer three clicks away arrives too late.

Both is the right answer: questions in context on the relevant page, and a complete FAQ page as the reference. That is how ours works — the pricing page carries its own FAQ, service pages carry theirs, and every article on this blog ends with the questions that article raises.

That last pattern is worth copying. An FAQ at the end of a page is the place a reader's remaining doubts live, and answering them there is the difference between a page that informs and a page that converts.

Mark it up, honestly

A genuine question-and-answer page should carry FAQPage structured data, so the pairs are machine-readable as pairs rather than as prose that happens to be formatted that way. The full case for markup is in structured data is not an SEO trick.

One rule: the markup must match what is visible on the page. Marking up questions that are not there, or answers different from the ones shown, is the failure mode that gets structured data disregarded entirely.

Feed it back into the product

The highest-value thing an FAQ produces is not the page. It is the list.

A question that appears constantly is a signal about something other than documentation. If everyone asks where the delivery cost is, the delivery cost is in the wrong place. If everyone asks whether they own the code, your contract language is unclear.

An FAQ is a list of things your site failed to communicate. Answering the question is the patch. Fixing the page is the cure, and the best FAQs shrink over time in the places where the underlying problem got solved.

This matters doubly if you run any kind of automated support. Bronjoy's help bot answers from a knowledge base imported from the product's own documentation — which means the quality of the documentation is the ceiling on the quality of the bot. It also escalates after repeated unhelpful answers, and those escalation logs are the most honest FAQ research available: they are the questions your content could not answer, recorded automatically.

If you are automating support, read that log monthly. It will tell you what to write next, ranked by how often it failed.

The one-day version

1. Read the last hundred customer messages. Tally the questions.
2. Take the top twelve. Include the uncomfortable ones.
3. Write each as a heading in the customer's words, with a self-contained, specific answer in the first sentence.
4. Put each one on the page where the question arises, and collect all of them on one reference page.
5. Add FAQPage markup that matches exactly what is visible.
6. Keep the list. Review it quarterly, and delete the questions that stopped being asked because you fixed the page.

We build conversion-first websites from $99 with the copy written as part of the work, and the FAQ is one of the places where that matters most — because the questions a business is embarrassed to answer in public are almost always the ones costing it the most sales.

Tell us what you need. You get a fixed price and a delivery date back — free, and with no obligation to proceed.

Frequently asked questions

How many questions should an FAQ have?

Ten to fifteen for most businesses, covering the questions that actually recur. A page of forty is a symptom of a product or a site that is confusing people, and it is better treated as a backlog than as a page.

Should I include questions nobody has asked yet?

Only if you know they will be asked — a genuinely new service, an unusual policy. Inventing questions to pad the page produces the template FAQ this article opens with, and readers can tell.

Is it bad to answer a question that might lose me the sale?

It loses you the wrong sale, earlier and more cheaply for both sides. A customer who needed a feature you do not offer was never going to become a happy customer, and they were going to find out eventually — after they had spent your time and theirs.

Where should the FAQ page sit in navigation?

In the footer is fine for the reference page. What matters more is that the individual questions appear in context on the relevant pages, where somebody is actually wondering.

Does an FAQ still help with search?

Yes, for both kinds. For ordinary search it targets question phrasings directly. For assistants it provides the cleanest possible extraction shape. The mistake is writing it for search — questions invented for keyword coverage read exactly as hollow as they are, to both audiences.