A cluster is an information system
A topic cluster is a deliberate set of pages that covers a broad subject and the related decisions beneath it. The purpose is navigation and maintenance, not an attempt to make a site look authoritative by publishing volume. Every page needs a distinct job, an accountable owner, and an obvious link to the next useful page.
Start with a core task, then map supporting questions by dependency. A core “data export” guide may connect to format definitions, permission setup, troubleshooting, API reference, and migration advice. Do not add pages that merely restate the core guide with a different adjective. Google’s people-first guidance cautions against producing lots of content across topics in the hope some will perform; the cluster should reflect knowledge you can actually maintain.
Map the reader journey
Create a one-page map with a hub, child pages, source-of-truth pages, and retirement candidates. The hub explains the topic, says who it is for, and directs people to an appropriate task. Child pages answer a narrower question completely. A reference page defines durable facts. A comparison page handles a decision between alternatives. This keeps tutorials from accidentally becoming policy documents.
For a fictional CRM vendor, a “sales pipeline” hub can link to setting stages, importing leads, forecasting definitions, permission roles, and switching from spreadsheets. A reader who wants to configure stage automation should land on a tested procedure, not a 4,000-word hub with one ambiguous paragraph. The hub still helps a new administrator understand where that procedure belongs.
Use ordinary HTML links with meaningful anchor text. Google recommends crawlable <a> links and says descriptive anchor text helps people and Google understand the linked page. Its link guidance supports a simple rule: link when the destination helps the reader take the next step, not to force every page into every footer.
Keep the cluster accurate
Assign an owner to each canonical page and a reviewer to cross-page facts. Give the hub a review date and a release trigger. When one definition changes, update the reference and audit links that summarize it. When two pages compete for the same reader decision, merge the stronger content and preserve a clear route from the old URL where practical.
Test the hub in a private browser: can a new reader find the correct procedure within two clicks? Test public delivery with the AI Search Readiness Checker, and ensure dynamic navigation does not hide essential destinations; see raw HTML versus rendered content. A cluster may improve comprehension and crawling paths, but it cannot guarantee an AI answer or citation.
Common mistakes
- Naming a collection a cluster without defining distinct page responsibilities.
- Linking pages because they share a word rather than a reader journey.
- Allowing a hub to duplicate every child page until neither stays current.
- Leaving no owner to update references after releases.
FAQ
How large should a cluster be?
Only as large as the real tasks require. Three maintained pages beat thirty thin ones.
Do clusters require a pillar page?
A navigational hub is useful when the subject is broad; a small subject may need only direct links.
See question research, content refresh audits, and agent readiness.