Your archive is also more valuable than it looks. Archive pages get indexed by search engines, get shared on social media long after the send date, and are often the first thing a potential subscriber reads before deciding to sign up. If a third of the links in your best-performing issue from 2022 now go nowhere, that's the impression a new reader gets.

This guide covers why archives rot, how to audit one, what you can and can't fix, and how to write issues that age better.

How fast links die

The best public data on this comes from large studies of the web in general, and it's sobering:

• Pew Research Center found that 38% of webpages that existed in 2013 were no longer accessible in 2023, and even of pages collected in 2021, "about one-in-five were no longer accessible just two years later" (Pew Research Center, May 2024).
• A Harvard study of links cited in legal journals found more than 70% of URLs no longer produced the information originally cited, and 50% of URLs in U.S. Supreme Court opinions had the same problem (Zittrain, Albert & Lessig, Harvard Law Review Forum, 2014).

That second study makes a distinction every newsletter writer should know:

• Link rot: the URL no longer loads anything useful. You get a 404, a server error or a dead domain.
• Reference rot: the URL still loads, but the content has changed or vanished. The page might now be a "custom 404" that returns a success code, a redirect to a homepage, or an updated article that no longer says what you quoted. The Harvard researchers found this was common even among links that returned HTTP 200.

Reference rot matters for curators, because a link checker that only looks at status codes will say everything is fine.

Why newsletter archives rot faster than blogs

1. Link density. A roundup issue can contain dozens of external links. More links means more chances to break.
2. Time-sensitive targets. Newsletters often link to news, launches, job posts, event pages, discount codes and tweets, which are some of the most short-lived content on the web.
3. You can't edit what was sent. The copy delivered to inboxes is frozen. The only version you can maintain is the web archive.
4. Click tracking adds a hop. Most email platforms rewrite links in sent emails to go through a tracking redirect on their domain before reaching the destination. That's fine while the account is active. If you change platforms, change your tracking domain or close the account, those tracking redirects in old emails can stop resolving.
5. Platform migrations change URLs. Moving between platforms usually changes the URL pattern of archive posts. Ghost's migration guide, for example, includes specific redirect rules for handling the /p/ paths that Substack and beehiiv custom-domain archives use (Ghost: Implementing redirects). Skip those redirects and every inbound link to your old archive breaks at once.

Auditing your archive, step by step

Step 1: Get a list of archive URLs

You need every web version of every issue. Depending on your setup:

• Check your archive's sitemap, usually at /sitemap.xml on your newsletter's domain. It lists every post URL.
• Or export posts from your platform's settings (most offer a CSV or content export).
• Or crawl the archive index page and let the crawler discover issue pages.

Step 2: Check every link on those pages

• Screaming Frog SEO Spider (free up to 500 URLs; limits): use Mode → List, paste your archive URLs, and in the crawl configuration enable checking of external links. Afterwards, the External tab shows every outbound link with its status code, and the Inlinks pane shows which issue each one appears in.
• For a single issue, a browser extension that highlights broken links on the current page is the quickest check.
• Command line: for a quick look at one URL's redirects and final status, use curl -sIL <url> | grep -iE "^(HTTP|location)".

Export the results and sort by issue, then by status.

Step 3: Triage

Not every dead link deserves the same effort. Prioritise:

1. Issues that still get traffic. Check your analytics or platform stats for the archive posts people still read. Start there.
2. Issues you link to from your welcome email, homepage or "best of" page. New subscribers read these first.
3. Links that carry the point of the issue, such as the main source or the tool you recommended, rather than passing mentions.
4. Sponsor links. Sponsors paid for a link that works, and a dead one reflects on you.

A note on scale: if your archive has hundreds of issues, don't try to fix everything in one weekend. Fix the top twenty issues by traffic, then set aside half an hour a week to work backwards through the rest. Keep a simple spreadsheet with the issue URL, the broken link, what you changed and the date, so you don't recheck the same links next time and so you can see the job shrinking.

Also watch for links to your own content. Newsletters often link to earlier issues, your website, your podcast or a lead magnet. Those are the links you have full control over, and they're often the ones broken by your own redesigns or platform moves. Fix these first: a reader clicking "as I wrote last month" and landing on an error page is a bad look.

Step 4: Fix

For each broken link:

• Look for the new location. Search the destination site or the web for the page title. Many "dead" links just moved.
• Use an archived copy. If the original matters (a quote, a statement, a dataset), the Internet Archive's Wayback Machine may have a snapshot. Its availability API returns the closest snapshot for a URL and a date, so a script can find candidates for a whole list at once. Link to the snapshot, and say that it's an archived copy.
• Replace it with an equivalent current source if the archived copy doesn't exist.
• Remove the link and adjust the sentence if nothing else works. A clear "this resource is no longer available" note is better than a dead link.

Edit the web version of each issue. You can't change what's already in inboxes, but the archive is what search engines, new readers and shared links reach.

