FAQ Page Design: How to Build Accordions, Search and Categories

In this guide, Talha Aslan and team walk through the method we use on web design projects, step by step. The job is not only visual layout. Question selection, information architecture, accessibility, deep linking, and search engines all play a part. The examples are not real client cases; they are example scenarios that make the ideas concrete.

Why does a FAQ page still matter?

When visitors research a service or a product, they rarely pick up the phone to ask a small question. If they cannot find the answer, they close the tab. Therefore a well planned FAQ page keeps the answers your sales team repeats every day ready on the site. Visitors find them at midnight, and your team stops typing the same explanation again and again.

On the other hand, a FAQ page is not a junk drawer. If you dump everything that does not fit on a service page into it, visitors get lost. Its real job has three parts:

• Remove doubts before a decision, such as delivery time, returns, or payment options.
• Reduce repeat questions that reach your support team.
• Send visitors back to the right service or product page.

In short, a FAQ page supports the rest of the site. It does not replace a service page; it backs it up.

Where should you collect FAQ questions from?

The most common mistake is to invent questions at a desk. For example, nobody really asks "Why should you choose us?" Your team, however, hears the real questions every day. So the first step is to trust their ears instead of guessing. Sales reps, support staff, and even delivery drivers can bring you very useful questions.

We suggest building the question pool from these sources:

1. Questions your sales team hears in pre-quote calls.
2. Support emails and live chat transcripts.
3. Repeat requests that come through WhatsApp or the phone.
4. Site search terms that return no results.
5. Reasons customers give for returns or cancellations.

For example, in an example scenario for a furniture store, the most frequent question turns out to be "Do you take custom size orders?" No marketing meeting would come up with that. Still, it shows up in support logs every single week. That is exactly the kind of question a FAQ page exists for.

After you collect the questions, merge the duplicates. Turn five tickets that ask the same thing in different words into one question. However, keep a note of the different phrases people use. Those phrases become the synonym list for your search box later.

Which questions should stay off the FAQ page?

Not every question deserves a spot. Some need their own page, and some should not appear at all. If you sort this out early, the page stays clean.

• Topics that need long explanations: move them to a guide page and give a short summary with a link.
• Personal situations: link questions like "Where is my order?" to the account area or the support form.
• Changing details: keep things like campaign terms in one single source.
• Marketing slogans dressed up as questions: they hurt reader trust.

Also, pick one source of truth for answers that involve legal or technical detail. For instance, if return terms differ between the FAQ and the returns page, visitors do not know which one to trust. So the FAQ answer gives a short summary and links to the main page for details.

How many questions should you include, and in what order?

There is no fixed number; the scope of the site decides it. A small business with one service may need only ten to fifteen questions. A multi-category online store can easily pass a hundred. These ranges are a starting point from field experience, not a rule.

For order, we follow two principles. First, frequency: the most asked questions go to the top of each category. Second, decision order: a visitor first wonders "Is this right for me?", then "How long will it take?", and finally "How do I pay?" As a result, ordering questions along that line makes reading feel natural.

Also, watch the wording. Write each question in the user's own words. For example, "How many days until my order arrives?" works better than "Our delivery policy" for both readability and site search.

How do you structure FAQ page categories?

Once you pass a few dozen questions, categories become essential. Group them by the topics in the visitor's head, not by your org chart. In other words, "Payments and invoices" is clearer than "Accounting".

In an example scenario for a service company, we would suggest these categories:

• Scope and fit of the service.
• Process and delivery time.
• Payment, invoices, and contracts.
• Support, maintenance, and warranty.
• Account and privacy.

We usually keep between four and eight categories. More makes choosing harder, while fewer makes each one bloated. In addition, a short description line under each category helps visitors find the right section fast. If a question fits two categories, place it in one and link to it from the other; never write the same answer twice.

In practice, keep category names short and consider showing the question count next to each one. That way, visitors see at a glance which section is the largest. Category order matters as well, so put the most visited topic first.

Should category navigation use tabs or a list?

There are a few patterns for moving between categories. The right one depends on question count and device. The table below sums up the options we compare on projects.

