How Do You Find and Fix Link Rot in an Old Blog Archive?

How do you find and fix link rot in an old blog archive?

Crawl your own site for outbound links, check the status of every destination, then triage into three buckets: gone forever, moved somewhere new, and still fine but changed. Fix the moved ones first, replace the gone ones, and leave the rest alone. The whole job is mechanical once the list exists.

This is the tutorial I wish someone had handed me when my archive passed a few hundred posts. Every article I published cited sources. Every source was a URL owned by somebody else. And every year, a slice of those URLs quietly stopped resolving.

The reader situation I am writing for is specific: you own a content heavy site, most of it built on a CMS, you are the only person maintaining it, and you have never audited outbound links. Here is how I would do it in an afternoon.

Why does link rot matter more on an old archive?

Because your oldest posts are usually your most linked and most cited, and they are the ones pointing at the most URLs that have since died. A broken citation does not just annoy a reader. It quietly undermines the thing the citation was there to prove.

There is a trust cost that compounds. A reader who clicks two dead sources in one article stops treating the article as evidence based, no matter how careful the writing was. For anyone doing serious work on expertise and trust signals, that is the whole ballgame.

There is also a practical cost. Dead outbound links are a signal that nobody maintains the page, and an archive that nobody maintains is an archive you cannot confidently point new readers at.

What is the fastest way to get the list of outbound links?

Run a crawler over your own domain and export every external link it finds along with the page it appeared on. A desktop crawler such as Screaming Frog or Sitebulb does this in one pass, and most SEO platforms including Ahrefs offer an equivalent export. Check each vendor's current crawl limits before you start.

If you would rather not use a crawler, you can reach the same place from your CMS. Export the rich text field for every item, then pull every href out of the HTML with a short script. On a Webflow site this is a single export and about twenty lines of code, and it has the advantage of telling you exactly which CMS item holds each link.

Whichever route you take, the output you want is boringly consistent: one row per link, with the source page, the destination URL, and the anchor text. Put that in Google Sheets or Airtable, because you are going to work through it over more than one sitting.

How do you check which destinations are actually dead?

Request each destination and record the status code. A 404 or 410 is gone, a 301 or 302 means moved, and a 200 means it resolved. The one to watch for is a 200 that lands on a homepage or a generic error page, because that is a soft failure the status code will not tell you about.

Your crawler will do this checking for you. If you are working from a CMS export, a short script that requests each unique URL and writes back the status and the final resolved URL is enough. Deduplicate first, because a large archive will cite the same URL many times.

Handle rate limits politely. Space the requests, and do not hammer a single domain. The point of the exercise is to be a good citizen of the web you are citing, and that starts with how you crawl it.

Which links should you fix first?

Sort by the traffic of the page containing the link, not by how broken the link is. A dead citation on a post that gets read every day matters far more than three dead citations on a post nobody has opened in a year. Pull the page list from Google Search Console and join it to your link table.

Within that, fix redirects before you fix the dead ones. A link that redirects still works for the reader, but updating it to the final destination is a two second edit that removes a hop and protects you from the day the redirect is switched off.

Then handle the genuine 404s, in the same traffic order. This is where the actual editorial judgement lives, and it is worth slowing down for.

What do you replace a dead source with?

The same claim from a live primary source, if one exists. If the original page is truly gone, use an archived copy from the Internet Archive Wayback Machine so the evidence is still inspectable. If neither is available, the honest move is to remove the claim the link was supporting.

That last option is the one people resist and the one I use most. A sentence that only stood up because of a source that no longer exists is a sentence that no longer stands up. Deleting it is not a loss, it is maintenance.

Never swap in a different source that says something slightly different and hope nobody checks. That is how an article drifts from being true to being plausible, and plausible is not the standard.

How do you handle internal links that broke along the way?

Treat them separately and fix them all, because internal links are entirely within your control and there is no excuse for a dead one. Any that point at a URL you have changed should be rewritten to the current path rather than left to ride a redirect.

The common cause on a CMS site is a slug change. Change one item's slug and every hand written link to the old path breaks at once, which is why I am so careful about slugs on large collections.

If you want the mechanics of catching these as they happen rather than in an annual sweep, I wrote about finding and fixing broken links across a Webflow site, and the same tooling covers both directions.

How do you stop the archive rotting again?

Schedule the crawl. Quarterly is plenty for most archives, monthly if you publish daily. The work only feels large the first time, because after that you are checking a quarter of new links against a list you already cleaned.

Two habits reduce the volume at source. Cite primary sources rather than blog coverage, because a vendor's own documentation outlives a third party write up. And prefer stable URLs, avoiding links to search results, session based pages, and anything with a date in the query string.

It is also worth deciding your rel attribute policy once and applying it consistently, which I covered in how to use rel attributes on external links in Webflow. Consistency here makes future audits faster to read.

What does this change for readers who arrive from search?

It changes whether your page survives scrutiny. A reader who arrives from an answer engine is often checking a specific claim, and the first thing they do is click the source. Working links are how that reader decides you are worth reading twice.

The same applies to a reader who lands on an old post from an internal link. If the destination of a broken link is your own site, make sure your error page helps them onward, which is the job of a good 404 page on a content heavy site.

Across 350 plus published articles, the maintenance I have never regretted is this one. It produces no new content and no new traffic, and it protects everything I have already written.

What should you do next?

Block two hours this week. Crawl your domain, export the external links, check the status codes, join the list to your top twenty pages by traffic, and fix only those. That subset will cover most of the damage a reader could actually encounter.

Then put the next crawl in your calendar before you close the spreadsheet. The habit is the deliverable, not the spreadsheet.

If your archive is large enough that this sounds like a week rather than an afternoon, reach out and I will tell you how I would scope it. Let's chat.