Mortise (opens in a new tab) 5 min read

How to find newly broken links after a website migration

After a migration, the links that used to work and now 404 are the ones that hurt. Baseline the new site, then alert only when a link newly breaks.

Run a crawl once the new site is the site people are using, keep that crawl as a silent baseline, and get an alert only when a link that worked then later returns 404 or 410. The migration creates the risk. The follow-up crawl is what catches it.

What a migration breaks

Pages move. A post that lived at /blog/old-title now lives at /journal/old-title, or it does not live anywhere. Navigation is rebuilt. A template that printed a related-post URL now prints a slug that 404s. A footer link still points at a campaign page you deleted on purpose, and another still points at a page you deleted by mistake.

Redirects cover the URLs you remembered. They do not cover the URL a template is still emitting.

Three kinds of link

Treat them differently or the crawl turns into a pile.

  • Redirects. A 301 or 302 from the old URL to the new one is a success for the visitor, as long as the target itself loads. The broken case is a redirect to a URL that then 404s, or a chain you did not mean to leave in place.
  • Internal links. These are the ones your templates, menus, and body copy still point at. A wrong internal link is a page on the new site sending people to a dead page on the new site.
  • External links. Mortise checks links it finds on the pages it visits, including external URLs. An external 404 can be a vendor that moved, or a URL you mistyped in the new CMS. It is still a dead end for the visitor.

www and the apex domain count as one site. You verify a site you own before it is crawled. Mortise does not crawl a site you cannot prove is yours.

Why the new breaks matter most

A full audit on day one lists every broken link, including ones that were broken on the old site and ones you already decided to leave. That list is useful once. It is a poor thing to re-read every Monday. For a punch list that also covers redirects, SEO basics, and SSL, SiteCheck (opens in a new tab) is the inspection tool; Mortise is the follow-up that watches for new breaks.

After launch, the question changes. Did this week's template edit, content import, or redirect cleanup break something that was fine yesterday?

That is the question Mortise (opens in a new tab) is built for. The first crawl is a silent baseline. Later crawls notify only after a link fails twice as 404 or 410. A link that was already broken on the baseline stays quiet. A link that worked, then failed on two crawls in a row, is the alert.

The double failure is deliberate. One bad response can be a timeout or a blip. Two failures in a row, after a working baseline, is a link that newly broke.

When to take the baseline

Take it when you would be willing to call the new site "current":

  1. The new host is serving the site visitors get.
  2. The redirects you planned are in place.
  3. The templates that print menus and related links have been deployed.
  4. You have verified ownership of the site in Mortise.

Crawl then. That crawl does not send alerts. It is the picture of the site as you shipped it.

If you crawl too early, half-finished URLs become the baseline and later "fixes" look like changes, or real bugs get stored as normal. If you only crawl once, you get a snapshot and no ongoing check.

What the free plan covers

Free: 1 verified site, 200 pages per crawl, a manual crawl at most once every 24 hours, dashboard only, no card. A failed crawl does not use up that daily attempt. Links found on those pages are checked too, including external URLs. New-break history on Free is 14 days.

Pro is $12/month or $79/year: 10 sites, 2,000 pages per crawl, a daily or weekly schedule (or still manual), email and a signed webhook for new breaks only, CSV export, and 180 days of new-break history. Email alerts need outbound mail to be configured. Until then, Pro still includes the dashboard, schedules, CSV, and webhooks.

Two hundred pages is the free ceiling. Point the first site at the host you just migrated, not at a staging host you are about to throw away.

A sensible order of work

  1. Click the important paths yourself: home, top navigation, one sample of each template. Fix the obvious wrong hrefs before you baseline. A baseline full of mistakes you already know about is a noisy start, even if those mistakes stay quiet afterwards.
  2. Verify the site and run the first crawl. Read the dashboard. Do not expect an email. Free does not send one, and the first crawl would not have alerted anyway.
  3. The next day, or the next week on Pro, crawl again.
  4. Act on links that newly failed twice. Add the redirect, fix the template, or remove the link.
  5. Leave known dead links in the baseline alone, unless you have now fixed them and want the next crawl to see them as working.

A one-off checker will keep printing the same historical 404s. Why that happens, and why it wears people out, is in why broken-link checkers keep reporting the same broken links.

What this does not watch

Mortise does not tell you that a competitor's pricing page changed, or that your certificate is due. Those are URL checks. SignalWatch (opens in a new tab) does that job. The split is in website change monitoring vs broken-link monitoring.

Checklist

  • Baseline taken on the site visitors are using, after redirects and templates landed.
  • Ownership verified. Staging does not count unless staging is what you meant to watch.
  • Second crawl scheduled in your head, or on Pro, for real.
  • New 404s and 410s fixed at the template or the redirect, not by ignoring the alert.
  • Old, known broken links left quiet on purpose.