It’s critically important to get a website migration right as errors can result in a loss of traffic and revenue that can take months to recover. Even if everything is done correctly it is still likely there will be some initial traffic loss.

Wildebeest migration through river

There is less risk of death, but like a wildebeest migration,
website migrations are fraught with danger

Including all major stakeholders in the process (including the SEO department or SEO agency if applicable), planning ahead and thoroughly testing the website post-launch should help prevent any major issues when a website is moved to a new domain, redesigned, has a change in URL structure or is transferred to a new Content Management System (CMS).

This migration guide will look at pre-migration checks and considerations, the process of redirecting URLs (if they will be different on the new website) and important post-migration checks and considerations. Hopefully, you’ll discover some useful tools along the way.

Pre-Migration

Consider when the migration will take place – for an e-commerce store, for example, it isn’t wise to migrate 2 months before Christmas. Due to the potential for catastrophe, a site migration isn’t something that should be rushed or implemented if staff resources are lighter than usual.

Google Analytics screenshot of traffic loss after botched site migration

Only 40% of traffic was lost after this website migration – I’ve seen far worse

If your website is being redesigned an audit of your existing website can help identify issues that should be avoided and strengths that can be replicated on the new website.

Once the new design is complete it makes sense to prioritise certain sections of the website. For example, do pages that receive the most traffic exist on the new website? If not, is there a good reason? If these pages don’t exist or there is an error in the migration a significant chunk of your traffic could be lost.

For example, do pages that receive the most traffic exist on the new website? If not, is there a good reason? If these pages don’t exist or there is an error in the migration a significant chunk of your traffic could be lost.

Prioritising top organic traffic pages (e.g. in Google Analytics: Acquisition > Keywords > Organic > Landing Page) makes sense as errors here could see a huge loss in search traffic.If you track conversions (you should!) it makes sense to

If you track conversions (you should!) it makes sense to prioritise the pages that convert best – if the migration is part of a redesign, will a redesigned website convert better than the old website? It’s wise to do some usability and A/B testing.The highest authority

The highest authority webpages can be prioritised too. Looking at your webpages in Moz’s Open Site Explorer (Page Authority) gives a good idea of which pages have the highest authority gained from links. You could also run a Strongest Subpages report in Link Research Tools. Looking at the most linked to content in Google Webmaster Tools is an alternative.

In summary, if you can’t afford to lose the amount of traffic or revenue a page generates, make sure it exists (or has been replaced) and works on the new website. As well as the above you should:

  • Ensure a test website doesn’t appear in search engine indexes. The most secure way is to password protect it or only allow access to certain IP ranges.
  • Check and keep a record of organic keyword rankings.
  • Have a keyword strategy. Will title tags and other content be the same or similar on the new website? This is important if you want to keep existing keyword rankings intact.
  • Crawl your old website and keep a record of the URLs. DeepCrawl is useful as it can show a summary of the changes between a website pre and post-migration. Other recommended software: Screaming Frog SEO Spider (paid version if your website has over 500 URLs), Xenu’s Link Sleuth (free), or if you’re a subscriber – Moz’s crawl tool.
  • Check the load speed of some key pages (e.g. homepage, main category, sub category, product page, blog post). I use Pingdom Website Speed Test (make sure to uncheck “Save test and make it public”). Compare old pages to the equivalent new pages on the test website – if loading times have increased, why?
  • Crawl the test version of your website (check for issues such as 404 Not Found pages, 500 Internal Server Errors and canonical tag implementation).
  • Even with the most thorough preparations there might be a few broken links, so prepare a useful 404 Not Found page for the new website.
  • There are millions of parked domains so if you’re moving domain, add a landing page on the new domain. This is advice from Google – it helps their crawler understand a new website quicker.
  • Analytics – keep the same profile if you can. If you’re sticking to the same software there’s no reason to change. This makes pre and post-new-site comparisons easy.

URL Redirecting

Keep URLs the Same

Where possible the URLs of pages should be the same as they are on the previous website. This makes it easy for visitors to find the new pages (without you having to redirect them) and retains 100% of the authority that flows to a particular page – and all other things being equal usually retains keyword rankings.

However, if your URLs are not user or search engine friendly, this is a good time to optimise them. For example:

www.example.com/category/short-product-description
is much friendlier than
www.example.com?category=5462eg&product_id=1687&id=b4cn

301 Redirect URLs That Have Changed

A redirect transfers a user from one URL to another. “301 Moved Permanently” and “302 Found” are the two most well known redirects. The 301 redirect ensures authority is passed from the old to the new URL, which is why it is so important to use 301 redirects. 302 redirects only signify a temporary change in URL (though Bing and Google have said if they follow a temporary redirect often enough they will assume a 301 is intended).Using the correct redirect prevents a large temporary dip in traffic as it ensures the website remains fully indexed in search engines.