Step 5: Check for reference rot on your most important links

For the handful of links that matter most, open them and check they still say what you quoted. If the page has changed, link to an archived copy from around your send date, or update your text.

Writing issues that age better

Prevention is far cheaper than cleanup. A few habits make new issues last longer:

• Link to the most stable version of a source. The original research, the official documentation, the publisher's own page, rather than a syndicated copy, a social media post or a URL with tracking parameters.
• Save important sources when you link to them. The Wayback Machine's "Save Page Now" at web.archive.org/save captures a page on demand. Doing it at publish time means a snapshot exists when you need it later.
• Give readers enough context to search. "Pew's 2024 study on disappearing web content" stays findable even if the URL dies. "This study" doesn't.
• Own the links you reuse. For links you put in many issues (your sign-up page, your shop, a recurring resource), consider a short redirect on your own domain, e.g. yourdomain.com/guide. If the destination changes, you update one redirect and every past issue keeps working.
• Plan migrations properly. Before moving platforms, export the full list of old archive URLs, map each to its new URL, set up redirects, and then crawl the old list to confirm each one lands in a single hop.

Keeping an eye on it continuously

An archive audit is a big job the first time and a small one after that, as long as you keep checking. Because links break constantly in the background, a recurring automated check catches problems while they're still few.

Disclosure: I build Uchik, which can do that for a newsletter's website. Uchik crawls your site every day with read-only requests and emails a report of broken external and internal links, missing images and redirect chains, each tied to the exact issue page and HTML link that caused it. How it works explains how it follows each redirect hop and records the final status, and the features page lists every check. The sample report includes a publisher example. You can sign up for free, no credit card needed. Like any status-code checker it catches link rot, not reference rot, so keep the manual spot-check in Step 5 for links that matter most.

Checklist

• Full list of archive URLs (sitemap or export)
• External link check run across the archive
• Results sorted by issue; high-traffic and "best of" issues fixed first
• Dead links replaced, pointed to archived copies, or removed
• Key sources spot-checked for reference rot
• Migration redirects tested in list mode (if you've ever changed platforms)
• New-issue habits in place: stable sources, saved snapshots, owned redirects
• Recurring check scheduled or automated

A newsletter archive is a public record of your judgement. Keeping its links working keeps that record useful to new readers.

This article covers what redirect chains and loops are, what they actually cost (without overstating it), how to find them with free tools, and how to fix them so they stay fixed.

Definitions

• Redirect: the server answers a request with a 3xx status (usually 301 or 302) and a Location header saying "go here instead."
• Redirect chain: one redirect leads to another redirect, then another, before a page finally loads. Example: http://shop.com/dress → https://shop.com/dress → https://www.shop.com/dress → https://www.shop.com/products/summer-dress
• Redirect loop: the redirects never end. A sends you to B, and B sends you back to A (or round a longer circle). Browsers give up and show an error such as Chrome's ERR_TOO_MANY_REDIRECTS.

What chains and loops cost

1. Speed, especially on mobile

Every hop is a separate request and response. The browser has to receive the redirect, then make a new request to the next location before any content starts downloading. If the hop changes host (for example shop.com → www.shop.com), it may also need a new connection. Google's Lighthouse documentation says each extra trip "can delay the loading of the resource by hundreds of milliseconds", and its audit fails a page with two or more redirects (Chrome for Developers: Avoid multiple page redirects). Ad and email traffic often lands on mobile connections, where round trips are slowest, so that's where chains hurt most.

2. Fragility

A chain only works if every hop works. When one intermediate URL in a four-hop chain gets deleted, edited or caught in a new rule, the whole chain breaks, and every link that relied on it breaks with it. Short chains have fewer things that can fail.

3. Search engines may give up

Google says its crawlers follow up to 10 redirect hops by default, and some Google tools don't follow redirects at all (Google: How HTTP status codes affect Google's crawlers). Most chains are well under 10 hops, so this rarely causes outright failure. Still, each hop is wasted crawling on a site that may have thousands of product and filter URLs, and Google's own migration guidance recommends avoiding chained redirects and updating internal links to final URLs (Google: Site moves with URL changes).

4. Loops are outages

A loop isn't slow; it's broken. A shopper who hits a looping product, cart or login URL can't reach it at all. Because loops often come from a server or CDN setting rather than one bad link, they can take out a whole section or the entire site at once.

Where chains and loops come from in stores

Protocol and host hops stacked together. The most common chain is HTTP → HTTPS → www (or the reverse). Each rule is fine on its own, but together they make two hops. Fix it with one rule that sends any variant straight to the final https:// + preferred host.

Migration layers. The store moved from platform A to B in 2021, then changed its URL structure in 2024. Old URLs redirect to the 2021 version, which redirects to the 2024 version. Nobody updated the first set.

