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

When a blog or personal website experiences dead links, a common dilemma arises: should you attempt to fix them or leave them as historical records? Many blog owners run a link checker and discover dozens or even hundreds of broken links, particularly in older posts. Some argue that readers shouldn't care about the post's creation date, as search engines and social shares will continue to drive traffic to those pages.

They believe that dead links simply make the post appear abandoned and that all sites should be kept up-to-date.

However, there are valid concerns surrounding dead links. Expired domains can be purchased and turned into spam or malware sites, which is harmful to readers who click on the outdated links. In some cases, replacing a link could lead to misleading information, as the redirected page might now contain outdated or incorrect details.

Additionally, fixing numerous dead links in a large archive could be a time-consuming and impractical task. In such cases, it might be more efficient to write new posts instead of updating the old ones.

The author of this piece proposes a middle ground approach. They recommend treating link fixes like errata, rather than editing the original content. If an archived copy of the post is available from around the time it was written, link to that snapshot to maintain the integrity of the historical record. Only replace the link when the target has clearly moved, such as when a project has moved from one domain to another and the same page exists on the new domain.

In these cases, updating the link is necessary, but not changing the content itself. The author suggests adding a note at the end of the post to indicate that changes were made, such as "Updated in 2026: two links pointed to pages that no longer exist; they now go to archived copies." This allows readers who are interested in the historical context to see what changes were made while providing working links for the majority of visitors.

Broken links to hijacked domains should be removed immediately, as these are obviously harmful to readers. However, when dealing with a large archive, prioritize fixing links based on traffic, link type, risk, and your own changes to the original content. For code examples and social media posts, consider creating a short paraphrase and removing the link, or use a redirect on your own site if necessary.

While some aspects of this approach may not be entirely clear, the author provides a rough plan for tackling a large archive. They suggest prioritizing the most visited posts, fixing links in the main body of tutorials before addressing those in the "Further Reading" section, and focusing on links that point to risky domains first.

The author also recommends creating a redirect for your own slugs instead of editing every post that linked to them, and pinning code examples to specific commits to maintain both the historical record and a working link.

Ultimately, the author emphasizes the importance of making future posts easier to maintain. This can be achieved by linking to stable things, such as project documentation and release tags, archiving as you publish, quoting important information from sources to preserve the original point even if the page changes, and regularly checking the traffic of your posts to catch dead links before they become a significant issue.

By following these guidelines, you can strike a balance between maintaining historical records and providing useful, up-to-date content for your readers.