Newsletter Link Rot on Substack, Ghost and beehiiv: Archive Checks That Work

Every newsletter issue is sent once and read for years. The email lands in inboxes on Tuesday. The web version sits in your archive, gets indexed, gets shared, and becomes the thing new readers browse before subscribing.

The links in those archive pages quietly decay. Sources move, tools shut down, sponsors rebrand, tweets disappear, and your own old URLs change when you switch platforms or add a custom domain. Pew Research Center found that 38% of webpages that existed in 2013 were no longer accessible a decade later, and that even of pages collected in 2021, about one in five were gone two years on (Pew Research Center, 2024). A newsletter that links to a dozen sources an issue builds up dead links fast.

This guide is practical and platform-specific: what to check before you send, how to audit an archive on Substack, Ghost or beehiiv, the custom domain and migration traps, and a routine that fits around a weekly publishing schedule.

Part 1: The pre-send check (two minutes per issue)

The cheapest dead link to fix is one that never ships. Before every send:

1. Open the web preview and click every link. Yes, every one, especially the sponsor link and your main source.
2. Watch for redirects to homepages. If a source link lands on the site's homepage instead of the article, the article has probably moved or been removed. Find the current URL.
3. Strip tracking junk from links you copied (?utm_..., ?ref=..., session IDs). They make URLs longer and more fragile.
4. Prefer stable sources: original research, official docs and the publisher's own page over syndicated copies, screenshots of screenshots, or social posts.
5. Save key sources to the Wayback Machine. Submitting a URL to web.archive.org/save before you publish means a snapshot exists if the page later disappears.

For longer issues, a quick command-line pass over the links on the web preview catches typos you'd miss by eye:

curl -sL "https://yournewsletter.example/p/issue-slug" \
 | grep -oE 'href="https?://[^"]+"' | cut -d'"' -f2 | sort -u \
 | while read -r u; do
     printf '%s %s\n' "$(curl -s -o /dev/null -L --max-time 15 -w '%{http_code}' "$u")" "$u"
   done | sort

Anything that isn't 200 deserves a look. Some sites return 403 to scripts but work in a browser, so treat those as "check by hand", not "broken".

Part 2: Find every archive URL with the sitemap

You can't audit an archive you can't list. Fortunately, the major platforms publish sitemaps:

• Substack publications serve a sitemap at /sitemap.xml listing the archive, about page and individual posts under /p/…. You can see this on Substack's own publication at on.substack.com/sitemap.xml.
• Ghost "automatically creates and updates an XML sitemap for your website" (Ghost: SEO in Ghost), at /sitemap.xml, which links to separate sitemaps for posts, pages, tags and authors.
• beehiiv and other platforms generally provide a sitemap too. Check yourdomain/sitemap.xml, or look for a sitemap reference in /robots.txt.

Extract the post URLs:

curl -sL https://yournewsletter.example/sitemap.xml | grep -oE '<loc>[^<]+' | sed 's/<loc>//' > archive.txt
# For a Ghost sitemap index, repeat for each child sitemap listed (e.g. sitemap-posts.xml)

Now you have the complete list of issue pages to check.

Part 3: Audit the archive

Check every outbound link

Feed archive.txt into a crawler in list mode. Screaming Frog SEO Spider does this with Mode → List and is free up to 500 URLs (limits), which covers years of weekly issues. Configure it to check external links, then filter outbound links by 4xx/5xx and use the Inlinks pane to see which issue each dead link is in.

Prioritise

Fix in this order:

1. Issues that still get traffic. Check your platform's post stats or analytics.
2. Issues linked from your welcome email, about page or "start here" page. New subscribers read these first.
3. Sponsor links. A sponsor paid for a working link.
4. The main source of each issue, before passing mentions.

Fix

• Moved: update to the new URL.
• Gone but archived: link to the Wayback Machine snapshot and say it's an archived copy. The Wayback availability API can find the closest snapshot for a URL and date, which helps for bulk fixes.
• Gone, no archive: replace with an equivalent source or remove the link and adjust the sentence.

