Testing redirects before and after go-live

In a migration, the redirects often decide whether rankings and visitors stay. If important URLs change and the old ones then lead nowhere or to the wrong target, the new website loses rankings and visitors. This guide shows how to check redirects before and after go-live.

Why should you test before go-live?

Before launch, the new website usually sits on a staging environment. That is where you set up the 301 rules and check them before real users and Googlebot see them. Errors you find here cost no traffic. You still need the test after go-live, because the server, CDN and configuration of the live environment can behave differently.

Preparing the redirect mapping

The mapping contains every old URL that will no longer exist after the migration, each with its new target. On very large websites you rarely manage this for every URL. In that case, the URLs that carry value come first.

This list is worth it for small websites too. It shows which URLs must on no account return a 404 or redirect to the wrong place after go-live.

Which old URLs need a target?

Swap the live domain for the staging domain in all the URLs you collected and crawl the list. Every URL that does not respond with 200 on staging belongs in the mapping. Check the staging environment's 404 page first. If it is set up incorrectly, missing pages respond with 200 and you overlook them.

Ideally, the target of each redirect has the same content as the old URL. If there is no such page, use the page that serves the same search intent.

Avoiding redirect chains

A chain forms when one URL redirects to a second and that one to a third. Chains cost crawl resources and increase load time. According to Google, Googlebot follows up to 10 hops and then stops. For site moves, Google recommends keeping chains to three redirects where possible and in any case fewer than five. A direct jump is best.

1. Always enter the full URL with protocol, domain and path as the target. Check that exactly this variant responds with 200.
2. Have every variant of the old URL point directly to the target, meaning with and without www, http and https, with and without a trailing slash.
3. Global rules such as http to https or non-www to www only apply after the 1:1 rules, so only for URLs without a rule of their own.
4. Export all existing redirects. If one of them points to a URL that is now moving itself, enter the new target. In Excel or Google Sheets you can do this with VLOOKUP. Old rules that lead to error pages get a working target.
5. Resolve existing chains. Every link in the chain redirects directly to the final target.

More on the status codes and their effect is in the guide 301 and 302 redirects.

Testing redirects on staging

The staging environment usually has its own domain or subdomain. For the test, you replace the domain in all source and target URLs of the mapping with the staging domain. Every old path there must point to the planned target with a 301, and the target responds with 200.

1. Crawl the list of old URLs with the staging domain in your crawler's list mode.
2. Match the status code and target of every URL against the mapping with VLOOKUP.
3. Have deviations fixed and crawl the list again until every row is correct.

For spot checks, the terminal is enough. The command shows the status and target of a URL without following the redirect.

For a whole list, write each URL on its own line in a text file and output the result as a table.

Once all rules are correct, they usually go live with the website. You only replace the staging domain in the target URLs with the live domain.

Special case: domain change

For a domain change, you test the same way. However, the rules only sit on the new website during the test phase. At go-live they move to the old domain, because that is where the requests arrive. Every old URL then redirects directly to its counterpart on the new domain.

If redirects are implemented differently on the old and new platforms, you can also test on a staging environment of the old website. Then all you have to do at launch is switch the rules live.

After go-live: test, monitor, reduce

Right after launch, you crawl all old URLs from the mapping on the live domain. Each must point to its target with a 301, and the target must respond with 200. After that, you keep monitoring the old URLs regularly, because releases and new rules can break redirects again later.

Development teams often ask whether lots of redirects slow the website down. In a migration, the rule at first is the more old URLs redirect correctly, the better. Later, log files show which old URLs bots and users still request. Rules for URLs with no requests and no backlinks from other websites can then be dropped.

How long should redirects stay in place?

For site moves, Google recommends keeping redirects for as long as possible, generally at least one year. So decide after one year at the earliest, and only then based on logs and backlinks.

Common mistakes

• The staging environment's 404 page responds with 200. Missing pages go unnoticed in the test.
• Target URLs without protocol or with the wrong slash. Every rule creates an extra hop.
• Old redirects from earlier relaunches stay unchanged and point to URLs that now redirect themselves.
• With a domain change, the rules stay on the new domain and are missing on the old one.
• After go-live only the homepage is checked, and the list of old URLs goes untested.

FAQ