How many pages do we need for AI visibility?

Expanded answer

Page count is an output, not a target. The input is a map: which entities must be explained (product, category, problems, use cases, integrations, alternatives), which questions buyers ask at each stage, and which decision contexts need their own answer — comparison, pricing logic, proof, implementation.

From that map, the structure follows a simple shape: one canonical page per priority intent, plus supporting clusters — Q&A items, guides, comparisons — around the topics that keep generating questions. When the map is honest, the number lands where it lands: a focused service business may need a couple dozen strong pages; a complex platform may justify far more. Both are correct, because both are covered.

What never works is inverting the logic: generating hundreds of thin pages per keyword or prompt to "increase surface area". Systems and buyers read those the same way — repetitive, empty, interchangeable. Thin pages dilute your entity clarity, cannibalize your own intents, and bury the canonical pages retrieval should find. Coverage is measured in answered questions, not in URLs.

What to check

• Every priority entity and offer has one canonical page — and only one.
• Real buyer questions each map to a page or a deliberate section — no orphan intents.
• Clusters exist where questions keep coming, with a hub connecting them.
• No two pages compete for the same intent.
• New pages are added because an intent is uncovered — not to grow the sitemap.

Common mistakes

• Chasing a benchmark page count instead of mapping entities and questions.
• Generating thin prompt-pages for surface area — noise that weakens real pages.
• Splitting one intent across near-duplicate pages.
• Counting URLs as coverage while priority questions stay unanswered.