Topic clusters organise a broad subject and its supporting pages around connected user questions, using clear internal links and distinct page purposes.
Design coverage before volume
A topic cluster starts with a user problem, a hub or overview and supporting pages that answer narrower questions. It is an editorial architecture, not a requirement to manufacture pages for every phrase. Each page needs distinct evidence, scope and a route back into the cluster.
How to inspect it
Inventory existing pages, query themes and gaps. Map every proposed supporting page to a specific question, audience state and available evidence, then check whether the page would duplicate another target. Crawl the resulting link paths to confirm hubs, contextual links and return routes work as intended.
How to implement or improve it
Build the hub first or clarify its role, then publish the most useful supporting pages in small, reviewable groups. I start architecture with real user intents and coverage; a clean hierarchy matters only when each level answers a distinct question. Revisit the map as inventory and queries change.
Limits and common mistakes
A cluster diagram does not create authority by itself. Thin pages, forced links and overlapping intent leave users with more URLs but fewer answers.
Build a cluster from a decision map. Name the broad question, then list narrower questions a reader asks before or after it; discard proposed pages that repeat the same intent. Assign each retained page a unique title, evidence set and link relationship to the hub. Example: an overview of technical audits can link to separate pages about crawl scope, duplicate URLs and performance evidence because each solves a different next question. Verify the design by starting at a supporting page: the reader should be able to understand its scope, reach the hub and continue to a relevant neighbour without a forced loop. Periodically merge or retire pages whose roles overlap rather than accumulating thin supporting posts.
Maintain the cluster as a living inventory. For each page, store its primary question, audience state, evidence owner, hub relationship, inbound contextual links and last review date. Before adding a new page, compare it against the existing inventory and the search result sample; merge it when the question and answer would be substantially the same. When a hub changes scope, update its child links and the child introductions together so the architecture stays legible. A cluster should tolerate missing pages: it is better to leave a gap visible than to fill it with a weak article. The success condition is coherent coverage and navigation, not a fixed number of URLs or a promised “authority” outcome.