The FAQ inventory. How to harvest the questions buyers actually ask.

Why FAQ blocks matter more than they look like they should

AI engines retrieve answers, not pages. When a buyer asks one of the eight engines a question that touches your category, the engine prefers to cite a source that already contains the question phrased the way the buyer asks it, followed by a clean answer in plain language. That preference is structural. A page with a question-and-answer pair that matches the buyer's prompt gets weighted higher than a page that contains the same information buried inside a paragraph of marketing prose. The difference is large enough that we treat FAQ inventory as a separate stage with its own discipline.

The other reason FAQ blocks matter is that they are cheap. The work is owner-readable, the publishing tools are already in place on every Squarespace, Wix, WordPress, and custom site we audit, and the gain is visible inside one full crawl cycle, which is usually a week or two. There is no faster low-cost lever in the program.

Where the questions actually come from

We pull buyer questions from three sources, in order of signal strength.

Source one. Your own inbox and phone log.

This is the highest-signal source and the one most owners underuse. Every inbound buyer message contains a question. Every phone call your front desk logs contains a question. Every contact-form submission contains a question. The questions in these channels are the questions buyers are actually asking, in the words they actually use, before they decide whether to choose you. Most of the buyers who never become customers are also represented here, and their questions are even more useful than the ones from buyers who eventually convert, because they show what the site failed to answer in time.

The work in this stage is mechanical. Pull the last ninety days of inbound contact-form submissions, the last ninety days of front-desk phone notes if your team keeps them, and a sample of your own inbox replies. Strip the personal details. Cluster the questions by topic. Each cluster becomes a candidate FAQ entry. The first sentence of the cluster, in the buyer's voice, is the question. Your own answer is the answer.

Source two. The engines themselves.

AI engines surface the questions they are asked most often when you prompt them carefully. We run a set of test prompts on each of the eight engines for the buyer's category and geography. The shape of those prompts is "what should I know before choosing a [category] in [city]," "what questions should I ask a [category] before I hire them," and "common questions about [specific service]." The engines return lists of questions, and the overlap across engines is the high-confidence signal. A question that shows up on five or six of the eight engines for a category is a question the buyer is almost certainly going to ask before deciding.

We do not copy the engine's answer. We use the engine's question list as a checklist for what our own answer needs to cover. The engine's answer is a synthesis from many sources, often with mistakes specific to your business. Our answer is the authoritative version from the business itself.

Source three. The FAQ pages of competent competitors.

We read the FAQ pages of the three or four competitors who already show up well in AI search for your category. We do not copy their content. We read for completeness, looking for question categories we have not yet covered. A competitor's FAQ that includes "do you accept walk-ins" when ours does not is a signal that we should at least decide whether walk-ins are a question worth answering on our site. The decision can go either way. The question still belongs on the inventory list for review.

Across the three sources, the inventory typically lands between thirty and seventy candidate questions for a small or mid-sized business. The next pass is the prioritization.

How to prioritize down to the ten to thirty that ship

Not every question deserves an FAQ entry. We keep three rules.

The first rule is frequency. A question that appears in your inbox or phone log five times in ninety days is shipping. A question that appears once is parked for review. The shipping threshold is intentionally low because cold-email and discovery-mode buyers are under-represented in inbox data, so a question that surfaces five times in the inbox is probably surfacing many more times in the engines.

The second rule is decisiveness. A question that changes whether the buyer will choose you is shipping regardless of frequency. "Do you accept new patients?" is a decisive question for a healthcare practice. "What is your response time?" is decisive for an emergency-trade service. "Do you handle weddings of more than 200?" is decisive for a venue. These are shipping even if they only show up twice in the inventory.

The third rule is recoverability. A question whose answer is "yes" or "no" is recoverable in one sentence. A question whose answer requires three paragraphs of nuance is harder and slower to ship. We ship the recoverable ones first and queue the nuanced ones for the content-rewrite stage in stage five.

After the three rules, the typical inventory is twelve to twenty-five Q-A pairs ready to ship. That is the right number for stage two. More is fine if the inventory genuinely contains that many decisive questions. Fewer is fine if the category is narrow.

Where each question belongs on the site

We do not put all twenty questions on one mega-FAQ page. We put each pair on the page where a buyer would naturally expect the question to live. A question about insurance coverage lives on the insurance page or the contact page, not the FAQ page. A question about a specific service goes on that service's page. A question about scheduling lives on the booking page.

