How many pages belong in a cluster?

Enough to cover distinct intents without overlap. Many useful clusters have one pillar and a handful to a few dozen supporting pages. Size follows the SERP map, not a round number.

Do we write the pillar first?

Often yes, or we draft the pillar outline first and publish supporting pages in an order that lets links resolve. Exact sequence depends on what already ranks and what gaps hurt most.

Can you build clusters from our existing blog?

Yes. Much of the work is regrouping, retargeting, merging, and adding missing members rather than starting from zero.

Is a pillar the same as a cornerstone or hub page?

In practice, yes: the broad page that orients the topic and links to depth. We care more about role and links than about the label your team prefers.

How do clusters relate to programmatic pages?

Clusters are usually editorial architectures for distinct intents. Programmatic sets use templates at scale. Some sites use both, but thin templated pages should not pose as thoughtful cluster members.

Topic Cluster Strategy | Pillar and Supporting Pages

Why clusters outperform random topical posts

Search systems evaluate how completely and clearly you cover a subject. A pillar that summarizes the topic and supporting pages that go deep on sub-intents give you both breadth and depth. Random posts on the same theme often overlap, leave gaps, and link nowhere useful.

A working cluster also reduces cannibalization. Each URL has a primary job. When a new idea appears, you know whether it belongs as a new supporting page, a section on the pillar, or a note in an existing article. That discipline is the difference between a library and a pile.

If two pages could swap titles without anyone noticing, you do not have a cluster. You have twins.

Pillar pages that earn the hub role

The pillar is not automatically the longest page. It is the page that should own the broad query and orient the reader to the supporting answers. It links out to depth pages. Depth pages link back with anchors that match their intent. The pillar stays useful on its own, but it is designed as a map as well as an article.

Broad primary keyword that matches hub intent, not a narrow how-to
Clear sections that preview supporting topics without stealing their depth
Visible internal links to each cluster member with honest anchors
Maintenance rules: when the pillar updates versus when a child page updates

If you want a practical build sequence, how to build a topic cluster walks through the same logic we use in client work: map intents first, assign URLs, then write in an order that lets links land on live pages.

How we design a topic cluster strategy

Define the subject boundary so the cluster does not swallow the whole site
List query groups and SERP formats for pillar and supporting roles
Assign one primary intent per URL and note near-duplicate risks
Draft the link graph: pillar to children, children to pillar, selective siblings
Sequence production: foundation pages first, then depth, then refresh loops

Intent labeling matters here. Informational supporting pages should not quietly compete with commercial comparison URLs. When comparison or alternatives pages belong in the set, they get their own ownership rules. Comparison and alternatives pages often sit in commercial clusters and need different evidence than beginner explainers.

2026 note: Clusters still work when each page earns its place. Adding thin supporting posts to look complete usually fails. Prefer fewer strong members over a crowded map of weak pages.

Internal links as architecture

Links are not decoration at the end of a draft. In a cluster, they are the wiring. We specify which pages must link where, which anchors to prefer, and which orphan risks to avoid. Production briefs inherit those rules so writers do not invent a new linking habit every time.

Cluster link patterns we commonly use
From	To	Purpose
Pillar	Each supporting page	Route to depth and distribute discovery
Supporting page	Pillar	Confirm hub and contextualize the subtopic
Supporting page	Sibling (selective)	Help related next steps without loops
Older related URL	New cluster member	Pass existing equity into the set

Avoiding cannibalization inside the cluster

Clusters fail when supporting pages chase the pillar keyword, or when two children target the same SERP. We document exclusion notes: phrases a child page should not try to own. When overlap appears in Search Console later, keyword cannibalization: find and fix becomes maintenance work on the same architecture.

Merge and retarget decisions are part of cluster strategy, especially when you already published overlapping posts. Building a clean cluster sometimes means consolidating old URLs before adding new ones.

Topic cluster strategy fits

Teams expanding coverage in a subject they want to own for years
Sites with scattered posts that never formed a coherent set
Product companies with education and comparison intents in one topic
Programmes ready to sequence writing around a link graph

Not the right first move when

You only need one promotional page with no supporting set
Core crawl or indexation issues block new pages from appearing
You want dozens of near-identical location or attribute pages (see programmatic)
Leadership expects the cluster to rank fully within a few weeks

Cluster engagement deliverables

Subject boundary and cluster goals
Pillar and supporting URL map with primary keywords
SERP and intent notes for each member
Internal link graph and anchor guidance
Production sequence and refresh rules
Cannibalization and merge recommendations for existing pages

Building and maintaining the set

We can stop at architecture and briefs, or continue into production for the pillar and supporting pages. Either way, clusters need maintenance. Search intent shifts. Product lines change. Supporting pages decay. A cluster strategy includes a revisit cadence so the hub does not rot while you chase new topics.

Timelines are honest: designing the map may take one to three weeks. Filling it with strong pages takes longer, and organic results for new members commonly show over three to nine months on domains that already earn traffic. The payoff is a system you can grow without rewriting your information architecture every quarter.

Clusters across product and education intents

Many sites need one educational cluster and a separate commercial set for the same broad subject. Mixing beginner definitions with hard buyer comparisons on one URL usually weakens both. Strategy draws that boundary early: which pages teach, which pages help someone choose, and how they link without stealing primary ownership.

Subject experts help most on commercial and advanced supporting pages, where generic summaries fail. Pillars still need accuracy, but supporting depth is where product truth and field experience show. We plan SME time against those pages instead of asking experts to rewrite every intro paragraph in the set.

If your library already mixes intents on the same URLs, cluster design may include splitting or retargeting before new writing starts. That feels slower at first. It prevents a polished cluster that still cannibalizes itself six months later.

Topic Cluster Strategy