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 (any pages that are critical for search engine access, any that are not?)

AMP Page Specific Tasks

  1. Each non-AMP page (i.e. desktop, mobile) should have a tag pointing to the corresponding AMP URL.
  2. Each AMP page should have a rel=”canonical” tag pointing to the corresponding desktop page.
  3. Any AMP page that does not have a corresponding desktop URL should have a self-referring canonical tag.

eCommerce Specific Tasks

  1. Do category pages contain indexable links to the products?
  2. Check faceted navigation, pagination for best practices
  3. If link to image comes before anchor text link, is keyword rich ALT text used?

WordPress Specific Tasks

  1. Redirect URLs in WordPress on Dev site using Simple 301 Redirects Plugin
  2. Install Google Tag Manager Plugin on WordPress site & CMS and configure it
  3. Set up Yoast WordPress SEO & Yoast Analytics plugins
  4. If you use a CMS like HubSpot – Install & Set Up the CMS plugin
  5. Set up Yoast Analytics

As a separate task, we also create conversion optimization recommendations based on the Dev site to help optimize the new site’s conversions.

How to Prioritize Tasks

The live site to dev site comparison helps you to launch the new site while minimizing the effect on your current traffic.

As you create a list of fixes for the development website from this migration checklist, keep in mind that launching a worse site (in terms of SEO) is what is most likely to harm your traffic potential.

We’d urge you to ensure that, at a minimum, the new site is “on par” with the previous site to reduce the risk of traffic drops post-migration. Any fixes that help establish parity between the old and new site should be prioritized as a necessity.

And if your goal is to actually grow traffic, try to ensure that there are clear wins/improvements in addition all other factors being equal.

A Warning About Waking the Beast

Finally, if you are a larger, more complex site with any present SEO issues and a long (favorable) history in Google, keep in mind that “on par” is likely not a good enough standard to hold yourself to.

A site migration represents an opportunity for Google to focus on your site in detail, and, rest assured, they do. They may suddenly start noticing things wrong with your site that you’ve been getting away with for years… but suddenly you aren’t getting away with them anymore. We’ve seen this enough times that we’ve nicknamed it: “waking the beast”.

If you have any major issues present: fix them, and do so prior to migration. Otherwise, you risk stepping off your current rankings pedestal to a lower one, and spending the next several months (to years) recovering your existing rankings. 

It isn’t really a separate phase, but at this point: launch the new website!

Phase 4: Launch Checks to Ensure All’s Gone Well

Now, the benchmark data collected from the old site to aid in parity of the newly-launched site comes into play.

Even the best planned migrations can have technical issues.

Data that was prepared to be migrated seamlessly hit an undetected technical snag that changed its parameters or didn’t transfer it through. Another common mistake is accidentally including things that were part of the staging environment, such as the bot-blocking robots.txt code on the live site. Catching such issues early on and fixing them is crucial.

We always make sure to stay on deck when a launch happens or shortly after to verify that everything is functional and working properly.

With all of the many moving parts and URLs that are typical to eCommerce stores, we’ve found that the earlier things get fixed the better.

Step 1. Site Crawl / Analysis Checks

In this step, you’ll check for matching data between the live site and the staged site:

  1. Verify 301-redirects were all properly implemented:
    • Run a redirect chain report in Screaming Frog
    • Identify redirect chains
    • Use the crawl file from Phase 1 to verify all known URLs correctly 301 to the expected, 200-status code pages
  2. Crawl the new site to identify technical issues and accessibility. 
  3. Ensure the new live site is not blocked from being crawled and indexed.
    • Check robots.txt
    • Look for noindex tags in site crawl
  4. Verify that a “Nofollow” tag was added to pages you don’t want indexed. These should have been identified on the dev site, such as on faceted navigation links.
  5. Make sure the “index, follow” meta tag is on each page as necessary
  6. Look for 404 pages that shouldn’t be there
  7. Check internal links: Look for broken links, AND links to the Dev site
  8. Verify proper implementation of canonical tags
  9. Check for canonicals and duplicate URLs (“www” vs non-www, “http” vs “https,” /trailing-slash/ vs. /non-trailing-slash URLs)
  10. Check Title Tags (match to old data)
  11. Check Meta Descriptions (match to old data)
  12. Check H1, H2 usage (match to old data)
  13. Check IMG ALT attributes (match to old data)
  14. Check word count (match to old data. Account for all template text within <body> tags)
  15. Check internal link counts by page (match to old data; are any critical pages losing links?)