The reason matters. Engines retrieve question-answer pairs cleanly when they are grounded in the page that owns the topic, and they retrieve them poorly when they live in a generic dump. A buyer asking about "All-on-4 implants near Portsmouth" gets routed to your All-on-4 service page, and the FAQ block on that page about cost, recovery, and provider credentials is the asset the engine cites. The same content on a generic FAQ page does not surface as cleanly because the engine cannot tell which service the buyer is asking about.

Some categories of question genuinely belong on a top-level FAQ page. Cross-cutting questions like "how do I pay" or "what is your service area" do not live on any one service page. Those go on the FAQ page. The rule of thumb is: if the question is about a single service or topic, it lives on that service or topic's page. If the question cuts across all services, it lives on the FAQ page.

How to write the answer

The answer is the easy part if the question is right. Three rules.

First, answer the question in the first sentence. Engines weight the opening sentence of an answer more than the rest. "Yes, we accept new patients and the next available appointment is usually within ten business days" is a complete answer the engine can extract cleanly. "We are proud to serve our community with comprehensive care and welcome new patients to join our practice family" is the same fact dressed in marketing prose, and engines skim past it.

Second, name specifics where they apply. Engines retrieve specifics more reliably than generalities. "We accept Delta Dental, Cigna, MetLife, and Aetna" is retrievable. "We accept most major insurance plans" is not retrievable as a useful fact and shows up in engine responses as "the provider accepts most plans," which is what the buyer can already guess.

Third, never invent a claim. If you do not know whether the practice accepts a specific insurance, ask. If you do not know the exact response time for after-hours emergency calls, find out before publishing. The no-guess rule applies to FAQ content as strictly as it applies to anything else on the site. An invented answer that surfaces in an engine response and then turns out to be wrong is a credibility loss the business may not recover from with that engine.

How to mark each pair up so engines can retrieve it

Plain-text Q-A pairs in your visible page content are already useful. The engines read prose. They retrieve question-answer formats they recognize even without machine-readable markup. But the retrieval gets sharper, faster, and more consistent when the pairs are wrapped in FAQPage Schema.org markup. Stage three of the engagement covers schema in detail, but the FAQPage block specifically is so cheap and so closely tied to stage two that we usually publish the markup at the same time the Q-A pairs land on the page.

The structure is simple. An FAQPage block is a JSON-LD script in the page head or near the FAQ content, and it lists every Q-A pair on the page. Each entry has a Question and an Answer, each with a name and a text body. The validator at Google's Rich Results Test will tell you whether the block is well-formed, and the engines that matter beyond Google read the same underlying spec.

The block looks like this in shape:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Do you accept new patients?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes, we accept new patients. The next available new-patient appointment is usually within ten business days."
      }
    },
    {
      "@type": "Question",
      "name": "Which insurance plans do you accept?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "We accept Delta Dental, Cigna, MetLife, and Aetna. We do not currently accept United Healthcare or Blue Cross at this office."
      }
    }
  ]
}
</script>
      

Every page that carries an FAQ block gets its own FAQPage script with the questions specific to that page. The block on the All-on-4 service page lists the All-on-4 questions. The block on the contact page lists the cross-cutting logistics questions. Engines parse each page's block independently, so duplicating questions across pages does no harm and sometimes helps when a question genuinely applies to multiple pages.

What ships and what does not, in the typical engagement

At the end of stage two of a typical engagement, the site has between ten and thirty Q-A pairs distributed across the pages where buyers would expect to find them. Each pair is in plain visible text on the page so a human reader can see it, and each pair is also wrapped in an FAQPage Schema.org block so the engines can retrieve it cleanly. The Q-A pairs replace nothing on the page. They are net-new content alongside the existing prose, the existing services list, and the existing call-to-action. They earn their place by being the literal answers to the literal questions buyers ask.

What does not ship is the "FAQ page with twenty marketing-flavored questions" that lives on so many small-business websites. We delete those when they exist, replace them with the real inventory, and move on.

The owner version, in one paragraph

Pull the last ninety days of inbound questions from inbox, phone, and contact form. Cluster them. Ask the engines what buyers in your category ask before choosing. Read three competitors' FAQs for category coverage you missed. Cut the inventory to the twelve to twenty-five decisive, frequent, recoverable questions. Write each answer in plain English with the fact in the first sentence and the specifics named. Put each pair on the page where the buyer would expect it, not on a generic dump page. Wrap each page's pairs in an FAQPage Schema.org block and run the validator. Ship. The engines pick it up inside a week or two and the question-routed buyers start landing on pages that actually answer the question they came with.

For the sequencing context that makes stage two work, see the cheap fixes first. For the entity-clarity work that comes before this stage, see entity clarity field notes. For the eight engines this FAQ inventory is being retrieved by, see the eight AI engines in plain English.