FAQ Pages That Actually Help

When an FAQ helps and when it hides content

Nielsen Norman Group's article FAQs Still Deliver Great Value (Susan Farrell, 2014) argues that a well-run FAQ helps visitors and the business. If people "have questions before they can buy what you're selling", answering the common ones on the site can save you emails and calls. It also notes that "many people already know to look for an FAQ when they need a fast answer", and that site search alone is "rarely enough", because your words and your visitors' words often differ.

The UK government takes the opposite line for its own site. The GOV.UK style guide says: "Do not use FAQs on GOV.UK. If you write content by starting with user needs, you will not need to use FAQs."

For a business website, the two views fit together:

• An FAQ helps when it collects short, separate questions that come up again and again: how a first meeting works, who owns the finished work, which areas you cover, how payment is handled.
• An FAQ hides content when it holds things every visitor needs, such as what a service includes, the main steps of a project or the key terms. Those belong on the service page itself, where people already are. If nearly every visitor would need an answer, it is not an FAQ item.
• An FAQ is a warning sign when the same question keeps arriving because a page or form is confusing. NN/g suggests using questions "as clues" to problems elsewhere and fixing the cause, not only adding an answer.

Choosing the questions

The commonest mistake is inventing questions. NN/g calls made-up questions a "bad practice" it has long warned against, and puts it simply: "If you're listening to your users, you know what their questions are."

Good places to find real questions:

• enquiry emails, contact form messages and call notes from the last few months;
• questions your sales or project staff answer before every job (NN/g says your salespeople "can probably dictate the FAQs you need to publish");
• your site search log, if you have one, and the search queries in Google Search Console;
• questions customers leave on your Google Business Profile or in reviews.

Write each question in the visitor's words, not your internal terms. NN/g puts it this way: "People don't search for your solution, they search for their problem." Questions phrased the way people type them are easier to find.

Leave out questions that are really adverts ("Why are we the best choice?"). They waste the reader's time and make the real answers less believable. Our guide to the content you need before a website build covers gathering this material early.

Writing the answers

NN/g lists the questions a reader is quietly asking while reading an FAQ, including: "Are the answers written in clear, grammatical language?", "Do the answers seem factual and frank or more like marketing hype?" and "Does the FAQ openly acknowledge the problems or limitations that everyone knows about?"

In practice:

• Answer first. Start with "Yes", "No" or the direct fact, then add the detail.
• Keep each answer to one question. If an answer needs several paragraphs, steps or a table, give it its own page and link to it.
• Be honest about limits. If you do not offer something, say so and, where you can, point to someone who does. NN/g notes that linking to good outside sources can make an organisation "seem more helpful and credible".
• Link to the main page that covers the topic in full, so the FAQ does not become a second copy of your site.
• Give a way out. End the page with a clear way to ask a question that is not listed.

Our guide to writing website copy people read has more on plain, scannable writing.

Layout: one list, topic groups or separate pages

NN/g says the traditional "question list followed by the individual questions and answers" is still the best design for short and medium-length FAQs. For longer FAQs, or answers with screenshots or several options, "a separate list of questions that lead to answer pages (or topic pages) works best".

• Group questions by topic once you have more than a handful, so people can "rule out most of the topics quickly", in NN/g's words.
• Make questions visually distinct from answers, for example as headings, so the page can be scanned.
• Put a few short, page-specific questions at the bottom of a service page rather than sending people to a separate FAQ page for them.
• Link to the FAQ from the footer or a help menu, as NN/g suggests, and from the pages where the questions arise. Our guide to planning website navigation covers where such links go.

Accordions and accessibility

Many FAQ pages show only the questions and open each answer on a click. This is an accordion. NN/g's Accordions on Desktop: When and How to Use (2023) names "FAQ pages and product-detail sections" as good candidates, because each answer is independent and people only need a few of them.

The same article lists the costs:

• "Valuable content that is hidden under an accordion may be missed altogether", especially if the heading is vague.
• If people need information from most sections, "it is better to display all the content at once (even if it results in a longer page)".
• Accordions that close one panel when another opens stop people comparing answers.
• With only a little content, accordions "will make the page look mostly empty".

