When I work on website migrations as an SEO consultant, I always push for testing redirects in the staging environment before the launch.

I wrote about this in 2019, and it still holds true: Testing redirects before you go live will save you from avoidable traffic losses.

Website migrations: From straightforward to end boss

Depending on the complexity of the migration, testing redirects on staging can be straightforward, a bit tricky, or technical SEO end boss level:

Straightforward – Website changes without a domain switch: You can simply set up path-based redirect rules and then crawl your old URL paths on staging to check if they redirect correctly to their new equivalents.

A bit tricky – Website migrations with a domain switch: You need to account for the fact that the redirects have to be implemented for your old domain and point directly to targets on the new domain, without going through a redirect chain. How you test will depend on how exactly the redirects are set up. In some cases you can still use path-based rules on your staging environment for testing. In others, the redirect rules will have to contain host names, which pushes you closer to the next level.

Technical SEO end boss level – Merging several domains into one: There will be at least some duplicate paths across the different domains, so redirect rules cannot be purely path-based. And as all redirects will likely be handled by the same server environment after the migration, redirect rules have to include host names in most cases.

Read on to learn how we handled the end boss in a complex multi-platform migration I worked on recently and why testing the redirects on staging, although it required a complicated setup, saved us.

A 15-month migration project

The most recent migration I worked on involved merging three content platforms into an already existing global corporate website.

We worked on the project for about 15 months prior to launch and SEO was an important part of the discussion right from the beginning.

A migration project of this scale covers many topics within SEO and even more in other areas, but what I would like to focus on here is how exactly we tested the redirects on staging before the launch. And why I’m glad we did.

Convincing stakeholders under pressure

If you’ve ever worked on a website migration, you know this: When the launch date approaches, tension rises and urgent last-minute tasks keep piling up. Convincing stakeholders that redirects must be tested on staging can be difficult in such a situation, especially when the setup for the testing is complicated.

In this particular case, we faced the challenge that we had to test redirect rules for three different domains on a heavily protected staging site for the final consolidated corporate website. The redirects had to contain the domain host names and could not simply be path-based. So a crawl that only checked the old URL paths on the staging environment would not be enough.

The technical solution: Crawling with host override

After some back and forth, we figured out that the best solution was to use a host override to point the three old domains to the staging server’s IP during crawling, bypassing the public DNS records. A big thank you to Michael for making the setup possible with our crawling platform searchVIU, in cooperation with the client’s technical providers.

Like with most website migrations, everything happened too late and the redirect testing setup was ready only a few days before the launch date.

Friday afternoon: We discover critical errors

On Friday afternoon, the last working day before the launch, we noticed that there was a serious problem with the redirect setup for one of the three platforms:

We had planned to set some old URLs to 410 instead of redirecting them, but somewhere along the long line of communication from the platform’s SEO agency to the team that managed the platform to the overall migration project manager to the dev team to the technical provider who actually set up the redirects and 410s on the server, wires got crossed and URLs got mixed up.

The result was that about 2000 high-traffic URLs were nuked by setting them to 410 instead of redirecting them to their equivalents on the destination website.

Not something you want to find on the last working day before the launch. But even less something you want to miss.

A closer look at the issue revealed that there were more problems with the redirect mapping for this platform. Untangling the whole mess required another full day of work (spread out over the weekend), but we managed to get everything fixed almost on time for the launch:

The revised redirect mapping and list of 410 URLs were live just two hours after the launch on Monday morning.

Staging tests can’t catch everything

On launch day, new redirect errors emerged which we couldn’t have spotted during our tests on staging, as they were only added after the launch:

The team needed a solution for showing an info banner about the migration to users who entered the website through a redirect, and the solution they picked was to add parameters to the redirect targets. I spotted this during my first redirect tests after the launch and immediately intervened.

The fix was to replace the parameters with URL fragments: a better solution from a crawling perspective and also for web analytics.

It took another few hours to get this fixed, but at 6pm on launch day, we had an acceptable redirect setup. Anyone who has ever worked on a complex website migration would agree that this is a major win.

Always push for it

Now imagine what would have happened if we hadn’t tested on staging: we would have discovered several serious issues on launch day that would have taken at least two days to fix. On top of all the other problems you have to take care of during the days after a launch. Google would have crawled thousands of 410s and faulty redirects and our traffic would certainly have suffered.

Testing redirects on staging is complicated. Push for it anyway.