Should you fix dead links in old blog posts, or leave them as a historical record? Let's argue about it

Every blog, engineering or personal, eventually hits this. You run a link checker for the first time in years and it finds 140 dead links, almost all of them in posts written before 2021. A tutorial links to a library that was renamed. A "further reading" list points to a conference talk whose video was taken down. A tweet you quoted now goes to a login wall.

The obvious answer is "fix them". But some people argue, sincerely, that old posts should be left as they are: they're a record of what you thought and linked to at the time, and silently editing them is a kind of rewriting history.

I don't think either camp is entirely right. Here's the case for each, and where I've ended up.

The case for fixing everything

Readers don't care when you wrote it. Search engines and social shares keep sending people to old posts. To a reader landing today, a dead link is simply broken, and a post full of them feels abandoned. They'll trust the rest of the advice less, and probably they should.

Dead links are a small cost of doing business. If you keep a site online, you maintain it. Nobody argues that you should leave a broken image or a 500 error on an old page for historical reasons.

Some dead links are actively harmful. Expired domains get bought and turned into spam or malware. A link from your 2018 post to a library's old homepage might now send your readers to a casino. Leaving that alone isn't preservation, it's negligence.

The case for leaving them alone

Old posts are a record. A post from 2019 describing how you set up a build pipeline is valuable partly because it shows what the ecosystem looked like in 2019. Swapping in today's links quietly changes what the post said.

Replacements can be wrong. A link to "the docs" in 2019 meant version 2. Pointing it to today's docs for version 7 might be more misleading than a dead link, because the reader now trusts a page that contradicts your instructions.

It doesn't scale. For a big archive, hand-fixing every link is weeks of work for posts that get a few visits a month. Some people would rather write new posts.

Where I land: fix the link, keep the record

The middle ground that works for me is to treat link fixes like errata, not edits:

Prefer an archived copy over a modern replacement. If the original page is in the Wayback Machine from around the time you wrote the post, link to that snapshot. The reader sees exactly what you meant, and the record stays intact.
Replace only when the target clearly moved. If a project moved from one domain to another and the same page exists, update the link. That's fixing an address, not changing the content.
Mark what you changed. A short line at the end, such as "Updated in 2026: two links pointed to pages that no longer exist; they now go to archived copies", keeps you honest. Readers who care about history can see it, and everyone else gets working links.
Remove links to hijacked domains immediately. No debate there. Unlink, and note it.
Leave content alone. Don't rewrite the advice while you're in there. If the advice is outdated, add a banner at the top pointing to a newer post rather than silently changing the old one.

A rough triage for a big archive

If the link checker hands you hundreds of results, you don't need to treat them equally:

Start with traffic. Fix the posts that actually get visits first. Your analytics will show that a small number of old posts get most of the traffic.
Then by link type. Links in the body of a tutorial matter more than links in a "further reading" list at the bottom.
Then by risk. Domains that now redirect somewhere unrelated, or that resolve to parked pages, go to the top regardless of traffic.

Many teams also batch it: one afternoon a quarter, top 20 posts, done. That's better than a once-a-decade cleanup.

The parts I'm less sure about

Quoted social posts. If an embedded post is deleted, linking to an archive of it may preserve something the author chose to remove. I usually replace the embed with a short paraphrase and no link.
Your own old URLs. If you changed your own slugs, the right fix is a redirect on your side, not editing every post that linked to the old one. But editing them too avoids a pointless hop.
Code examples. Links to a specific line of a file on GitHub's main branch will drift. Pinning them to a commit is arguably the "historical record" option and the "working link" option at the same time.

Making the next cleanup smaller

Whatever you decide about the archive, you can make future posts rot more slowly:

Link to stable things. A project's docs landing page outlives a deep link to one heading. A release tag outlives a branch.
Archive as you publish. Submitting the pages you cite to the Wayback Machine on the day you publish costs seconds, and gives you a snapshot from exactly the right date if the link dies later.
Quote the important bit. If one sentence from a source is the reason for the link, quote it. The reader keeps the point even if the page goes.
Check on a schedule. A monthly check of the posts that get traffic catches dead links while you still remember what they pointed to.

Whichever side you're on, the first step is knowing how many dead links you have and where they are, which is the part linkbruno.com helps with.