Voiced by Amazon Polly

Public service announcement: Migrating your eCommerce site to a new design, platform, or domain means that you have to be ultra-diligent in executing the move.

Otherwise, you risk a hit to SEO that affects your traffic, conversions, and revenue.

In our experience with helping dozens of eCommerce stores migrate, we’ve seen that a lot of “gotchas” can occur. These are a variety of little errors with the potential to create a big downswing in your organic traffic and rankings.

Most eCommerce migration checklists present a vague list of SEO factors to consider, without giving you a real, strategic workflow to follow that avoids those errors. Fulfilling this checkmark or that checkmark without knowing the strategy and reasoning behind those actions leaves your site vulnerable.

Here, we’re sharing our internal 5 Phase Migration Checklist that we implement for clients who want to protect their SEO from a potential hit after migrating. Review it before launching your new site in order to minimize any potential negative SEO impacts caused by a site migration.

At Inflow, we handle migrations often and are here to help you make sure any SEO impact is minimized. If you’d like us to handle this on your behalf please give us a shout.

What to Expect with a Website Migration

Getting your ducks in a row prior to an eCommerce website migration is crucial for ensuring its continued success.

While a downward bump in SEO is usually to be expected when migrating a site, historically: we’ve observed that fixing errors prior to launch can actually help traffic remain steady. In some cases, it can even help traffic go up by improving the new site’s SEO.

Not all migrations are the same ⁠— things change and it’s smart to consider certain specifics for each scenario when you migrate to:

  • A new design
  • A new hosted or self-hosted platform
  • Or a new domain.

Migrating your website can be a stressful process given its risks.

The goal here is for you to understand how to reduce any organic rankings/traffic drops by adopting an optimized and streamlined SEO migration strategy.

Why Migrate?

If you’re thinking about a migration, it’s important to know why that migration is occurring so you don’t do it superfluously.

It makes sense to migrate in certain situations, including when:

  • You have an old/outdated website design.
  • Your business changes priorities or service offerings, so you need to add new information or change existing information to be more current.
  • You rebrand (this can involve migrating to a new domain when the business name changes).
  • There are problems with your CMS platform and you want to change to a platform with more/different robust features, or a lower cost.
  • Your site just isn’t converting, and you want to start from scratch on a new domain.

What is the best eCommerce platform for SEO to migrate to? In a previous article, we outlined what to consider when picking a new platform to migrate to, so we won’t be covering that here.

Instead, we’re going to get into the nuts and bolts of migrating successfully. Starting with the risks involved.

Before You Start: What Type of Migration Is It?

The risk of impact to your SEO varies depending on the type of migration. Some migration scenarios are more risky than others.

Low SEO Risk: Site Redesign/Reskin

When the extent of the migration is limited to simply changing the design of the website, the risk is relatively low.

When comparing a design change or reskin to other migrations, there is a lower risk of an SEO drop simply because no URLs are changing.

Depending on your team’s experience, it may not be necessary to enlist help from an outside agency to keep SEO protected from a site redesign or reskin.

Side note: Certain designs contain JavaScript that cloaks content. Hiding or “cloaking” content is not something Google tends to like. This type of code is common on spam sites attempting to keyword-stuff their pages without the text visually displaying.

Watch out for such designs containing JavaScript that could trigger inadvertent SEO impacts.

Medium SEO Risk: URL / Changes (With No Platform Change)

You’ll want to monitor things carefully when your domain changes, or when other changes occur that require a new URL structure with abundant redirects.

In this scenario, there is a moderate amount of risk as any URL changes create a risk to your SEO. Your website’s new URLs will need to be indexed.

The goal is to get new URLs indexed quickly by Google post-launch by making them easy to crawl. Whether the actual design changes or not, new URL paths are a fundamental change to a site’s SEO and should be monitored.

Medium SEO Risk Scenario 2: Change in eCommerce Platform

In general, a platform change means that the site’s URLs will also change. This is due to the way that various eCommerce platforms structure their URLs differently.

For example: As a path to products in Shopify’s “collections,” the URL structure has to be domain.com/products/productname or domain.com/collections/collectionname/products/productname

An example of Shopify's URL structure

Meanwhile, WordPress and other CMSs have their own URL structures with different needs. This is why in many cases, maintaining the original URL isn’t possible ⁠— even if you want to.

Changing platforms also presents the risk of losing core functionality that your SEO (or your other marketing channels!) are currently benefiting from. Evaluating and minimizing such a risk is key when migrating platforms.

