Broken Links: Why They Matter and How to Fix Them

Broken Links: How to Find the Cause and Choose the Right Fix

A broken link is a link that does not take the reader to the page, file, or section they expected. The destination may return a 404 or 410 response, but the same symptom can also be caused by a typing mistake, a failed server, a blocked request, a deleted image, an expired external domain, or an in-page link that points to an ID that no longer exists.

The correct fix depends on what happened. Update the link when its destination is wrong. Redirect an old URL when a genuinely relevant replacement exists. Remove the link when it no longer helps the reader. Leave a real 404 or 410 response in place when content has intentionally gone and there is no suitable substitute. Google’s guidance for unavailable content treats 404 and 410 responses as valid when a page is no longer available, rather than errors that must always be redirected.

This guide gives you a practical workflow for confirming the issue, prioritising the links that matter, choosing the appropriate response, and verifying that the repair worked. Fixing broken journeys can improve usability and help search engines discover your live pages, but it does not guarantee a ranking increase.

Broken Links TL;DR: Use This Five-Decision Workflow

1. Confirm the problem from the source page. Check the exact link being clicked, not only the destination URL shown in a report.
2. Identify the failure. Is it a typo, a 404 or 410, a redirect problem, an access restriction, a temporary server failure, a missing file, or a broken in-page anchor?
3. Choose the least disruptive valid fix. Update the link, remove it, restore the destination, correct access, or add a permanent redirect to a closely equivalent replacement.
4. Prioritise by reader and business impact. Fix navigation, checkout, contact, high-traffic, high-conversion, sitewide, and externally linked URLs before low-value references.
5. Re-crawl and verify. Confirm that the source now points directly to the intended destination and that the destination returns the response you expect.

Do not redirect every removed URL to the home page. Google warns that irrelevant redirects can confuse users and may be treated as soft 404s. A relevant replacement is the deciding factor.

What Broken Links Actually Affect

User journeys and trust

A reader who selects a product, guide, contact route, download, or navigation item expects it to work. A dead destination can stop that task entirely. The impact is highest when the link sits in primary navigation, a checkout path, a lead form, a support journey, or a heavily visited article.

Discovery and internal site structure

Search engines use crawlable links to discover pages and understand how a site is connected. Google’s link best-practice documentation says that every page you care about should be linked from at least one other page. A broken internal link removes one discovery path and can leave an important page harder to reach, particularly when it has few other links.

Traffic and signals attached to old URLs

An old URL may still receive visits from bookmarks, search results, campaigns, or links on other websites. When a close replacement exists, a permanent redirect can preserve that journey and help Google understand the new preferred location. When no relevant replacement exists, keeping a genuine 404 or 410 is more honest than sending everyone somewhere unrelated.

Maintenance at scale

One incorrect URL in a shared menu, footer, product template, or content component can create hundreds of reported broken links. Fixing the template once is usually more valuable than editing each affected page independently.

Crawl efficiency, with context

Repeatedly sending crawlers through dead or unnecessary URLs can add waste, but crawl-budget concerns are most important for very large or rapidly changing sites. Most small sites should prioritise broken links because they obstruct users, weaken internal discovery, or expose poor release processes—not because a few ordinary 404s trigger a sitewide search penalty.

Diagnose Before You Fix: Broken Link or Something Else?

A crawler result is evidence to investigate, not an automatic instruction to create a redirect. Start by checking both the page containing the link and the destination it calls.

• 404 Not Found: The server cannot find the requested resource. The response does not, by itself, say whether the absence is temporary or permanent. See the MDN explanation of HTTP 404.
• 410 Gone: The resource has intentionally been removed and is expected to remain unavailable.
• 301 or 308: The URL has moved permanently. The redirect may be correct, but your own internal links should normally point straight to the final destination rather than through the old address.
• 302 or 307: The move is temporary. Confirm that the original URL is expected to return.
• 401 or 403: Access is restricted. This may be intentional, or it may mean a public page, file, or crawler has been blocked incorrectly.
• 429, 5xx, timeout, DNS, or connection failure: The destination may be temporarily unavailable rather than permanently gone. Retest before deleting or redirecting anything.
• Soft 404: The page looks like an error or has no useful main content but returns a 200 success response. A custom error page should still return the appropriate 404 status.
• Broken fragment: The page loads, but a link such as #delivery points to an in-page ID that is missing or duplicated. Many page-level crawlers will not report this as a 404 because the server never receives the fragment.

Google Search Console’s current Page indexing report can show URLs Google encountered as not found, while URL Inspection can test important individual URLs. It does not replace a site crawl that shows which live pages still link to each failing destination.

If ScanMySEO reports a “Potentially Inaccessible Link,” verify it before acting. Bot protection, authentication, rate limiting, temporary outages, and external servers that reject automated requests can all produce a result that differs from an ordinary browser visit.

Step by Step: Find, Prioritise and Fix Broken Links

1. Build a usable list of source and destination URLs
   Run a crawl that records the page containing each link, the exact destination, the link type, and the returned status or failure. Search Console can supplement this with URLs Google has encountered, but it will not give you a complete source-to-destination link map.
2. Validate each important result
   Open the source page, locate the link, and inspect its exact href. Test the destination in a normal browser and, where possible, check the returned HTTP status. Retest intermittent failures. For external sites, distinguish a genuine dead page from a crawler block or temporary outage.
3. Prioritise by impact, not raw error count
   Fix links in primary navigation, checkout, account, booking, contact, and conversion journeys first. Then address sitewide template errors, high-traffic pages, important internal discovery paths, and old URLs with meaningful external links or continuing visits. A hundred repeated footer errors may be one template fix; one broken payment link may be the more urgent problem.
