Internal Linking: A Practical Guide for Content Teams

Say you run content for a mid-size B2B software company. You've got 140 published articles, a handful ranking well, most sitting quietly on a few hundred visits a year. Nobody has ever deliberately linked one to another. That's the state most content libraries end up in, and it's the scenario this internal linking guide will follow from one messy cluster to a working system. We've run this exact fix across content libraries of similar size, and the pattern repeats almost every time: one strong page, nine orphans, zero deliberate connections.

Google's own crawling documentation is blunt about the stakes: pages worth ranking need at least one internal link pointing to them, or they risk never getting found properly at all (Google Search Central). A Semrush audit of live sites found 88.6% had pages with only a single internal link, and 38.6% had pages sitting more than three clicks deep (Semrush). This isn't a niche failure. It's closer to the default state of an unmanaged library, and treating it as an ongoing workflow rather than a once-a-year cleanup is the whole shift this guide is arguing for.

Start with one cluster

You don't fix 140 articles in a week. You fix one topic properly and use it as the template for everything after.

Pull every article touching "onboarding" into a list. You'll find customer onboarding pieces, employee onboarding pieces, an onboarding email sequence, a couple of onboarding checklists, eight or ten in total, written months apart by different people, each treated as though it were the only article on the subject. None mention each other. One is clearly the strongest, most complete piece on the topic, and it has zero links pointing to the other nine.

That's the pattern almost every unmanaged library falls into. Articles get written to a brief, published, then forgotten. Nobody circles back to ask how this new piece relates to the twelve other things already said on the same subject, so the connections that should exist by default simply never get made. Building linking into the publishing step, rather than saving it for a quarterly audit, is what stops the gap from reopening every time someone hits publish.

The shape of the cluster changes by site type but the logic holds everywhere. An ecommerce category might have forty product pages under "waterproof jackets," none cross-linking to sizing guides. A documentation hub has API reference pages written in isolation, never pointing back to the getting-started guide or sideways to the endpoint a developer would naturally check next. What differs is which pages count as the cluster and how obvious the grouping is once you actually look. Pick one, work it properly, and the mechanics repeat everywhere else.

A rough checklist for picking your first cluster:

• One topic, named plainly, that already has eight or more articles touching it
• One clear standout piece that's already ranking or getting the most traffic
• At least a few pages that are clearly related but never mention each other
• A cluster small enough to finish in a day, not a project

Pick the hub

The hub is the broad, authoritative page a topic should orbit. Everything narrower underneath it is a spoke, and the two directions of linking both matter. Spokes link up to the hub, and the hub links back down to every spoke, not just the first three that got built during launch week.

In the onboarding cluster, the hub is "The Complete Guide to Customer Onboarding," a 3,000-word piece already covering the topic end to end. The spokes are pieces like "Async Onboarding for Remote Teams," "A 30-60-90 Day Onboarding Template," and "Common Onboarding Mistakes." The actual edits look like this. A link from the hub's "planning your first 90 days" section down to the template article, placed in the paragraph itself rather than dumped into a related-posts block. A link from "Common Onboarding Mistakes" up to the hub, added in the intro rather than buried at the bottom. A sideways link from the async piece to the template, because a remote team building a schedule genuinely benefits from seeing both.

A hub-and-spoke cluster is easy to picture. One central page sits in the middle, several narrower pages link up to it, and a few of those narrower pages link sideways to each other where the topics genuinely overlap. If you're mapping this out for the first time, sketching it on paper or in a slide, hub in the middle, spokes around it, arrows showing which direction each link runs, is often faster than trying to hold the whole structure in your head.

Google's sitelinks documentation supports this structurally. It says its systems analyze link structure to work out important pages and the relationships between them, and recommends linking important pages from other relevant pages rather than leaving them to stand alone (Google Search Central). A hub with no spokes pointing at it looks, to a crawler, exactly like a page nobody thought was worth referencing. Until you link it, that's technically accurate.