High SEO Risk: Domain Migration

Regardless of any URL changes or design changes, migrating your eCommerce site’s domain presents a lot of risk.

The problem is that a domain name has a lot of context and history with Google. So, unfortunately when starting from scratch you are bound to lose some equity.

In this scenario, be prepared to do a bit more work to mitigate the SEO impact and pain of losing traffic.

Why change domains in the first place? In this case, the short term hit to SEO should be for a long-term gain ⁠— like a rebranding or name change of the organization.

So, what migration scenario fits yours? Now that you understand the risks, below is a detailed list of all the factors to verify.

Note: Please do not be overwhelmed by the level of detail we’re presenting.

There are many small factors in SEO. Usually, drops happens as a result of multiple little factors going wrong…or one catastrophic miss.

So while the list of checks is numerous, there’s a reason for it:

  • First, to create the optimal website structure for Google to index
  • And second, to catch any potential errors prior to the launch of the new site

Let’s start with Phase 1.

Phase 1: Evaluate Live Site & Opportunities for Improvement. Collect Benchmark Data. 

A very important first step is to review the live site in order to see where everything stands.

Since this is a data migration process from one platform to another, you’ll use the old site’s data as a benchmark for reference and comparison to the new site in a later step.

The goal is to launch the development site with as few discrepancies as possible when comparing its features to the live site.

Step 1. Crawl the Current Domain Using DeepCrawl and/or Screaming Frog

Screaming Frog is a widely used tool and its data output is suitable for this process.

A view of the Screaming Frog Dashboard

We like to use DeepCrawl for larger sites or Screaming Frog as a cheaper and easier option for smaller sites. That said, you can use the crawl tool of your choice.

A view of the DeepCrawl Dashboard

Crawling the current live domain provides us with a list of URLs on the site plus a wide variety of data about those URLs that we can use for checks and benchmarks.

Step 2. Perform Google Search Console Analysis

Google’s own data about your site is important to review.

Data is provided in GSC in a dashboard format, where you’ll:

  • Export .csv data of the site 
  • Does any structured data need carried over to new site?
  • Do hreflang tags need to be carried over to new site?
  • Do any 404 errors need to be addressed pre-launch?

If any data is present that should be transferred, or if any errors exist that Google says should be corrected, that’s a checkbox to mark early on in the process.

Step 3. Crawl and Analyze the Old Site

Now that you have crawl data and Google’s data, you’ll document the following points to be able to reference them in comparison to the new site:

  • Look for Meta robots nofollow tags in source code
  • Document GAID & type of code being used (Universal, GTM)
  • Look for pages with noindex tag
  • Review canonical tags
  • Review Title tags
  • Review Meta description tags
  • Review header (h1, h2 etc) usage
  • Collect all known live URLs (via a site crawl, serp scrape, GSC, GA, etc. as needed) in a file (to crawl & verify working redirects upon go-live).

Often, we’ll look at this data and use it to identify opportunities for optimization of the new site’s SEO as well. It is generally part of the process for doing an SEO content audit.

Step 4. Other Considerations

The data collected from the above steps is necessary regardless of the type of migration.

To double check your relevant migration scenario before doing further work, make sure you have evaluated the characteristics of it so that you can take the proper steps.

To determine the ‘type’ of migration as mentioned earlier, identify if it’s a:

  • Redesign (the site’s design is the only change)
  • URL Changes on the Same Platform (with or without design changes)
  • A Platform Change (usually involving URL & design changes)
  • A New Site on a New Domain

Some other important questions that help determine the risk level of your situation are:

  • Is the domain name changing?
  • Is the URL structure changing?
  • Is the site architecture changing?
  • Have you performed keyword research, created a keyword matrix and/or a keyword gap analysis to ensure a solid keyword strategy is in place?
  • Is conversion optimization a consideration?
  • Do you currently need help selecting a new eCommerce platform, system, software etc? (If so, please reach out to us for help to determine it.)

In the next phases, you’ll identify the needed action steps and fixes to implement to the staging site prior to migration.

Phase 2: Evaluate Stage Site & Technical Opportunities for Improvement

Now, we’ll do the technical work of going through the possible errors (“gotchas”) and take the needed steps to test and address them.

eCommerce sites have many facets that can get affected during a migration.

Revenue is linked to SEO, and a migration presents a risk of impact to it. If there was ever a time to be thorough with a technical checklist: this is it.

Tip: Understand Your Development Timeline

