Technical SEO

SEO Site Migration Checklist

Migrating a site to a new platform or domain, or implementing a major redesign, is one of the most stressful situations in search engine optimization. The potential for massively impacting organic search traffic and sales is higher during these launches than at any other time. But with planning and priority on the SEO impact of the launch, it’s possible to actually improve SEO performance after a major launch event.

However, most sites neglect to include an SEO professional in the planning, design, development and launch phases of the project, typically resulting in a loss of SEO performance post-launch. While an experienced SEO professional can certainly come in afterwards to guide the team through a strategy to revive the site’s SEO performance, this process typically takes three to six months of planning, rework from the design and development teams, and a loss of traffic and revenue in the interim.

Speaking from experience helping clients through many platform changes, redesigns, domain moves and other assorted SEO pitfalls, these are my best tips for arriving at the other end of the launch with your search engine rankings safely intact.

Migrations on the Same Domain

Most migrations occur on the same domain, where a site needs to implement a new ecommerce platform perhaps, or is redesigning the site for better branding and usability. Even if the subdomain, domain and top-level domain (“TLD,” such as .com) don’t change, the URIs are likely to change in these situations. And anytime a URI changes there will be an impact on SEO.

URIs are the name by which search engines know your pages. It’s how they’re stored in the engines’ indices. Changing those names without warning or helping the engines understand how the new URIs relate to the old URIs they have indexed is like starting all over again with fresh pages that have no history or link popularity. That’s essentially SEO suicide.

The first step is to bring in an SEO professional at the start of the project. Until the wireframe redesign stage, it’s unlikely that the SEO will do much more than absorb information, but that background can be invaluable when it comes time to actually making recommendations. The SEO professional should be involved all the way through design, development, pre-launch testing and post-launch monitoring.

URLs and Migrations on the Same Domain

Whenever possible, keep the URLs the same. In a cosmetic redesign, where the same pages are getting new skins, this should be entirely possible. In a more complex redesign or a platform migration, URIs are likely to change. When there’s a one-to-one match between pages, make every effort to use URL rewrites to convert the new URI to the same old URI that the engines know and love for that page. For example, if a site has a sweater category page before and after the redesign or migration, and the purpose of that page will remain relatively constant, then the platform’s new URL of should be able to be rewritten to the pre-migration URL of Even if URL rewrites are only done for the most important pages of the site – those that drive significant organic search traffic and sales and the major category pages – it’s better than changing every URI on the site. Protect the majority of your organic search traffic and sales by keeping the same URIs for the pages that drive the most organic search traffic and sales.

If the URIs have to change, 301 redirects are the best bet to preserve as much of the site’s link popularity and transfer it to the new URIs. This transfer is critical to not only infuse the new URIs with link popularity and to communicate to the search engines that the URI that they have indexed has moved and should be de-indexed and replaced with this new URI. If you’re unable to use 301 redirects for some very important reason, use cross-domain canonical tags — explained here in Google Webmaster Tools. It’s important to note that canonical tags are suggestions to the search engines while 301 redirects are commands, so be certain that 301 redirects are truly not a viable option before settling for canonical tags.

Google Webmaster Tools explains the use of cross-domain canonical tags.

Google Webmaster Tools explains the use of cross-domain canonical tags.

Some marketers try to play it safe by running the old and new sites simultaneously to ensure that users don’t encounter broken links from various marketing channels. Sites that do this must apply 301 redirects to the old URIs, or the old and new sites will be considered full-site copies of each other and could face duplicate content issues. At the very least, the engines will serve a confused mixture of the old and new URLs to searchers, throwing off the site’s ability to measure the success of the transition to the new site. At worst, the site could drop out of rankings entirely because the new site will be indexed based on internal links but the old orphaned site will have the benefit of the external links its pages have earned over the years. So a few of the strongest old pages may still rank, but the new pages won’t have the benefit of any external links to help them rank and drive traffic and sales.

Navigation and Migrations on the Same Domain

Oftentimes a new design rejiggers the navigation, adding or removing categories and subcategories, merging or splitting categories and subcategories, adding or removing rollovers or other features. Check the URI implications of any navigation change very carefully. Copy all of the URLs in the header navigation and all the URLs in the side navigation and compare the list with the URLs produced on the development site for the header and side navigation. If there’s a large degree of change, expect a similarly large degree of risk to the SEO performance of the site. Push to keep the same URI or at lease do 301 redirects to preserve as much link popularity and trust as possible.

Once the SEO professional can get access to the development or testing environment, he or she will want to identify how many URIs are changing site-wide and whether new sources of duplicate content are being generated. The easiest way to do this is to crawl the site. Filtering and sorting in particular tend to generate unwanted pockets of duplicate content, as do some implementations of breadcrumb navigation. Crawling the site and sorting the list of resulting URLs alphabetically will show where multiples of the same base URI are duplicated with parameters of subdirectories to enable these features.

