Organising content around pillars and clusters to build the topical authority engines reward.
A topic cluster is a way of organising content so that a subject is covered as a connected whole rather than as scattered posts: one pillar page addressing the topic broadly, surrounded by cluster pages treating its specific questions in depth, all linked together. The structure does two things at once — it demonstrates comprehensive coverage to engines, and it gives AI systems many well-organised passages to retrieve. And because the pages reinforce each other, the whole group tends to rise together.
A topic cluster is a group of related pages organised around a central subject. At its centre sits a pillar page: a substantial resource covering the topic broadly, addressing its main dimensions without exhausting any single one. Around it sit cluster pages, each treating one specific aspect, question, or subtopic in genuine depth. Internal links connect the pillar to each cluster page and the cluster pages to one another where relevant.
The model contrasts with the common alternative of publishing individual posts as opportunities arise, which produces content that may cover a subject in aggregate but does not appear as coherent coverage. The cluster makes the relationship explicit: these pages belong together and constitute deliberate treatment of a subject. Understanding what a cluster is establishes the shape — one pillar, linked deep clusters — that the rest of the practice builds on.
The pillar page addresses the topic as a whole. It should be genuinely substantial — a resource someone could read to understand the subject broadly — covering its major dimensions, defining its terms, and orienting the reader. What it should not do is exhaust every subtopic, because the depth belongs in the cluster pages it links to. The pillar provides the overview and the map; the clusters provide the detail.
Practically, a pillar page targets the broader, more competitive terms describing the topic, and functions as the hub that receives and distributes internal authority within the cluster. It is usually the page you would send someone who asked about the subject generally. Understanding the pillar’s role prevents the two common errors: pillars so thin they serve as mere link lists, and pillars so exhaustive they leave the cluster pages nothing distinct to cover.
Cluster pages each take one specific aspect of the topic and treat it thoroughly — a particular question, a subtopic, a comparison, a how-to. Their value comes from depth and specificity: rather than mentioning a subject briefly as a pillar must, a cluster page can answer a narrow question completely. This makes them well-suited to long-tail queries and to the specific sub-questions AI engines generate when decomposing a broader question.
Each cluster page should have a distinct purpose, so that pages do not overlap and compete. Together they should cover the topic’s facets comprehensively, which is what makes the cluster genuine coverage rather than a partial gesture. Understanding that depth lives in the cluster pages is why building a cluster is substantially a matter of identifying the topic’s real questions and answering each properly, rather than producing variations on the same material.
Without internal links, a pillar and its related pages are merely pages on similar subjects; the links are what constitute the cluster. Each cluster page links up to the pillar, establishing it as the topic’s centre. The pillar links out to each cluster page, showing the scope of coverage. And cluster pages link to one another where genuinely related, forming a connected web rather than a hub with isolated spokes.
This linking does real work: it makes the relationships legible to engines, distributes authority through the group, and helps retrieval reach the right page for a specific question. Internal linking is what turns posts into a cluster — the single most important structural step, and the one most often neglected because content is published without being connected. Understanding its centrality is why linking should happen as part of publishing, not as an occasional cleanup.
The cluster model works because comprehensiveness is evidence. A publisher who has covered a topic’s main dimensions and its specific questions has demonstrably invested in the subject, which makes their treatment of any particular question more credible than that of a site with one incidental page. Engines reward demonstrated topical depth for this reason, and the cluster is the structure that makes such depth both achievable and visible.
This connects the cluster model directly to topical authority, covered in its own piece: clusters are the practical mechanism by which topical authority is built and displayed. The distinction is that topical authority is the standing you earn, while the cluster is how you organise content to earn it. Understanding why comprehensiveness signals authority is why the model rewards genuinely covering a subject rather than producing the appearance of coverage.
Internal linking is what turns individual posts into a cluster. Comprehensive, connected coverage signals genuine authority — and gives AI engines many well-organised passages to retrieve and cite.
The most valuable property of the cluster model is that its benefits accrue to the group rather than to individual pages. As cluster pages earn links, mentions, and visibility, the internal linking distributes that authority across the group, including to the pillar. As the cluster grows more comprehensive, the whole becomes more credible as coverage of the subject. The result is that pages rise together rather than each competing in isolation.
This compounding is why the model rewards patience and continued investment: each addition strengthens what already exists, rather than merely adding another isolated page. A mature cluster becomes progressively harder for competitors to match, since replicating it requires replicating the whole connected body of work. Understanding that clusters compound is why the model suits long-term content strategy rather than opportunistic publishing.
Topic clusters align unusually well with how AI engines work. When an engine decomposes a question into sub-questions and retrieves sources for each, a well-built cluster offers many focused, well-organised passages — one per specific question — rather than a single page that touches everything shallowly. Deep clusters give AI engines many passages to cite, multiplying the points at which you can enter an answer.
The structure also helps retrieval find the right passage: focused cluster pages, clearly organised and interlinked, make it easier for an engine to locate the specific content that answers a specific sub-question. This is a genuine advantage of the model in the AI era, beyond its traditional benefits. Understanding why clusters suit AI retrieval is why the model has become more valuable, not less, as answer engines have grown in importance.
A working cluster shows up as citations across a subject’s many questions. DUNkē tracks your citations across eight AI engines — per prompt, against competitors — so you can see whether your cluster is being retrieved across the topic.
Building a cluster starts with defining the topic precisely enough to be coverable, then mapping its dimensions and the specific questions within them. From that map, the pillar page addresses the topic broadly while each significant question or subtopic becomes a cluster page. Existing content is plotted against the map, since much of it may already fit, needing only connection and gap-filling rather than replacement.
The sequence that works is usually to establish the pillar early, giving the cluster a centre to link to, then build out cluster pages against the map, linking each as it publishes. Attempting to complete every cluster page before connecting anything delays the structural benefit. Understanding the practical sequence is what makes cluster-building a manageable programme rather than an overwhelming one, since the structure grows incrementally from a defined map.
The main structural risk in a cluster is pages that overlap enough to compete with each other, splitting signals and confusing which page should serve a query. This happens when cluster pages are defined by keyword variations rather than by genuinely distinct questions, producing several pages that essentially answer the same thing in different words.
The prevention is to define each cluster page by a distinct underlying job: what specific question does this page answer that no other page answers? If two planned pages would satisfy the same intent, they should be one page. Where overlap already exists, consolidation into a single stronger page usually beats maintaining both. Understanding cannibalisation is why cluster planning should be done at the level of intents rather than keywords, which is where the distinctions are real.
Topic clusters and site architecture are closely related but not identical. Architecture concerns the overall organisation of a site — hierarchy, navigation, click depth, and how authority flows through the whole. Clusters concern the organisation of content around subjects. In practice they should be designed together, since a cluster is easiest to build and most legible when the site’s structure reflects it.
Practically this means placing cluster content coherently within the site’s hierarchy, ensuring pillar pages are reachable within a few clicks, and letting the navigation reflect the topics you cover. A cluster whose pages are scattered across an incoherent structure works less well than one whose organisation is reinforced by the site’s own architecture. Understanding the relationship is why content planning and structural planning belong in the same conversation.
A common practical question is how many clusters to run and how large each should be. The honest answer is that fewer, deeper clusters generally outperform many shallow ones, because the model’s benefits depend on comprehensiveness. A cluster covering a topic’s questions thoroughly demonstrates authority; three clusters each covering a third of their topics demonstrate none.
Size should be determined by the topic rather than by a target number: a cluster is complete when it genuinely covers the subject’s significant questions, which varies by subject. The practical guidance for most organisations is to build one cluster properly before starting another, expanding into adjacent topics once the first is genuinely comprehensive. Understanding this is why the discipline is concentration — the model rewards depth, and depth requires focus.
Clusters require maintenance as well as construction. Questions within a topic change in importance, new questions emerge, existing pages become outdated, and gaps appear as the subject evolves. A cluster left untouched gradually becomes less comprehensive relative to the topic as it now exists, which erodes both the authority signal and the retrieval value.
The practical routine is periodic review: checking the map against the topic as it currently stands, adding pages for newly-important questions, updating pages whose content has aged, consolidating any that have drifted into overlap, and verifying that internal linking still connects everything. Understanding that clusters need maintenance is why the model is a commitment to a subject rather than a build-once project, and why consistency over time is part of what makes it work.
The recurring mistakes are structural. Publishing related content without linking it produces posts rather than a cluster, forfeiting the model’s central mechanism. Building pillars that are thin link lists rather than substantial resources leaves the centre weak. Defining cluster pages by keyword variations produces overlap and cannibalisation. Spreading effort across many shallow clusters produces comprehensiveness nowhere. And abandoning a cluster after an initial build lets it decay.
The remedies follow directly: link deliberately as you publish, make the pillar genuinely substantial, define cluster pages by distinct intents, concentrate on fewer topics covered properly, and maintain what you build. Because the model’s benefits depend on connection and comprehensiveness, these errors undermine the whole approach rather than merely reducing its effect. Understanding them is what separates a working cluster from a set of pages that merely resemble one.
An early decision in cluster building is where the topic ends, and it matters more than it appears. A boundary drawn too wide produces a cluster that can never be comprehensive, since the subject encompasses more than you can cover. Drawn too narrow, it produces a cluster that exhausts itself in a handful of pages and cannot demonstrate meaningful depth.
The workable test is whether you can plausibly cover the subject’s significant questions thoroughly with the resources you have, while still having enough to cover that the result looks like genuine depth. Understanding boundary-setting is why the first hour of cluster planning is often the most consequential — a well-chosen scope makes the rest achievable, while a poorly-chosen one guarantees permanent incompleteness or premature exhaustion.
Most organisations building a cluster already have relevant content scattered across their site, which means the first practical step is usually auditing rather than writing. Plotting existing pages against the topic map reveals what is already covered, what is covered poorly, what overlaps and should be consolidated, and where the genuine gaps sit.
This audit frequently shows that the cluster is closer to existing than expected, needing connection and improvement more than wholesale creation. It also surfaces cannibalising pages that should merge into single stronger ones. Understanding that auditing precedes building is why cluster projects should begin with an inventory: creating new content around unaddressed existing overlap compounds the problem rather than solving it.
Cluster pages need not be uniform in format, and varying them by what each question requires generally serves better. Some questions want a thorough explanation, others a step-by-step procedure, others a comparison, others a reference table. Matching format to the underlying job produces more useful pages than applying one template across an entire cluster.
Format variation also improves extraction prospects, since comparison tables and procedural content are cited disproportionately when the content genuinely has that shape. The practical guidance is to decide each cluster page’s format from the question it answers rather than from a house style. Understanding format variation is why a strong cluster looks heterogeneous — each page shaped by its question rather than by a template.
The cluster model is usually justified in terms of engines, but its benefits to readers are real and worth stating. A visitor arriving on any cluster page finds clear routes to the broader topic and to related specifics, which supports the natural research behaviour of exploring a subject rather than consuming a single page.
This alignment matters because engagement signals and genuine usefulness ultimately support the visibility the structure is meant to produce. A cluster built purely as a machine-legible structure, without regard for whether it helps someone actually learn the subject, tends to feel mechanical and perform accordingly. Understanding the reader benefit is why the model works best when built as genuine navigation through a topic rather than as an SEO artefact.
Clusters should be measured at cluster level rather than page level, because the model’s benefit is that pages rise together. Useful measures include total visibility across the cluster’s pages, the breadth of queries the cluster appears for, whether pages you did not specifically target are gaining visibility, and citation breadth across the topic in AI answers.
Page-level measurement misses the compounding effect entirely and can make a healthy cluster look mediocre, since individual pages may perform modestly while the group performs well. The practical approach is to define the cluster as a reporting segment and track it as a unit. Understanding cluster-level measurement is what lets you tell whether the structural investment is working, well before any individual page becomes a standout performer.
Clusters suit subjects with genuine depth — topics containing many real sub-questions worth answering separately. They suit some situations poorly: a subject with only a handful of meaningful questions does not need a pillar and spokes, and forcing the structure produces thin pages created to fill a diagram rather than to answer anything.
The honest test is whether each planned cluster page answers a question someone actually asks that no other page answers. Where that test fails repeatedly, a single comprehensive page is the better artefact. Understanding when clusters are the wrong model prevents the common failure of applying the structure mechanically, which produces the appearance of depth without the substance that makes depth valuable.
Clusters spanning many pages and months of work benefit from explicit ownership, because the failure mode is not usually poor individual pages but a structure nobody is responsible for maintaining. Someone needs to hold the topic map, decide what belongs in the cluster, ensure new pages are linked on publication, and notice when coverage has drifted or gaps have opened as the subject evolved.
Without that ownership, clusters decay predictably: pages get published without being connected, overlapping content accumulates because nobody checks the map first, and the coverage that once looked comprehensive gradually stops matching the questions people now ask. The practical arrangement is to name an owner for each significant cluster and give them the map as a living document. Understanding ownership as a structural requirement is why cluster strategies succeed or fail on process as much as on content quality.
A cluster passes through recognisable phases, and what it needs differs at each. In construction, the priority is establishing the pillar and filling the map’s significant gaps quickly enough that the coverage looks genuine. In maturity, the priority shifts to depth and quality — improving the pages that underperform, adding the questions that emerged since the map was drawn, strengthening internal connections.
In decline — which happens when a subject loses relevance or the organisation moves on — the honest decision is either to reinvest or to consolidate the cluster into fewer, stronger pages rather than maintaining a sprawl nobody updates. Understanding the lifecycle is why cluster strategy should include an explicit view on which clusters are being built, which are being maintained, and which are being wound down, since treating all three identically wastes effort on the wrong ones.
A topic cluster organises content around a subject: one substantial pillar page covering the topic broadly, surrounded by cluster pages each answering a specific question in depth, all connected by internal links. The linking is not decoration — it is what turns individual posts into a cluster, making the relationships legible to engines, distributing authority through the group, and helping retrieval find the right page.
The model works because comprehensive coverage is genuine evidence of expertise, which engines reward, and because the pages reinforce one another so that the whole group rises together rather than competing individually. In the AI era it has an additional advantage: deep clusters give engines many focused, well-organised passages to retrieve and cite across a topic’s many sub-questions. Build fewer clusters properly rather than many shallowly, define each page by a distinct job, link as you publish, and maintain what you build.
“Related posts don’t make a cluster — links do. Connect a substantial pillar to genuinely distinct deep pages, and the whole group rises together while giving engines many passages to cite.” The Age’X Research Team
Get a free GEO audit — the same analysis behind every article here.