An earlier NN/g article, Accordions Are Not Always the Answer for Complex Content on Desktops (2014), adds: "It is easier to scroll down the page than to decide which heading to click on." With five or six short answers, simply showing them all is often better.

If you use an accordion, build it so everyone can use it. The W3C ARIA Authoring Practices accordion pattern describes each header as a button inside a heading, with aria-expanded set to true or false so screen readers announce whether it is open, and Enter or Space to open and close it. The HTML <details> element gives a simpler built-in "disclosure widget"; MDN explains that giving several of them the same name lets only one be open at a time, which is the auto-closing behaviour NN/g warns about, so leave name off for FAQs. Our website accessibility basics guide covers keyboard and screen reader testing.

FAQ pages and Google

For years, adding FAQPage structured data could make questions appear under a page in Google results. That is over:

• In August 2023 Google's post Changes to HowTo and FAQ rich results said FAQ rich results would "only be shown for well-known, authoritative government and health websites".
• Google's documentation changelog says the FAQ rich result "will no longer appear in Google Search starting May 7, 2026", and its documentation has since been removed.

The 2023 post added that "there's no need to proactively remove" the markup, and: "Structured data that's not being used does not cause problems for Search." So existing FAQ markup can stay, but an FAQ page now has to earn its place by helping visitors.

Do not write FAQs just to catch searches. Google's guide to creating helpful, reliable, people-first content lists warning signs, including content "primarily made to attract visits from search engines" and pages that promise "to answer a question that actually has no answer". Our guides to helpful content for business websites and structured data go further.

Keeping answers current

An out-of-date answer is worse than none: it tells people something you no longer do, and they may act on it. NN/g lists "How fresh is the latest information?" among the things visitors weigh up, and recommends treating the FAQ as part of a process, not a page written once.

• Give it an owner. One person checks the FAQ when services, policies or contact details change.
• Review it on a schedule, for example with the yearly checks in our website maintenance checklist.
• Feed it from real questions. When a new question arrives several times, add it; when one stops coming, consider removing it.
• Keep markup in step. If your FAQ has structured data, the marked-up text should match what visitors see.
• Do not fake freshness. Google's helpful content guide lists "changing the date of pages to make them seem fresh when the content has not substantially changed" as a warning sign.

A checklist

• Every question came from a real customer, enquiry or staff member.
• Nothing every visitor needs is only in the FAQ; it is on the main pages too.
• Each answer starts with the direct answer and links to the full page.
• Accordions are used only where they help, work by keyboard and announce their state.
• The page is not there just for search traffic or rich results.
• One person owns the FAQ and reviews it on a set schedule.
• There is a clear way to ask a question that is not listed.

Frequently asked questions

Does every business website need an FAQ page?

No. If people keep asking the same short questions, an FAQ can answer them. If the answers are things every visitor needs, such as what a service includes, put them on the main pages instead. GOV.UK does not use FAQs at all for that reason.

How many questions should an FAQ have?

As many as people really ask, and no more. A few questions can sit at the bottom of a service page. When the list grows, group it by topic, and give long answers their own pages.

Should FAQ answers be hidden in an accordion?

Only if people need a few answers out of many. Nielsen Norman Group names FAQ pages as a good use of accordions, but warns that hidden content can be missed. With a handful of short answers, showing them all is usually better.

Does FAQ schema still show in Google results?

No. Google limited FAQ rich results to authoritative government and health sites in 2023, and its documentation changelog says the feature no longer appears in Google Search from 7 May 2026. Existing markup does no harm and does not need removing.

How often should we update our FAQ?

Whenever a service, price, policy or contact detail it mentions changes, and on a regular review, for example once a year. Add questions that keep coming in and remove ones nobody asks any more.

Planning a new website? Whoever builds it, the domain and your content should always be in your name, and our projects end with a short handover so your team can edit content. See our website development service and all our services, or email [email protected].