A broken link is more than a line in an SEO crawler report. It may prevent a visitor from booking a service, reading the evidence behind a claim, reaching a policy, or finding a useful next step. The right fix depends on what was supposed to happen when the link was followed. Some errors are caused by deleted pages, others by incorrect URLs, old migrations, temporary server faults or content that now belongs elsewhere. A practical audit should identify the exact source page and destination, decide what the visitor expects and make a repair that remains useful after the next site release.
Start with the purpose of the link, not the error count
Before changing a URL, read the paragraph, button or navigation label containing it. What does the visitor expect to reach? A service quotation link has a different priority from an outdated historical reference. A link to a regulator's guidance should lead to the precise relevant document or a clear replacement, not to an unrelated homepage. Classifying purpose protects against the common mistake of fixing a tool warning while breaking the reader's task.
Create a working record with the source URL, anchor text, destination URL, observed response, content owner and business significance. When a site uses shared navigation or footer components, one bad destination may appear across many pages. Count the underlying defect separately from the number of times it is exposed. Prioritise important routes such as booking, contact, product information, source references and compliance information.
Understand what an HTTP status does and does not reveal
An HTTP 404 usually indicates that the requested resource was not found. A 410 can communicate that content is intentionally gone; server-side 5xx responses indicate a different category of failure. A redirect may be perfectly legitimate, but a long chain or an unrelated landing page can frustrate users. Some systems display an error message while returning HTTP 200, sometimes called a soft 404, which requires inspection beyond the visible words.
Do not treat one failed automated request as proof that a live destination is permanently broken. Access controls, rate limits, bot protection and intermittent failures can affect crawlers differently from ordinary visitors. Open significant URLs manually where appropriate and, for a site you control, inspect response headers and server logs. Record the time and conditions, especially if the error does not reproduce consistently.
Distinguish internal links from external references
Internal links are usually within the website owner's authority. Fix incorrect paths at their source, restore appropriate content where justified, or update navigation to a current equivalent. If an important page moved during a redesign, a properly selected permanent redirect may preserve a useful path for old visitors and references. But do not send every missing article to the homepage merely to remove error counts; the destination should fulfil substantially the same intent.
External links may require more editorial judgement because the source owner controls the destination. Check whether the original organisation has published a new official location, whether the document has been archived, or whether the supporting claim needs a different trustworthy citation. Removing a link can be acceptable when the reference is no longer relevant, but review the surrounding statement so the article does not retain an unsupported factual assertion.
Use crawlers to find candidates, then check important cases
A website crawler can identify links, source pages, HTTP responses and redirect chains at scale. Configure it for the correct domain and scope so it does not accidentally include inaccessible environments or unwanted authentication paths. Review robots and service terms, and avoid excessive automated requests. A crawl report is an inventory of observations, not an automatic instruction to rewrite all URLs.
Export or retain the source URL, link target, status and location on the page. Combine repeated failures by destination when useful, then identify affected templates. For critical customer journeys, perform direct browser tests as well. Automated tools may miss links created only after interaction, while some errors reported by automated requests may not affect normal visitors. Human review is necessary to decide whether a proposed replacement actually makes sense.
Choose a repair rather than a blanket redirect
If a URL contains a typo, correct the link where it appears. If content has genuinely moved to a new equivalent address, update important internal links directly and consider a suitable redirect for old external references or bookmarks. If a topic has been retired without a meaningful replacement, an honest gone or not-found response can be better than sending the user to an irrelevant page. The decision should reflect the content lifecycle rather than a desire to make a crawler report entirely green.
Check redirect type and chain length, retain canonical consistency and test the final destination. A redirect loop or multiple hops can create new usability and crawl problems. Avoid changing sitewide rewrite rules without a reversible plan and representative tests. Document who owns the change so future content editors do not recreate the old link from copied material.
Repair broken links inside navigation and conversion flows
Navigation links, enquiry buttons, download actions and checkout steps deserve special attention. A broken booking URL can lose a potential customer; a missing privacy notice may undermine trust and compliance. Test the linked journey through to the intended outcome, not just the first page load. For a downloadable file, confirm that the correct file opens and that its name and format make sense.
On mobile, inspect whether a link can be tapped and whether overlays or sticky elements cover it. Keyboard users need visible focus and link text that makes the destination clear. Changing a broken destination without fixing an ambiguous label can leave the experience confusing. Recheck shared header, footer and menu components after deployments, because one template change can affect many pages.
Check source evidence and copyright-sensitive material
A reference link may point to a published study, government document, technical standard or image licence. When it fails, do not simply invent a replacement or cite an unrelated article as if it supported the same claim. Find the current original publisher or a legitimate archival copy where appropriate and confirm the material actually contains the relevant evidence. If the claim can no longer be supported, revise or remove it.
For images, the visible file may load while its source and licence link is broken, or the reverse may occur. Both deserve review. A legitimate attribution should identify the creator, file source and reuse conditions accurately. Avoid taking an arbitrary image from a search result without permission merely to replace a broken asset. Keep the editorial and rights decisions distinct from technical reachability.
Retest after changes and monitor recurring patterns
After each repair, open the source page, follow the link and confirm that the destination meets the original expectation. Check the HTTP response and any redirects. A successful 200 response alone does not prove that the content is the right replacement. Retest with the relevant public device and access conditions; do not rely only on an administrator session that bypasses caching or permissions.
Schedule proportionate reviews after migrations, website redesigns and significant editorial changes. Search Console may reveal important errors or linked-page issues for a verified site, but it is not a substitute for auditing the links your own site exposes to visitors. Track recurring sources, templates and link-writing practices. An organisation that fixes the underlying publishing process will reduce repeat defects more effectively than one that repeatedly edits isolated pages without addressing causes.
Report what was actually fixed
For each issue, distinguish observed error, repair decision and verification. State the number of unique broken destinations and affected source links separately when that distinction matters. Record whether the repair was a corrected URL, updated reference, meaningful redirect, restored document or deliberate removal. Avoid unsupported claims that correcting a fixed number of links guarantees SEO growth. The immediate acceptance test is a working, relevant journey for the reader.
Maintain a simple handover: issue, owner, correction, tested public URL and any unresolved dependency. That gives future editors a reliable route for maintenance. Primary guidance includes Google Search Central's HTTP status and network-error documentation, redirect guidance and W3C link-purpose guidance. These sources explain technical and accessibility implications rather than guaranteeing a search position.
Broken links: which remedy matches the real condition?
Five examples show why a single blanket redirect is not an adequate maintenance strategy.
| Link condition | Preferred investigation | Likely remedy and verification |
|---|---|---|
| Mistyped internal URL | Locate source markup and intended live destination | Correct source href and follow it on the public page |
| Article moved to equivalent new URL | Confirm content identity and preferred canonical | Update internal links and use suitable redirect for old paths |
| Content deliberately retired | Determine whether a meaningful successor exists | Remove obsolete links or serve an honest absence response |
| Third-party official source moved | Find current authoritative publication and check claim | Update citation or revise unsupported statement |
| Intermittent server error | Check response pattern, access controls and logs | Repair underlying delivery issue rather than guessing a new URL |
Source A: Google HTTP and network error guidance. Source B: Google redirect guidance. The comparison describes repair principles rather than actual defects confirmed for Epic Creative.
Broken-link repair: five questions
Should every broken URL redirect to the homepage?
No. A redirect should lead to an equivalent or genuinely useful replacement. Sending unrelated missing pages to the homepage can confuse visitors and fail to resolve the underlying problem.
Is a 404 always a website fault?
No. A not-found response can be appropriate when content has been retired. Investigate whether visitors still need the resource, whether a relevant replacement exists, and whether internal links incorrectly promise it.
Can a crawler identify every broken link correctly?
It can discover many candidates, but bot restrictions, temporary errors and interactive content may change the result. Verify important cases directly and record response conditions before making large changes.
What should I do with an external source that has disappeared?
Look for a current authoritative source containing the same evidence. If the claim cannot be supported, revise it. Do not substitute an unrelated destination simply to clear the broken-link warning.
How do we stop broken links returning after a redesign?
Maintain a redirect and link inventory, update internal sources, test shared templates, and include critical customer paths in release QA. Record the exact corrected destination and verification result.