You built twelve spoke articles around a solid pillar page, linked them all together in a burst of enthusiasm, and six months later the hub still isn't ranking for the head term it was built for. That's the most common failure in topic cluster internal linking structure: founders build the cluster, then link it like a spiderweb instead of a wheel, and wonder why the equity never concentrates anywhere.
Here's the direct answer, because this is the part everyone gets slightly wrong. A correct topic cluster internal linking structure links every spoke to the hub, links the hub back to every spoke, and only links spoke-to-spoke when the two pages have a genuine, narrow topical overlap — not just because they share a parent category. Get that ratio wrong and you dilute the one page you're trying to rank.
The Exact Linking Pattern (Spoke-to-Hub and Spoke-to-Spoke Rules)
This is the part that actually determines whether your cluster ranks, so let's be precise about it instead of vague.
- Every spoke page links to the hub page at least once, using a variation of the hub's target keyword as anchor text, placed within the first third of the article body.
- The hub page links out to every spoke in its cluster, typically in a structured list or embedded contextually within relevant sections — never buried only in a footer widget.
- Spoke pages link to each other only when there's a direct, specific relationship between the two subtopics — not because "they're both about SEO."
- Each spoke should carry no more than 2-3 spoke-to-spoke links. More than that and you're spreading equity sideways instead of letting it pool at the hub.
- Anchor text on hub-bound links should vary — don't use the identical phrase on all twelve spokes, or you risk looking manipulative to both users and algorithms.
- New spokes get linked into the existing cluster within the same publishing cycle, not "eventually." A spoke sitting unlinked for three weeks is invisible to your own hub.
- The hub itself should never link out to pages outside the cluster in its primary content area — save external context links for a resources section at the bottom.
- Revisit the full link map every quarter, because clusters that grow past 15-20 spokes need sub-groupings, or the hub page turns into an unreadable directory.
Picture the hub as a hotel lobby and each spoke as a guest room. Every room has a hallway that leads back to the lobby — that's non-negotiable. But rooms don't need doors connecting them to every other room on the floor. Room 204 connects to 205 because they share a wall and a topic (say, both are "keyword cannibalization" adjacent), not because they're both hotel rooms. That's the difference between a structure that concentrates authority and one that just links everything to everything, which Google reads as noise, not architecture.
Why Link Equity Actually Flows This Way
Search engines distribute ranking signal through links the way water finds the lowest point — it follows the path you build, and it pools wherever the most paths converge. If every spoke funnels a link to the hub, the hub becomes the page with the most internal links pointing at it on your entire site. That concentration is precisely what tells Google "this is the page that matters most for this topic," which is the whole point of running topic clusters instead of one giant standalone article.
The mistake that undoes this: founders link spokes to spokes liberally because it "feels helpful for users," and forget that every outbound link on a page divides that page's equity among its targets. A spoke page with eight outbound links (three to spokes, one to the hub, four external) is handing away most of its authority instead of consolidating it upward. We've seen founders do the math wrong here constantly — they treat internal linking like a content recommendation engine instead of an authority-routing system. It's both, but the routing matters more for rankings.
The Gap Nobody Explains: Linking the Second Spoke Correctly
Almost every guide on topic clusters explains the hub-to-spoke relationship in detail and then treats every spoke as interchangeable. They're not. The second spoke you publish in a cluster — the one that goes live after your initial hub-plus-one-spoke launch — is the highest-use link decision in the entire structure, and it's the one nobody walks through properly.
Here's why it matters more than spoke five or spoke nine: at the point you publish spoke two, your hub has exactly one internal link pointing at it from inside the cluster. Adding the second spoke doubles that signal, so the anchor text and placement decisions you make here set the pattern that every future spoke either follows or breaks. If spoke two links to the hub using the exact same anchor phrase as spoke one, you've already introduced anchor text repetition into a cluster that's only two pages deep, a problem that compounds with every spoke you add afterward.
The fix is simple but specific. Spoke two should link to the hub using a genuinely different angle on the keyword than spoke one used, not a synonym for the sake of variety, but a phrase that reflects how spoke two's specific subtopic relates back to the pillar concept. And spoke two is also your first real opportunity to test a spoke-to-spoke link, back to spoke one, because at this stage you can evaluate the relationship between exactly two pages without the noise of a ten-page cluster obscuring whether the link actually makes sense. Get spoke two right and the pattern holds. Get it wrong and you're untangling anchor text across a dozen pages eighteen months from now.
Common Mistakes That Break Link Equity Flow
Three mistakes account for most broken clusters we've reviewed, and they're rarely subtle once you know to look for them.
The first is orphaning spokes — publishing a new spoke, linking it from the hub, but forgetting to link it back to the hub because the writer assumed the hub link was "already covered somewhere." Equity flows both directions in a healthy cluster; a one-way relationship isn't a cluster, it's just a list.
The second is over-linking laterally. Founders discover spoke-to-spoke linking is good practice, then apply it everywhere, connecting every spoke to every other spoke like a fully meshed network. This actually works against you — it flattens the hierarchy so nothing looks more important than anything else, which is the opposite of what a hub-and-spoke model is supposed to signal.
The third, and the one that costs the most traffic long-term, is publishing overlapping spokes that compete with each other for the same query. If spoke three and spoke seven both target "how to find keyword gaps," you don't have a cluster problem, you have a cannibalization problem, and no internal linking pattern fixes that — you need to consolidate or differentiate the pages first. It's worth running a cannibalization check across your cluster before you spend more time optimizing the link map around pages that are fighting each other.
How This Differs From a Flat Internal Linking Structure
A flat internal linking structure links pages based on general relevance — anything mentioning "SEO" links to anything else mentioning "SEO," with no hierarchy implied. A topic cluster internal linking structure is deliberately hierarchical: one hub receives concentrated inbound links from every spoke, spokes link laterally only on narrow overlap, and the whole structure mirrors a table of contents rather than a web. Flat structures work fine for small sites under 20 pages. Past that, they stop signaling what actually matters most on your site, and that's exactly when a hub-and-spoke model starts outperforming it.
Building and Maintaining the Structure Without It Falling Apart
Clusters rot. That's the uncomfortable truth nobody puts in the intro of these guides. You build a clean 8-spoke structure in March, and by October you've published four more articles that touched on adjacent topics but never got wired into the cluster, because whoever wrote them didn't check the existing link map first.
The practical fix is treating your cluster as a living map, not a one-time diagram. Before publishing any new SEO content, check whether it belongs in an existing cluster or needs to start a new one, and if it belongs, add both the spoke-to-hub link and any legitimate spoke-to-spoke links at publish time, not "eventually." This is exactly the gap WriteGap's topic cluster planning closes: it maps your hub and spokes together so a new article gets slotted into the right cluster with the linking pattern already suggested, instead of relying on someone remembering the structure six months in.
It also helps to audit link direction periodically rather than assuming it's still correct. A quick pass through Search Console data can show you which spokes are actually passing traffic and ranking signal toward the hub and which ones are sitting isolated, a decent proxy for a cluster that's structurally sound versus one that only looks organized in a spreadsheet.
What to Do With a Cluster That's Already a Mess
If you're staring at a cluster of 15 articles with inconsistent linking, don't start over. Map what exists first: list every page, note which ones link to the hub, note which ones link to each other, and you'll usually find the damage is concentrated in a handful of pages rather than spread evenly. Fix the hub-to-spoke gaps first, since that's the highest-use repair. Then prune spoke-to-spoke links down to genuinely relevant pairs. Leave the rest alone — a cluster doesn't need to be perfect to work, it needs the core hub relationship intact.
How Do You Fix a Topic Cluster With Broken Internal Linking?
Start by identifying every spoke that doesn't link back to the hub — that's the single highest-impact fix, since a missing hub link is worse than a missing spoke-to-spoke link. Then check anchor text across all spokes for repetition, since identical phrasing across ten pages looks templated rather than natural. Finally, resolve any pages competing for the same keyword before touching the link structure further, since no amount of internal linking fixes two pages fighting for the same ranking spot.
If you're rebuilding a cluster from scratch, running your keyword gap analysis first tells you which spokes are worth building before you wire up any links at all — there's no point perfecting the internal linking structure around a spoke topic that was never worth targeting.