Broken links & redirects after a site migration: a practical checklist

A redesign, CMS switch, or domain move can erase years of earned URLs overnight if redirects are an afterthought. Traffic dips are common during migrations; preventable 404 storms and redirect chains are not. This checklist walks you through inventory, 301 planning, chain cleanup, sitemap and internal-link updates, and Search Console monitoring so visitors and crawlers land on the right page every time.

1. Why migrations break SEO

Search engines do not “know” you redesigned the site. They know URLs, status codes, redirects, canonicals, and links. When those change without a careful handoff, rankings and bookmarks point at empty space. The usual failure modes look boring in a project plan and catastrophic in analytics:

  • Missing redirects: Old URLs return 404 or soft 404 pages instead of permanent redirects to equivalents.
  • Wrong targets: Product or article URLs all dump onto the homepage, diluting relevance signals.
  • Redirect chains: Old → temporary staging → new path → trailing-slash fix → HTTPS, adding latency and risk.
  • Stale sitemaps: XML still lists old hosts or dead paths while the live site uses new ones.
  • Conflicting signals: Canonicals, hreflang, or internal links still advertise pre-migration URLs.

Treat migration SEO as a transfer of identity from old URLs to new ones. Content quality and design matter, but if the transfer fails, the best redesign still starts from a crawl hole. Pair this guide with the wider foundations in our practical SEO guide and the technical SEO hygiene checklist.

2. Inventory every URL that matters

Do not start mapping in a spreadsheet of “important pages from memory.” Build an evidence-based inventory before go-live.

Pull these sources

  • Crawl of the live site: All indexable HTML URLs, plus PDF/download paths that earn links.
  • Search Console: Pages with impressions over the last 12–16 months (Performance → Pages).
  • Analytics landing pages: Organic and referral landings that convert or drive meaningful sessions.
  • Backlink reports: External links to deep URLs—these are the ones that hurt most when they 404.
  • CMS exports: Slugs, category archives, pagination patterns, and old campaign landing pages.
  • Known aliases: HTTP vs HTTPS, www vs non-www, trailing slash variants, and legacy parameter URLs worth preserving.

Deduplicate after normalizing hosts and protocols. Keep a column for “keep / merge / retire.” Retiring a page is fine when content is obsolete—just redirect to the closest useful parent, not always the homepage. For discovery of dead paths after launch, use the broken link checker against both the old host (while it still responds) and the new site once redirects are live.

Prioritize by impact

Rank inventory rows by impressions, backlinks, and conversion value. Map high-impact URLs first and test them manually. Low-traffic URLs still need a rule (pattern redirect or intentional 410), but they should not delay the core map. Pattern rules help for dated blog paths or ID-based CMS URLs when the new structure is predictable; unique marketing pages need explicit one-to-one rows.

3. Build a one-to-one 301 map

A permanent redirect (HTTP 301, or 308 where your stack prefers it) tells browsers and search engines that the resource has moved for good. Temporary 302/307 codes are for short-lived situations—A/B tests, seasonal swaps—not platform migrations. If you use temporary codes by accident, search engines may keep the old URL in the index longer than you want.

Mapping principles

  • Equivalent intent: Old service page → new service page; old article → rewritten article or closest topic cluster page.
  • Avoid homepage dumping: Mass homepage redirects look like soft soft-404s and waste link equity.
  • Preserve query strings only when needed: Tracking parameters can usually be stripped; product filters that represent unique content may need careful handling.
  • Document owners: Note who approved each high-value mapping so content merges do not reverse-engineer themselves later.

Draft rules with the redirect generator and validate path shapes with the URL structure analyzer. Export the final map as CSV plus the platform-native format (nginx, Apache, Cloudflare, WordPress plugin, Shopify redirects). Keep one source of truth; duplicate maps in three tools are how chains appear.

Worked pattern examples

# Explicit one-to-one (highest confidence)
/old-about-us/          → /about/
/blog/2021/seo-tips/    → /guides/seo-tips/

# Pattern when IDs map cleanly (verify samples)
/product.php?id=123     → /products/widget-pro/

# Retire obsolete promo to category, not home
/summer-sale-2019/      → /collections/seasonal/

Test a sample of each pattern with curl or a redirect checker before launch. Confirm status code, final destination, and that the destination returns 200 with the expected content—not a soft 404 template.

4. Kill chains, loops, and soft 404s

A redirect chain is any path that needs more than one hop to reach the final URL. Chains slow users, complicate debugging, and can drop intermediate signals. Loops (A→B→A) are worse: crawlers give up and users see errors.

Common chain factories during migrations

  • CDN or host forces HTTP→HTTPS, then www→non-www, then trailing-slash, then CMS slug rewrite.
  • Old redirects left in place that point to intermediate “new” URLs which themselves redirect again.
  • Staging hostname rules accidentally promoted to production.
  • Case-sensitivity rules on Linux hosts after a case-insensitive legacy server.

Flatten every high-traffic path so the first response is a single 301 to the final destination. Keep global host/protocol rules, but make content redirects target the already-canonical form (HTTPS, preferred host, preferred slash). After launch, crawl the old URL list and flag any path with more than one hop.

Soft 404 and thin targets

A 200 response that says “page not found,” an empty category, or a near-blank template is a soft 404. Redirects that land there teach search engines that the destination is worthless. Prefer real content pages. If content was intentionally removed, a 410 Gone can be clearer than a fake success page—use it sparingly and only when nothing useful remains.

Canonical confusion compounds the problem. If the new URL’s canonical points back to an old host or an alternate path, you undo the redirect story. Align canonicals with the preferred new URLs using the same discipline covered in robots, noindex, and canonical when to use, and scaffold tags with the canonical URL generator when needed.