Without the right approach, technical SEO can seem like a never ending process. If the migration is to be completed by the target date, the team needs to have the scope of work and a deadline to help keep things moving.

Structuring the work according to the below outline should help you to do that.

Step 1. Check for Server Changes

Is the server changing?

Ask your developer to host the development site on the new server to identify potential issues. Don’t forget to ask the developer to block search engine bot access to the staging or development sites using the robots.txt file.

Step 2. Establish a 301 Redirect Strategy

To get new URLs indexed, a systematic approach to implementing redirects is a vital step.

To do it:

  1. Formulate a 301-Redirect Strategy using the site crawl data.
  2. Document how the redirect strategy will be implemented, and who is responsible. Everyone should be on the same page on how redirects will be structured and implemented
  3. Are there legacy redirects that need updated? Eliminate redirect hops it’s best to have fewer redirects if possible.

We’ll also be checking for success of the redirects upon launch/migration.

Step 3. Conduct Technical Dev Site Optimization

Remember: we’re trying to get the development site optimized prior to launching it.

Conducting a technical audit is key for success:

  1. Review Sitemaps & Wireframes for new site
  2. Ensure site is being blocked from indexation
  3. Verify a custom 404 error page exists & properly issues a 404 header response. Page title for 404s should always read “Page Not Found” (or similar) so errors can be found in GA, as well (aka those errors that users access)
  4. Crawl the Dev Site; fix 404 and soft 404s
  5. Ensure links/URLs that you don’t want indexed on the dev site are Nofollowed. This would be needed for new faceted navigation, for example
  6. Test redirects (if possible)
  7. Browse the Dev site with multiple devices
  8. Plan for Faster Indexing; Create an XML sitemap (if necessary) with all of the old URLs and plan to leave this up after the site has launched
  9. Test & enhance site speed, as much as is possible for a dev site.

When possible we do a live site to dev site comparison of site speed. But staging environments don’t often have caching setup, or other things that make site’s actual speed visible. 

Since the speed of the dev site is an estimate, enlist the development team to help you see where things are lacking and what you can do to improve it.

Step 4. Determine Analytics Migration Strategy

In this step, we’re essentially preparing to share information about the new site with Google to get it indexed faster.

To do it:

  1. Add the analytics code to the dev site. (Block the IPs of team members accessing this site.)
  2. Goals: Compile a list of URLs to update in the analytics goals when the new site goes live
  3. Check mobile-friendliness of different types of pages on the site
  4. Check that parameters function as expected (and critical tracking parameters aren’t dropped from the URL during a page reload or redirect)
  5. Check parameters report in GSC for duplicate content issues (this feature from the old GSC may not remain around for long)
  6. Check GA to ensure that this website cannot be its own referrer (on the Property level, in Tracking Info > Referral Exclusion List)
  7. Social Media Shares: Compile a list of URLs with highest social counts. Maintain old embed code to keep social counts. If no pages have worthwhile counts, don’t waste development efforts to implement this.

Now, your dev site is further prepared for parity with Google.

Phase 3: Compare Live Site vs. Stage Site to Ensure Parity (or Better!)

To further evaluate the stage site prior to making it live, compare it to the old site to find a list of prioritized discrepancies to fix.

The broad steps for this phase are:

  • Look at the new site, compare to old site,
  • Make a checklist of things to fix with the goal of keeping traffic as close as possible to flat during migration.

Note: Content and mobile site specific tasks will apply to everyone, but some are more specific (for example, if your site has AMP pages or is hosted on WordPress).

Content

  1. Is the site at risk for duplicate content and/or URLs?
  2. Migrate all content to Dev site; is as much as possible staying the same?
  3. Ensure title tags and meta descriptions are being carried over and are the same as or better than the current site.
  4. Check page content, canonical tags, internal linking, usage of H1s/H2s, IMG ALT tags.

Mobile Site Specific Tasks

  1. Crawl as mobile googlebot in Screaming Frog; validate mobile parity among page: titles, descriptions, headers, content, inlinks, images, directives, etc. 
  2. Implement meta=”viewport” tag to <head> section of site <meta name=”viewport” content=”width=device-width, initial-scale=1”>

Javascript Site Specific Tasks

  1. Visually audit all major page types (Fetch & Render in GSC if possible)
  2. Audit HTML source for missing content 
  3. Audit using inspect element for missing content
  4. Compare HTML source vs. inspect element for contradictions
  5. Identify content based on user-interaction (a