Our default choice is often a single page with headed sections. That is because the browser's own find-in-page feature works across all of the text. On the other hand, content inside hidden tabs may not show up in that search, which is a real drawback.

Should your FAQ page have a search box?

If you have more than about thirty questions, think seriously about search. Visitors want to type the question in their own words; browsing a category tree feels like plan B. We cover the general value of on-site search in our article on why site search matters for UX and conversions. Here we only look at points specific to a FAQ.

• Put the search box at the very top, right under the heading.
• Filter results as people type, so nobody needs a separate results page.
• Add synonyms, so "return", "send back", and "exchange" lead to the same answer.
• When nothing matches, show a contact option and popular questions instead of an empty screen.

Also, log searches that return nothing. That list is the most honest source for the questions you should add next month. That way, the page turns into a system that feeds itself.

In the results, show the question together with the first sentence of the answer. Visitors often read the answer before they even click, so this saves time. Highlighting the search term in the results also helps them spot the right question faster.

Does an accordion or an open list work better?

An accordion shows only question headings and reveals each answer on click. It makes long lists easy to scan. However, it is not always the right choice.

Nielsen Norman Group's writing on accordions points to the same balance: accordions help when users need only part of the content. If most readers will read every answer, collapsed panels just add clicks.

Our practical rule looks like this:

• Few questions that everyone will read: use an open list.
• Many questions, each relevant to different people: use an accordion.
• A long page on mobile: an accordion usually cuts scrolling a lot.

That said, an "expand all" button is a good compromise. Visitors who want to read or print every answer can do it in one click.

What makes a FAQ accordion accessible?

An accordion looks simple, but when you build it wrong, it becomes useless for screen reader and keyboard users. The W3C ARIA Authoring Practices accordion pattern is the official reference we rely on.

At a concept level, the core rules are these:

1. Each question heading should be a real button; clickable text alone is not enough.
2. The button should report whether its panel is open or closed through the aria-expanded attribute.
3. Next, it should point to the panel it controls with aria-controls.
4. Also, it should sit inside a heading element, so screen reader users can jump between headings.
5. The Enter and Space keys should open and close the panel.

Also, never remove the focus indicator. Keyboard users need to see which question has focus. For the wider framework, see our guide to web accessibility and WCAG standards.

Which accordion design details make a difference?

Once the accessibility base is in place, small visual choices shape the experience. These are the details we fix most often on projects:

• Toggle icon: use plus and minus or a down arrow, and switch it with the state.
• Click area: make the whole row clickable, not only the tiny icon.
• Touch target on mobile: leave enough height for a thumb.
• Animation: keep it short, and skip it for users who turned on reduced motion.
• Contrast: question text and background should meet the WCAG threshold.

Next, decide on the one-panel rule. Some accordions close the open panel when another one opens. That annoys people who compare answers. For example, someone who wants to read the delivery times of two packages side by side will not enjoy one closing the other. So we usually let several panels stay open.

Another detail is the loading moment. If panels flash open and then close as the page loads, the screen jumps. Send the collapsed state from the start. Finally, remember links and lists inside answers. An answer does not have to be a plain paragraph; a numbered list makes step-by-step answers easier to read.

How should you write FAQ answers?

Put simply, good design cannot rescue bad copy. Our rule for answers is simple: the first sentence answers the question directly. Conditions and details come after that, if needed.

For example, answering "Is shipping free?" with "Shipping is free on orders above a set cart value; you can check the current threshold on the shipping page" beats two paragraphs of generic intro. That way, the reader gets the answer in the first line.

• Keep answers around 40 to 80 words; if one grows longer, move it to its own page.
• Use the customer's words instead of corporate jargon.
• Do not bury numbers that change inside the FAQ; link to the main page instead.
• When useful, end each answer with one clear link to the related page.

We cover the general principles of microcopy in our UX writing guide. FAQ answers are one of the places where those principles matter most.

Why should every question have a deep link?

A deep link is an address that goes straight to one specific question. When your support team replies to a customer, they want to send that exact question, not the whole FAQ page. Therefore give each question a unique ID and URL fragment.