Edit the web version of each issue; the emails already delivered can't be changed. Keep a short changelog of what you fixed and when, so a later audit doesn't re-check the same dead sources and you can spot which sites rot most often.

Part 4: Your own URLs, the links you can actually control

The most damaging rot in a newsletter archive is often self-inflicted: your own URLs changing.

Adding a custom domain

Moving from yourname.substack.com to your own domain is a common step. Substack says that when you add a custom domain, "all previous links using the Substack subdomain will automatically redirect to your new custom domain" (Substack: Bulletin). Its help centre recommends hosting on a subdomain such as www. with the root domain redirected to it (Substack Help: custom domains). After the switch, test a handful of old subdomain links yourself, including from old emails, and confirm they land on the right post in one redirect.

Changing platforms

Platform moves usually change URL patterns. Ghost's redirect tutorial includes specific rules for handling the /p/ post paths used by Substack and beehiiv when migrating to Ghost, and explains that redirects are managed by uploading a redirects file in Ghost's settings (Ghost: Implementing redirects). Whatever the direction of your move:

1. Before migrating, save the full old sitemap (archive.txt above). It's your old-URL inventory.
2. Map old patterns to new ones (often a single rule per pattern).
3. After migrating, run the old list through a status check. Every old URL should 301 to its new home in one hop.
4. Update internal links in recent issues and your about/welcome pages so they don't depend on redirects.

I wrote a fuller recovery process for site moves in 404 Errors After a Site Migration or Redesign: A Recovery Checklist. It applies just as much to newsletter archives.

Links between your own issues

"As I wrote last month…" links point at your own archive. Use the canonical URL of the post (custom domain, not the old subdomain) so they never rely on a redirect.

Links in email bodies

Most email platforms rewrite links for click tracking through their own domain. That works while the account is active. If you change platforms or tracking domains, links in emails already sitting in inboxes can stop resolving, which is one more reason the web archive, which you can fix, matters.

Part 5: The quiet failure mode, reference rot

Some links still "work" but no longer show what you linked to: the page is now a custom 404 returning 200, a redirect to a homepage, or an updated article that no longer says what you quoted. A Harvard study of legal citations found that more than 70% of URLs in the journals studied, and 50% of URLs in U.S. Supreme Court opinions, no longer produced the information originally cited (Zittrain, Albert & Lessig, Harvard Law Review Forum, 2014). Status-code checkers can't catch this. For your most important sources, open them by hand once in a while, and keep Wayback snapshots of anything you quote.

Part 6: A routine for busy writers

For the bigger picture of what to check daily, weekly and monthly on any site, see Automating Website Monitoring: What to Check Daily vs Weekly vs Monthly.

Automating the archive check

The quarterly crawl is the step that usually slips, because it's never urgent until a reader or sponsor points out a dead link.

Disclosure: I build Uchik, which can run that check daily for a newsletter's web archive. Uchik crawls the site every day and emails a report of broken outbound and internal links, broken images and redirect problems, showing the page where each one was found. The features page lists the checks and the sample report shows what a report looks like. Limits worth knowing, also covered in the FAQ: it checks the public web archive, not the emails in inboxes; it detects link rot, not reference rot; and it reads server-delivered HTML, so links added only by JavaScript may be missed; and the free plan covers one site. Google Search Console is still worth connecting for your archive's indexing and 404 reports. You can sign up for free.

Checklist

• [ ] Pre-send click-through for every issue
• [ ] Welcome email and "start here" page links checked monthly
• [ ] Key sources saved to the Wayback Machine at publish time
• [ ] Archive URL list pulled from the sitemap
• [ ] Quarterly outbound link check; top-traffic issues and sponsor links fixed first
• [ ] Dead links updated, pointed to archived copies, or removed
• [ ] Custom domain redirects tested from old subdomain links
• [ ] Platform migration: old-URL inventory, mapping, one-hop redirects, re-check
• [ ] Internal "as I wrote" links use canonical URLs
• [ ] Important sources spot-checked for reference rot

Your archive is the best case for subscribing. Keeping its links alive keeps that case strong.