How To Do A Website Migration Without Harming Your SEO

So you’ve decided to upgrade your website to a new platform or a new CMS version?

Well good luck!

You’re in for an SEO rollercoaster ride over the next few months, with rankings most likely bouncing around everywhere, with no possible tracking to work from.

However when the dust has settled, you’re hoping that everything finishes off a few spots higher, or even better a few pages higher!

But be warned, a site migration is probably the #1 cause of a ranking drop across the entire web.

Follow this simple checklist to avoid a slump and prevent that embarrassing conversation with your boss.

SEO Migration Checklist Overview

1. Page Mapping
2. Redirects
3. Internal links
4. Tracking Codes & Pixels
5. Development Stage
6. Going Live
7. Final Audit
8. Monitoring

1. Page Mapping – No Traffic Left Behind

Your existing website most likely has many legacy pages that were created years ago by an unknown developer or content writer. Whoever is in charge now (including yourself) may think that these pages are redundant, and can simply be ignored in the brand new shiny site upgrade.

I encourage you to check them first!

You will be surprised at what’s gaining traffic, even that old 200 word article from 2010 could be sending your site traffic, and more importantly conversions.

So don’t delete a page without checking if it’s definitely not benefiting the website.

Finding True Redundant Pages

Go to your Google Analytics, and under Behaviour -> Site Content go to Landing Pages.

This is where you can find all of the truly redundant pages.

Set the time period to the last year, and filter by traffic lower than 10 (you may wish to edit this number to make the results more relevant to your website traffic overall).

This will show you all of the pages that received less than 10 visits in the last year.

Now you want to remove any pages from the list that are in the long term SEO plans, and you will be left with non-essential, low traffic pages.

From my experience these pages fall into two categories:

1. Cannibal pages – similar topics to more powerful, main pages.
2. Non-keyword targeted pages / generic blog posts.

If a page is a cannibal, then you should follow my keyword cannibalization fix, which is to delete the page and 301 redirect the url to the main page of that keyword.

If a page is in the second category, then see if it has any user benefit. If it has, then set it to noindex and leave it on the website. If it doesn’t, then delete it and redirect it to the parent page / homepage.

An example.

If we had a clothes category, and we also had a blog post about “The clothes on Brand.com”, then that would probably be a cannibal page (as anyone searching for a keyword around “clothes” and the “brand” would 99% of the time want to see the clothes section on their website as opposed to a blog post talking about them).

If the page is sending taffic and isn’t a cannibal, then you should include it in your new website, fitting it into any url structural changes.

301 Redirects – THIS IS KEY!

It can’t be said more strongly:

FAILED REDIRECTS ARE THE NUMBER 1 REASON FOR A BAD SITE MIGRATION

If you get your redirects wrong, Google doesn’t see it as a site migration, it sees it as a mess. And guess what? Mess doesn’t rank that well.

Each url of the original website needs to 301 redirect to the corresponding page on the new website.

This obviously only applies if you have changed the url structure or form (for example moving from domain.com/sub-page/ to domain.com/page/sub-page/ OR domain.com/page.aspx to domain.com/page/ ).

If a page is being deleted, it also has to 301 redirect somewhere. Ideally to the most relevant page on the site to the pages topic, or failing that the homepage.

If you are combining pages together, then the previous versions must 301 to the new version.

A new sitemap will not cut it, only a 301 redirect will do.

*Important note: make sure you retain all of the previous htaccess rules in your new website, as otherwise you will have lots of legacy 404’s to deal with. If you have the time and budget, it’s best to remove any redirect chains from the htaccess file, and so updating old rules to redirect straight to the new location (instead of them going to the previous page and redirecting again) is best.

**Second Important Note: the robots.txt file of the old website may contain some very convenient rules to block bots on your old CMS, but do they apply to the new website? There may be rules in there that need updating, for example if your new ecommerce system uses a different url for parameters or filters. Run through each rule, work out what it was used for, and see if there is an equivalent on your new CMS.

Internal Links Must Be Updated

This goes hand in hand with the redirects section, as if a url has changed then all of the links within the website content to that page are now incorrect.

Even though the links would work (because of your successful redirect) following redirects slows Google’s crawler down on your website, which can make it less likely to crawl your important pages as often. It will also slow your page load time, making it worse for converting customers.

The way you fix this may differ depending on your website system, but using a database find and replace tool can be a simple way to do it. The end result you need is for each internal link to point to the new url of the page, not the old one.