Conceptually, it works like this: if the address ends with a question ID, the page scrolls to that question and opens its panel on load. Moreover, a small "copy link" button next to each question makes life much easier for your team.

• Make IDs readable: a short version of the question, not a random number.
• Keep the ID even when you edit the question text, so old links keep working.
• If you use one page per category, keep the URL structure stable.

In an example scenario, a software company that starts adding question links to support emails no longer writes a long reply to the same question each time. Also, when you update the answer, every old email link shows the current information.

Deep links help in one more way. When you reply to a question in social media comments or customer messages, you can share the same address. As a result, one correct answer stays the same across every channel, and different people on your team stop giving different explanations.

Should we build your FAQ page for you?

The structure above looks simple on paper, but in practice it takes many small decisions. Building the question pool, shaping the category tree, coding an accessible accordion, and setting up search are separate skills.

If you would like us to build this section on your site, our web design service plans the FAQ page together with your service and product pages. We run a short question gathering session with your sales and support team, and then we deliver the design and the code. To scope the work, simply fill in the quote request form.

Is FAQ schema still worth using?

FAQPage markup describes the question and answer pairs on a page in a machine readable way. For a while, many sites showed expandable FAQ rows in search results. However, Google narrowed that display.

According to Google's FAQPage documentation, FAQ rich results now appear only for well known, authoritative government and health websites. This scope can change, so check the current status in the documentation. We also look at the change in detail in our article on FAQ rich results and FAQPage schema.

So should you delete the markup? Our view is this: if the markup is correct and matches the content on the page exactly, it does no harm. Still, do not treat it as a traffic tactic. The real value of a FAQ page is the answer it gives visitors on your site. If you want to generate markup, you can use our schema generator tool.

How do you optimize a FAQ page for search engines?

Even without rich results, a FAQ page can earn search traffic, because people type questions into Google too. A few basic steps cover most of it:

• Keep questions as real text on the page; content that loads only on click is risky.
• Write the page title and description so they explain the scope of the FAQ.
• Use a clean heading order, such as categories as H2 and questions as H3.
• Do not copy the same question across several pages.

Also, do not worry about text hidden inside an accordion; if the content sits in the page code, search engines can read it. Specifically, the real problem appears when an answer loads from the server only after a click. So send the answers with the page and only toggle their visibility.

How do you link from a FAQ page to service pages?

A FAQ page should never be a dead end. After reading an answer, visitors should see the next step. That is why related answers need contextual links to service or product pages.

For example, the answer to "What does the maintenance plan include?" should link to the maintenance service page. Likewise, "Which payment methods do you accept?" should point to the payment page. Keep the anchor text clear: name the topic of the target page instead of writing "click here".

The reverse direction matters as well. Under each service page, you can add a short block of three to five questions about that service, plus a link to the full list. Then the two pages feed each other. We explain the logic of internal links in our internal linking strategy guide.

How should a FAQ page work on mobile?

A large share of visitors reach the FAQ from a phone, often in the middle of a task. So do not think of the mobile layout as a smaller copy of desktop.

• Show the search box on the first screen.
• If category tabs get squeezed into side scrolling, switch them to a select menu.
• Give question rows enough height so a thumb does not hit the wrong one.
• Keep paragraphs short in long answers.
• Add a "Did not find your answer?" block with a contact option at the bottom.

Also, when an opening panel pushes the page down, make sure users keep their place. For example, the heading of the opened question should stay at the top of the screen. This small detail cuts the feeling of getting lost in long lists.

Finally, do not forget page speed. A heavy search library or extra animation makes the page load slowly on mobile data. A FAQ page is a simple page, and its weight should match.

How does a FAQ page differ for online stores and service sites?

One template does not fit every site. On an online store, questions mostly focus on what happens after the order: shipping, returns, exchanges, and payment security. On a service site, questions cluster before the decision: scope, timing, process, and contract.

That difference shapes the design. Store visitors usually arrive with a problem and want a fast answer, so search and a shortcut to order tracking come first. Service visitors, by contrast, have not decided yet. Consequently, it makes more sense to place links back to service pages and a quote step between the questions.

