Every outbound link in your archive was checked exactly once — on the day it was published. That check has an expiry date: Pew Research Center found that 8% of webpages that existed in 2023 were already inaccessible when it re-checked them in October 2023, rising to roughly one in five for pages from 2021 and 38% for pages from 2013. A link rot audit is the scheduled re-resolution pass that catches those deaths, plus a written rule for what to do with each one — because the hardest cases don't return a 404 at all.
That last part is where most audits fall apart, so let's start there.
Here are two citations resolved on 11 August 2026, both of which any reasonable person would have called "verified" on the day they shipped.
The first: developer.twitter.com/en/docs/twitter-api returns a 307 redirect to https://docs.x.com/ — the documentation root. If your 2023 post cited a specific endpoint to back a sentence about rate limits, that sentence now points at a landing page. Every status-code checker on earth marks it green. The link works; the citation doesn't.
The second: segment.com/blog/introducing-segment-personas/ returns a 301 to Twilio's error page, which returns an honest HTTP 404 — complete with a playable block-stacking game and the line "404: Builders drop pieces too." Your checker catches that one, but only if it follows the chain and evaluates the final status. A tool that stops at "301, fine, it moved" reports a clean archive.
Two links, two different kinds of death, and neither has anything to do with how carefully you verified them at publish time. Publish-time verification answers was this real? It cannot answer is this still real? Those questions are asked years apart, and only one of them is on your calendar.
Google, incidentally, agrees about the first case. Documenting soft 404 warnings that appeared after summer 2016 site migrations, Glenn Gabe quoted John Mueller: "Redirects to the homepage or non-relevant pages can be treated as soft 404s. Google will eventually remove those pages from the index, treating them as standard 404s, even though they properly redirect." If Google won't count a homepage redirect as a real destination, neither should your citation.
Numbers make this schedulable rather than vibes-based. Pew sampled roughly 90,000 pages per year from Common Crawl for each year from 2013 to 2023 and checked them in October 2023, counting a page as inaccessible only when it returned one of nine error codes that definitively indicate the page or host is gone. That deliberately conservative method produced the ladder above, plus one headline figure: 25% of the whole sample was inaccessible.
The split inside that 25% is what you can act on. Sixteen percentage points were pages deleted while their domain kept working; nine were root domains that vanished entirely. So most dead citations are page-level deaths on sites that are still alive and still ranking — the failure you cannot catch by scanning your archive and thinking "those companies all still exist." The company exists. The page doesn't.
Worse, the URLs a blog post cites are the ones that die fastest. A study of 27.3 million URLs sampled from the Wayback Machine and re-checked in 2023 found a median lifespan of 1.3 years for deep links against 8.8 years for root URLs, with 64.7% of the sample dead at the re-check. Over half of all deep links disappeared inside their first year. You don't cite stripe.com — you cite a changelog entry, a pricing page, a docs anchor. Every one of those is a deep link.
Source type matters as much as depth. A 20-year study of 2,886 web citations across 608 articles in four library and information science journals, published 14 January 2026, found .edu domains 93% accessible against .com at 42%, and static PDFs at 92% against database-driven content at 41%. Accessibility fell from 87% for citations under five years old to 38% for those over ten, and about 15% were unrecoverable by any method the authors tried. That's your prioritisation rule: the startup blog posts and vendor docs you lean on sit in the 42% bucket, standards documents and university PDFs in the 93% one.
One piece of illustrative arithmetic, mine rather than a sourced statistic. A two-year-old blog with 60 posts averaging a dozen citations carries about 720 external links. Apply Pew's ~20% two-to-three-year rate and roughly 140 are already dead. Apply the finding that 13% of still-resolving links in the New York Times archive had drifted significantly and another 70 or so quietly point somewhere else. That's an order of magnitude, not a prediction — but it's enough to tell you the audit will find something.
One number to avoid is the one everyone reaches for: Ahrefs' finding that 66.5% of links to 2,062,173 sampled websites since January 2013 had rotted. Real study, wrong scope — it measures inbound backlinks pointing at those domains, not outbound citations inside posts. Use it to say the links you earned decay too, never as the decay rate of your own footnotes.
Once you accept that "does it return 200?" is the wrong question, the audit needs a taxonomy — in ascending order of how hard each case is to detect.
Honest death: 404 or 410. The page is gone and says so. Google handles both the same way, dropping the URL from the index and reducing crawl frequency. Any checker catches this. Even Google lets its own URLs die this way: on 11 August 2026 the old webmaster-blog URL for "Evaluating page experience" returned a hard 404, while the post itself lives happily on Search Central. Every pre-migration post that cited the webmaster blog now has a broken citation.
Redirect to an error page. The Segment case above — catchable, but only by a tool that evaluates the destination.
Redirect to a homepage or section root. The docs.x.com case, invisible to status codes because the final response genuinely is a 200. Google's own definition of a soft 404 describes the same category of lie from the other direction: "The page request returns what we think is a soft 404 response. This means that it returns a user-friendly 'not found' message but not a 404 HTTP response code."
Content drift: still 200, no longer the same page. Klein et al.'s analysis of 3.5 million science, technology and medicine articles from 1997–2012 named this reference rot — link rot plus content drift — and found one in five articles affected, rising to seven in ten among those containing web references. Drift compounds with age: across 553,693 New York Times articles and 2,283,445 external links, 4% of still-reachable links in 2019 articles had drifted, against 25% of those in 2009 articles.
Now the counter-example, because a rule that cries wolf gets switched off. nextjs.org/docs/basic-features/pages hasn't been a canonical path for years, yet it still lands on the equivalent current documentation — a true 1:1 redirect, a reorganisation handled well. So the rule isn't flag redirects. It's flag redirects whose destination isn't the same thing.
You can predict most of your failures before running anything, which is how the first pass stays finishable.
Acquired startups. Content gets folded into the parent's site and the long tail of blog posts rarely survives the merge. Note that segment.com/blog/ itself redirects cleanly to Twilio's blog while the individual post redirects into a 404 — page-level death on a living domain, the pattern behind Pew's 16%.
Rebrands. developer.twitter.com → docs.x.com. The docs still exist; your specific anchor no longer resolves to anything specific.
Platform migrations. Google's webmaster blog moving to Search Central. Any vendor moving off a hosted CMS onto their own docs framework does this to you.
Shorteners and campaign URLs. These fall off a cliff rather than decaying. Google announced on 18 July 2024 that goo.gl links would stop resolving: "these URLs will no longer return a response after August 25th, 2025" and "all links served will return a 404 response." An August 2025 update spared links still in active use — but Google's framing of the rest was that "more than 99% of them had no activity in the last month." If an old post cites a goo.gl URL, the base rate says it's gone. Grep for shortener domains first; it's the highest-yield search you'll run all day.
Expired domains — the case that stopped being cosmetic. Infoblox research reported by Krebs on Security in December 2025 found visitors to parked domains directed to "illegal content, scams, scareware and anti-virus software subscriptions, or malware" over 90% of the time, against under 5% in 2014. The detail that should change your tooling: those redirects are driven by visitor profiling — geolocation, device fingerprinting, cookies — and visitors arriving over a VPN or from a non-residential address get the benign parking page. Your link checker runs from a datacenter IP, so it sees the safe version. Your readers don't.
Expired domains also get bought for their history, which Google names in its spam policies as expired domain abuse: "an expired domain name is purchased and repurposed primarily to manipulate search rankings by hosting content that provides little to no value to users." The canonical case is The Hairpin, which stopped publishing in January 2018, let its domain lapse, and was bought in 2024 by a Serbian DJ who filled it with AI-generated SEO articles under replaced bylines — telling Wired he'd bought it for its "great reputation and excellent backlinks." Every post that ever cited it now recommends a content farm.
The mechanics are cheap. The reason people abandon link audits isn't cost — it's noise.
If your blog lives in a git repo, lychee is the natural fit: a Rust link checker that reads Markdown, HTML, text, globs, remote URLs or stdin. Start with inventory rather than judgement — --dump will "dump all the links extracted from inputs that would be checked" without checking anything, which tells you how many outbound citations you're carrying. Then tune: --accept sets which codes pass (default 100..=103,200..=299), --exclude and .lycheeignore hold your regexes, --cache with --max-cache-age (default one day) keeps repeat runs cheap, and --host-concurrency (default 10) plus --host-request-interval (default 50ms) stops you hammering a small site. What it doesn't do: the docs claim no soft-404 detection, so the homepage-redirect case stays yours to adjudicate.
Make it a schedule, not a chore you remember. lychee-action runs on cron — its README shows on: schedule: - cron: "00 18 * * *" — and the documented pattern pipes the Markdown report into peter-evans/create-issue-from-file@v5 when steps.lychee.outputs.exit_code != 0, given issues: write permission. A dead citation then arrives as a GitHub issue with the report attached. If you already handle publishing a blog post by pull request, a citation repair ships through the same gate as a new article: branch, preview, merge.
If your blog is hosted or CMS-based, Screaming Frog's SEO Spider does the equivalent. Crawl the site, open the Response Codes tab, filter to "Client Error (4XX)", then use the Inlinks pane to see which of your posts links to each dead URL, anchor text included. The documented bulk path is Bulk Export > Response Codes > Client Error (4XX) Inlinks, with External > No Response Inlinks for timeouts and DNS failures. Plan around two things: the free version crawls up to 500 URLs (a licence is £199/year), and it classes external broken links as low-priority warnings — sensible for most audits, exactly backwards for this one.
Simpler setups work. One indie blogger's entire audit is a single linkchecker invocation with --check-extern and --ignore-url patterns for image paths, geo-redirecting corporate domains, consent pages and login-gated services. The last documented run: 376 links across 378 URLs, one error, fixed from a Wayback snapshot. That's the shape of a maintained archive, and it's what makes the job feel finishable. If you'd rather buy soft-error detection than build it, Dr. Link Check advertises a check for pages "returning 200 OK responses but with content indicating actual problems", plus scheduled runs and a malicious-domain blacklist.
Now the noise. Automated checks mislead in both directions. Terence Eden, who audited his own 16-year archive by hand, is blunt about why he distrusts status codes: "Lots of the dead sites have been taken over by scammers, spammers, and AI grifters. They return an HTTP OK and then serve up advertising." And in the other direction, plenty of live URLs simply refuse to talk to robots: on 11 August 2026, a tweet URL that exists returned HTTP 402 Payment Required to an automated fetch. That's one client on one day rather than a claim about any platform — but paywalls, consent walls and bot management routinely answer non-browser agents with 402, 403 or 429.
So the target is never zero errors. Automate detection and inventory, keep a human on adjudication, and treat the ignore list as a maintained artefact: every entry should carry a comment saying which URL it covers and why. Otherwise, in eighteen months, it's just a list of things you've agreed not to look at.
The audit only pays off if each result has a predetermined action; otherwise the report becomes a backlog. Start from the best-documented policy in existence — Wikipedia's — whose first principle is the one most people get wrong: "In general, do not delete cited information solely because the URL to the source does not work any longer." The claim and the link are separate things. Wikipedia's repair order runs: find the content at its new location, check web archives, find an alternative source so the loss doesn't harm verifiability, then request a URL move. Dead links get a dated {{dead link}} tag, because "marking dead links signals to editors and to link rot bots that this link needs to be replaced."
That approach scales: by October 2018, more than 9 million broken Wikipedia links had been repaired by pointing them at Wayback snapshots, across 22 language editions. Your archive is not Wikipedia, but the pattern transfers.
Here's the table version, adapted for a blog. It's a proposal rather than a standard — commit it beside your ignore list, and a scary-looking report turns into ten minutes of work.
| What the pass sees | What it usually means | The rule |
|---|---|---|
| 200, same page | Healthy | Leave it; cache the result |
| 301/308 → equivalent page | Reorganisation (the Next.js case) | Rewrite the URL to the final destination; no prose change |
| 301/307 → homepage or docs root | Page deleted, redirect papering over it | Treat as dead: find the new page, else a snapshot, else re-source the claim |
| 301 → error page | Content retired in a migration | Same as above — your checker must evaluate the final status |
| 404 / 410 | Honest death | Snapshot if the claim still needs the citation; otherwise replace the source |
| 402 / 403 / 429 / consent wall | Probably alive, bot-blocked | Verify by hand once, then add to the ignore list with a comment |
| 200 but content unrelated | Drift, repurposing, or a resold domain | Highest risk: re-read your own sentence, because the claim may now be wrong |
| DNS failure or parked page | Domain expired or resold | Never re-link the live URL; snapshot or remove |
| No snapshot anywhere | Unrecoverable | Rewrite the sentence so the claim stands alone, or cut it |
Two of those rows lean on archives, and that step has an API so it needn't stay manual. The Wayback availability endpoint — http://archive.org/wayback/available?url=example.com×tamp=20060101 — returns the closest snapshot's URL, timestamp and status, or {"archived_snapshots":{}} when nothing exists. That empty object is your triage signal: no snapshot means the citation is unrecoverable and the work moves back into the prose. Note the limits, though. The Internet Archive was knocked offline by a DDoS attack on 9 October 2024, and archive.org was still only provisionally available in read-only mode on 21 October. Combined with that ~15% of citations nothing could recover, archives are an excellent fallback and a poor strategy.
The cheapest repair is the one you set up before the link dies — and almost nobody does. Klein's analysis found that about 75% of URI references had no archive snapshot within 30 days of their citing article's publication. The snapshot you want later usually doesn't exist, because nobody took it at the time.
Three habits fix that. First, save each cited page as you publish: Save Page Now at archive.org/web "save[s] a specific page one time" — it does not add the URL to future crawls, and there's a documented 3–10 hour lag before the capture appears. Second, record what the link resolved to: the final URL, the destination title, and the one sentence you're relying on. Since no small-blog tool reliably detects "still 200, no longer the same page", evidence stored at publish time is the only thing a later drift check can compare against. Third, Robust Links is the standards-flavoured version: data-originalurl, data-versionurl and data-versiondate attributes on the anchor, so a reader can choose the live page or the snapshot as it stood the day you cited it.
This is where automated drafting earns its place instead of adding to the pile. The useful output of publish-time checking isn't a green tick — it's the record of what every link resolved to and when. Magic Share won't save a draft until every cited URL resolves, and it attaches a link verification report to every draft: read that report as the day-zero baseline your day-700 drift check will diff against, and archive its URLs while they're warm. If you're auditing fresh drafts rather than an old archive, the companion piece is our 20-minute fact-checking checklist for AI drafts — same discipline, opposite end of the timeline.
Keep the dates honest afterwards. Google's guidance is direct: "Don't specify future dates, or the date of the action described on the page. The dates must describe the publication or update date of the page", and visible dates must stay consistent with structured ones — where dateModified means the date and time the article was most recently modified. Repairing two links is not a republication; a genuine rewrite is.
Pick the interval from the decay data rather than from enthusiasm. At roughly 8% loss per year, an annual pass leaves about a twelfth of your citations wrong for up to twelve months, while a daily full crawl mostly re-checks links that were fine yesterday. Monthly across the whole archive is cheap once responses are cached, quarterly is defensible, and every build should re-check the newest post's links plus any URL that has failed before. Prioritise by risk with the evidence you already have: deep links before root URLs, .com before institutional domains, shorteners before anything, vendor docs and startup blogs before standards bodies.
Be honest about the payoff, because a technical reader will ask. Outbound links are not a ranking factor — Search Engine Journal's verdict is "unlikely", quoting Mueller in 2016 that "external links to other sites... isn't specifically a ranking factor. But it can bring value to your content and, in turn, can be relevant for us in search," and Danny Sullivan in 2019: "I'd think of linking as just part of proper attribution." So don't sell this as a traffic lever. Sell it as accuracy, reader trust, and not handing readers a parked domain. The adjacent case for touching old posts at all is HubSpot's report that historical optimisation raised monthly organic views on the posts it optimised by an average of 106% across 75 posts — though that's a vendor self-report, and the intervention was a full refresh rather than link repair.
One question is worth flagging rather than answering: as answer engines increasingly summarise archives, does a dead citation make a page less likely to be cited? I found no evidence either way. What is evidenced is that verification pressure is rising at both ends of the pipeline — an April 2026 study of commercial deep-research agents found 3–13% of citation URLs hallucinated and 5–18% non-resolving. If you're working on getting cited by ChatGPT and AI Overviews, a citation trail that still resolves is table stakes.
"Done" isn't zero broken links forever. It's a maintained ignore list, a written rule per verdict, a scheduled job that files its own issue, and a first pass that ends like that indie blog's did: 376 links, one error, one snapshot substitution.
How often should I run a link rot audit on my blog? Monthly across the whole archive if your checker caches results, quarterly if you'd rather batch it, and on every build for the newest post plus any URL that has failed before. At roughly 8% loss per year, an annual pass leaves about a twelfth of your citations broken for up to a year.
Do broken outbound links hurt my SEO rankings? Not directly — Search Engine Journal's ranking-factor verdict on outbound links is "unlikely", and Google's spokespeople frame linking as attribution rather than a ranking input. The real costs are accuracy, since drift can silently make your prose wrong, and reader trust, given that over 90% of visits to parked domains now end in scams, scareware or malware.
What's the difference between link rot and content drift? Link rot is a URL that no longer resolves; content drift is a URL that resolves to something that no longer says what you cited it for. Together they're called reference rot. Drift is the more dangerous half because status codes can't see it — 13% of still-resolving links in the New York Times study had drifted significantly.
Should I replace dead links with Wayback Machine snapshots or delete them? Follow Wikipedia's principle: don't delete cited information solely because the URL stopped working. Look for the content at its new location, then a snapshot, then an alternative source. Cut the claim only when the availability API returns no snapshot and no replacement exists — roughly 15% of cases in the LIS study.
Why does my link checker report errors for pages that clearly work?
Because many live pages refuse non-browser clients: paywalls, consent walls, login gates and bot management commonly return 402, 403 or 429 to automated fetches. Verify each by hand once, then add it to .lycheeignore or --exclude with a comment explaining why. Aim for a maintained ignore list, not a zero-error report.
Publish-time verification is the floor. It proves a citation was real on the day it shipped, which matters — but a link checked once is a link checked once, and the median deep link only lives about 1.3 years. A scheduled re-resolution pass plus a written rule per verdict turns that decay from an ambient embarrassment into a small recurring task with a defined end.
Set the cron job this week. Grep for shortener domains first, run lychee --dump to see how many citations you're carrying, and commit the decision table so future-you doesn't have to re-litigate what a homepage redirect means.
And if the bigger problem is that new posts arrive faster than you can verify them, that's the part Magic Share handles: the agent researches, drafts, and resolves every cited URL before a draft is saved — then waits for your approval, because merging the pull request is the publish step. The free plan includes three posts, enough to point it at your own site and read a real verification report before you commit to anything.
Magic Share researches, writes and fact-checks posts like this for any site — point it at your URL and review your first draft today.
Plant your first post