If your website structure has changed in a uniform way, then you can do a find and replace on the string, for example if you’ve gone from domain.com/product-category/category-name to domain.com/category/category-name, then you may be able to do a search and replace for the string product-category.

Some CMS have useful plugins for this, such as the Better Search and Replace tool for WordPress.

The worse case scenario is that you have to login to your CMS and do each one by hand, but in 99.9% of cases it will be much better to pay a developer to code some rules (or outsource those changes overseas).

Tracking Code and Pixels

The previous website will probably have had many different tracking codes, scripts, and pixels in the code to do lots of offsite marketing and analytics. These are quite easy to forget during the migration, as the current person may not have inserted them, but they may still be providing essential business data.

A quick “hack” to find these at a glance, is to use the Ghostery browser extension, which displays all of the tracking cookies and scripts that a website is loading.

This can help you get the easy ones, however sometimes there will be scripts that only appear on certain pages. Some of the most important pages to manually check for these are the homepage, the main category and product pages, and pages in the conversion funnel (such as cart, checkout and success pages on ecommerce websites).

Make a checklist of each pixel and piece of tracking code, and make sure you tick each one off on the new website.

Development Stage Testing – Baby Steps

The development area is where you test the new version of the website, and so it makes the perfect place to check that the SEO is all working correctly.

The best tool for technical checks is Screaming Frog. Crawl the website and make sure that all the pages are crawlable, that most (if not all) of the internal redirects have been updated and fixed, and that there aren’t any errors.

The next step is user experience testing, as a terrible user experience can sky rocket your bounce rate and ruin conversions. Pay people to test your development website, and submit comments or user videos so that you can find anything that’s broken ahead of time.

Some of the main areas to check are the conversion funnel (including full checkout payment steps in ecommerce) as errors here cost you serious money.

Going Live – Fingers Crossed!

So it’s time to go live. You’ve done everything you can think of, and now it’s the moment of truth.

Steps to going live:

1. Be in a position to easily switch back to the old site if errors are found.
2. Make the switch to the new site (cms dependent). Make sure the .htaccess and robots.txt file are the new ones!
3. Crawl the old site urls to ensure all redirects are working correctly.
4. Crawl the new site to make sure all pages are working correctly.
5. Do user tests to ensure the new site is performing correctly (multiple browsers and devices).
6. Submit new sitemap to Google Webmaster Tools
7. Use the Fetch and Render tool in Google Webmaster Tools and index the main pages of the new website.

Monitoring and Rankings

Traffic and rankings will be all over the place initially, so it’s important not to jump to conclusions based upon a few bounces.

However anything that looks “suspicious” should be noted, and then run through the following checks:

1. Does the old url 301 redirect properly to the new one?
2. Has the new page lost any specific keywords from the SEO elements (Title, Meta description, H1)?
3. Is the new page missing any important information from the old website?
4. Do the internal links still point to this page?
5. Does user testing bring up any problems?

If you find the issue is anything but the url changing, then rectify the problem and re crawl the page.

If the url has dropped a keyword and it has resulted in a drop in rankings, then you should seriously consider changing it back to the old url and removing the redirect.

If you’re changing domain names, then don’t lose control of the old domain, as it has a lot of your link equity in it, and so should remain hosted with the .htaccess file intact.

Depending on the size of the site, and how much it gets crawled, the aftermath of a site migration can last for months. Things to monitor in Google tools:

1. Search Console -> Crawl Errors: This is a sign that your internal links or redirects haven’t been implemented properly, and should be fixed asap.
2. Search Console -> Indexed Pages: Look for big drops in indexed pages, as something might be blocking them from being indexed.
3. Google Analytics -> Landing Page (bounce rate): If you see spikes in bounce rate then something may be broken or missing, so do some visual checks and then dig deeper by device / browser.

Bench Mark Rankings – Your Guiding Star

There will most likely be a few rankings that you use internally as examples of what “you’re known for”.

They will symbolise the most traffic, or where you’re the best in your industry.

These are the rankings that you should focus on during the migration, as they will most likely be crawled the most, get the most traffic and get updated the quickest.

Big drops in these rankings could be a sign of a problem across the board, so they should be taken more seriously than a keyword moving from page 3 to page 7.

Final Thoughts

Site migrations are tough, expensive, and can make rankings worse not better.

Before you implement one, you should seriously consider if you will see the return on the investment from it, as in many cases the risk won’t be worth the small reward.

However if you’ve got a legacy system that’s bad for users or not secure, then you have no choice.

If you have any questions about migrations from an SEO perspective, or would like some help, then email me: info@matt-jackson.com