Website Migration Redirect Checklist: Test Every Destination

A website migration can leave old URLs broken, send visitors to the wrong pages, or introduce redirect chains that are hard to spot in a quick review. Use this website migration redirect checklist to plan URL mappings before launch, test redirects, and check important destination pages after the change.

Key Takeaways

• Map each valuable old URL to its closest relevant new page before launch; don’t send every old URL to the homepage.
• Test redirects for status codes, chains, loops, unexpected destinations, and HTTP-to-HTTPS behavior.
• Check destination content and status codes—not just whether a redirect completes.
• After launch, update internal links and canonicals, submit current sitemaps, and monitor search engine reports and server logs.
• Redirects are signals, not guarantees of preserved rankings, traffic, or indexing.

1. Build and review the URL map before launch

Start with a list of old URLs that matter: pages receiving organic visits, backlinks, conversions, or internal links. Use existing analytics, Search Console reports, backlink data, and a crawl of the current site where available. Include important URL variants, such as trailing-slash versions or URLs with query parameters, if they resolve to meaningful pages.

Create a mapping sheet with at least these columns:

For every old URL, choose the closest new page that satisfies the same visitor need. If a page has a direct replacement, map it there. If its content has been combined into a broader page, map it to that page only when the destination is genuinely relevant. If there is no suitable replacement, don’t manufacture one by redirecting to an unrelated page; decide whether the old URL should return an appropriate not-found or gone response instead.

Preserve URL paths where practical. For a domain-only move, keeping the same path often makes mapping simpler. For a new URL structure, map individual pages rather than relying on a broad rule that may point unrelated pages to a single destination. Review query-string behavior too: tracking parameters may be safely ignored in some setups, but parameters that select content or products may need to be preserved.

Before launch, check the mapping for duplicate sources, missing destinations, accidental self-redirects, and destinations that are themselves scheduled to move. Keep the mapping file as a test plan and as a record of intended behavior.

2. Test redirects in a staging environment

Test a representative set of URLs before launch, then test the full old-URL list if possible. Include high-traffic pages, pages with backlinks, URLs from different site sections, and edge cases such as mixed case, trailing slashes, query strings, and encoded characters.

Check each redirect for four things:

1. Status: A permanent move should use a permanent redirect, commonly 301 or 308. A temporary redirect may be appropriate only when the move is genuinely temporary. Don’t choose a status code simply because it appears to work in a browser.
2. Destination: Confirm the final URL is the exact intended page, not the homepage, a search page, or an unrelated category.
3. Path length: Prefer one redirect from the old URL to the final destination. A chain—old URL to an intermediate URL to another URL—adds steps and makes failures harder to diagnose.
4. Completion: Confirm that the destination responds successfully and contains the expected page. A 200 response alone doesn’t establish that the content is relevant or usable.

Use GET requests when practical. Some servers handle HEAD requests differently from normal page requests, so a HEAD-only check can miss behavior visitors encounter. With curl, inspect one response at a time:

curl -sS -D - -o /dev/null 'http://old.example.test/guides/old-topic'

Look at the status line and the Location header. Then check the final result while following redirects:

curl -sS -L --max-redirs 10 -o /dev/null \
  -w 'status=%{http_code}\nfinal_url=%{url_effective}\nredirects=%{num_redirects}\n' \
  'http://old.example.test/guides/old-topic'

A successful result might report a final status of 200, the expected HTTPS destination, and one redirect. Curl stops when it exceeds the redirect limit; that is a useful clue to investigate a loop or an excessively long chain, but inspect the individual Location headers to find the cause.

Test HTTP and HTTPS variants separately. Confirm that the old HTTP URL reaches the intended final HTTPS page, that the new HTTPS URL loads without a certificate error, and that redirects do not send visitors back to HTTP. If the migration changes both host and URL structure, test combinations of old host, scheme, and path rather than assuming one rule covers them all.

3. Verify destination pages, not just redirect rules

For each tested mapping, check that the destination:

• Returns the expected successful response and renders the intended content.
• Is accessible without a login or accidental staging restriction, if it is meant to be public.
• Uses the intended canonical URL, preferably pointing to the final URL rather than the old address or an intermediate redirect.
• Has working page assets and navigation, with no migration-related broken links.

A redirect can be technically valid while landing on a page that is empty, irrelevant, blocked from crawling, or canonicalized elsewhere. Check page content and response headers in addition to the redirect status.

4. Launch-day checklist

• Deploy the redirect rules alongside the new site and verify that they apply at the intended layer, such as the web server, CDN, or application.
• Test a sample of high-priority old URLs from outside the staging environment.
• Check old HTTP and HTTPS URLs, and confirm the final destination uses HTTPS.
• Check for loops, unexpected hosts, missing paths, and destinations that return errors.
• Confirm that robots directives and access controls do not accidentally block the new pages.
• Publish an updated XML sitemap containing the preferred new URLs, not the redirected old URLs.
• Update navigation, contextual links, and other internal links to point directly to the new URLs.

Keep both the old and new sites available to your team during validation if your infrastructure allows it. Avoid changing unrelated site elements at the same time when possible; fewer simultaneous changes make problems easier to isolate.

5. Monitor after launch

Recheck priority URLs shortly after deployment and continue monitoring during the migration. Review server or CDN logs for frequent requests to old URLs, unexpected response codes, and destinations that differ from the mapping. Crawl the new site to find internal links that still point through redirects or lead to missing pages.

In search engine tools, monitor indexing and crawl reports, sitemap processing, and important page queries. If the move changes the domain, check the applicable search engine site-move guidance and any available change-of-address process for your property. These tools and reports can help surface issues, but they don’t guarantee that every URL will be indexed or that rankings and traffic will remain unchanged.

Search engine recommendations and product interfaces can change. I could not retrieve live search engine documentation for this article, so verify the current official instructions for your search engines and property before launch. Treat permanent redirects, updated internal links, and sitemap submissions as sound migration practices—not promises of a particular ranking or recovery timeline.

Common Mistakes

• Redirecting every old URL to the homepage: This often fails to give visitors a relevant destination. Map pages individually where they have suitable replacements.
• Checking only that a URL returns a response: A redirect can end at the wrong page, a broken page, or an unsuitable canonical URL.
• Testing only the homepage: Deep paths, query parameters, HTTP variants, and less common URL patterns can behave differently.
• Leaving redirect chains in place: Update rules so old URLs point directly to final destinations where practical.
• Keeping internal links on old URLs: Redirects may still work, but internal links should lead directly to the new pages.
• Assuming a redirect guarantees SEO outcomes: Redirects communicate a move; they cannot guarantee indexing, rankings, traffic, or an exact processing schedule.

Best Practices

• Maintain one reviewed source-of-truth mapping file, and use it to drive both redirect configuration and tests.
• Give each old URL a deliberate outcome: a relevant destination or an appropriate error response.
• Check both redirect behavior and destination-page quality.
• Keep a record of test results and investigate exceptions before removing old redirect rules.
• Review current official search engine guidance for the specific type of move, especially when changing domains.

Conclusion

A dependable migration starts with a precise URL map and continues with tests of both redirects and destination pages. Validate representative cases before launch, check the full set of important URLs afterward, and monitor search and server reports without treating any redirect as a guarantee of SEO results.