Broken backlinks: the links you are losing to pages that are gone

A backlink to a 404 or a redirected dead end gives you little or nothing. The linker meant to endorse a page that no longer exists. That weakens your topical authority and wastes crawl budget on errors. It also harms users who click those links and bounce.

On a small site, every solid backlink counts. If five good links now hit 404s, that is the weight of a new feature launch gone. Fixing them is low effort with clear gain, and you can do it once a quarter.

• A link to a URL that returns 404 or 410.
• A link to a URL that now redirects, but the redirect is off topic or loops.
• A link with a typo or out-of-date path that never existed.
• A link to a page you noindexed after launch.

Example: a blog links “yourproduct.com/guides/getting-started” but you renamed it to “/guide/getting-started”. The old path returns 404. That is a broken backlink until you map it to the right place.

You need three sources. A backlink tool for external links and target status. Your crawler for internal discovery and redirect chains. Your 404 logs from the server or analytics for real user hits. Combine them once, then fix in a batch.

1. 1

   Backlink tool export

   Export your backlinks with the target URL and target HTTP status. Filter to targets that are 404, 410, 5xx, or have 3xx and long chains. Save the linking page, anchor and first seen date.

2. 2

   Site crawl

   Crawl your domain. Export 3xx chains, 4xx pages, canonicalised URLs that are not indexed, and any page with high inlinks that is non-200. Note pages that should exist but do not resolve cleanly.

3. 3

   404 and 410 logs

   Pull the last 28 days of 404 and 410 hits from your server logs or error tracking. Group by path. Mark those with referrers from external domains.

4. 4

   Join and prioritise

   Merge by the dead target URL. Score each by referring domains and recent hits. Prioritise anything with multiple referring domains or live traffic. Leave edge cases for later.

Most backlink tools let you filter by target status and export. You want the rows where the target on your domain is not 200. Do not guess from counts alone. Download the detail and inspect a few links by hand to confirm the page is truly gone or wrong.

• Filter: target HTTP status is 404 or 410.
• Filter: target HTTP status is 301 or 302, with more than one hop in the chain.
• Include: source URL, anchor, target URL, first seen, last check, referring domain.

Check a few examples. If a source page links to “/pricing-2022” that now 404s, yet you have “/pricing”, plan a redirect. If a source links to “/features/abc” and the product is gone, a redirect to a category or successor feature may fit, or you retire the link and restore a summary page instead. Decide case by case, with the user in mind.

Backlink indexes lag and can miss minor blogs or fresh posts. Your own crawl and logs close the gap. A crawl shows broken internal links and long redirect chains you created. 404 logs show real users hitting old paths from bookmarks, emails and embeds that no tool knows about.

1. 1

   Crawl output to check

   Export: 3xx inlinks and chains, 4xx URLs with inlinks, non-indexable pages that receive inlinks, and duplicate content that now canonicals away.

2. 2

   Server or analytics logs

   Group 404s by path for the last 28 days. Pull referrer where available. Prioritise 404s with external referrers or high hit counts.

3. 3

   Sanity check in a browser

   Open the dead URL, confirm status. Click the source page and see the context of the anchor. Decide the best destination based on the promise of the anchor text.

Map each dead URL to the single best live page that fulfils the same intent. Use a 301. Keep the chain to one hop. If nothing matches, restore the page or return 410 and accept the loss.

Keep the redirect decision tight to the anchor. If the anchor says “API rate limits”, the target must explain rate limits, not your generic docs index. If two candidates exist, choose the more specific page even if it has lower traffic. The linker vouched for a topic, not your brand.

Restore the page if the link is to unique content that you removed but people still seek. That can be a benchmark, a PDF, an API reference, or a blog post that the web still cites. Do a light refresh, add a banner with the current state, and keep the URL. You avoid mismatched redirects and keep the original promise intact.

• Bring back the exact URL if you can.
• If you must move it, restore then 301 to the new canonical page.
• Add a note at the top that it is archived or updated.

Example: you deleted “/whitepaper/edge-caching.pdf”. There are ten referring domains to that file. Restore the PDF or publish a HTML version at the same path. If you only redirect to “/guides/edge-caching”, some readers will not get the cited figures and will leave. Restoring keeps trust and usefulness.

A mass redirect to the home page breaks user intent and can be treated like a soft 404 as of 2026. You do not earn credit for piling unrelated links onto the root. You frustrate users who expected a specific answer and got your hero banner.

• If a precise match exists, use it.
• If a near match exists, prefer it over the home page.
• If nothing matches, restore or 410. Do not dump to root.

Example: a dead “/blog/schema-examples” should go to “/guides/structured-data-checker” or a schema tutorial, not “/”. A dead “/partners/agency-xyz” should go to “/partners”, not “/”. Match intent or retire gracefully.

1. 1

   Create a redirect map

   Build a CSV with from, to, rule type. Keep it under source control with a date. Note why you chose the target, in one phrase.

2. 2

   Implement 301s

   Use your platform’s config. Test a sample in a browser and with a header checker. Ensure the final target is 200, indexable and not blocked.

3. 3

   Fix internal links

   Update menus, footers, docs and blog posts that still point to the old URL. Internal 301s waste crawl budget and slow users.

4. 4

   Test chains and loops

   Run a crawl. Ensure no from URL returns 200, no loops occur, and each redirect is one hop.

5. 5

   Request re-crawl

   Fetch the from URLs in Search Console to speed up processing. This helps move link signals faster.

A fixed page looks like this: the old “/pricing-2022” now 301s to “/pricing” in one hop, “/pricing” is 200, canonical to itself, and appears in your links report as the target of those backlinks over time. Your 404 log is quiet for “/pricing-2022” after a week.

Track three things. The count of referring domains that now point to live 200 pages. The 404 rate on the fixed paths. The organic traffic to the mapped targets over the next 28 days. Document the batch and compare to the previous one.

• Re-run your backlink export monthly or quarterly.
• Review 404 logs every 28 days.
• Add redirect map updates to your release checklist for any URL change.

You create most broken backlinks by changing URLs without a map. Lock your URL patterns and only change paths when content truly moves. When you must rename, ship the redirect the same day and update internal links in the same pull request.

• Freeze slugs after publish. Edit the content, not the path.
• Ship redirects with any rename or replatform.
• Use a staging crawl to catch future 404s before deploy.
• Keep PDFs and assets stable, or version them with clear successors.
• Update external docs and partner pages you control when URLs change.