- Source questions from sales calls, enquiry emails and Search Console, not from guesswork.
- Group questions by topic and answer each one directly in the first sentence.
- Put service-specific FAQs on the service page too; the FAQ page shouldn't be the only place answers live.
- Google stopped showing FAQ rich results in 2026, so write FAQs for people, not for a search feature.
What an FAQ page is for
An FAQ (frequently asked questions) page collects short, direct answers to the questions people ask before they buy from you. Done well, it removes the doubts that stop someone getting in touch, cuts repetitive emails and calls, and gives search engines and AI assistants clear answers to quote.
Done badly, it's a dumping ground of questions nobody asks ("Why choose us?") with answers that sound like a brochure. The difference is where the questions come from.
How to create an FAQ page
1. Collect real questions
Look where your buyers already ask questions:
- Sales and customer service: ask colleagues for the ten questions they answer most often.
- Enquiry emails and chat logs: the questions people ask before committing.
- Search Console: the Performance report's queries often include questions ("how much does…", "do you…", "can I…").
- Google's "People also ask" boxes for your main services.
- Reviews: what customers mention as a worry they had at the start.
2. Choose and group them
Keep questions that are genuinely common and that affect the decision to get in touch. Then group them under headings, for example: Pricing and contracts, How it works, Getting started, Support, Security and compliance.
3. Write direct answers
- Answer in the first sentence. "Yes, we support firms across [region], with on-site visits within four hours." Then add detail.
- Keep answers short: usually two to four sentences. If an answer needs a page, link to a guide or service page.
- Use the customer's words in the question, not internal jargon.
- Be specific and honest. If the answer is "it depends", say what it depends on.
- Link onwards to the relevant service page, guide or contact page.
4. End with a way to ask more
Finish with "Didn't find your answer?" and a direct contact option: a phone number, an email address, or a link to the contact form. See our guide to the contact us page.
FAQ page design
| Element | Good practice |
|---|---|
| Layout | Grouped sections with clear headings; a short list of section links at the top for long pages |
| Questions | Written as the customer would ask them |
| Expand/collapse (accordions) | Useful for long pages, but make them keyboard accessible and keep the text in the page's HTML so search engines can read it |
| Search | Worth adding only for very long FAQ pages |
| Contact prompt | Visible at the end, and optionally at the top |
| Mobile | Large tap areas for each question; no tiny icons |
FAQ page examples by business type
| Business | Sections that work | Example questions |
|---|---|---|
| IT support provider | Pricing; onboarding; support hours; security | "What's included in the monthly fee?" "How quickly do you respond?" "Can you take over from our current provider?" |
| Manufacturer | Ordering; lead times; quality; delivery | "What's your minimum order quantity?" "Which certifications do you hold?" "Do you deliver internationally?" |
| Law firm | Fees; process; first meeting | "How are your fees calculated?" "What should I bring to the first meeting?" "How long does it usually take?" |
| Training provider | Booking; format; certificates; funding | "Can you run the course on-site?" "Do delegates get a certificate?" "What happens if I need to cancel?" |
| Care provider or school | Admissions; costs; visits; daily life | "Can we visit before deciding?" "What's included in the fees?" "How do you communicate with families?" |
FAQ page or FAQs on each page?
Both, used differently:
- Service pages should answer the questions specific to that service, near the call to action. See services page.
- The FAQ page covers questions that apply across your business: contracts, process, coverage, how to get started.
Don't duplicate the same long answers in both places. Keep the full answer in one place and link to it.
What FAQ schema does now
FAQ schema (FAQPage structured data) is code that marks up questions and answers so search engines can read them as pairs. For several years it could earn expandable FAQ results under your Google listing.
That has changed. Google limited FAQ rich results to well-known, authoritative government and health websites in August 2023, and from May 2026 FAQ rich results stopped appearing in Google Search altogether.
What that means for you:
- Don't add FAQs to pages just to chase a search feature. Add them where they help readers.
- Existing FAQ schema does no harm. It's still valid Schema.org markup, and other search engines and AI tools can read it. Keep it if you have it, but it's no longer a priority.
- Clear question-and-answer content still helps. Direct answers to real questions are exactly what search engines and AI assistants look for when choosing what to show or cite.
Questions
How do I create an FAQ page?
Collect real questions from sales, enquiry emails and Search Console, group them by topic, write a direct answer to each in two to four sentences, link to deeper pages where needed, and end with a way to contact you.
How many questions should an FAQ page have?
As many as are genuinely common and useful, often 10 to 30 for a small business, grouped into sections. Fewer, better answers beat a long list of filler.
Does an FAQ page help SEO?
It can, by answering questions people search for and giving search engines clear answers to understand and quote. It won't earn FAQ rich results in Google any more, so write it for readers first.
Is FAQ schema still worth adding?
It's low priority. Google no longer shows FAQ rich results, but the markup is harmless and other search engines and tools can still read it. Don't add it to pages that don't have genuine FAQs.
Should FAQ answers be hidden in accordions?
Accordions are fine for long pages, as long as they work with a keyboard and screen reader and the text is in the page's HTML rather than loaded later.
Every guide is checked against the platform it describes before it’s published, and re-checked when the platform changes.