Page redirects during migration
Why you should test your redirects before migrating your site
Testing redirects after a site migration is probably something most checklists and project plans already consider, but due to the importance of properly redirecting your old URLs, you should minimize the risk of starting with the wrong redirects.
Before your new site goes live, it will most likely be available for testing in a staging environment. This is where you need to set up your 301 redirect rules and test that they work as they should before migrating.
Testing your redirects before the move on a staging version of the new site doesn't eliminate the need for retesting after the move, but it does reduce the risk of going live with incorrect redirects and causing irreparable damage.
Before we dive into the details of testing redirects on a staging site, let's take a quick look at one big task that needs to be done before we can even test anything: creating a redirect map.
What to consider when creating a redirect map
Your redirect map should contain all old URLs that will no longer exist after the site is migrated. On very large sites, you may not be able to create a redirect map for all old URLs, so it makes sense to focus on the most important URLs:
To determine which of the old URLs you collected need to be redirected, you can use Excel or Google Sheets to replace your domain with your staging domain in all URLs and then search the entire list. Any URLs that do not return a 200 status code on the staging site will need to be included in your redirect mapping. Caution: If the staging site's 404 error page is not yet configured correctly (a very common error), URLs that do not exist on the new site may return a 200 status code. Before running this test, make sure that you have site with the appropriate 404 error page.
If you are not using software that automatically matches your old and new redirect mapping URLs, the next step will be to manually determine a matching redirect target for each URL in your list. Ideally, the redirect target should have the same content as the old URL, or at least match the same search intent and queries. For each old URL that needs to be redirected, make sure you find the most similar URL on your staging site.
What you can do to avoid redirect chains
Redirect chains occur when a URL redirects to another URL, which then redirects to another URL. These chains should be avoided at all costs, as they waste crawl resources and most likely won't handle as much importance as a redirect without detours. Here are some things you can do to avoid redirect chains:
Monitoring and reducing post-migration diversions
As mentioned earlier, even if you thoroughly test your redirect rules on a staging site, it doesn't eliminate the need to retest as soon as the new site goes live. Go through all the URLs you created redirect targets for and make sure they all 301 redirect to the target you specified and the target returns a 200 status code. You can use the list mode in Screaming Frog and VLOOKUP to run these tests in Excel or Google Sheets.
It's also a good idea to set up a monitor for your old URLs to periodically check them to make sure they're still redirecting to the right destinations and that the destinations are returning 200 status codes.
Some of you may be concerned about the large number of redirects that slow down page loading. There's really no room for negotiation when it comes to site migration: the more old URLs you redirect, the better. To reduce the number of redirects after a site migration, you can monitor your log files to see which old URLs are still being requested by bots and users. If a URL has not been requested for several months and has no links from other sites pointing to it, the 1:1 redirect rule that applies to it can be removed. This is a trade-off that SEOs concerned with maintaining organic search performance and developers concerned about redirects slowing down page loads should be comfortable with.