Check Broken Links Before Website Migration: Complete Checklist

Website migrations are one of the highest-risk events in SEO. Whether you are moving to a new domain, switching CMS platforms, restructuring your URL hierarchy, or migrating from HTTP to HTTPS, every URL on your site is at risk of breaking. And broken URLs mean lost rankings, lost traffic, and lost revenue.

The good news: almost all migration-related traffic loss is preventable. The key is systematic link checking before, during, and after the migration. This guide gives you a concrete checklist for each phase.

Why Website Migrations Break Links

Before diving into the checklist, it helps to understand why migrations produce broken links in the first place. There are a few common causes:

• URL structure changes. Moving from /blog/post-title to /articles/post-title without redirects leaves every inbound link pointing at a 404.
• Domain changes. Switching from oldsite.com to newsite.com requires redirects for every single URL on the old domain.
• CMS differences. Different platforms generate different URL patterns. WordPress uses /?p=123 by default; a headless CMS might use /posts/post-slug.
• Missing pages. Content that exists on the old site but was not migrated to the new one. This is especially common with tag pages, author pages, and pagination URLs.
• Internal link rot. Hardcoded internal links in content that still reference old URL patterns after the migration.
• Parameter handling. Query parameters like ?utm_source= or ?page=2 that the new server does not handle correctly.

Each of these issues creates broken links. And at scale -- a site with 10,000+ pages can easily have 50,000+ internal links -- manual checking is impossible. You need a systematic process.

Phase 1: Pre-Migration (Before You Touch Anything)

The pre-migration phase is where most of the work happens. Get this right and the rest is verification. Get it wrong and you are chasing broken links for months.

Step 1: Crawl and Document Every URL on the Current Site

Before changing anything, you need a complete inventory of every URL on your current site. This is your baseline. Every URL that exists today needs to either exist at the same path on the new site, or have a redirect pointing to the correct new location.

Export a full list of URLs from your current site. Sources to pull from:

• Your sitemap(s). Download sitemap.xml and extract all URLs. Check for sub-sitemaps.
• Google Search Console. Export the Pages report to get every URL Google has indexed. This catches pages that might not be in your sitemap.
• Server access logs. Find URLs that receive traffic but are not in your sitemap or GSC. These are often legacy pages that still get backlinks.
• Backlink tools. Use Ahrefs, Semrush, or Moz to find URLs with external backlinks. These are your highest-priority redirects.
• A full site crawl. Use a crawler to find every internally linked page, including ones missed by the above sources.

Combine all sources into a single CSV. Deduplicate. This is your master URL list. For a typical site migration, expect this list to be 2-10x larger than your sitemap alone.

Step 2: Check the Current State of Every URL

Before building your redirect map, you need to know the current status of every URL on your master list. Some of these URLs might already be broken, redirecting, or returning errors. There is no point setting up redirects for URLs that are already 404s.

Upload your master URL list to a broken link checker and run a full status check. For each URL, record:

• HTTP status code (200, 301, 404, 500, etc.)
• Final destination URL (if it redirects)
• Response time
• Whether the page has meaningful content (soft 404 detection)

This gives you a clean baseline. You only need to create redirects for URLs that currently return 200. URLs already returning 404 or 410 can be excluded from your redirect map (unless they have valuable backlinks).

Step 3: Build Your Redirect Map

The redirect map is the single most important document in a website migration. It is a spreadsheet that maps every old URL to its new URL. The format is simple:

Rules for building the redirect map:

1. Every URL with traffic or backlinks gets a redirect. No exceptions. These are your revenue-generating pages.
2. Use 301 (permanent) redirects, not 302 (temporary). A 302 tells Google the old URL might come back. A 301 transfers ranking signals to the new URL.
3. Map to the closest equivalent page. Do not redirect everything to the homepage. A blog post should redirect to the equivalent blog post, a product page to the equivalent product page.
4. Avoid redirect chains. If /old-a already redirects to /old-b, map /old-a directly to the final new URL. Do not create /old-a → /old-b → /new-c.
5. Account for trailing slashes and case sensitivity. /blog/post and /blog/post/ are different URLs. Map both.

Step 4: Validate Your Redirect Map Before Going Live

Before implementing redirects on production, validate the map:

• Check that every new URL in your map actually exists on the new site (staging environment). A redirect to a 404 is worse than no redirect at all.
• Check for circular redirects (A redirects to B, B redirects to A).
• Check for redirect chains longer than 2 hops.
• Verify that your redirect rules do not conflict with each other.

Use a URL status checker against your staging environment to verify every new URL returns a 200 before going live.

Phase 2: During Migration (Launch Day)

Migration day is about executing the plan and verifying it worked. The less improvising you do on launch day, the better.

Step 5: Implement Redirects and Verify They Work

Deploy your redirects. Then immediately verify a sample. Take 50-100 of your highest-priority old URLs and check them manually or with a bulk checker. Confirm:

• Each old URL returns a 301 status code (not 302 or 307).
• Each old URL redirects to the correct new URL (not the homepage, not a different page).
• The final destination returns a 200 status code.
• The redirect happens in a single hop (no chains).

Step 6: Run a Full URL Check on the New Site

Once redirects are live, check every URL on the new site for broken links. This catches:

• Internal links pointing to old URL patterns. Content that was migrated but still contains hardcoded links to old paths.
• Broken navigation. Menu items, footer links, or sidebar links that reference old URLs.
• Missing assets. Images, CSS, JavaScript files that were not migrated or have different paths.
• Broken external links. Links to third-party sites that have changed since the content was written.

For a site with 10,000+ pages, this is where a bulk URL checking approach becomes essential. You cannot check 50,000 internal links by hand.

