Internal Linking for Topical Authority: The Hub–Spoke–Mesh Method

Structure internal links in three layers: a hub, where your pillar page links down to every supporting article in the cluster; spokes, where every supporting article links back up to the pillar; and a mesh, where supporting articles link sideways to each other when their topics genuinely overlap. Use anchor text that names what the destination page is about — never "click here." Do that, and Google can read your cluster as one connected body of expertise instead of a pile of disconnected posts.

That's the Hub–Spoke–Mesh method. The rest of this page shows you how to build each layer, what anchor text to use, and how to map your whole cluster in about 30 minutes.

Why this matters: internal links are how search engines understand your site's structure. Google's Search Central documentation is explicit that internal links help Google discover pages and understand how pages relate to each other. Topical authority — the thing you're building when you build out a content cluster — isn't judged article by article. It's judged as a system. Links are what make it a system.

There's also a newer reason, one most internal linking guides skip entirely: your link structure shapes which of your pages AI assistants can retrieve and cite. We'll get to that, including an embarrassing story from this very blog.

One honest caveat before we start. Internal linking won't rescue thin content, and it's not a substitute for a real topical map. It's connective tissue, not muscle. But it is the one authority lever you control completely. No outreach. No backlinks. No waiting on anyone. You can fix it this afternoon.

The hub is your pillar page — the long guide that covers your core topic end to end. In the Hub–Spoke–Mesh method it has one linking job: link down to every supporting article in the cluster. Every single one.

Three rules make hub links count:

1. Complete coverage. If the hub doesn't link to a supporting page, that page is invisible inside your own architecture. You wrote it, but your site never points at it. No exceptions, no "we'll add it later."
2. Body links, not widgets. A link inside a paragraph, surrounded by sentences about that subtopic, tells Google exactly why the two pages are related. A "related posts" card at the bottom of the template says almost nothing. Keep the cards if you like them — they don't replace in-body links. We learned this one the hard way, and the AI-citation section below has the receipts.
3. Anchors name the subtopic. The link to your anchor-text article should say something like "anchor text strategy for internal links," not "this post." The anchor is the label Google reads.

If you can't say which page your hub is, you don't have a linking problem — you have a structure problem. Sort that first: our guide to topic clusters covers how pillars and supporting pages fit together.

Most sites that attempt internal linking get the hub layer roughly right. It's the next two layers where things fall apart.

A spoke is any supporting article in the cluster. Its linking job: one in-body link back up to the pillar, placed early — ideally within the first few paragraphs, where you naturally reference the broader topic anyway.

The two-way part is the whole point. Hub links down, spoke links up. That closed loop lets a crawler enter the cluster from any page and still find everything else. A spoke without a return link is a dead end, and every dead end weakens the signal that these pages belong together.

Here's the failure pattern I see constantly, including in our own early cluster: the pillar links out to all twelve supporting articles, seven of them link back, five don't. Nobody decided that. It happened one forgotten link at a time, across weeks of publishing. Memory is not a linking strategy — which is why the 30-minute exercise below uses a spreadsheet.

Anchor guidance for the return link: name the pillar's topic, and vary the phrasing from spoke to spoke. If ten spokes all link to the pillar with the identical exact-match anchor, that's a template artifact, not a natural pattern. "Building topical authority from scratch," "our full topical authority guide," "what topical authority is and how to earn it" — same destination, natural variation, each one still naming the topic.

One more placement note: put the return link where the pillar's topic actually comes up in your prose. Don't bolt a "Read our ultimate guide!" sentence onto the intro. If the article never references the broader topic, that's a sign the article may not belong in the cluster at all.

The mesh is the layer most sites never build: links between supporting articles. Sideways, not up and down.

Why bother? Because hub-and-spoke alone is a wheel, and real expertise doesn't look like a wheel. Your article on anchor text naturally touches your article on orphan pages. Your audit guide naturally references your measurement guide. When siblings cite each other, you're demonstrating that your pages exist in relationship — a web of knowledge, not a hub with satellites. That interconnection is much harder for a competitor to fake with a content calendar.

The test for a mesh link is one question: does this article already mention, assume, or clearly benefit from the sibling's concept? If yes, link at exactly that spot. If you'd have to write a new sentence just to hold the link, don't. Forced mesh links read as filler to humans and dilute the meaning of your anchors for machines.

What this looks like in practice — this is opinion from running our own clusters, not a study: one to three mesh links per supporting article is the normal range. Zero usually means you missed a real connection. Six or more usually means you're linking on keyword match instead of actual conceptual overlap.

