Your website has an FAQ page, yet customers keep asking what a service costs, what it includes and whether you cover their area. Before adding more questions, look at what people encounter before they contact you. The answer might be buried elsewhere. Or they may have found it, only to discover that "Contact us for a custom quote" tells them very little.
An FAQ answers frequently asked questions. It can be a dedicated page, a section within a service description or a few answers beside a form. Decide on the format after identifying what the visitor needs to know and where they need it.
The purpose is to help someone take an informed next step: choose a product, prepare an enquiry or understand the terms. You won't eliminate every question. For a complicated purchase, a customer may still want to discuss their situation even when the general information is clear.
When an FAQ helps, and when the page itself needs fixing
A central FAQ works well for questions that apply across the business, such as payment methods, obtaining purchase documents or contacting someone after an order. It gives those answers a stable location and makes them available outside office hours.
Someone reading about a particular service has a more immediate task: deciding whether it fits their needs. If the scope, exclusions and pricing explanation exist only in a separate FAQ, they have to piece the offer together across several pages.
Imagine an installation company advertising a complete installation service. The main description says everything is included, while a collapsed answer at the bottom says room preparation costs extra. The information exists, but its position makes it easy to miss. That exclusion belongs beside the scope and price.
Some questions point to a functional problem. If customers cannot tell whether their enquiry was submitted, check the confirmation message and form behaviour. Repeated questions about available dates may call for a booking calendar or a clearer explanation of scheduling. An extra FAQ entry will not repair a broken form.
That does not make dedicated FAQ pages inherently bad. Use a central page for shared information and put the details that affect a particular purchase close to that offer. Both can be useful on the same website.
Find questions in customer conversations, not a blank document
Start with what people already ask in emails, chat messages and calls. If sales or support staff handle those conversations, ask them for recurring questions and examples that take several exchanges to resolve.
Keep the customer's original wording. "Do you clean sofas?" might ask whether you offer upholstery cleaning at all, or whether you can clean a particular fabric. Rewriting it immediately as "What services do we offer?" loses that distinction.
A simple working log is enough:
| Record | Why it matters |
|---|---|
| The question in the customer's words | Preserve what they were trying to find out |
| Page or stage, if known | Identify where the answer was needed |
| What had to be explained | Find the missing detail |
| How often it comes up | Help prioritise changes |
| Who can verify the answer | Avoid publishing incorrect terms |
Do not copy unnecessary personal details into the log. The question and its context are usually enough to identify a pattern. Anonymise public examples or rewrite them as clearly hypothetical situations.
Reviews and internal search can add useful evidence. A search for "returns" tells you someone wanted return information, but it doesn't prove the policy is poorly presented. Check what the search returned and whether the result led to the right information.
Treat analytics as a way to find things to investigate. Moving from a product to a delivery page can be a sensible step. If someone then leaves, that sequence alone does not establish that delivery charges caused the departure.
Frequency should not be the only priority. An occasional compatibility question may prevent a costly mistaken purchase. Conversely, repeated questions about your location might be better addressed by a visible address and map than by a long FAQ answer.
Competitors can help you spot an omission, but their question lists are not a substitute for your own evidence. Their products, terms and customers may differ from yours.
Put the answer where the customer needs it
Open the page where the question is likely to arise. Can it give a short, useful answer without sending the visitor elsewhere? If so, provide that information there.
These are illustrative situations, not reported client results:
| Customer question | Where the main answer belongs | What may need a separate resource |
|---|---|---|
| What does the price include? | Beside the price and service scope | How additional work is estimated |
| Do you cover my area? | Near service selection or booking | Coverage map and travel charges |
| Will this part fit my model? | Beside the product variant selector | Compatibility table or checking instructions |
| When can the work start? | Near the timeline and enquiry form | Preparation requirements and project stages |
| What happens after I submit this form? | Beside the action and in its confirmation | A longer explanation of the process |
| How do I get my purchase documents? | In shared payment and account guidance | Instructions for a particular purchase method |
A short answer and a detailed page can coexist. A product page might explain how delivery is priced, with a link to the full terms. The short version should answer something on its own rather than merely say "Read more here."
Name the destination clearly: "Check compatibility" or "View our service area." Our internal linking guide explains how to choose these connections around the visitor's next task.
Don't assume that everyone arrives through the homepage. Someone may land directly on a product or service from search. Check whether the page makes sense without an earlier introduction to the business.
If an answer appears in several places, decide where its information comes from and who maintains each version. Different delivery charges in the FAQ and at checkout create another question instead of resolving one.
Replace vague answers with something a customer can use
Answer the question first, then explain the conditions and what to do next. There is no required answer length. A sentence may be enough; a compatibility question might need a table or photograph.
The following examples describe hypothetical businesses. They illustrate answer structure, not terms to copy into your website unchanged.
Pricing: explain what changes the estimate
Question: "How much does it cost to clean an apartment after renovation?"
A weak answer is: "Every project is unique. Contact us for a quote."
A more useful version would be:
The estimate depends on the apartment's size and its condition after the renovation. Send the floor area and photos of the rooms for an initial quote. Let us know if you need window cleaning, paint or adhesive removal, or construction waste disposal; we price those tasks separately.
If the business can give a meaningful range or a starting price with a defined scope, include it. Explaining the calculation should not become an excuse for hiding a price you could already provide. An unusually low starting figure is unhelpful if it rarely covers the work being described.
Put the main explanation alongside pricing. An FAQ can answer a narrower follow-up about what changes the final estimate.
Timing: separate the start date from the time needed
Question: "When will it be ready?"
"We work as quickly as possible" offers little help with planning.
A hypothetical shoe repair shop could answer:
Standard repairs take five business days after you drop off your shoes. We will confirm the collection date when we inspect them. If we need to order replacement soles or another part, we will explain the additional wait before you agree to the repair.
The five days are an illustrative timeframe. Use your actual duration, or explain when you can confirm it. Customers need to distinguish the time spent doing the work from the wait for an available slot.
Service area: let people check their address
Question: "Do you travel outside the city?"
"We serve the whole region" may leave the customer unsure whether that includes them or involves an extra charge.
A hypothetical field service could answer:
Our standard service area is marked on the map. If your address falls outside it, include your town in the enquiry. We will confirm availability and any travel charge before you book.
Where boundaries and charges are already known, show them directly. There is no need to make every customer ask for information they could check themselves. A map or address lookup may work better than a long list of place names.
Compatibility: show customers how to check
Question: "Will this filter fit my system?"
"Compatible with most popular models" gives no reliable way to decide.
A more useful answer would be:
Match the full model number against the compatibility table. You can find it on the housing label; the photograph shows its location. If your model is missing from the table, send us the number before ordering so we can check it.
That answer needs a real table and photograph. If connector shape distinguishes two versions, show a close-up. A short video can demonstrate a sequence of actions, but keep model identifiers and important restrictions available in text too.
For all these cases, leave a way to ask for help. A contact link is more useful when it explains what information to include. Requiring someone to read the entire help centre before speaking to a person adds work to the customer's task.
Make the FAQ easy to find and use
A short set of questions can be an ordinary list. Expandable answers help when displaying everything makes the page cumbersome. However, an essential price, exclusion or purchase condition should not be available only inside a collapsed panel.
For a larger collection, group questions by recognisable tasks such as payment, delivery or preparing for the work. Internal department names are less useful to someone unfamiliar with the organisation.
Search can help in a substantial help centre; a small FAQ may not need it. If you add search, test actual customer phrases and alternative wording. People should not have to guess the exact heading to find an answer. Give them a clear contact route when a search returns nothing useful.
Before launch, check that:
- a phone user can find a topic without scanning the entire collection;
- questions can be opened with a keyboard and the focused control is visible;
- a screen reader user can identify whether an expandable answer is open;
- tables and images remain usable on a narrow screen;
- a particular answer has a link that someone can share;
- links lead to the relevant resource rather than the support homepage.
Ask someone to complete a concrete task: check whether their address is covered or find what is needed for an estimate. Watch where they look and what remains unclear. This gives you more to work with than asking whether they like the FAQ's appearance.
What an FAQ can do for search
Customer questions can reveal subjects your website should cover. Writing in question-and-answer format does not itself guarantee rankings. A detailed explanation may deserve its own article, while a small clarification belongs on the service page it describes.
Avoid filling the page with near-identical keyword variations. "What does installation cost?" and "What is the installation price?" do not need duplicate answers. The difference between a standard installation and a more complicated job is a useful distinction to explain.
Be careful with older advice about structured data. Google stopped showing FAQ rich results on May 7, 2026, and removed the feature's documentation in June. Adding FAQ markup should no longer be sold as a way to obtain expandable questions beneath a Google search result.
That change concerns Google's search presentation, not whether customers benefit from answers on a website. Judge the work by the information it provides and how people use it, rather than by the presence of a special search feature.
Check the outcome and keep the answers current
Record the problem before editing the page. Suppose people requesting an estimate don't know which materials to send, and someone has to request them in every reply. The relevant question is whether enquiries become more complete, not simply whether the FAQ gets views.
Start with one page and a few related questions if that makes the work manageable. Keep the original copy, note the change date and choose what to compare:
- enquiries about the selected topic relative to relevant visits or orders;
- the share of enquiries containing the information needed to proceed;
- follow-up exchanges needed to clarify an enquiry;
- searches that fail to find an answer and customer feedback;
- completion of the intended action, such as an enquiry, booking or purchase.
Opening an answer indicates interest, not necessarily that it helped. No click is ambiguous too: the visitor may have found the information in the main description or missed the FAQ entirely. A "Was this helpful?" control adds feedback, but only from the people who choose to respond.
Compare reasonably similar periods and account for changes in traffic, advertising and the offer itself. Fewer enquiries alongside fewer visitors are not evidence of a successful FAQ. More enquiries arriving with the required details are closer to the original goal, though a before-and-after comparison alone cannot attribute the entire change to the copy.
Assign someone to maintain answers that can change. Prices, lead times, coverage and delivery terms need checking when the underlying conditions change, not only during a periodic content review. Staff should know where to report a mismatch between the website and what they tell customers.
Choose one question your business explains repeatedly. Find where it arises, place a sufficient answer there and check whether a visitor can continue without unnecessary searching. That improvement may need only a change to an existing page, not a new section or a website rebuild.