Worth separating this from navigation and breadcrumbs. Those tell a crawler how the site is organized structurally. A contextual link inside a paragraph tells a crawler, and a reader, that two specific pieces of content are related in substance. A page can sit neatly in a nav menu and still be functionally isolated if nothing in body copy ever points to it. That's the gap most teams miss, because the nav menu looks like proof the linking work is already done.

Write links that explain the destination

Anchor text should describe what's on the other side of the link, in plain language, before the reader clicks. Google's link guidance says as much directly, noting that anchor text helps people and search engines understand the destination page, and warning against stuffing anchors with exact-match keywords as a shortcut (Google Search Central).

"We covered this here" tells nobody anything. "Our guide to structuring a 30-60-90 day onboarding plan" tells the reader exactly what they're getting, and it costs nothing extra to write the second version instead of the first. Vary the phrasing across different mentions of the same page too. A page linked ten times with the identical anchor "customer onboarding guide" reads as engineered, even when nobody meant it that way, and it wastes the chance to describe the destination slightly differently each time context allows for it.

Use the pages already earning traffic

Your best-performing article should link into your weakest ones. A link from a page with real traffic does more for a struggling page than a link from another struggling page ever will, because it's passing along signal that's actually there to pass.

Pull analytics for the onboarding cluster and you'll typically find one article, maybe "Common Onboarding Mistakes," quietly pulling in most of the organic visits while the rest sit near zero. That page is the lever. Adding two or three genuinely relevant links from it into the thinner, newer articles in the cluster is one of the highest-leverage edits available, and it takes minutes rather than hours.

In the 140-article library this guide opened with, that single fix, three new contextual links added to the one high-traffic mistakes article, was enough to pull two previously stagnant spokes out of the "a few hundred visits a year" range within a couple of months. Nothing else about those two pages changed. The content, the title, the URL all stayed the same. The only variable was a working link pointing at them from a page Google already trusted.

This matters more than it might sound like it should, because organic traffic is brutally concentrated across most sites. Don't overcorrect into turning the strong page into a directory, though. Three to five contextual links inside the body is usually the ceiling before the page starts reading like a sitemap instead of an article someone wrote to be read.

Fix orphans and keep the system current

Find orphans and dead ends before building anything new, because both quietly damage a library and neither shows up unless someone goes looking for them.

An orphan page has no internal links pointing to it at all. A dead end has links coming in but none going out, leaving a reader with nowhere else to go once they finish. In the onboarding cluster, orphans tend to be the older pieces nobody remembered to update once the hub launched. Dead ends are usually the newer articles, written well in isolation but offering no next step.

Paginated archive pages are their own category of problem, and the fix isn't a normal content link at all. Google recommends linking every page in a paginated set back to page one of that series, to reinforce where the collection actually starts (Google Search Central). Archive pages are exactly where orphaned older content tends to hide, mostly because nobody thinks to check them.

Canonical mistakes belong on this list too. When linking within your own site, link to the canonical URL rather than a parameter-heavy or duplicate version of it. Google's guidance on consolidating duplicate URLs calls this out specifically, since linking to the wrong version undercuts the very signal the link was meant to send (Google Search Central). Teams running UTM-tagged links or filtered archive views hit this constantly, usually without noticing.

Screaming Frog and Sitebulb both surface orphans and dead ends this way, crawling a site and reporting crawl depth and internal link counts per page, and Google Search Console's Links report will show you which pages have the fewest internal links pointing in. Running that report against the onboarding cluster is usually how the zero-link hub gets noticed in the first place. Cross-checking the crawl report against Search Console's own link counts catches the gap faster than trying to trace paths by hand.

A short list to work through, in order:

• Run a crawl and flag anything with zero internal links pointing to it
• Flag anything with links in but nothing linking out
• Check paginated archive pages link back to page one of the series
• Check links point to canonical URLs, not parameter-heavy duplicates

None of this holds if it only happens once. When a new spoke goes live, it should link up to the hub, receive a link or two from older relevant articles, and link out to something the reader would plausibly want next. Building that into the publishing step, rather than leaving it as a task someone means to circle back to, is the difference between a cluster that stays connected and one that quietly comes apart again within a few months.