Internal Linking for a Content Library: Graph Design Against Orphans

A content library should treat internal linking as graph engineering: designed link types, an equity-spreading generator, and a CI check that reads the whole graph — because the failures that matter are invisible at page level. Ours proved it: naive alphabetical related-links left 74 of 176 pages with zero inbound internal links while 3 pages collected 83 links each, and nothing looked wrong on any individual page [our data].

That collapse, its discovery, and the sprint that produced it are documented in the 100-pages-in-a-week field report. This page is the design that came out of it, as steps you can copy.

Why does internal linking fail at library scale?

Because links get chosen per page while the failure mode lives in the distribution. Every page in our collapsed graph had a plausible-looking related-links block; the defect — 74 pages nobody linked, 3 pages collecting 83 links each — only existed in aggregate, where nobody was looking [our data]. Hand-curation fails the same way at scale: humans maintain the links they remember, and a 150-page library exceeds what anyone remembers.

The stakes are discovery. Google's documentation lists links from already-crawled pages among the primary ways new pages are found (Google, Search Essentials), so an orphan depends on the sitemap alone — one discovery path where the linked page has several, plus the crawl-frequency and context benefits links carry. An orphan is also invisible to every reader actually navigating the site.

What link types does a content library need?

Four, with different owners and different failure modes — the separation is what makes the graph checkable [our data]:

The up-link rule keeps every page one hop from the spine of the site — on this library, every page links up toward the flagship pillar — while the editorial layer carries actual judgment: which page a reader should visit next, linked from the sentence where the need arises.

How do you spread link equity deliberately?

By making inbound distribution an explicit constraint on the generator, not a byproduct of whatever ordering fell out of the file system. The naive version picked siblings alphabetically — an incidental ordering with degenerate cases, which is exactly what produced 3 pages with 83 inbound links [our data]. The rebuilt generator works from the content graph: related pages by cluster and topic, a floor under every page's inbound count, and a scoring penalty that grows with the links a page has already collected.

Floors and penalties are the whole trick. A minimum inbound count is what makes orphans structurally impossible rather than merely unlikely, and the concentration penalty steers the generator past the same few hub pages. Everything else — which related page is most related — is refinement on top of a distribution that is already sound.

Anchor text is the editorial layer's contribution to the same goal. A link that says what the destination answers — in the destination's own terms — gives readers and crawlers the context a bare "read more" never carries, and it costs nothing beyond writing the sentence properly the first time.

How do you verify the link graph?

In CI, on every build, because every tranche reshapes the graph. Our build runs 2 graph-level checks: every editorial link target must resolve to an existing page — a link to an unshipped slug fails the build — and inbound counts are computed across all routes with the orphan list required to be empty [our data]. A one-time link audit is a snapshot of a moving structure; the 74-orphan graph would have passed any audit run before the sprint that created it.

The retrofit step closes the loop: when a tranche of new pages lands, the live hub pages it extends get edited in the same commit to link down to them — so no new page starts life depending on the generated graph alone.

This is also a fleet-production dependency: parallel writers linking same-tranche pages only works because the gate confirms every target exists at build time — the coordination mechanics are covered in parallel page production, and the full system in the authority engine.

Does internal linking help AI citations?

The documented benefit is discovery and coherence; anything beyond that is unproven, and we say so. Links from known pages are a primary discovery path in Google's documentation, and AI crawlers fetching your pages follow the same graph. No study on our source list connects internal-link architecture to citation rates in AI answers — we treat that link as plausible but unmeasured, and we build the graph for the benefits that are documented.

Against our own interest, one scope note: a 15-page site does not need graph tooling. Hand-link the pages, check them quarterly, done — the engineering in this guide pays off somewhere past 100 routes, when no human can hold the inbound distribution in their head. Our record just shows what happens at 176 routes when nobody checks [our data].