If URLs have changed each old page URL needs a 301 server-side redirect pointing to the new version of the URL.

If URLs aren’t redirected at all, search engines and visitors could enter your website at a broken page (e.g. via a bookmark, link, or search engine), which in many cases will cause them to abandon a website completely.

301 redirect example:

X is a URL on old website: http://www.example.com?category=5462eg&product_id=1687&id=b4cn
Y is a URL on new website: http://www.example.com/category/short-product-description
X should be 301 permanently redirected to Y.

301 Redirect Pages That No Longer Exist

In most cases, if a page from the old website doesn’t exist on the new website, the old URL should be 301 redirected to the closest available match on the new website. For example, if you had an individual contacts page for a number of cities in the UK, but moved to regional pages, each of the city pages would need to 301 redirect to the new regional pages e.g.

Old website (these pages will not exist on the new website):

A: www.example.com/contact/london
B: www.example.com/contact/york
C: www.example.com/contact/edinburgh
D: www.example.com/contact/glasgow

The new website has country pages, which are the closest match to the city pages that exist on the old website:

Y: www.example.com/contact/england
Z: www.example.com/contact/scotland

URLs A and B would redirect to Y.
URLs C and D would redirect to Z.

Frustrated women at laptop

Avoid making your visitors feel the emotion this model is portraying

Think of the person browsing a website – if a page doesn’t exist any more, what is the best page on the new website for them to land on? Keep their frustration to a minimum! In some cases it might be better for an old page to point to a 404 Not Found page – if the 404 page is useful in offering possible solutions to a visitor.

Other Redirect Considerations

Plan Ahead

Plan ahead by creating a spreadsheet containing a list of old URLs and the new URL they will be mapping to.

Group Redirects Together

To save redirecting every URL individually, often URLs can be grouped into one rule with pattern matching. This saves resources, as hundreds of individual redirects can slow down the performance of a server and hence the whole website.

Avoid Redirect Chains

Ideally redirect chains should be avoided; if any pages on the old website currently redirect, they should be updated to redirect directly to pages on the new website, rather than via an intermediate page e.g.

Page A and Page B exist on the old website.
Page A redirects to Page B.
Page C is the equivalent page on the new website.
Page A should redirect directly to Page C as should Page B, rather than Page A redirecting to Page B which then redirects to Page C.

301 Redirect Summary

To repeat, in most cases every page of content that changes URL should be 301 permanently redirected to the new URL the content resides at, or the closest available match.

How Do I Redirect URLs?

The easiest way on Microsoft IIS servers (version 7 and later) is to install the URL Rewrite Module. Here is a guide to the module: www.iis.net/learn/extensions/url-rewrite-module On Apache servers URLs are usually redirected in the .htaccess file. Rewriting URLs on Apache servers:

On Apache servers URLs are usually redirected in the .htaccess file. Rewriting URLs on Apache servers: httpd.apache.org/docs/2.0/misc/rewriteguide.html Some CMSs allow 301 redirects to be inputted. WordPress has the

Some CMSs allow 301 redirects to be inputted. WordPress has the “Simple 301 Redirects” plugin. In Magento, go to Catalog > Url Rewrite Management.

If you’re unsure what server/CMS your website runs on check at builtwith.com. Redirects can also be written at page-level in the code of your website. Here is a list of the code to use in various programming languages, including PHP and ASP.NET:

Redirects can also be written at page-level in the code of your website. Here is a list of the code to use in various programming languages, including PHP and ASP.NET: www.webconfs.com/how-to-redirect-a-webpage.php

Always remember to 301, and remember that hundreds of individual redirects can slow a website down, so group redirects together when possible.

Post-Migration

Man smiling at laptop

Hopefully he’s really happy about buying and isn’t laughing at the number of 404 Not Found errors on your newly migrated website

Once the new website is complete and online, and the 301 redirects have been implemented, there are a number of important checks to complete.

Immediate Post-Migration Actions

Check redirects are working.

Check analytics is reporting visits to the new website (Google Analytics’ Realtime view is quick and easy).

If the domain has changed (e.g. from example.com to example-new.com) then notify Google via Webmaster Tools and use Bing’s Site Move tool. Keep control of the old domain for as long as possible – especially if it has high authority links you’re unable to get changed.

In Google Webmaster Tools go to Crawl > Fetch as Google and submit the most important of your website’s pages (e.g. most trafficked and/or best conversions as mentioned in “Pre-Migration” section above).

Run a crawl of the website and check for issues such as 404 Not Found pages, 500 Internal Server Errors, crawl restrictions (such as Meta or robots.txt noindex) and canonical implementations. You can use Screaming Frog SEO Spider to verify your analytics code is included on every page.

