How to Create an Internal Linking Map: Example and Template

An internal linking map is a record of which pages link to which destinations and why. A diagram can make a small set of relationships easier to inspect, but a source-to-target table makes changes easier to assign and verify.

Use this guide when you need to plan links across several pages. For individual anchor markup, nofollow attributes and link counts, start with the internal linking fundamentals guide.

Define the inventory before drawing a map

Choose the website, host boundaries and page types in scope. Record the inventory source and date: for example, a CMS export, repository route list or controlled crawl. Compare sources where possible. A sitemap can supply candidates, but may omit deliberate exclusions and does not describe which page links to which.

Keep useful published pages, intentional redirects, restricted pages and retired URLs distinguishable. Do not add links to every URL merely because it exists in an export. Confirm each destination’s intended purpose and canonical address first.

A crawl that follows links cannot by itself prove it found every unlinked page. Compare its discovered URLs with an independent inventory before investigating possible orphans. Say “no incoming links found in this sample” when that is all your evidence establishes.

Download the source-to-target template

Download the blank internal linking map CSV and the worked example CSV. Open either in a spreadsheet or text editor. The example is a proposed editorial plan using real Overhyped routes, not a measured crawl or a completed implementation.

Use one row per source, destination and placement. Two links to the same destination in different parts of a page may need separate rows.

Keep observed evidence separate from editorial suggestions. An attractive diagram must not turn a planned link into a claimed live connection.

A worked internal linking map

Suppose an editor reviews four Overhyped pages: the tools directory, Internal Link Checker, this mapping guide and the internal linking fundamentals guide. These are real routes, but the relationships below illustrate a plan rather than certify the current site.

A compact internal link visualization of that proposal is:

Tools directory → Internal Link Checker
Fundamentals guide → Mapping guide → Internal Link Checker
Fundamentals guide ← Mapping guide

The arrows show direction, not authority scores, crawl depth or a guarantee of discovery. The downloadable example preserves the same four proposed relationships and labels each one proposed.

Collect observed links without inventing coverage

Use the Internal Link Checker for an individual source page, or an appropriately scoped crawler for a larger inventory. Record the final source URL after redirects and resolve relative destinations against it. Store the observed anchor text, placement and relevant relationship attributes.

The checker reads initial HTML. If links appear only after client-side rendering, inspect the rendered page separately. Keep authenticated or excluded routes outside automated scope unless access is explicitly authorized.

Destination health is a separate check. A declared link can point to a missing page, a redirect or a response blocked for an automated client. Use the Broken Link Checker where its bounded sample is appropriate, then review ambiguous responses before changing the map.

Use data to choose useful changes

Data driven internal linking means using evidence to make an editorial decision. It does not mean adding every suggested link or treating a keyword’s search volume as proof that a destination deserves more links.

Prioritize broken links on important journeys, useful pages with no incoming links found within a well-defined inventory, and contextual gaps where readers need the next explanation. If Search Console or analytics is available, it can help identify pages and journeys worth reviewing; a traffic change alone does not establish that internal links caused it.

For each proposed link, complete this sentence: “A reader here may need this destination because…” If there is no clear answer, leave it out. Preserve necessary navigation, deliberate restrictions and qualified link relationships. Avoid site-wide exact-match anchor replacements or links between unrelated pages solely to repeat a keyword.

Google’s link best practices support descriptive, contextual anchors. Use that principle instead of imposing an arbitrary number of links per page.

Verify each implemented row

1. Review the proposed source, target, wording and reason with the responsible editor.
2. Add a real anchor with a resolvable href in the agreed location.
3. Check the generated source and rendered page where needed. Open the destination and confirm it delivers the intended content.
4. After approved publication, fetch the public source again and record the release and verification dates. Keep intentional redirects, canonicals and indexing controls intact.
5. Mark the row verified only when those checks pass. Otherwise leave its actual state and explain what remains.
6. Re-run the scoped crawl when needed, using comparable boundaries, and compare the observed graph with the independent inventory.

A verified live link is evidence of the implementation. It does not prove that Google has recrawled it, indexed the destination or increased impressions. Record those outcomes separately when reliable evidence becomes available.

Method note: the four-row example is a proposed editorial plan, not a site-wide audit. The CSV files contain no private analytics or client data. Last reviewed 18 October 2026.