Testing redirects before and after a website migration

Among all of the factors you have to consider when migrating a website, your URL redirects are probably the single most important one. A website migration that involves changes to important URLs is doomed to fail if the old URLs do not redirect correctly to the new ones. In this article, you will learn everything you need to know about testing your redirects before and after a website migration.

Are you in a hurry? Jump straight to the TL;DR summary of this post.

Content:

• Why you should test your redirects before a website migration
• What you should consider when creating your redirect mapping
• What you can do to avoid redirect chains
• Setting up your redirects on the staging environment
• Special considerations in case of a domain switch
• Testing, monitoring and reducing your redirects after the migration
• TL;DR

Why you should test your redirects before a website migration

Testing redirects after a website migration is probably something most checklists and project plans already consider, but due to the importance of correctly redirecting your old URLs, you should minimise the risk of going live with faulty redirects in the first place.

Before your new website goes live, it will most likely be available for testing in a staging environment. This is where you should set up your 301 redirect rules before the migration and test if they are working the way they should.

Testing your redirects before the migration on the staging version of the new website does not eliminate the need to test them again after the migration, but it reduces the risk of going live with incorrect redirects and causing irreparable damage.

Before we dive into the details of testing redirects on a staging website, let’s have a quick look at one big task that needs to be taken care of before we even have anything we can test: The creation of a redirect mapping.

What you should consider when creating your redirect mapping

Your redirect mapping should contain all old URLs that will no longer exist after the website migration. On very big websites, you might not be able to create a redirect mapping for all old URLs, so it makes sense to focus on the most important URLs:

• All URLs that have had clicks and impressions, according to Google Search Console.
• All URLs that are landing pages for organic search traffic, according to Google Analytics (or the web analytics tool your organisation is using).
• All URLs that have rankings, according to the SEO tool you use for checking and monitoring rankings (tools like Sistrix, Searchmetrics, SEMrush, etc.).
• All URLs that have links from other websites pointing to them. You should collate backlink data from Google Search Console and link databases from SEO tool providers (like Sistrix, SEMrush, Ahrefs, etc.) in order to get a complete dataset. The referrals report in Google Analytics can also help you identify more backlinks to your URLs (searchVIU finds and verifies these links automatically).

Even if your website is small enough to create a redirect mapping that contains all old URLs, you should definitely create a list with all of the URLs mentioned above, so you can pay special attention to them. You don’t want any of these URLs to give back a 404 error or to redirect to the wrong target after the migration.

In order to determine which of the old URLs that you have collected need to be redirected, you can use Excel or Google Sheets to replace your domain with the domain of the staging environment in all URLs and then crawl the entire list. All URLs that don’t give back a 200 status code on the staging website will have to be included in your redirect mapping. Careful: If the 404 error page of the staging website is not configured correctly yet (a very typical error), URLs that don’t exist on the new website might give back a 200 status code. Before you run this test, you should make sure that you have a proper 404 error page on your staging website.

If you’re not using a software that automatically matches your old and new URLs for a redirect mapping, the next step will be to manually define a matching redirect target for every URL in your list. Ideally, the redirect target should have the same content as the old URL, or at least cater to the same search intents and queries. For every old URL that needs to be redirected, make sure you find the most similar URL on your staging website.

Before we get to actually setting up the redirect rules for testing on your staging website, let’s talk about another very important aspect of redirects that you should pay attention to when migrating a website: Redirect chains.

What you can do to avoid redirect chains

Redirect chains occur when a URL redirects to another URL, which then redirects to another URL again. These chains should be avoided by all means, as they waste crawling resources and most likely don’t pass on as much relevance as a redirect without detours. Here are some things you can do to avoid redirect chains:

• If the way your redirects are set up allows for it (depending on the system you are using for implementing redirect rules), always define absolute URLs containing the protocol (https), full domain and URL path as redirect targets. Always double-check that the exact URL variant you specify as a redirect target gives back a 200 status code.
• Your redirect rules should apply to all variants (www / non-www, http / https, trailing slash / no trailing slash, etc.) of your old URLs, so that each variant redirects directly to the defined redirect target.
• If you are using global redirect rules (like http > https, non-www > www, no trailing slash > trailing slash), these should apply after your 1:1 redirect rules (only for URLs that you haven’t specified a 1:1 redirect for).
• Update your legacy redirects: Export a list of all redirect rules that are currently implemented on your website. If the redirect targets contain URLs that are included in your list of URLs that need to be redirected, replace them with their new redirect targets. You can do this with a VLOOKUP in Excel or Google Sheets. Define new working redirect targets for legacy redirects that redirect to error pages.
• Break up existing redirect chains (you will probably find plenty while checking your legacy redirects) by redirecting every single link of the chain directly to the last link of the chain (the final redirect target).

Once you’ve finished your redirect mapping, added and updated your legacy redirects, and made sure your rules are not causing any redirect chains, it’s time to set up your redirects on the staging environment and test them.

Setting up your redirects on the staging environment

Your staging environment most likely has a different domain or at least a different subdomain than your live website. For testing, you will have to replace the domain of all URLs in your redirect mapping with the domain (or subdomain) of the staging website.

