A broken link report is only a list of observations. The useful work starts when you connect each result to a source page, decide whether the destination should still exist, choose the right repair, and verify that the visitor now reaches a meaningful page. This broken link audit workflow turns a scan into a controlled maintenance process instead of a rushed exercise in redirecting every error.
The method is designed for site owners, editors, developers, and SEO teams working on a public website. It works for a focused page review, a small-site crawl, or a post-migration check. It does not assume that every failed request is a search problem or that every redirect is harmful. The goal is simpler: protect real user journeys and keep the internal structure accurate.
How should you define the audit scope before scanning?
Start by writing down why the audit is happening. A migration review has different risks from a routine content cleanup. After a migration, old internal URLs, protocol changes, and redirect destinations deserve close attention. Before a campaign launch, the important paths are the landing page, primary calls to action, legal links, and supporting resources. During routine maintenance, repeated sitewide errors may be more valuable than a single old citation.
Choose a starting URL that represents the work. The homepage is useful for a broad small-site review, while a category or article URL is better for a contained audit. Decide whether external links are in scope. External checks add context, but they also create more ambiguous results because another server can block, rate-limit, or time out an automated request.
Record the following before the scan:
- the starting URL and intended crawl boundary;
- the event that triggered the audit;
- the page types that matter most;
- whether external links should be checked;
- the person responsible for content, redirect, and deployment decisions;
- the evidence required to call a repair complete.
This short setup prevents an export with hundreds of rows from becoming the plan. The plan is the user journey; the scan is evidence that helps you review it.
Run a focused crawl and preserve the evidence
Open the Broken Link Checker, enter a public HTTPS page, choose practical scan limits, and enable external checks only when they support the audit goal. The checker can report discovered source pages, target URLs, internal or external scope, response status, final URL, response time, and request failures. Export the result before making changes so you can compare the repaired state with the original state.
Treat the scan as a bounded sample. A safe server-side checker reads links from fetched public HTML; it cannot log into private areas, guarantee discovery of every URL, or behave exactly like a full browser on JavaScript-only interfaces. A remote server can also return a block or timeout that a human visitor does not see. Those limitations do not make the scan useless. They tell you which rows require confirmation.
For a page-level review, you can also paste the page source or copied markup into the URL Extractor. That gives you a separate list of links to compare with the crawl output. The comparison is especially helpful when a link is injected by a template, appears only in a specific content block, or was missed because the rendered page differs from its fetched HTML.
Keep the raw export unchanged. Add review decisions in a copy or tracking sheet rather than overwriting the observed status. A clean evidence trail makes regression checks easier and prevents a later reviewer from confusing a proposed fix with a verified result.
Classify results before choosing fixes
Do not place every non-success response into one “broken” bucket. The response and the intended destination both matter.
A 404 or 410 can mean a destination was removed. If the removal was deliberate and there is no equivalent replacement, the status may be correct. The actual defect is often the internal source link that still promises the removed resource. A 5xx response suggests a server-side failure, but a single observation is not enough to diagnose its cause. A timeout may reflect a slow or blocked remote server. A 403 can be an intentional access rule rather than a missing page.
Redirects need their own review. A single intentional redirect to the closest relevant destination can preserve a changed path. A chain adds delay and makes ownership harder to understand. A redirect that lands on an unrelated homepage may technically return a successful page while failing the visitor’s need. Use the Redirect Checker to inspect the hop sequence and final destination before deciding that a redirected row is resolved.
Give each row one review label, such as:
- confirmed broken internal link;
- intentional removal with stale source link;
- valid redirect that needs direct-link cleanup;
- redirect chain or irrelevant destination;
- temporary server error requiring owner follow-up;
- external result requiring manual confirmation;
- blocked, authenticated, or JavaScript-dependent page;
- false positive or no action required.
This classification keeps technical observations separate from editorial decisions. It also makes the next scan measurable: you can check whether the confirmed problems disappeared without pretending every uncertain response was a defect.
Prioritize by impact, repetition, and ownership
Raw counts are a poor priority system. One broken navigation link can affect more visitors than many isolated links in an old archive. Rank work using three questions: where does the link appear, how often does it appear, and what should happen when someone follows it?
Fix sitewide internal links first when they sit in primary navigation, footers, shared calls to action, or reusable components. Next, review links on pages that support important user tasks, receive meaningful search visibility, or act as hubs for other content. A broken path from a high-value guide to its associated tool interrupts both the visitor and the internal linking structure. Repeated source occurrences also deserve attention because one template repair may resolve many rows safely.
External links generally come after internal journeys. Replace an external reference only when you can identify a trustworthy equivalent. If the reference is optional and no suitable replacement exists, remove the promise cleanly rather than linking to a loosely related page. For legal, medical, financial, or security-related references, use the organization’s approved review process instead of choosing a substitute solely because it returns a successful status.
Assign every planned repair to an owner. Editors can update contextual links, developers can repair templates and route logic, and infrastructure owners can investigate server failures. A row without an owner is likely to reappear in the next audit.
Choose a repair that matches the original intent
There are four common repairs: update the source link, restore the destination, redirect the removed URL, or remove the link. Choose the smallest accurate option.
Update the source link when a live equivalent already exists. This is usually better than leaving an avoidable redirect in an internal path. Restore the destination when the page was removed by mistake and its content still serves a valid need. Add a redirect when an old URL has a clear successor and people or external sites may still use the old path. Remove the link when the destination is intentionally gone and no meaningful alternative exists.
Avoid redirecting unrelated old URLs to the homepage. A visitor who selected a specific guide, policy, product, or tool expects that subject, not a generic starting point. Also avoid creating a circular redirect or extending a chain simply to make the first request stop returning 404.
If crawl access looks inconsistent, review the site’s rules with the Robots.txt Tester, but keep the concepts separate. A robots rule can affect crawler access; it does not repair an incorrect hyperlink. Likewise, changing a canonical tag does not turn a dead destination into a working user journey.
Document the planned source URL, old target, chosen destination, reason, owner, and deployment reference. That record is far more useful than a vague note saying “fixed broken links.”
Practical example: audit links after a URL migration
Imagine that a site moved its learning section from /resources/ to /guides/. A crawl finds an old internal link to /resources/link-audit, a redirect from that URL to /guides/seo, and several other pages that still use the old path.
First, confirm whether /guides/seo satisfies the specific promise of “link audit.” If a new /guides/link-audit page exists, the current redirect destination is too broad. Point the old URL to the specific replacement, then update all internal source links directly to the new address. This preserves old external references while removing an unnecessary hop from the site’s own pages.
Now consider a second result: an external research link times out during the scan. Open it manually, check whether the publisher changed the URL, and confirm whether the citation is still available. If it works normally, label the automated timeout as unconfirmed and leave the useful reference intact. If the resource was removed, find an authoritative replacement or rewrite the sentence so it no longer promises unavailable evidence.
Finally, scan the same starting scope again. Compare confirmed broken internal rows, redirect chains, final destinations, and source occurrences with the preserved export. The audit is complete only when the important paths work as intended, not merely when a spreadsheet cell says “done.”
Verify repairs and watch for side effects
Run focused checks immediately after the change and again in the deployed environment. Local route behavior can differ from production redirects, caching, authentication, or hosting rules. Open the repaired source page, follow the link as a visitor, and confirm the final page contains the promised information.
For redirects, verify the complete chain, final status, destination relevance, query-string behavior when applicable, and whether internal pages now link directly. For restored pages, check navigation, canonical URL, indexability policy, and important embedded resources. For removed links, read the surrounding sentence to ensure it still makes sense.
Then repeat the original scan with the same boundary. A like-for-like rerun is the clearest way to distinguish a real improvement from a different crawl scope. Keep unresolved blocked or intermittent requests visible instead of forcing them into a passed state.
You can find the supporting utilities in the SEO Tools collection. Use only the tools that answer a specific review question; more scans do not replace a clear decision log.
Final checklist
A reliable audit ends with evidence and ownership:
- define the purpose and crawl boundary before scanning;
- preserve the original export;
- separate confirmed defects from blocks, timeouts, and intentional removals;
- prioritize important internal journeys and repeated template errors;
- update internal links directly when a live equivalent exists;
- redirect only to a destination that satisfies the original need;
- confirm uncertain external results manually;
- deploy, follow the repaired paths, and rerun the same scope;
- retain an owner and next action for every unresolved row.
This process keeps link maintenance proportional. It fixes what actually obstructs people, preserves correct removals, and gives the next reviewer enough context to continue the work without guessing.