5. Before → after URL map (diagram)

Think of the migration as a directed map: every old URL that still receives traffic or links should resolve in one hop to a living new URL. The diagram below shows a healthy pattern versus a chain-heavy failure.

Before to after URL map for a site migration Diagram comparing a good one-hop 301 from old URLs to new URLs against a bad redirect chain with multiple intermediate hops and a 404. Good: one-hop 301 map old /services/ old /about-us/ new /services/ (200) new /about/ (200) Bad: chain + dead end old URL staging slash fix 404 page fail
Figure: Healthy migrations map each important old URL to a final new URL in one permanent redirect. Chains and 404 endpoints discard equity and trust.

6. Update internal links and key external ones

Redirects are a safety net, not a license to leave the site pointing at itself through hops. Update navigation, footer, in-content links, XML/HTML sitemaps, and structured data URLs so the preferred new paths are the ones users and crawlers see first.

  • Rebuild menus and breadcrumbs from the new information architecture; generate markup carefully with the breadcrumb generator if you expose BreadcrumbList schema.
  • Search-and-replace old absolute domains in templates, emails, and PDFs you control.
  • Ask major partners, directories, and press pages with high-value backlinks to update when feasible—redirects cover the rest.
  • Check hreflang and alternate language maps if you run multi-locale sites; use the hreflang generator to rebuild consistent pairs.

Internal linking also surfaces orphaned new pages. After launch, crawl the new site and confirm every money page is reachable within a few clicks of the homepage. Orphans that only exist in a sitemap are fragile.

7. Refresh sitemaps, robots, and canonicals

On cutover day, your discovery files must describe the new world—not the old one.

XML sitemaps

Include only indexable, preferred new URLs that return 200. Remove old hosts, redirected URLs, and noindexed paths. Keep lastmod honest for pages that truly changed. Policy detail lives in XML sitemaps: include vs exclude; build and validate with the XML sitemap generator, XML sitemap validator, and sitemap tools.

robots.txt

Point Sitemap: directives at the new sitemap location. Do not accidentally disallow the new CMS paths while copying an old robots file. Generate a clean file with the robots.txt generator and re-read disallow rules against the new URL structure.

Canonicals and meta robots

Every indexable template should self-canonicalize to the live preferred URL. Staging, preview, and parameter variants should stay noindexed. Cross-check with the SEO audit checker and the broader technical SEO tools set after templates stabilize.

8. Launch-day and week-one checks

Have a short written runbook. Assign owners. Do not rely on “we will notice if something is wrong.”

  1. DNS and SSL: Confirm certificates and host redirects (www/HTTPS) before content redirects.
  2. Spot-check top 50 URLs: Old URLs → single 301 → correct 200 body.
  3. Homepage and key conversions: Forms, carts, phone links, and analytics tags fire on the new host.
  4. Crawl sample: Broken-link and status-code crawl of old inventory against production.
  5. Submit new sitemap in Search Console (and Bing Webmaster Tools if you use it).
  6. Change of Address only when moving domains permanently and prerequisites are met—follow Google’s current documentation exactly.
  7. Annotate analytics with the launch date so traffic dips have context.

Week one is for triage: fix missing redirects within hours, not weeks. Keep a shared “404 watch” sheet fed by Search Console, server logs, and the broken link checker. Temporary spikes in 404s are normal while crawlers relearn; rising unique 404 URLs without fixes are a process failure.

9. Search Console monitoring plan

Search Console is your post-migration radar. Pair it with a weekly habit like the one in our Search Console weekly checklist.

Reports to watch for 4–8 weeks

  • Pages → Not found (404): Prioritize URLs with impressions or known backlinks; add redirects or 410s deliberately.
  • Pages → Redirect error / page with redirect: Investigate chains, loops, and accidental indexing of redirecting URLs.
  • Coverage / indexing: Confirm important new URLs move to “Indexed”; investigate exclusions that were not intentional.
  • Performance: Compare query and page trends against the annotated launch date. Expect volatility; look for structural drops (whole sections missing) versus normal noise.
  • Sitemap status: Ensure the submitted sitemap stays “Success” with expected discovered URL counts.

If rankings wobble while redirects are clean and content is equivalent, give recrawling time before rewriting everything. If impressions vanish for a section whose old URLs still 404, fix the map first—content tweaks will not heal a broken transfer.

For ongoing hygiene after the dust settles, return to the technical SEO hygiene checklist and keep schema honest as covered in schema markup: helpful vs spammy. Browse more playbooks on the Guides & Blog index.

10. Frequently asked questions

Plan to keep important redirects for years, not weeks. External links and bookmarks persist. Many teams keep high-value redirects indefinitely and review low-value ones annually. Removing redirects early reintroduces 404s for anyone still using old URLs.

Only if the move is truly temporary. For a permanent redesign or CMS cutover, ship 301/308 from day one. Temporary codes can delay consolidation of signals onto the new URLs.

Prefer unique equivalents when content still exists. When several thin pages merge into one stronger page, multiple old URLs may correctly share one target. Avoid sending unrelated URLs to the homepage just to avoid a 404 count.

Short-term volatility is common while Google recrawls. Verify indexing of key URLs, content parity, internal links, and Core Web Vitals regressions. If a whole section is missing from the index or still 404ing, fix technical transfer issues before rewriting titles and copy at scale.

If the domain or protocol/host combination changes, verify the new property (or URL-prefix property) and keep the old one available for historical comparison and Change of Address flows when applicable. Submit the new sitemap on the property that matches the live preferred URLs.