A redirect map is not finished when the rules are written. It is finished when the old URL, every expected redirect hop, the final URL, the status code, and the destination page have all been checked in a real environment.
This checklist focuses on a typical migration where old URLs should permanently resolve to their most relevant new equivalents.
Before the launch
- Export the old URL list. Include priority landing pages, pages with backlinks, legacy campaign pages, XML sitemap URLs, and URLs found in analytics or server logs.
- Map each old URL to one relevant destination. Do not send unrelated removed pages to the home page just to avoid a 404.
- Choose the right redirect type. Use a permanent server-side redirect only when the move is intended to remain permanent. Use a temporary redirect for a temporary change.
- Check the destination. It should return a successful response, use the preferred canonical URL, and be allowed to be crawled when it is intended for search.
Test the redirect chain, not just the final page
A browser may eventually show the right page even when the route takes unnecessary hops. Check every old URL from the outside and record the full path. A clean result is usually one redirect from the old address to the final address. Investigate loops, long chains, redirects to the wrong page, mixed HTTP and HTTPS behavior, and unexpected temporary responses.
Also test the common variants: HTTP and HTTPS, www and non-www where applicable, trailing slash versions, URL parameters that must survive, and case variants when the server treats them differently.
After the launch
- Re-run the high-priority URL list from production.
- Submit or update the XML sitemap with the new canonical URLs.
- Review crawl errors and landing-page traffic for missed routes.
- Keep the redirect map as a maintained launch artifact, not a one-time spreadsheet.
Common mistakes to avoid
Do not use a JavaScript redirect when server-side control is available. Do not redirect every old page to the home page. Do not remove old redirects immediately after a migration. And do not treat a 200 response as proof that the page is the correct destination.
Use the HTTP Status & Redirect Checker to test up to 25 public URLs at a time, inspect the chain, and export the results for a migration record.