“What makes us different?” and “Why choose our platform?” aren’t FAQs. They’re marketing copy wearing a question mark.
Meanwhile, the customer trying to find out whether they can return an item after 30 days or why they were charged twice can’t find the answer. They open a support ticket and leave frustrated. The page missed its job. Search misses it too, because nobody searches for those marketing questions.
A good FAQ page does two things: it helps customers resolve questions without contacting support, and it makes those answers easy to find in search and AI assistants. This guide covers how to write effective FAQ pages, structure answers, use FAQ schema correctly, and avoid the mistakes that make FAQ pages useless.
Key takeaways
- An FAQ page has two jobs: help a customer resolve a question without contacting you, and be findable when that question is typed into a search bar or an AI assistant. Write for both or you serve neither.
- The goal is not to list every question you can think of. It is to answer the handful of questions customers actually ask, in the words they use, before those questions become tickets.
- FAQ schema no longer earns a rich result. Google restricted FAQ rich results to authoritative government and health sites in 2023, then removed the feature for everyone in May 2026. Add schema for machine-readability, not for a decorated search listing.
- Answer first. Put the direct answer in the first sentence or two, then the detail, then a link to the deeper doc. A buried answer sends the reader to your contact form.
- FAQ pages go stale faster than almost any other page. A wrong answer is worse than a missing one, because it teaches the customer that the page lies.
What is an FAQ page?
An FAQ page answers the questions customers ask most often, using the words customers actually use. Those two constraints do most of the work. A page answering rare questions—or common ones phrased in internal jargon—is an FAQ page in layout only.
It isn’t the same as a knowledge base. Think of the FAQ as the shortlist and the knowledge base as the library. The FAQ answers the most common questions in two or three sentences, then links to the full article when someone needs more detail. The knowledge base holds those detailed articles and procedures. Building a scalable internal knowledge base is its own discipline.
Every FAQ page has two audiences: the customer looking for a quick answer and the search engine or AI assistant deciding whether to surface it. Both reward the same thing: a clear question followed by a direct answer.
SEO benefits of FAQ pages
Let’s address the biggest misconception first: “FAQ schema doesn’t get you rich results anymore, so FAQ pages are outdated.”
The first half is true. Google restricted FAQ rich results to authoritative government and health sites in 2023, then removed the feature for everyone in May 2026. FAQPage schema no longer changes how your search listing looks, so anyone still selling it that way is working from an outdated playbook.
The second half doesn’t follow. FAQ pages still provide SEO value for three reasons:
- They capture the questions people actually search. Search has shifted toward conversational queries like “Can I…?”, “How do I…?”, and “Why was I charged…?” An FAQ written in the customer’s language is often the closest match to those searches.
- They give answer engines something easy to quote. AI Overviews and assistants look for pages that ask a clear question and answer it directly. A well-written FAQ already follows that format.
- They strengthen internal linking. Each answer can point to a deeper guide, policy, or product page, helping readers find the next step while strengthening your site’s structure.
FAQ SEO is no longer about winning a rich result. It is about being the clearest answer to a real question. Write for customers first, not crawlers. Clear, direct answers work better for both.
A found answer is also a deflected support ticket. The internal side of that story, helping your own team answer fewer repeat questions, is covered in how better internal documentation reduces support tickets.
How to write FAQ questions and answers
Your questions should come from customers, not a brainstorming session.
Use the customer’s language. Mine support tickets, live-chat transcripts, site search, and “no results” queries. Write the question the way someone types it at 11 p.m., not the way your product team describes it. “Why was I charged twice?” beats “Understanding duplicate transaction events.”
One question per entry. Don’t bundle multiple questions into one answer. Each entry should answer one question clearly.
Answer first, then add detail. Put the direct answer in the first sentence or two. Anyone who only needs the yes or no gets it immediately. Everyone else can keep reading.
Keep it short and link deeper. Aim for two to four sentences. If the full answer is a ten-step process, summarize it here and link to the complete guide.
Order by frequency. Put the questions customers ask most at the top. Alphabetical order looks tidy but often buries the answers most people came for.
Answer honestly. If the answer is “No, we don’t offer refunds after 30 days,” say so. Dodging difficult questions sends customers straight to your support queue.
Compare these two versions:
Marketing version: “What is our industry-leading return policy?”
Customer version: “Can I return an item after 30 days?”
The second question matches how people actually think and search. That’s the difference between an FAQ that gets used and one that gets ignored.
Good FAQ pages respect the customer’s language instead of making them learn yours. Building the habit of checking those answers before opening a ticket is a separate challenge, which we cover in how to build a self-service culture inside your organization.
FAQ schema markup best practices
FAQPage schema is structured data that labels each question and answer so search engines and AI systems can read them more accurately. It is still worth adding, even though Google removed FAQ rich results in May 2026. Schema improves machine readability, not how your search listing looks.
Follow a few simple rules:
- Mark up only genuine, visible Q&A. The schema should match exactly what users see on the page. Don’t add markup for hidden questions, and don’t let the schema differ from the visible answer. Search engines may ignore structured data that doesn’t match the page.
- Use FAQPage only for real FAQ pages. Don’t add FAQ schema to product or marketing pages with a token question.
- Don’t stuff keywords into the markup. Write answers for people, not search engines.
- Skip promotional questions. “Why are we the best?” doesn’t belong in your FAQ or its schema.
- Keep the schema in sync. Whenever you update an answer on the page, update the markup too.
A minimal FAQPage entry looks like this:
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [{
"@type": "Question",
"name": "Can I return an item after 30 days?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Most items, no. Within 30 days of delivery you get a full refund; after that we offer store credit on unused items with tags for up to 90 days."
}
}]
}
That is the basic structure: one FAQPage containing one or more Question items, each with an acceptedAnswer. Whether your CMS, plugin, or custom code generates it doesn’t matter. The important part is that the markup always matches the visible content.
Schema.org still defines the FAQPage type, and Google's general structured-data policies still apply, so check both when you implement. Just remember that valid FAQ markup no longer produces a Google rich result.
FAQ page examples
The best FAQ pages answer the questions that generate the most support contacts. Two common examples are e-commerce returns and SaaS billing.
An e-commerce returns FAQ answers questions customers ask every day: “Can I return an item after 30 days?” “How long do refunds take?” “Do I pay for return shipping?” “What if my item arrived damaged?” Each answer starts with the direct response, includes the key details or numbers, then links to the full return policy for edge cases. No brand story or marketing language. Someone with a broken blender wants to know what to do, not how much you value customer satisfaction.
A SaaS billing FAQ tackles high-stakes questions like “Why was I charged twice this month?” “How do I update my card?” “What happens if I downgrade?” and “Can I get a refund?” The answers are specific and transparent. Explain the charge, link to the relevant settings or policy, and be honest about limitations. A customer who knows they won’t get a partial refund may still cancel, but they won’t feel misled.
Both examples follow the same pattern: real customer questions, a direct answer first, specific details where they matter, and a link to the longer explanation when needed. They answer the questions customers actually ask, not the ones the company wishes they would.
Common FAQ mistakes
Each mistake below is one of the practices above, skipped.
- Writing the questions you wish people asked. The fake question, "What makes us different?", is the original sin of FAQ pages. It fails both jobs at once: no customer has that question, and no search matches it. Every fake question is a slot a real one should have filled.
- Burying the answer. An entry that opens with three sentences of context before the answer loses the reader who only needed the answer. If they have to dig, they contact you instead, which is the exact outcome the page existed to prevent.
- Ignoring how people search. A page written in internal jargon ("duplicate transaction events") matches none of the queries customers actually type ("why was I charged twice"). Align to their phrasing, or the page ranks and gets quoted for nothing.
- Letting it go stale. FAQ pages rot faster than most, because they answer specific, changeable things: prices, windows, steps, policies. A wrong answer is worse than a missing one, because it teaches the customer that the page cannot be trusted, and they stop coming back. When a whole library has decayed to the point that nobody believes it, that is a governance problem, and we treat it separately in why most company wikis fail and how to fix them.
- Turning it into a dumping ground. Two hundred uncurated questions is not thoroughness, it is a place answers go to hide. Answer the twenty or so questions that drive most of your contacts, and answer them well.
- Stuffing the schema. Markup that does not match the page, or that exists only to chase a rich result you will not get, is effort spent looking dated. Mark up the real answers, or none.
The FAQ page you write for search ranks for nothing; the one you write for the confused customer at 11pm is the one search ends up quoting. Answer the real question, in real words, keep the answer true, and both jobs take care of themselves.
FAQ
What is the difference between an FAQ page and a knowledge base?
An FAQ page answers the most common questions in short, direct entries using the customer’s own words. A knowledge base is the larger library of detailed articles and procedures those answers link to. The FAQ is the shortlist; the knowledge base is the shelves behind it. As your content grows, the FAQ becomes the front door to the knowledge base.
Do FAQ pages still help SEO?
Yes, though not for the reason they used to. FAQ pages no longer earn rich results, but they capture long-tail question searches, match the way people actually ask questions, and give search engines and AI assistants clear question-and-answer pairs to surface. The value is in being the clearest answer to a real question.
Does FAQ schema still get rich results?
No. Google restricted FAQ rich results to authoritative government and health sites in 2023, then removed the feature entirely in May 2026. You can still add FAQPage schema to help search engines and AI systems understand your content, but it will not change how your search listing looks.
How many questions should an FAQ page have?
As many as you have genuinely common questions, and no more. For most pages, that means somewhere between ten and thirty. A focused page people trust beats an exhaustive one they scroll past. When a topic needs more depth, link to a dedicated article.
How do I know which questions to put on my FAQ page?
Use your own data. Support tickets, live chat, site search, and search queries all show what customers actually want to know. Answer the most common questions first, using the same language your customers use.
What makes a good FAQ page?
A good FAQ page answers the questions customers actually ask, using the words they use. Put the answer first, keep each entry focused on one question, and link to more detailed documentation when needed. The best FAQ pages help customers find the answer without contacting support.