Redirecting to a URL that itself redirects. On Shopify, WooCommerce or any CMS, it's easy to create a redirect whose target was renamed later. The old redirect now points into another redirect.

Trailing slashes and case. /Sale → /sale → /sale/ is a chain made purely of formatting rules.

Conflicting rules (loops). Two systems disagree about the "right" URL. Classic examples:

• A CDN set to connect to your server over plain HTTP while the server forces HTTPS, so each side keeps redirecting the other. Cloudflare documents this exact case with its "Flexible" SSL mode (Cloudflare: ERR_TOO_MANY_REDIRECTS).
• A WordPress site whose Site Address setting says http:// while the host forces https://.
• A redirect plugin rule that sends /shop to /store while another rule (or the theme) sends /store back to /shop.
• Geolocation or language redirects that bounce between country versions.

How to find them (free)

Check a single URL in your terminal

curl is built into macOS, Linux and current versions of Windows:

curl -sIL https://shop.com/old-product | grep -iE "^(HTTP|location)"

-I fetches headers only, -L follows redirects, and the grep shows each status and Location. More than one 3xx line means a chain. If curl stops with "Maximum redirects followed", you have a loop.

Check in the browser

Open developer tools (F12) → Network, tick Preserve log, and load the URL. Each redirect appears as a separate row with a 301/302 status. The Initiator and Location response header show where each hop went.

Crawl the whole site

The free version of Screaming Frog SEO Spider crawls up to 500 URLs (limits). After a crawl:

1. Response Codes → Redirection (3xx) lists every internal link that hits a redirect.
2. Reports → Redirects → Redirect Chains exports each chain with every hop, the number of redirects, and whether it ends in a loop.
3. To test old URLs (from a previous platform, an old sitemap or a backlink export), switch to Mode → List and paste them in. This is the best way to audit a past migration.

Check Search Console

In Google Search Console, Indexing → Pages includes a Redirect error reason for URLs Google couldn't follow, such as loops, chains that are too long, or redirects to an empty or invalid URL. Page with redirect is normal and simply means Google indexed the target instead.

How to fix them

Rule 1: Point every redirect straight at the final URL

For each chain, write down the first URL and the final 200 URL. Then edit the first redirect so it points directly at the final URL, and repeat for every intermediate URL that still gets traffic. Afterwards each old URL takes a single hop.

On Shopify, export redirects from Content → Menus → View URL redirects → Export, fix the "Redirect to" column in a spreadsheet, and re-import (Shopify: URL redirects). On WordPress/WooCommerce, the free Redirection plugin lets you edit targets and see hit counts, so you know which old URLs still matter.

Rule 2: Update your internal links

Redirects are for links you can't control (backlinks, old emails, printed QR codes). Your own menus, product descriptions, theme settings and sitemaps should link straight to the final URL, so no internal click ever passes through a redirect. Screaming Frog's Inlinks tab for each 3xx URL shows exactly which pages to edit.

Rule 3: One canonical host rule

Decide on one form, such as https://www.shop.com. Then make sure there is one rule (at the CDN or the server, not both) that sends any other variant there in a single hop. If you use a CDN, set its SSL mode to match your server's certificate so the two never fight. That alone prevents the most common sitewide loop.

Rule 4: Breaking a loop

1. Find the hops with curl -sIL --max-redirs 10 URL.
2. Identify which system issues each hop. The server header and other response headers often show whether it came from the CDN, the web server or the app.
3. Turn off or change one of the conflicting rules. Don't add a third rule to "override" both.
4. Clear the browser cache before re-testing. Browsers cache 301s, so you may keep seeing the old behaviour after it's fixed.

Rule 5: Use the right status code

Use 301 (or 308) when a move is permanent and 302 (or 307) when it's temporary, such as a sold-out seasonal page that will return. Google treats 301 as a strong signal and 302 as a weak one (Google). Leaving a "temporary" redirect in place for years sends mixed signals.

Keeping it clean

• Before any migration or URL restructure, export the current redirect list and test it in list mode after launch.
• When adding a redirect, test the target first. If it returns 3xx, use its final destination instead.
• Review redirects twice a year. Delete ones with no hits that nothing links to, and flatten any new chains.
• Watch for new chains after theme or app changes, which sometimes add their own URL rules.

Automating the check

Chains and loops tend to appear quietly after admin changes, so a recurring check beats a one-off audit. Screaming Frog's paid licence can schedule crawls, and SEO suites with site audits will flag chains too.

Disclosure: I build Uchik. Uchik is a hosted option that crawls your site daily with read-only GET requests and emails you any redirect chain or loop it finds. How it works describes the method: it follows redirects one hop at a time and stores every hop in order, so you see the whole chain, not just the final URL. The sample report shows a demo redirect-chain finding with its source page. You can sign up for free and add one site.

Summary

Every redirect should take one hop, land on a page that loads, and only exist for links you can't edit yourself.