Check Redirects After a Website Migration

A website migration is not finished when the new site loads. You also need to check that important old URLs lead to the right new pages, without redirect loops, unnecessary hops, or dead ends. This URL-by-URL workflow helps website owners and SEO teams build a useful test list, verify destinations, and document fixes. Redirect checks can catch migration problems, but they cannot guarantee rankings or traffic outcomes.

Key Takeaways

Prioritize URLs with substantial organic traffic, valuable incoming links, and important business or editorial value.
Compare each old URL’s purpose with the content at its final destination; a successful HTTP response alone does not prove the mapping is right.
Record the redirect path, final status, destination, content relevance, and any issue for every tested URL.
Fix missing mappings, irrelevant destinations, chains, and loops, then retest after deployment.

1. Build a representative list of old URLs

Start with a complete URL inventory if you have one, such as a crawl of the old site, a CMS export, or a list of known URLs from your migration plan. Then prioritize URLs that are most costly to get wrong:

High-traffic pages: Use analytics or search performance data to find old URLs that brought in visits or conversions.
Important incoming-link destinations: Check backlink reports, referral data, and known partner links. A page with valuable links may matter even if it has modest current traffic.
Core pages: Include product and service pages, key categories, lead-generation pages, and important support or editorial content.
Representative URL patterns: Sample pages from each template or section, including pagination or language variants if those are part of the migration.
Known edge cases: Add URLs with trailing slashes, uppercase or lowercase variations, query strings, old file extensions, and retired content.

Do not rely on a small sample alone if you can test the full old-URL inventory. Sampling is useful for an initial review; it cannot establish that every untested URL has a correct mapping.

Create a spreadsheet with at least these columns: old URL, intended new URL, observed final URL, redirect count, final HTTP status, content match, result, issue, owner, and retest date. Fill in the intended destination before checking the live behavior. That makes it easier to spot a redirect that technically works but goes to the wrong place.

2. Check the path and the destination

Test the old URL as a normal visitor would request it. For a quick command-line check, use curl with a URL from your own migration list:

curl --silent --show-error --location --max-redirs 10 \
  --dump-header - --output /dev/null \
  --write-out '\nFinal URL: %{url_effective}\nFinal status: %{http_code}\nRedirects: %{num_redirects}\n' \
  'https://old.example.com/old-page'

The response headers show the redirect responses and their Location values; the summary reports the final URL, final status, and number of redirects. Replace the example with an old URL you are authorized to test on your site. If the command reports an error or exceeds the redirect limit, inspect the header sequence and test the path one hop at a time. A browser or a redirect-checking tool can also help inspect individual URLs; [Redirect Checker](Redirect Checker) is one option.

For each row in your spreadsheet, verify all of the following:

The old URL responds as expected. For content that has moved permanently, the migration plan will usually call for a permanent redirect. Confirm the actual response rather than relying on the plan.
The final URL is the intended page. Compare it with your prewritten mapping, not merely with the site’s homepage or a page that returns 200.
The destination is relevant. Read the page or inspect its title and main content. The new page should satisfy the old URL’s purpose. If the old page has no relevant replacement, decide deliberately whether it should return a not-found or gone response instead of redirecting visitors to an unrelated page.
The destination loads successfully. Check for an error response, a soft 404, a blocked page, or a page that immediately redirects again.
The experience works in context. Test important URLs in a browser and, where relevant, on mobile. Confirm that query parameters needed for the page or campaign are handled as intended.

A 200 final status only tells you that a response was returned. It does not tell you whether the redirect mapping is relevant or whether the page is useful.

3. Find chains, loops, and missing mappings

A redirect chain occurs when an old URL passes through multiple redirects before reaching its destination. For example, /old-page may redirect to an intermediate URL that then redirects to /new-page. Update the old URL’s mapping to point directly to the final destination where practical, and update internal links so they do not send visitors through the old path.

A redirect loop occurs when URLs redirect back to one another, or a URL ultimately redirects to itself. Browsers and command-line tools stop following after a limit. Review each Location header to find the cycle, then correct the conflicting rules—often in redirect configuration, a proxy, or application routing. Retest the old URL and each affected destination after changing the rules.

A missing mapping is an old URL that returns a not-found response, a server error, or an unintended default page when the migration plan calls for a replacement. Compare the response with the intended destination list. Add a specific mapping for valuable content, or document why there is no suitable replacement.

Also look for broad rules that send many unrelated old URLs to one destination. They can make automated checks look superficially successful while failing to preserve the original page’s purpose. Review the actual destination content, especially for URLs that share a pattern but represent different topics or products.

4. Document outcomes and retest

Use consistent result labels so teams can filter the spreadsheet: Pass, Wrong destination, Chain, Loop, Missing mapping, Unexpected status, or Needs review. Record the observed URL and status, not just a checkmark. For a failure, include the proposed fix and assign an owner.

After fixes are deployed, rerun the affected checks. Then repeat the broader test after changes to redirect rules, DNS, hosting, or the new site’s routing. Keep a record of when and where checks were performed; staging and production may behave differently. For larger migrations, automate checks against the inventory and preserve results so regressions can be compared over time.

Google’s site-move guidance treats URL mapping and redirects as part of a move involving URL changes. Follow the guidance relevant to your migration type, and check related technical details such as crawl access and submitted sitemaps. Monitoring is still necessary after launch: a redirect test is a diagnostic snapshot, not a prediction of search rankings.

Common Mistakes

Checking only the homepage or a handful of URLs: This misses failures on important sections and URL patterns.
Treating any redirect as a pass: The destination must match the old page’s purpose.
Assuming a 200 response proves success: The page may be an error page, irrelevant content, or a soft 404.
Ignoring intermediate hops: Record the full path and reduce avoidable chains.
Redirecting every retired page to the homepage: Map to a relevant replacement when one exists; otherwise choose an appropriate response deliberately.
Testing only before launch: Production configuration can differ, so verify after deployment and after later routing changes.
Assuming redirects guarantee rankings: Search visibility depends on many factors; no redirect workflow can promise a particular ranking or recovery timeline.

Best Practices

Start with traffic and incoming-link evidence, then cover every old URL you can inventory.
Write down the intended destination before testing the live redirect.
Prefer direct, relevant mappings and keep internal links pointed at current URLs.
Test important URL variants, not just the canonical-looking version.
Keep findings actionable: observed behavior, intended behavior, owner, fix, and retest result.
Use search performance and crawl monitoring after launch to discover issues that a pre-launch sample did not reveal.

Conclusion

A reliable migration check compares every old URL’s observed redirect path with an intentional, relevant destination. Prioritize valuable URLs, document failures, fix the underlying mappings, and retest in production. This gives your team a clearer view of migration issues without mistaking a successful HTTP response for a guarantee of search performance.

References

Google Search Central: Site moves with URL changes — guidance for site moves that change URLs.

How to Check Redirects After a Website Migration