Step 2. Google Analytics / Search Console Checks

Now you can see what data Google has registered for the new site:

  1. To ensure its accurate: verify analytics code is on all pages, and that the correct code is implemented
  2. Update goals in analytics; verify they are working correctly
  3. Annotate analytics with the date the site launched

Step 3. Site Speed Check

  1. Run a few pages through the site speed tool. Compare to site speed on old site & dev site
  2. Make notes for improvement, if applicable

Step 4. Other Tasks

  1. Did the site change servers? Make sure there are no server-related issues
  2. Compare top landing pages; before and after (title, meta description, headers, page content etc)
  3. Verify 404 pages return a 404 status
  4. Verify old XML sitemap is on new site; re-submit to Google Search Console & Bing Webmaster Tools
  5. If the domain is changing, claim the new domain variations in GSC and submit a change of address request.

Phase 5: Site Monitoring Over 1-2 months

Now, the benchmark data collected from the old site to aid in parity of the newly-launched site comes into play.

To minimize a traffic drop, the priority is to look for organic traffic decreases. If there are any, dig into why and where they are happening.

For example, are the traffic drops widespread, isolated to a few pages, or affecting just one section of the site?

Knowing where the drops are happening clues us into what is broken that needs fixing.

We recommend to monitor new websites periodically: 1 week, 2 weeks, 1 month, and 2 months after launch to ensure that everything is going smoothly and correct anything that isn’t.

Sometimes monitoring should go on even longer because the bigger and more complex the site, the longer you’ll need to monitor its indexation.

1 Week Post-Launch

  • Monitor Google Search Console (crawl stats, rankings, traffic, indexed pages, etc.)
  • Check GSC for new indexed pages (and check for any that haven’t)
  • Check the old GSC profile to ensure the old pages are getting de-indexed
  • Leave old XML sitemap(s) up for Google to re-crawl 

2-3 Weeks Post-Launch

  • Monitor Google Search Console (crawl stats, rankings, traffic, indexed pages, etc.)
  • Remove the old XML sitemap(s). Replace them with the new XML Sitemap(s)
  • Check the sitemap.xml file. Are the correct URLs in there? (no extraneous URLs, no Dev URLs etc)
  • Submit the new XML sitemap to Google Search Console & Bing Webmaster Tools

1 Month Post-Launch

  • Monitor Google Search Console (crawl stats, rankings, traffic, indexed pages, etc.)
  • Check analytics for loss of traffic. If so, which pages lost traffic and why?

2 Months Post-Launch

  • Continue to Monitor Google Search Console (crawl stats, rankings, traffic, indexed pages, etc.)
  • Most migrations typically see a dip and rise in traffic after launch. That said, every site and migration is different, so the actual impact is hard to predict. At Inflow, we work to negate any drops prior to site launch and the result tends to be steady traffic or sometimes gains.
  • The best bet is to follow this process. Doing so ensures that the data of the new site remains indexed by Google and thus visible to potential customers.

Conclusion

We know that this checklist seems comprehensive and technical, but believe it or not we could go on. There are so many unique situations to consider that are individual to specific eCommerce websites when they migrate.

A successful migration is definitely worth it for many businesses, and to keep its value in doing so, it’s important to get the technical aspects of migration right.

This migration checklist is something we developed to help make migrating as streamlined as possible, and make sure the new site is launched on time.

We believe anyone knowledgeable in SEO should be able to execute on the above process, That said, this checklist was originally something that we developed for our internal team.

If your team isn’t highly technical, we highly recommend you enlist our help to migrate your store! We’ve handled all kinds of situations to help make sure our clients’ ducks are in a row before migrating.

Contact us to learn more and get our recommendations for your migration scenario.