A few days ago Google updated its guidelines for “transferring, changing or migrating” a website. While they’re not really saying anything new in terms of how to go about it, site migrations remain a massive SEO and online marketing challenge. (So much so that a guided site rollover, as we call it, is one of RankAbove’s most in-demand services.) Too often, websites lose significant portions of their traffic during a rollover due to mistakes and oversights in the required steps, which, while definitely not painless, can be avoided with meticulous planning. While some of the tips seem obvious, their implementation isn’t. We’ve seen certain mistakes made repeatedly, and therefore recommend that you pay special attention to these 5 tips and common pitfalls.
Map your URLs.
Good URL mapping requires continuous updating partly because updates to the website are almost always made during the planning of the rollover. Also, the bigger the site, the higher the chance is of unaccounted-for pages – pages that, somehow, no one in the company even knows exist. Create a spreadsheet and match each URL and/or URL type to the corresponding URLs on the new site. Use all available resources to identify all of your website’s URLs and page types: historical Google Analytics data, Google Webmaster tools, old CMS platforms, analytics platforms and backlink tracking tools.
Redirect URLs via 301, not 302.
For a temporary move to a different location, a 302 response code will work. But there is no reason to use 302s in a site rollover. (Remember that 302s don’t transmit any link value.) While this fact is ‘bread and butter’ to SEOs, coders and developers are often unaware of it, and many content management systems assign 302s by default. We can’t count how many times we’ve seen companies unknowingly use 302s instead of 301s (which is why you need to test: tip #5).
Don’t redirect pages that don’t need to be redirected.
Don’t be afraid to 404! Sometimes it makes sense to 404 a page if there is no corresponding, relevant page on the new site. If you no longer offer a certain product, the visitor – and Google – may very well prefer to reach a nice 404 page that says ‘this product is no longer available’ rather than a different, and sometimes unrelated, product or category page.
Beware of server migration.
Redirect issues are particularly prevalent when the rollover involves a change in server architecture – perhaps from Apache to IIS (Linux to Windows), or vice versa. The chances for bugs are higher. For example, Apache servers don’t differentiate between capital and lowercase characters, while Windows servers do. So if a website migrating to Windows is coded to recognize only lowercase characters in its URLs, all pages with capital letters in the URLs that are redirected will 404.
Revision testing, both pre and post launch.
We’ve seen people succeed to redirect correctly, but do so to the wrong target page or to a 404 page. We’ve also seen cases where one file or even one extra space in the URL rewrite rule sabotaged the entire rollover, and the website essentially went down. There’s a myriad of other examples, all of which could have been avoided by continual testing.
Here’s a simple method we’ve used for testing URLs: Change the domain name in each URL (Find and Replace in Excel) and test them live in the staging environment. Several tools offer header checkers which check the server responses of each URL – some are more manual and some are more automated, like ours 😉 .
Try to take advantage of the available tools when planning a rollover, especially if it’s for a website which has a great deal of traffic and revenue at stake. It was this very exposure to website-migrations-gone-wrong that inspired us to include in our platform’s functionality a rollover tool that checks the link status of all 301 redirects, as well as to offer the rollover service.
Let us know any questions or comments @rankabove.