Strategy
1,430 Words

Topic Cluster Content Strategy: Pillars, Spokes, and Internal Links

Topic Cluster Content Strategy: Pillars, Spokes, and Internal Links
AI Generated

A topic cluster is not a keyword list with extra blog posts. HubSpot defines it as related cluster pages organized around one central pillar page, connected by internal links. Keyword clustering still matters—it assigns one intent to one URL—but the cluster is the architecture layer: a hub that umbrellas many supporting URLs so search and AI systems see coverage of a subject, not a set of pages competing with each other. That architecture only works if each spoke owns a distinct question, the pillar is broad enough to be a real umbrella, and links run both ways in context—not a footer dump. Sparse coverage (a couple of supporting articles) reads as thin; a working cluster typically needs a full spoke set, early spoke-to-pillar links, and a merge-and-redirect rule when two URLs chase the same intent. Clustered sites are also associated with more organic traffic, longer ranking duration, and more AI citations than standalone pages, including when query fan-out sends sub-questions to spokes the pillar is too broad to own. This article is the operator OS for that model: how to sniff a true pillar, plan unique-intent spokes, wire bidirectional links, kill cannibalization before you publish more, and ship a reusable cluster map so scaled publishing stays on one topic.

Summary
  • A cluster is a pillar plus unique-intent spokes plus bidirectional links that make the pillar the hub.
  • Keyword clustering is one intent per URL; the topic cluster is the site-architecture layer around those URLs.
  • Plan roughly 8–12 spokes, link each spoke to the pillar in the first 200–300 words, and merge overlapping URLs onto the strongest page.
  • Clustered content is associated with about 30% more organic traffic, longer ranking hold, and several times more AI citations than standalone posts.
  • Audit and relink what you already have, then track the cluster as a unit: pillar rank, spoke coverage, and link completeness.

A topic cluster is a hub, not a pile of similar keywords

Hub-and-spoke architecture diagram showing a pillar page connected to unique spoke pages with bidirectional internal links

That setup is why a topic cluster is not a spreadsheet of related phrases. It is three working parts: a broad pillar page that covers the subject at a high level, supporting pages that each own a distinct search intent, and internal links that treat the pillar as the hub.

Keyword clustering is a different job. It maps one intent to one URL so you do not publish two pages that compete. A topic cluster sits one layer up: it is the site architecture that groups those unique URLs around the pillar so crawlers—and AI features that fan out across sub-questions—can read the set as one subject. If you still need grouping mechanics, use a keyword-clustering playbook; this piece owns the graph those URLs sit in.

The difference is what you ship: not more similar posts, but a map you can audit as a unit—pillar, spokes, and the links between them.

Key Takeaway

Architecture first — A cluster ranks as one subject only when a pillar, unique-intent spokes, and hub links are planned and shipped together—not when related keywords sit in a list.

Sources

The pillar sniff test—and how many spokes actually count

Pillar sniff-test checklist beside a spoke-count gauge filling toward an 8–12 spoke topic cluster

That architecture only holds if the hub is actually a pillar. Run a sniff test before you write another outline: would this page answer the head query a searcher typed, and is it broad enough to umbrella many supporting posts? A long-tail how-to fails it; that URL belongs as a spoke, not as the page everything else points to.

HubSpot planned the same way when they rebuilt their blog: topics broad enough for 20–30 different posts, still narrow enough to own as a real pillar. Leslie Ye’s version of the test is the same two questions—does the page answer every question behind the head keyword, and is it an umbrella for 20 to 30 posts? If you cannot say yes to both, you do not have a pillar yet.

Depth of coverage is the other half of the test. Most successful clusters include 8–12 supporting pages per pillar; two or three posts read as shallow coverage, not a cluster. Eight to twelve is a practical minimum to start with. Audit URLs you already have before inventing new spokes so the pillar sits on coverage that exists, then fill only the intent gaps that remain.

Key Takeaway

Sniff test — A pillar is a head-query page wide enough to umbrella many posts; plan 8–12 unique-intent spokes and map them to URLs you already have before you write new ones.

Sources

Unique-intent spokes—and the cannibalization gate

Overlapping articles colliding on one query then merging into a single strongest URL with a redirect

Once you know the pillar can umbrella a real cluster, the next filter is intent, not wording. Cannibalization is two URLs answering the same job. Similar titles are a clue; identical searcher tasks are the collision. If two pages both try to close the same query, neither should stay live as a spoke.

Assign each spoke one unique intent so a publishing pipeline cannot spawn near-duplicates from the same map. That assignment is the gate: if two briefs describe the same job, you do not ship a second URL. Merge overlapping posts onto the strongest page first. HubSpot’s guidance is to combine the information on the highest-ranking URL and redirect the other posts toward it. 301 the rest, then brief new spokes only for intents that still have no home.

If you already have a cluster brief, treat this as passed only when every planned spoke maps to a distinct job and leftover collisions are merged. The worksheet that follows assumes that gate is closed; skip it and you scale duplicates, not coverage.

Key Takeaway

Gate — One intent, one live URL. Merge and 301 collisions onto the strongest page before you add spokes.

Bidirectional links that actually make the pillar the hub

