Define the link graph you are actually auditing

Choose a public entry point and record the crawl scope before collecting data. Include the hostname, subdomain policy, robots handling, rendering mode and any URL exclusions. A crawl restricted to one directory cannot establish that a page has no links anywhere on the site. Its conclusion is narrower: no incoming links were found within the chosen graph.

Export source URL, destination URL, anchor text, link location, follow attributes and destination response. Keep redirects as separate observations rather than silently replacing every destination with its final target. You need to see both what the template publishes and where the request eventually arrives.

Define the audit population using the CMS and canonical inventory. Account screens and tracking variants should not compete with current product or service pages in the same priority list. The site architecture framework provides the planning context; the audit tests whether the intended relationships survive in production.

Gather evidence before interpreting low link counts

The evidence checklist includes a fresh navigation crawl, rendered checks for major templates, the live content inventory, sitemaps and a sample of Search Console landing pages. Join records using documented URL rules. Lowercasing a path or deleting all parameters may merge genuinely different pages, so preserve the original values alongside any comparison keys.

For each important destination, record distinct referring pages and link locations. Separate a repeated header link from editorial mentions. Neither is intrinsically bad, but they answer different questions. A global category link may provide a stable entry point; a contextual link can explain why a particular detail page is useful at that moment.

Inspect representative anchors in the browser and source. Confirm that ordinary destinations use anchors with usable href values. JavaScript-inserted anchors can be discoverable, but event handlers without equivalent links need closer testing. Document whether the audit actually rendered those templates before interpreting their absence from an HTML-only crawl.

Test competing explanations for weakly linked pages

A valuable page with few incoming links may be new, assigned to the wrong category, missing from a template query or intentionally excluded. Check publication time and expected parent before proposing more links. If a whole page family loses its parent relationship together, the likely repair belongs in the template or data model rather than individual copy edits.

Another possibility is measurement failure. The crawler may have stopped at a limit, ignored JavaScript or followed a different locale from the intended one. Reproduce a single missing edge manually: open the supposed parent, inspect the link and request its destination. One verified example can identify why thousands of records look anomalous.

Use orphan-page reconciliation when no incoming route appears in the captured graph. Keep that finding distinct from a claim that Google has never discovered the page. External links, sitemaps and historical crawls may all provide discovery outside your current internal crawl.

Assess anchors and placement as editorial evidence

Read the sentence around a link. The anchor should make the destination reasonably clear without forcing a string of keywords into the prose. Generic repeated labels become a problem when the surrounding context does not explain what differs between destinations. Product cards may use concise product names perfectly well; a troubleshooting article usually needs a more explicit next step.

Check whether navigation labels and destination headings describe the same task. A link labelled installation that opens a sales category creates a journey problem even if it is technically crawlable. Review image-only links for meaningful accessible text, and ensure hidden mobile controls do not remove essential routes.

Do not set an arbitrary sitewide anchor percentage or a minimum number of links per page. Those thresholds can encourage pointless additions. Instead, identify relationships the reader needs: prerequisite instructions, supporting definitions, alternatives and the appropriate next action. Remove or rewrite links that interrupt those tasks rather than treating every extra edge as an improvement.

Find broken, indirect and contradictory routes

Group links pointing to errors, redirects and non-preferred URL variants. Fix the source when a template repeatedly links through an unnecessary redirect. A functioning redirect protects old references, but it should not become the default publishing path for newly generated navigation. Confirm the final target is actually equivalent before replacing links in bulk.

Inspect links that append tracking or sorting parameters to canonical detail pages. The same component can reproduce a poor destination across the whole site. Also review internal nofollow usage where it appears to be an attempted architecture control. It does not substitute for deciding which URLs the application should generate or which pages belong in navigation.

Compare suspicious destinations with their canonical declarations and sitemap representation. A mismatch is evidence to investigate, not proof that a single signal caused a search outcome. The canonical tags guide helps establish whether the destination represents a genuine duplicate or a separate page that needs its own links.

Worked example: a publishing component drops a family

Illustrative example: a support centre publishes device setup guides, but the category grid includes only records tagged as articles. The guides appear in the sitemap and receive occasional visits, yet a homepage crawl cannot reach them. Adding a footer list would expose the URLs while leaving the faulty publication rule intact.

Compare one missing guide with a visible article. Confirm both are published, accessible and assigned to the same support category. Inspect the component query and reproduce the missing content-type condition in a test environment. Then change the grid to include the intended guide type and define how unpublished or superseded guides are excluded.

After release, crawl from the support homepage without seeding sitemap URLs. Every retained guide in that category should be reachable through the grid, with correct anchors and direct destinations. The example supports a specific engineering conclusion: a query omitted a content type. It does not establish how much search traffic the repair will produce or whether every omitted page deserves indexation.

Write acceptance criteria around edges and behaviours

For each issue, provide a source example, current destination, expected destination, affected template and reproduction steps. Explain the inclusion rule in plain language. A developer should be able to decide whether a newly published record passes without consulting the audit spreadsheet. That is more durable than a list of URLs to patch once.

Require checks for links before and after rendering, where relevant, plus mobile navigation and pagination boundaries. Confirm destinations return their intended statuses and that the repaired component does not expose drafts, archived content or private records. Include a fresh record in testing; an existing sample alone will not prove the publication lifecycle works.

For larger changes, compare distinct destinations by page family before and after deployment. Investigate unexpected losses rather than assuming a higher total is better. Use SEO release QA to preserve representative cases and capture the deployed evidence, including any known exceptions accepted by the content owner.

Prioritise repairs and preserve a rollback

Prioritise missing routes to valuable current content, widespread broken template destinations and accidental URL proliferation. A minor anchor improvement on one low-use article is usually a smaller job than a navigation query excluding an entire supported product family. State the business purpose and affected population rather than relying on a generic severity label.

Keep a versioned copy of changed components and the source records used for bulk edits. If an automated replacement links to the wrong regional or product variant, you need a precise reversal. Reverting only the visible anchor text will not repair a bad destination mapping. Test the reverse operation before applying a large content migration.

Finally, retain the audit’s limits: crawl coverage, missing historical data and templates not rendered. Recrawl after the next publishing cycle to verify the rules remain effective. Immediate ranking changes are not reliable proof of causality; direct evidence that intended routes now exist is the first success criterion.

Frequently asked questions

How many internal links should an important page receive?

There is no defensible universal count. Look for stable links from appropriate hubs and relevant contextual mentions. Compare similar page families to find outliers, then inspect the actual journeys. Ten useful referring pages can support a clearer route than hundreds of repeated links in an unrelated component.

Should all internal redirects be removed?

Update maintained links to the final intended URL where practical, especially repeated template links. Retain redirects that still protect old references. Before bulk changes, confirm the target is the correct equivalent and check locale, product variant and publication state. A technically successful redirect can still send users to the wrong place.

Are JavaScript links automatically an audit failure?

No. An anchor inserted by JavaScript can be crawlable when it has a valid href. The important questions are whether it actually renders, whether essential routes depend on user interaction and whether your crawler captured it. Compare source, rendered output and a direct destination request before classifying the issue.

Can I automate the whole audit?

Automate extraction, joins and regression checks, then review purpose and context manually. Software can flag broken destinations or missing expected relationships. It cannot reliably decide whether a sentence needs another link or whether two categories support genuinely different tasks. Preserve examples so editorial and technical reviewers can assess the same evidence.

Technical references