And do not full-mesh. Linking every page to every page feels thorough and signals nothing, because it treats every relationship as equally strong. The information in a mesh is in its selectivity. You're drawing a map of which ideas actually touch. A map where everything connects to everything is a map of nothing.

Anchor text is the visible, clickable text of a link. It does two jobs at once: it sets the reader's expectation and it tells the search engine what the destination page covers. Generic anchors waste both.

Do this:

• Name the destination's topic in the anchor. "How to run a topical authority audit," not "this post."
• Write the sentence first, then link the phrase that already names the topic. Natural anchors fall out of natural sentences. If no linkable phrase exists, the link probably doesn't belong there.
• Vary your phrasing across links to the same page. Different articles should describe the destination slightly differently, the way different people would.

Avoid this:

• "Click here," "read more," "this article." Blank labels. You're handing the engine an unlabeled box.
• The identical exact-match anchor on every link to a page. Uniformity is what templated linking looks like; variation is what real linking looks like.
• Anchors that overpromise. If the anchor says "step-by-step checklist" the page had better contain one. Readers bounce off bait, and you're training them not to click your links.

By layer, it breaks down like this. Spoke-to-hub anchors name the pillar's broad topic. Hub-to-spoke anchors name the specific subtopic. Mesh anchors name the sibling's concept in the natural flow of the sentence.

Honest sizing: anchor text is a modest signal on its own. It compounds inside a sound Hub–Spoke–Mesh structure, and it rescues nothing without one. Get the structure right first, then make the labels accurate.

Yes — indirectly, but decisively. Work the chain backwards. An AI assistant can only cite a page it retrieved. Google's AI answers draw on the same index as regular search, and assistants that browse the web find pages through search-style retrieval — indexes and crawls, same as a search engine. A page that isn't indexed can't be retrieved, and a page that can't be retrieved will never be cited. Internal links sit at the start of that chain: they give crawlers paths to your pages and give engines context about what each page covers.

There's a second effect people miss. When several of your pages touch the same topic, your internal links are a vote for which one is canonical. If your anchors consistently point "what is X" phrasing at one page, you're telling every retrieval system which page deserves the citation for that question. If your links are random, you've left that choice to chance.

Orphan pages are the extreme case: zero internal links pointing in, no context, no paths, weak crawl priority. Orphan pages don't get cited.

Now the embarrassing part. This site shipped thirteen articles in its topical authority cluster with zero internal links in the article bodies. The related-articles cards were there. The in-body links were not. Google indexed none of the thirteen. Zero.

I won't claim the missing links were the only cause — indexing failures usually have more than one parent, and we fixed several things at once. But pages with no in-body links gave Google no paths between them and no evidence they formed a cluster. Every article was an orphan in practice, whatever the sitemap claimed. The Hub–Spoke–Mesh method is the linking structure we built during that repair. This isn't theory we read somewhere; it's the manual we wrote from our own wreck. It's also why Inbounder now places internal links directly into the outline when it plans a cluster — hub, spoke, and mesh links are specified before drafting starts, so they can't be forgotten afterward.

Block 30 minutes and open a spreadsheet. You're building a link map — a one-tab inventory of your cluster's actual link structure. Here's the founder version, timeboxed.

Minutes 0–5 — inventory. One row per cluster page. Four columns: URL, role (hub or spoke), links out (to cluster pages), links in (from cluster pages). If you already built a topical map, this is copy-paste.

Minutes 5–10 — hub pass. Open your pillar. Confirm it links to every spoke, in the body, with an anchor that names each subtopic. Add whatever's missing right now, not "later."

Minutes 10–20 — spoke pass. Open each supporting article. Confirm one early in-body link back to the pillar with a descriptive anchor. Fill in the links-out column as you go.

Minutes 20–27 — mesh pass. For each spoke, ask: which sibling does this article already mention or assume? Add one to three sideways links where a sentence already wants one. Force nothing.

Minutes 27–30 — orphan check. Sort by links-in. Any page at zero is an orphan. Give it two or three inbound links from its most relevant siblings today.

That's it. You now have something most competitors don't: an actual map of how your cluster connects, plus the fixes already shipped. Two habits keep it alive. First, plan links before drafting each new article — decide its hub link and mesh links in the outline. Second, re-run this exercise monthly; a fuller topical authority audit each quarter catches coverage gaps this map won't.