Spoke article opening with a contextual link to the pillar and in-body pillar-to-spoke links instead of a footer list

Once overlapping URLs are merged, the cluster still is not a hub until the links say so. Every spoke should point to the pillar in the first 200 to 300 words so crawlers and readers hit the umbrella page immediately. The pillar should send people the other way in relevant body copy—not a dumped list at the footer. Related spokes may cross-link when it genuinely helps the next question, but a sparse web beats a mesh that dilutes the hub.

Treat density as a cue, not a stuffing rule: about one internal hyperlink per 150 words. Those two-way links are the citation and ranking lever. HubSpot’s original Topics Over Keywords work found that the more internal links they added between related pages, the higher those pages climbed in SERPs. Bidirectional internal linking has been associated with 2.7× higher AI citation probability, and proper internal linking is cited as boosting rankings by up to 40%. Leave automation rules, AI suggestions, and productized insertion to a dedicated internal-linking guide—this section is the policy that automation should enforce.

Key Takeaway

Hub first — Spokes link to the pillar early; the pillar links out in context; related spokes cross-link sparingly. That three-way map—not a footer dump—is what turns unique-intent pages into one subject.

Track the cluster as one subject, then ship the map

Cluster map template with pillar, spoke intents, link types, and metrics for traffic, ranking duration, and AI citations

Once the links are in place, stop scoring posts in isolation. Rank duration, organic lift, AI citations, and how deep crawlers have to go belong to the cluster, not to whichever URL happened to pick up a spike. Relink what you already published before you brief another spoke: completeness of spoke-to-pillar, pillar-to-spoke, and a few selective spoke-to-spoke connections is a shippable metric, not a later tidy-up.

Google’s AI features may use a “query fan-out” technique—issuing multiple related searches across subtopics and data sources—so a spoke can earn a citation on a sub-question the pillar is too broad to own. That is why five or more interconnected pages on a topic matter: in one 2025 citation analysis, 86% of AI citations came from sites with that depth, and clustered sites received 3.2× more citations than single-page competitors. Pages within three clicks of the homepage also generate far more SEO traffic than deeper URLs, which is another reason the hub has to stay easy to reach.

30%
More organic traffic vs standalone
2.5×
Longer ranking duration
3.2×
More AI citations vs one page

Hand writers and autoblogging a reusable map, not another how-to: the pillar keyword, eight to twelve unique spoke intents, and a three-way link plan. Publish that map as a unit so the cluster ranks as one subject instead of a pile of similar posts.

Key Takeaway

Ship the unit — Audit, relink, and report the cluster as one map—pillar, unique-intent spokes, and bidirectional links—before you add more URLs.

Key Takeaways

[01]
Hub, not a pileA topic cluster is a pillar, unique-intent spokes, and bidirectional links that treat one subject as a unit, not overlapping posts stacked on similar keywords.
[02]
Pillar sniff testA true pillar covers a head query with room for many posts; plan 8–12 supporting pages as a working minimum and audit existing URLs before you write new spokes.
[03]
Cannibalization gateMerge intent collisions onto the strongest URL with 301s so every spoke owns a distinct job before you brief new pages or fill a cluster worksheet.
[04]
Bidirectional hub linksSpokes link to the pillar in the first 200–300 words, the pillar links out in body copy, spoke-to-spoke stays sparse, and you aim for about one internal link per 150 words.
[05]
Ship the map as one subjectRelink what you already have, then hand publishing a reusable map of pillar keyword, 6–12 spoke intents, and a three-way link plan so rankings, duration, and citations are measured at cluster level.

Audit one live topic against this map, merge colliding URLs, wire bidirectional links, and ship the next cluster as a unit instead of another pile of similar posts.

Frequently Asked Questions

What is a topic cluster in SEO?
HubSpot defines topic clusters as related cluster pages organized around one central pillar page and connected by internal links. In practice that means a broad hub, unique-intent spokes, and bidirectional links—not a folder of similar posts.
How is a topic cluster different from keyword clustering?
Keyword clustering assigns one search intent to one URL so pages do not cannibalize each other. A topic cluster is the architecture that groups those URLs around a pillar so the site covers a subject as a hub-and-spoke system.
How many spoke pages should sit under a pillar?
Most successful clusters contain 8–12 supporting pages per pillar; two or three supporting posts read as shallow. HubSpot’s own rebuild used topics broad enough for 20–30 posts when the pillar truly umbrellas the subject.
Where should internal links go in a cluster?
Every cluster page should link to the pillar, ideally within the first 200 to 300 words; the pillar should link out in context, and related spokes should cross-link sparingly. Bidirectional linking has been associated with 2.7× higher AI citation probability.
Do topic clusters help with AI Overviews and citations?
Google’s AI features may use query fan-out—issuing multiple related searches across subtopics—which favors deep clustered coverage. One 2025 citation analysis found clustered sites receive 3.2× more citations than single-page competitors, with 86% of citations from sites with five or more interconnected pages on the topic.
What should I do with overlapping posts before adding spokes?
Cannibalization is an intent collision, not similar wording. Combine overlapping posts onto the highest-ranking URL and redirect the others toward it before you publish more spokes.
Sources

You Might Also Like

View All Articles