• Online store: clear category split, order tracking shortcut, link to the returns page.
• Service site: questions about process steps, contextual links to service pages, a quote call to action.
• Software product: setup, account, and billing split, links to help center docs.

In an example scenario for a cleaning company, we would build the FAQ around service area, pricing logic, and the booking process. If you move the same structure to a clothing store, size, shipping, and return questions take the lead. In short, the type of questions sets the center of gravity for the design.

What are the most common FAQ page design mistakes?

In practice, we see the same mistakes again and again when we audit sites. Most come from adding the page at the last minute, not from bad intent. The list below covers the ones we see most:

1. Every question sits in one long accordion with no categories and no search.
2. Question headings are clickable text; keyboards and screen readers do not treat them as buttons.
3. Answers use company language and do not answer in the first sentence.
4. Questions have no individual links, so support has to send the whole page.
5. The FAQ link lives only in the footer in small type.
6. Visitors who do not find an answer see no way to get in touch.

What these mistakes share is a company view instead of a visitor view. However, fixing them rarely needs a full redesign. For instance, turning accordion headings into real buttons and adding categories already improves the experience a lot.

Also, include the FAQ page in your site's wider UX review. That way, you see issues in the context of the whole site, not one by one.

Where should the FAQ page live on your site?

First, even the best FAQ page is useless if nobody finds it. On many sites, the FAQ link sits only in the footer in small text. When visitors have a question, they do not hunt for it; they leave.

For this reason, we recommend several doors into the FAQ:

• A visible link in the main menu or under a support menu.
• A "check these questions first" block on the contact page, above the form.
• A short list of related questions under each service and product page.
• Small links to shipping and return questions in the cart and checkout steps.

On the other hand, do not hide the contact form behind the FAQ. If visitors cannot find an answer, they should still reach you. The goal is not to block questions but to give the answer by the shortest path. As a result, visitors stay happy, and your team receives only the requests that truly need a personal touch.

How do you measure whether your FAQ page works?

Without measurement after launch, you cannot tell whether the page really reduces questions. You do not need a complex dashboard; a few signals are enough.

• Which questions do visitors open most? Track accordion opens as events.
• Which site search terms return no results?
• Where do visitors go after the FAQ: a service page, contact, or exit?
• Have repeat questions to the support team dropped?

In an example scenario, the most opened question is one that the service page should answer. Then moving the answer onto the service page as well helps conversions. In short, FAQ data is a roadmap for the rest of the site too.

We suggest reviewing the results as a team every quarter. A single month of data can mislead, because campaigns or seasons shift the mix of questions. A longer window shows the real trend.

How often should you update a FAQ page?

Above all, a FAQ page is not something you write once and forget. Products change, processes change, and questions change. We recommend a regular review schedule to our clients; set the frequency based on how fast your site changes.

At each review, ask a few questions. Is any answer out of date? Is there a question nobody asks anymore? Has a new wave of questions reached support? If you remove an old question that people still link to, consider sending its deep link to a close match.

Also, name an owner. A FAQ page without an owner fills up with conflicting answers over time. For example, when the return window changes, the FAQ, the returns page, and the service page should all change on the same day.

What is the FAQ page checklist?

We use the list below before launch. Each item maps to a decision in this guide:

1. You collected questions from sales and support logs.
2. You removed marketing slogans posing as questions.
3. You grouped categories by the user's topics.
4. If you have many questions, search and synonyms are ready.
5. The accordion uses real buttons and aria-expanded.
6. You tried opening and closing with the keyboard and checked the focus indicator.
7. Every question has a permanent deep link.
8. Answers respond directly in the first sentence.
9. Related answers link to service and product pages.
10. If you use schema markup, it matches the page content exactly.
11. On mobile, search and questions are reachable on the first screen.
12. An owner and an update schedule exist.

Your own team can work through this list. However, if you want the page built in a design language that matches the rest of your site, request a quote for our web design service, and we will plan and deliver the FAQ section together with your service pages.