4. Choose the correct action
   
   • Update the link when the destination URL is mistyped, outdated, or already redirects to a known final URL.
   • Restore the destination when a page or file was removed by mistake and should still exist.
   • Add a 301 or 308 permanent redirect when you control the old URL and a closely equivalent replacement exists. Google recommends permanent server-side redirects where possible and uses them as a signal that the target should become canonical. See Google’s redirect guidance.
   • Remove or replace the link when an external resource has gone and no redirect is under your control.
   • Keep a 404 or 410 when content is intentionally gone and there is no relevant replacement. Remove internal links to it and provide a useful custom error page that still returns the correct status.
   • Fix the underlying availability problem when the result is caused by permissions, server errors, rate limits, DNS, TLS, or application failures. Do not hide a temporary technical fault behind an unrelated redirect.
5. Update every controlled reference to the final URL
   Change internal links, navigation, canonicals where relevant, campaign templates, structured data references, and XML sitemap entries so they use the intended live URL. A redirect is a safety net for old requests, not a reason to keep publishing obsolete internal links.
6. Check the redirect path
   Point the old URL directly to the final destination. Avoid adding another hop to a redirect chain, and test that your rule has not created a redirect loop. Be particularly careful with broad wildcard or regular-expression rules that can affect unrelated URLs.
7. Re-crawl and verify the outcome
   Confirm that the original source page now points directly to the correct destination, the destination returns the intended status, and no new chain, loop, or soft 404 has appeared. For important URLs, use URL Inspection after deployment and allow time for Google to recrawl the change.

Common Broken-Link Fixes That Create New Problems

• Redirecting everything to the home page: The destination should satisfy substantially the same need as the old URL. An irrelevant redirect can confuse users and may be treated as a soft 404.
• Leaving internal links pointed at redirects: Update links you control so users and crawlers reach the final URL in one step.
• Treating every 4xx response as a mistake: A 404 or 410 can be the correct response for intentionally removed content. A 401 or 403 may protect private content as designed.
• Assuming a successful browser visit disproves the crawl: The page may behave differently by location, user agent, cookies, authentication, or request rate. Record what differed before dismissing the result.
• Fixing only the destination: Even after adding a redirect, repair the source link, sitemap, menu, template, or campaign that keeps publishing the old URL.
• Ignoring files and fragments: Broken images, PDFs, scripts, downloads, and in-page anchors can damage the experience even when the containing HTML page returns 200.
• Using a bulk redirect rule without samples: Test expected matches, near-misses, query strings, uppercase variants, and trailing-slash versions before deploying a broad rule.
• Prioritising the biggest count: Repeated low-impact links can dominate a report. Fix by user journey, business importance, template reach, and discovery value.

Worked Example: Four Broken Product Links, Four Different Fixes

Imagine an online running shop finds four failed destinations in a crawl. They all look like “broken links,” but they should not receive the same treatment.

1. A category page links to /lightwieght-shoes.
   The intended URL is /lightweight-shoes. Edit the source link. A redirect is optional only if the misspelt URL has been published elsewhere or receives real visits.
2. An old shoe model has been replaced by a direct successor.
   Update internal links to the successor and add a permanent redirect from the old product URL when the new page genuinely answers the same need. Verify that the redirect lands directly on the final URL.
3. A discontinued model has no equivalent replacement.
   Remove links that still promote it. Let the old URL return 404 or 410 and provide useful navigation from the custom error page. Do not send it to a generic footwear category merely to eliminate the report entry.
4. An external sizing guide returns 403 to the crawler but opens normally for customers.
   Investigate the access difference before changing the content. The external site may block automated requests. Keep the link if it remains useful and reliable for readers, then monitor it rather than treating the crawler result as conclusive.

The lesson is simple: classify the cause first. “Make every failed URL return 200” is not a repair strategy.

Verify the Fix and Prevent the Same Issue Returning

A broken-link task is complete only when the user journey works from the original source page. After deployment:

1. Re-crawl the affected section or site and compare the new results with the original export.
2. Open a sample of high-priority source pages and follow the links as a user would.
3. Confirm that permanent redirects go straight to a relevant live destination and that removed pages without replacements return a genuine 404 or 410.
4. Check that XML sitemaps, navigation, canonicals, templates, and campaign links no longer publish obsolete URLs.
5. Review server logs, analytics events, or error monitoring for heavily requested missing URLs that your crawler may not discover.

Prevention is mostly release discipline. Before deleting or renaming a URL, decide whether it needs a replacement, map any redirect, update internal references, and change the sitemap in the same release. Run a post-release crawl after migrations, redesigns, catalogue changes, and large content updates. For quieter sites, choose a maintenance schedule based on how often URLs and external references change rather than following an arbitrary calendar.

Quick Reference: What to Do for Each Result

• Wrong or mistyped destination: Correct the source link.
• 404 or 410 with a relevant replacement: Update controlled links and add a 301 or 308 from the old URL.
• 404 or 410 with no relevant replacement: Remove internal references and keep the correct not-found response.
• Existing 301 or 308: Point internal links directly to the final destination and check for chains.
• 302 or 307: Confirm that the move is genuinely temporary.
• 401 or 403: Confirm whether access should be restricted and whether crawlers or public users are being blocked unintentionally.
• 429, 5xx, timeout, DNS, or connection failure: Retest and resolve availability before deciding that the content is gone.
• 200 response showing an error or empty page: Investigate a soft 404 and return a meaningful status.
• Broken #fragment: Correct the fragment or restore the matching unique element ID.

Start with the links that stop people completing an important task. Then repair the sitewide and discovery issues that make the same failure repeat. A clean report is useful, but a working journey is the real outcome.