Step 7: Verify Your Sitemaps

Submit updated sitemaps to Google Search Console immediately after migration:

• Remove old URLs from your sitemap. Only include new, canonical URLs that return 200.
• Add a sitemap with old URLs that 301 to new ones. This helps Google discover and process redirects faster.
• Check that your robots.txt on the new site does not block critical pages or the sitemap itself.

Phase 3: Post-Migration (The Next 30-90 Days)

The migration is not done when you flip the switch. Post-migration monitoring is where you catch the problems that slipped through.

Step 8: Bulk Check All Old URLs Against Live Redirects

Take your master URL list from Step 1 and run every single old URL through a bulk checker against the live production site. This is the definitive test. For each URL, verify:

• The old URL returns a 301.
• The redirect target returns a 200.
• The redirect target is the correct page (not a generic fallback).

For sites with 50,000+ URLs, upload the full list as a CSV to Bulk URL Checker. Cloud processing handles the volume without tying up your machine, and you get a downloadable report with status codes and final destination URLs for every entry.

Step 9: Monitor Google Search Console for Crawl Errors

Google Search Console is your early warning system. After a migration, check it daily for the first two weeks, then weekly for the next two months. Watch for:

• 404 errors. Pages Google tried to crawl that returned a 404. These are URLs you missed in your redirect map.
• Soft 404s. Pages that return 200 but Google thinks are error pages. This usually means a redirect to a generic page.
• Redirect errors. Redirect loops, chains that are too long, or redirects to non-existent pages.
• Server errors (5xx). Pages that the server cannot serve. Could indicate redirect rules that overload the server.

When you find new 404s in GSC, add them to your redirect map and deploy the fix immediately. Every day a high-value page returns a 404 is a day you are losing rankings.

Step 10: Run a Full Re-Check at 30 Days

Thirty days after migration, run the complete check again. Take your master URL list and verify every redirect still works. This catches:

• Redirects that were accidentally removed during post-launch deployments or server configuration changes.
• New content published with old URL patterns that bypasses the redirect rules.
• Third-party services (CDNs, caching layers, load balancers) that cached the old site and are now serving stale responses.
• Redirect rules that expired. Some configurations set time limits on redirect rules.

This 30-day check is your safety net. If everything passes, your migration is in good shape. If you find issues, fix them before the 90-day mark -- after 90 days, Google is more likely to drop pages from the index permanently.

Website Migration URL Checklist (Summary)

Here is the complete checklist in one place. Print it, bookmark it, share it with your team.

Pre-Migration

• Export all URLs from sitemap, GSC, backlink tools, and access logs
• Combine and deduplicate into a master URL list
• Check current status of every URL (identify existing 404s and redirects)
• Build a redirect map: old URL to new URL, one-to-one
• Validate that every new URL exists on staging (returns 200)
• Check for circular redirects and chains in the map
• Prioritize URLs with backlinks and organic traffic

During Migration

• Deploy redirects
• Spot-check 50-100 high-priority redirects immediately
• Run a full internal link check on the new site
• Update hardcoded internal links in content and templates
• Submit new sitemaps to Google Search Console
• Verify robots.txt is not blocking critical pages

Post-Migration

• Bulk check all old URLs against live redirects
• Monitor GSC daily for 404s, soft 404s, and redirect errors
• Fix new 404s as they appear in GSC
• Run a full re-check at 30 days
• Run a final re-check at 90 days
• Track organic traffic trends in analytics vs. pre-migration baseline

Common Migration Mistakes That Create Broken Links

Even with a checklist, these mistakes come up repeatedly. Watch for them:

For more on identifying and fixing broken links across any site, see our guide on finding broken links on any website.

How to Handle Large-Scale Migrations (50,000+ URLs)

Enterprise and large content sites face unique challenges during migration. When your URL list runs into the tens of thousands, the process is the same but the tooling matters more.

At 50,000+ URLs, you cannot rely on desktop crawlers or manual checks. The practical approach:

1. Export your master URL list to a CSV file. One URL per row, with columns for the old URL and expected new URL.
2. Upload to a cloud-based bulk checker. Cloud infrastructure can process 50,000+ URLs without tying up your local machine. You get results by email when the batch is done.
3. Compare results against your redirect map. Filter for any URL where the actual destination does not match the expected destination in your map.
4. Fix discrepancies and re-check. Update redirect rules, then re-upload the problem URLs to verify the fixes.

This workflow is especially critical for migrations where URL patterns changed in unpredictable ways -- for example, moving from a CMS that uses numeric IDs (/post/12345) to one that uses slugs (/blog/post-title). Regex-based redirect rules often miss edge cases, and the only way to catch them is a full bulk check.

After the Migration: What Good Looks Like

A successful migration hits these benchmarks:

• Zero 404s for URLs with backlinks or organic traffic. Every valuable URL either exists at the same path or has a working 301 redirect.
• No redirect chains longer than 1 hop. Old URL redirects directly to new URL. No intermediate stops.
• Organic traffic within 5% of pre-migration levels within 30 days. Some dip is normal in the first week, but it should recover.
• GSC crawl errors trending down. New 404s should stop appearing within 2-3 weeks as Google processes your redirects.
• All internal links updated. No internal links on the new site still pointing to old URL patterns.

If you hit these benchmarks, your migration was clean. If you are seeing ongoing 404s or traffic loss beyond 30 days, go back to your master URL list and run another bulk check. The answer is almost always a missing or broken redirect.

Website migrations do not have to be traffic disasters. With a complete URL inventory, a careful redirect map, and systematic checking at every phase, you can migrate without losing the organic traffic you have spent years building. The tools exist. The process is straightforward. The only risk is skipping steps.