Internal Link Mapping: See Your Site the Way Google Does

An internal link map is a picture of your site as a graph: every page a node, every contextual link an edge. It's the closest you can get to seeing your site the way Google's crawler does: not the tidy hierarchy in your CMS, but the actual mesh of links that determines what gets discovered, what accumulates authority, and what sits invisible three hops past anything important. Building one takes an afternoon with a crawler export and a spreadsheet; reading one changes how you prioritize the next quarter of SEO work.

What a link map is (and what it isn't)

Your sitemap is a list. Your navigation is a tree. Your link map is neither: it's the directed graph formed by in-content links between pages, and it's the structure crawlers actually traverse and PageRank actually flows through.

The critical decision is what counts as an edge. If you include every header, footer, and sidebar link, every page "links to" every other page in the template, and the map collapses into a useless gray ball where everything is one hop from everything. Boilerplate links are also heavily discounted by Google's link weighting, so the ball isn't just unreadable; it's wrong. Map contextual, in-prose links only. (This is why LinkAgent's crawler excludes navigation, header, footer, and sidebar links when it builds a site's graph: the map you act on should contain only the links that carry weight.)

Three properties of each node make the map useful:

• Inbound in-text links: how many contextual links point at the page. The map's measure of internal authority and, below ~1–2, its orphan detector.
• Click depth: the shortest link path from the homepage. Depth predicts crawl frequency; pages beyond three or four clicks are on the map's periphery in every sense.
• Topic: what the page is about, so you can see whether related pages actually connect to each other. Structure without topical coherence is just plumbing; the internal link structure you want is one where clusters of related pages are densely connected internally and wired to their pillar.

Building a link map manually

You need a crawler that exports link-level data: Screaming Frog is the usual choice; any crawler with an "all inlinks" export works.

Step 1: Crawl and export edges. Crawl the site, then export the inlinks report: one row per link, with source URL, target URL, anchor text, and (crucially) link position/type if your crawler provides it, so you can filter to content links and drop navigation. Screaming Frog's "link position" column (content vs. navigation vs. footer) makes this filter possible; without it, you'll drastically overcount.

Step 2: Build the node table. In a spreadsheet or a script, aggregate per URL: count of contextual inbound links, count of contextual outbound links, click depth (crawlers report this directly), and a topic/section label (derivable from URL path for most sites: /blog/, /docs/, /products/).

Step 3: Sort and flag. Before any visualization, three sorts give you 80% of the findings:

Cross-reference the sitemap against crawled URLs: any sitemap URL the crawler never reached via links is a true orphan the crawl itself couldn't see.

Step 4: Visualize if it helps. Force-directed graph tools (Gephi is the classic; Screaming Frog has built-in crawl visualizations) turn the edge list into the familiar node-and-cluster picture. Visualization is genuinely useful for spotting shape: islands, one big blob vs. distinct clusters, and genuinely useless for deciding individual links. Use the picture for diagnosis, the sorted table for the work list.

The manual build's real cost isn't the first afternoon; it's that the map is stale the day after you build it, which is why the maintenance section below matters more than the tooling.

Reading the map: hubs, islands, and dead ends

A link map rewards the same reading skills as any network diagram. Four shapes to look for:

Hubs. Pages with far more inbound links than anything else: typically the homepage, the blog index, and a few old high-performing posts. Hubs aren't a problem; wasted hubs are. Check each hub's outbound contextual links: a page holding 80 inbound links whose body copy links to nothing is a reservoir with no outlet. Your strongest hubs should link, in prose, to the pages you most want to rank.

Islands. Groups of pages that link to each other but have few or no links from the rest of the site: a documentation section only reachable through one index page, an old campaign microsite, a blog category nobody cross-links. Islands get crawled through a single chokepoint and share almost no authority with the mainland. The fix is bridges: contextual links from topically related mainland pages into the island's key pages, and outbound links from the island back.

Dead ends. Pages with inbound links but zero contextual outbound links. Every reader and every unit of link equity that arrives stops there: the opposite of how internal linking is supposed to work, where every strong page passes authority onward. Long-form posts are the usual culprits: 2,000 words, no internal links out. Dead ends are the cheapest fix on the map: the page exists, it has authority, it just needs its mentions of other topics turned into links.

True orphans. In the sitemap, zero contextual inbound links anywhere. Discoverable only by sitemap, receiving no internal authority, sending no relevance signals. Decide per page: link it (3–5 contextual inbound links from related pages), merge it, or prune it. Orphan pages are common enough to deserve their own workflow.

Click-depth heatmaps

Depth deserves its own view because it's invisible in a force layout. Bucket every URL by click depth and look at the distribution, and more importantly at which pages sit in each bucket:

The heatmap version (coloring your site's sections by average depth) makes the pattern legible instantly: if /blog/2022/ glows red at depth 6 because the only path is Next-page pagination, you've found a structural problem no individual link will fix (fixes: bigger archive pages, year hubs, contextual links from newer evergreen posts to the old pieces that still matter). Depth is a function of your whole site structure, and the heatmap tells you whether to fix links or fix architecture.

Acting on the map

A map you don't act on is decoration. Convert each shape into a work item, in priority order:

1. Orphaned or buried money pages: highest value per link. Add contextual links from hubs and topically related pages until each sits at depth ≤3 with a handful of real inbound links.
2. Dead-end hubs: add outbound prose links from your strongest pages to priority targets. This is routing authority you already have.
3. Islands: bridge them or consciously decide they don't matter (then prune).
4. The long tail of near-orphans: batch by topic and work through them on a schedule, at sane densities (about one new link per 250 words of source copy, spread across many targets rather than piled on one).

Then accept the uncomfortable truth: the map decays. Every published post, pruned page, and rewritten paragraph edits the graph. The durable version of link mapping isn't a diagram you frame; it's a crawl that re-runs on a schedule, recomputes inbound counts, depth, and orphan status, and turns the diffs into a review queue. That's the model behind LinkAgent's internal link audit: sitemap-plus-link crawl, contextual-only graph, TF-IDF topic clustering so "related pages that don't link" is computable, and orphan/depth detection that stays current with weekly or monthly re-crawls instead of going stale in a spreadsheet.

Google doesn't see your org chart, your CMS categories, or your intentions; it sees the graph. Map it once and you'll find problems; keep it mapped and you'll stop creating them.