A simple canonical tag referring back to the default URI will resolve any of these sources of duplicate content. In this case, a 301 redirect is undesirable because the URIs have to exist, — i.e., not redirect back to the base URI — for human usability. For example, placing a 301 redirect on a URI that sorts the products on a category page so that products are shown by price would result in the user simply ending up on the default sweater page again without the sorting order they requested. That would be terrible usability. Because the canonical tag affects only search engine crawlers, it’s a safe alternative to canonicalizing in instances where customers need to see the page but it’s redundant to search engines. Make sure to identify and resolve duplicate content issues before the site launches, however, because once the horses are out of the barn — the duplicate content is live and indexed — it’s a lot harder to get them back in that de-indexation barn.

Other Considerations for Migrations on the Same Domain

Keep the old XML sitemap in place for a week or so to ensure that the bots get pointed to the old URLs, see the 301 redirects, pass the link juice to the new URLs and de-index the old URLs. Likewise, make sure that the old URLs are not blocked by a robots.txt disallow directive or a meta robots noindex tag, so that the 301 redirect or rel=canonical can be found. A week after the launch of the site, check Google’s cache date to be sure that the site has been crawled since the launch and then post the new XML sitemap with the new URLs. Checking the cache date is as simple as Googling this phrase: “” and reading the date in the blue box at the top of the screen.

Ensure that a friendly 404 page is in place to help users who accidentally stumble upon an error page have can reorient themselves and continue their shopping with as little disruption as possible. The 404 page also needs to return a 404 server header code, not a 200 OK server header code. The 404 code tells search engines that that page is gone and needs to be de-indexed. Ideally all pages will be covered with a 301 redirect so that the search engines don’t encounter any 404s, but mistakes do happen.

If the site doesn’t have web analytics set up yet, do it immediately to start collecting pre-launch data as far in advance of the launch as possible. Without this data, an ecommerce site will have no way of measuring the impact the migration has on its SEO program or any marketing channel. Google Analytics is free and fairly simple to install. It’s a good choice for sites that are pinched for time or resources.

If templates have changed during the project, ensure that every template has a default title tag formula associated with it. For example, a category page might have the formula “{Category Name}, Women’s Clothing |” The formulas will ensure that every page has an acceptable title tag at launch, but of course the formulaic title tags should be overwritten with manual optimization for the more valuable or important pages.

Lastly, take a look at the Traffic > Links to Your Site report in Google Webmaster Tools. Inform the important sites that link to the site about the changes and politely request that they change their link to point to the new URI. True, if the site has 301 redirects in place the users will still get to the desired page. However, even 301 redirects bleed a fraction of the old page’s link popularity. How much link popularity and trust is lost is unknown outside the engines’ walls, but even though it’s understood to be a small amount, any amount of link popularity loss is undesirable.

Moving to a New Subdomain, Domain or TLD

In addition to the above, a few special steps need to be taken when moving a site to a new subdomain, domain or TLD. This should really only happen in the case of a company merger, major rebranding initiative, or similar extremely large and rare business case.

First, verify the new site in Google and Bing webmaster sites, and make sure that the old site is verified as well. Every subdomain, domain and TLD need to be registered and verified separately, so be sure to cover all the bases. For instance, and need to be registered and verified separately in webmaster tools.

In Google’s Webmaster Tools, use the Change of Address option under Site Configuration to alert the engine of the site move. This, in conjunction with the 301 redirects, canonical tags and other signals completes the message that the site is indeed moving to a new location.

When moving a site to a new subdomain, domain, or top-level domain, use the "Change of Address" option in Google Webmaster Tools.

When moving a site to a new subdomain, domain, or top-level domain, use the “Change of Address” option in Google Webmaster Tools.

Measuring the Impact of the Site Move

Two sources of information will be critical to measuring the impact of a site move on SEO performance: web analytics and webmaster tools. A site’s web analytics will reveal any traffic and conversion impacts for the SEO channel. Expect unstable traffic for up to four weeks, longer if the migration involves multiple major changes, like large-scale content, URL structure, and navigational updates. Changing everything at once may confuse users and search engines, so Google in particular advises changing one aspect at a time, waiting for stability and then changing the next.

However, so many of these elements are tied together that it can be difficult to change just one aspect like design without changing platform the design was changed to accommodate, which in turn affects the URIs. Just understand that the more elements that change in terms of URIs and internal links, the more unstable organic search traffic and sales could be for a longer period of time. An SEO professional that has been through large-scale migrations before can help interpret the data to determine when a particularly concerning decrease is normal or when it’s a sign that some corrective action needs to be taken.

In addition, keep an eye on the webmaster tools accounts to monitor 404 errors. Not all 404 errors are concerning, however. A 404 error could mean a chance to 301 redirect that URI instead, or it could simply be a dead product URL that is intentionally 404ing. Look for an increase in the number of 404 errors post-launch and identify the URIs that are 404ing. Apply 301 redirects where it makes sense to preserve that link popularity and transfer the customer to the right page to transact, and rest easy that the friendly 404 error message is helping the rest of the users find their way through the site.

Migrating a site is always a complex process and should always include an SEO professional. Just as a marketing team wouldn’t dream of replatforming or redesigning without information architecture expertise, the same logic needs to apply to search engine optimization. The stakes are too high in terms of organic search traffic and revenue to risk cutting corners on SEO.

Jill Kocher Brown
Jill Kocher Brown
Bio   •   RSS Feed