You should also crawl the list of URLs you saved from the old website (mentioned in the Pre-Migration section above) to make sure any redirects of old pages match up as you’d expect and to check for unexpected 404 errors. In Screaming Frog SEO Spider you can see this in the “Response Codes” tab, filtering to “Client Error (4xx)” and “Redirection (3xx)”. DeepCrawl clearly shows redirects too.

If they exist already, I like to keep existing XML sitemaps online for 2-3 weeks after the website has been launched to help Google find the 301 redirects to the new URLs. After this time period has elapsed (you can check Google to see if the majority of your new pages have been indexed) the sitemap(s) should be replaced with an updated version and if it hasn’t been already – submitted to Google Webmaster Tools, and linked to in robots.txt.

Speaking of robots.txt, ensure that’s up-to-date too. Often pages get excluded from search engine crawlers that website owners want to appear in search engines.

Subsequent Days/Weeks After Migration

If URLs have changed they need to be updated where possible (even if 301 permanent redirects are in place). This can apply to external links (prioritising the most important), Google AdWords (which doesn’t allow URL redirects) and affiliate schemes (which might not track correctly if URLs have changed).

Check regularly for new crawl errors, HTML improvement suggestions and changes in performance (e.g. crawl rate) in Google and Bing Webmaster Tools. Monitor analytics packages for visits to 404 pages (this is easy to check in Google Analytics if the 404 Not Found page has something like “Page Not Found” or “404” in the title tag) – if a particular URL is receiving a lot of visits it might be worth permanently redirecting it if there is another similar page.

Even with the best plans in the world, URLs can be missed. There are plenty of tools for finding broken links on a site, which can then be checked for backlinks (to see if the broken links are worth redirecting). Link Juice Recovery is a great time saver – combining both these tasks into one tool.

Try site searches (e.g. site:example.com) in Google to see how Google is indexing the new website, and if old URLs remain. Look at the timestamps on cached pages.

Monitor changes in organic rankings, traffic and conversions. Some fluctuations are to be expected, but investigate anything major. Has the conversion rate dropped or risen for any particular pages? If so, why? Has bounce rate risen? Is there less social sharing? As well as focusing on individual keywords, to ensure you don’t miss anything major, overall organic search visibility can be monitored using tools from Searchmetrics and Advanced Web Ranking, amongst others.

Migrating to a HTTPS Website

There are few extra issues to be aware of if you’re migrating from HTTP to HTTPS.

  • If you’re migrating to a fully HTTPS website, it’s worth noting that SSL websites can be slower than unencrypted websites, so look into the reasons why
  • All http URLs need redirecting to https – this can usually be done with one redirect rule
  • If you use canonical tags, make sure they’re updated to https
  • Update all internal http references e.g. images and links to CSS files
  • Check all pages for SSL errors and warnings

Website Migration Checklist

Pre-Migration

  • Audit your existing website to help identify any issues that can be avoided on the new website
  • Prioritise certain pages/sections (e.g. pages that make the most money)
  • Keep a record of organic keyword rankings
  • Does the content on the new site give keyword rankings a good chance of remaining intact when the new website launches?
  • Check the page load speed of some key pages
  • Crawl your old website and keep a record of the URLs
  • Ensure test website doesn’t appear in search indexes
  • Crawl the test website to spot errors that can be fixed before migration
  • Prepare a useful 404 page
  • Keep the same analytics profile, so pre and post-launch comparisons are easy

URL Redirecting

  • Where possible keep URLs the same
  • If URLs change or don’t exist on the new website, 301 redirect them (in most cases)
  • Create a spreadsheet of old URLs and the new URL they will map to
  • Pattern match 301 redirection where possible
  • Avoid redirect chains

Post-Migration

Immediate Checks:

  • If meta noindex tags were used to block the test site from search engines, make sure they’re removed
  • Check redirects are working properly and 301 Moved Permanently
  • Crawl URLs from the old site to check 301 redirects match up as expected
  • If the domain has changed, notify search engines
  • Is data tracking in your analytics package?
  • “Fetch as Google” in Google Webmaster Tools and submit to index
  • Run a crawl of the new website and check for errors
  • Keep existing XML sitemaps online for 2-3 weeks
  • Check robots.txt is up-to-date
  • Compare the load speed of the key pages you checked on the old website

Subsequent Days/Weeks:

  • Update URLs that have changed (e.g. in Google AdWords, external links)
  • Check for new crawl errors and changes in Google Webmaster Tools
  • Check if a significant number of visitors are landing on 404 pages
  • site:example.com
  • Monitor changes in organic rankings, traffic and conversions

Do you have any advice to share? Site migration disaster stories? What would you have done differently second time round?