FAQ pages: the questions we get asked most

It is rarely the thing that gets a project approved, and often the thing that decides how it goes. The questions about FAQ pages that come up most often on our calls.

Pages that answer a real question outlive pages written to fill a slot in a sitemap. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

Do we need to care about this?

Answer the questions sales actually gets asked. Small and consistent beats large and occasional here. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. None of that requires a large budget, only a decision and someone to own it.

How do we know it is working?

Well-structured FAQs can win rich results. The cost of getting this wrong is rarely visible on the day it happens. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

What this looks like day to day

Writing for the web is largely an editing job: the first draft is always longer than it needs to be. Three things worth confirming about FAQ pages before you move on:

• Someone can say what the current setup is without going to look
• Do not use it to hide bad news — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you are not sure where your systems currently stand on this, it takes us about an hour to find out.