What Is an Internal Link Audit?

The audit maps exact source URL, destination URL, link placement and anchor, then groups issues such as broken destinations, redirect chains, orphan pages, dead ends, excessive depth, duplicated templates and irrelevant paths.

A useful audit produces prioritized actions with owners and verification steps. A spreadsheet of every internal link is an input, not the finished outcome.

• Defined website and subdomain scope
• Rendered page crawl
• Source-to-destination edges
• Anchor and placement context
• Status and redirect evidence
• Graph and page classifications
• Priority, owner and action
• Post-fix verification

1. Define the website scope and canonical host.
2. Crawl every allowed internal destination.
3. Build the source-to-destination link graph.
4. Classify issues by evidence and affected pages.
5. Fix the highest-value paths and crawl again.

An internal link audit connects exact link evidence with page purpose, graph role and accountable repair decisions.

Keep raw link edges beneath page-level summaries. A count cannot show which template created links, whether anchors are useful or whether one broken destination affects thousands of pages.

Join crawl results with sitemap, analytics, search landing pages, server logs, CMS records and conversion data where relevant. Label source and date because each system has different coverage and freshness.

• Source URL and page type
• Raw and final destination
• Response and redirect chain
• Canonical and index state
• Anchor or linked element
• Placement and template
• Rendered visibility
• Inlink, outlink and depth metrics
• Traffic, search and conversion evidence

1. Start with a fresh first-party crawl.
2. Normalize URLs without merging distinct pages.
3. Record every source page, destination and anchor.
4. Join page status, canonical and indexability signals.
5. Preserve the crawl timestamp for later comparison.

A trustworthy audit preserves exact edges and joins them with page, template and first-party outcome evidence.

Not every unusual pattern is an error. Legal footers naturally repeat, confirmation pages can be terminal and deep archival content may have limited prominence. Classify page purpose before assigning severity.

Use orphan page, dead-end page and link rot definitions consistently so one URL does not receive conflicting labels from different teams.

• Broken internal destinations
• Redirect chains and loops
• Orphan pages
• Dead-end pages
• Isolated content clusters
• Excessive crawl depth
• Noncanonical destinations
• Weak or misleading anchors
• Overlinked templates
• Missing hubs and breadcrumbs

1. Confirm the issue against the live source page.
2. Check the destination response and canonical state.
3. Identify every affected source before counting impact.
4. Separate broken behavior from intentional navigation.
5. Assign the repair to the page or template owner.

Consistent issue definitions keep technical, content and architecture teams working from the same graph evidence.

Include canonical host rules, subdomain decisions, URL parameters, case, trailing slashes and fragments in the crawl specification. A small normalization mistake can split one page into many nodes or merge distinct URLs.

Test desktop, mobile, authenticated and unauthenticated states when templates vary. A component can create a healthy graph for one user state and dead ends for another.

1. Define host, protocol and subdomain scope
2. Choose approved crawl entry points
3. Set parameter and fragment rules
4. Render JavaScript-dependent pages
5. Record raw and final destinations
6. Resolve redirects and canonicals
7. Capture anchor, placement and template
8. Repeat for important user states
9. Store crawl time and configuration
10. Validate representative pages manually

• Rendered and raw HTML link destinations where available
• Redirect chains and final response codes
• Canonical targets and robots directives
• Navigation, body, footer and template link locations
• Crawl timestamps and explicit exclusions

A reproducible audit records the crawl rules and verifies representative rendered pages before trusting graph-wide conclusions.

Raw link count can be dominated by global navigation and footers. Separate unique source pages, template links and contextual body links so a page with thousands of repeated edges is not mistaken for one with broad editorial support.

Use crawl depth as a graph measure, not a universal quality score. A page may be deep because it is archival, while a key conversion or reference page may need a shorter relevant path.

1. Calculate reachability from primary entry points
2. Measure shortest internal path
3. Count unique source pages
4. Separate template and contextual links
5. Identify hubs and isolated clusters
6. Map anchors to destination intent
7. Compare important pages with peers
8. Overlay traffic, search and conversion value
9. Flag structural exceptions
10. Open representative paths manually

• Pages receiving no crawlable internal links
• Important destinations buried behind long paths
• Templates creating repeated low-value links
• Anchors that do not explain destination context
• Clusters that are isolated from their parent topics

Graph metrics become useful only after template repetition, page purpose and real user value are included in the interpretation.

A navigation bug affecting every product page outranks one old blog redirect. A valuable orphan with backlinks and conversions may outrank thousands of low-value parameter URLs.

Group findings into incidents, batch template fixes, page-level improvements, architecture projects and intentional exceptions. Each action should name a source, destination or component and a testable completion condition.

1. Verify the issue on live representative pages
2. Measure affected pages and users
3. Identify shared template or release cause
4. Assess traffic, search and conversion value
5. Check backlinks to affected destinations
6. Estimate repair confidence and risk
7. Group duplicate findings into one event
8. Score impact and effort
9. Assign owner and deadline
10. Define post-fix verification

• User-facing links that return errors
• Important pages with no reliable discovery path
• Redirect chains repeated across shared templates
• Priority destinations placed unnecessarily deep
• Large link patterns whose fix affects many sources

The best priority queue groups root causes and ranks restored user value rather than sorting by the largest issue count.

Choose links because they advance the reader’s task, not because a tool recommends a target count. A relevant contextual path is more defensible than a mass-added footer link intended only to change metrics.

Update shared components at their source and verify every page type they reach. For migrations, link directly to final canonical destinations and preserve only redirects that serve valid external or historical paths.

1. Repair broken source-to-destination paths
2. Update links to final canonical URLs
3. Add relevant inlinks to valuable orphans
4. Add useful exits to dead ends
5. Create or improve topic hubs
6. Rewrite misleading anchors
7. Reduce irrelevant template repetition
8. Merge or retire obsolete pages
9. Test mobile and user-state variants
10. Recrawl affected scope

• Replace broken destinations at their source
• Link orphaned pages from genuinely relevant content
• Shorten unnecessary redirect chains
• Use descriptive anchors that fit the sentence
• Remove links that provide no navigation value

An internal link is fixed when its source context, technical path and final destination work together for the intended user journey.

Compare the same crawl scope and configuration over time. Track newly introduced issues separately from historical debt so releases can be evaluated without hiding regressions inside a large baseline.

Use the SEO tools system to connect findings, owners and retests. Cross-check externally linked destinations with Backlinks Explorer and the free Backlink Checker before retiring valuable URLs.

1. Save the baseline crawl configuration
2. Record issue and graph metrics
3. Retest completed fixes
4. Run checks after navigation and template releases
5. Compare new versus existing issues
6. Monitor linked high-value destinations
7. Alert the responsible component owner
8. Review intentional exceptions
9. Measure user and search outcomes
10. Run periodic architecture reviews

• Previously failing source and destination pairs
• Newly created orphan or dead-end pages
• Redirects introduced by migrations or publishing
• Changes in crawl depth for priority destinations
• Template changes that alter sitewide link patterns

Start with the free backlink checker for a representative source review, use the SEO tools system to connect crawl findings with repair work, and review Novaverb pricing when comparing ongoing monitoring with a one-time audit.

A link audit becomes a durable system when new releases are checked against a reproducible graph baseline and every regression has an owner.