All URL paths that you have created a redirect mapping for, when requested on the staging website, should 301 redirect to a matching URL on the staging website that gives back a 200 status code. Crawl the list of old URLs that you created in an earlier step with the live domain replaced by the staging domain. You can then use a VLOOKUP to make sure that each URL redirects to the exact URL that you have defined as a redirect target.

If you find errors, have them fixed and crawl the list again, until everything works as specified.

The good thing about this procedure is that the implementation of the redirects can normally be pushed live fairly easily when the rest of the staging website goes live, without needing any further adjustments, except for making sure that the staging domain is replaced with the new live domain in the redirect target URLs.

One case that requires a slight adjustment of the process described above is if your website migration also involves a domain switch. Let’s talk about this next.

Special considerations in case of a domain switch

If you are switching domains, you can (and should) test redirects in the exact same way as described above, but you should keep in mind that your redirect rules will only be set up temporarily on your new website while it is in the staging environment, but will then be removed from there when the migration happens and set up on the old domain instead.

The reason for this is that the redirect rules have to apply to URLs on the old domain after the migration, but your new website will sit on a new domain. In order to avoid redirect chains, it is very important to redirect all URLs on the old domain directly to their equivalent on the new domain.

A possible alternative to testing your redirects on the staging website of your new website, in case of a domain switch, is to test them on the staging site of your old website. This can be a good idea in cases where the way redirects are implemented on the new and old website is different. If you test your redirect rules in the staging environment of your old website, you only have to push them live for the migration, without worrying about changing the implementation from the staging site of the new website to the old domain.

In any case, using a global redirect rule to simply replace the domain in all old URLs first, and then redirecting them to their final targets should be avoided by all means, even if it might be easier to set up. I’ve seen website migrations with domain switches go terribly wrong because of this.

In fact, and this might surprise you, I would advise against using a global rule that simply replaces the domain in your old URLs altogether, even if it only applies after all of the 1:1 redirects you have created. The reason for this is that your old domain has probably collected a high number of URLs that don’t exist anymore, that contain errors and that give back all kinds of 4xx and 5xx status codes. A domain switch is a great opportunity to get rid of all of this technical debt. If you created a global redirect rule that simply replaced the domain in all remaining URLs after your 1:1 redirect rules have applied, you would generate equivalents on your new domain of all of the remaining historical URLs and error URLs that are still being requested by bots and users once in a while.

The solution to this problem is to create a very thorough list of 1:1 redirects and maybe, if applicable, some rules that catch all URLs of a certain type and make a certain modification to them. Then, in the end, you can create a rule that redirects all of the remaining clutter to the home page of your new website, instead of generating the equivalent of that clutter on your new domain. Just make sure that you define as many 1:1 redirects and more general rules as possible, so that there’s not too much clutter left, as redirecting lots of URLs to your new home page isn’t the best idea either. In this case though, it’s definitely a better solution than taking your clutter with you.

Testing, monitoring and reducing your redirects after the migration

As mentioned before, even if you thoroughly test your redirect rules on the staging website, this does not eliminate the need to test them again as soon as the new website goes live. Crawl all URLs you’ve created redirect targets for and make sure that they all 301 redirect to the target you’ve specified and that the target gives back a 200 status code. You can use list mode in Screaming Frog and VLOOKUP in Excel or Google Sheets to run these tests.

It also makes sense to set up a monitoring for your old URLs which checks them once in a while and makes sure that they still redirect to the right targets and that the targets give back 200 status codes.

Some of you might have concerns about high numbers of redirects slowing down page load times. In the case of a website migration, there is really no room for negotiation: The more old URLs you redirect, the better. One thing you can do though, in order to reduce the number of redirects after a website migration, is monitoring your log files to check which old URLs are still being requested by bots and users. If a URL has not been requested for several months and does not have any links from other websites pointing to it, the 1:1 redirect rule that applies to it can be removed. This is the compromise that SEOs who care about saving their organic search performance and developers who have concerns about redirects slowing down page load times should agree on.

TL;DR

• Test your redirects on your staging website before the new website goes live in order to minimise the risk of going live with faulty redirects.
• Testing your redirects before the migration does not eliminate the need to test them after the migration.
• Collect all URLs that have clicks, impressions, sessions from organic search and backlinks.
• Crawl all old live URLs on your staging website to determine which of them don’t exist there and thus need to be redirected.
• Define redirect targets manually or automatically.
• Avoid redirect chains by making sure that all variants of your old URLs redirect directly to a working new URL.
• Update your legacy redirects, add them to your mapping and break up existing redirect chains.
• Set up your redirect rules on your staging website and crawl your old URLs there to make sure they’re redirecting correctly.
• If you are switching domains, make sure you remember to move your redirect rules to the old domain before your new website goes live.
• Don’t use a global rule that simply replaces the domain in your old URLs.
• Crawl all old URLs directly after your new website goes live to make sure they all redirect correctly.
• Set up a monitoring for your old URLs that regularly checks if they’re still redirecting correctly.
• Monitor your log files and remove redirect rules for URLs that haven’t been requested for a long time and that don’t have links from other websites pointing to them.

Thanks for reading! I hope you enjoyed this article. If you have any remarks or questions, please feel free to leave a comment below or speak to me on Twitter or Linkedin. I’m looking forward to hearing from you!