Over the last years, I’ve worked with clients in need of an SEO consultant for their web migrations. Usually, these were a change of URL structure or a change from HTTP to HTTPS.

I was contacted by the owner of a small business in the beauty industry asking if I can help them with their CMS migration.

The client arranged a call with, the development and design agencies he was working with. The web migration was just about to start and was due to happen in 2 days.

Taking into consideration that this was a fairly complicated web migration for an e-commerce site moving from Shopify to Woocommerce it’s almost impossible to do all the SEO planning in 2 days.

In this post, I’m going to detail the outcome of this web migration as well as the challenges faced during the process.

[TOC]

Planning the Web Migration

During the first call with the client and the two other agencies working on this project, I asked if the web migration could be delayed a couple of weeks since 2 days is not enough time for me (or any other SEO!) to do all the required SEO planning.

After 1 hour of negotiations, the client accepted to delay the web migration 3 days more. Now I had 5 days to assess the SEO impact and plan the redirects implementations ASAP.

First, I crawled the website with Sitebulb and found several duplicated product pages (something to be expected when working with Shopify sites). There were product pages for each category: “/product-category-x/product-y”, and finally the “original” product URL: “/products/product-x”.

The site had a discounts page that listed the products that currently have a discount. These products had also a duplicated URL that looked like this: “/collections/discounts/product-category-x/product-x”.

Similarly, the featured products that appeared on the home page had a URL that looked like this: “/collections/homepage/product-category-x/product-x”.

I also found that the about and contact pages had a URL that used “/pages/” as a prefix. For example, “/pages/about-us”, instead of being just “/about-us”.

This is not the way I would recommend structuring the site, every product page should be unique and be “inside” its product category, and the normal pages don’t need to have the “/pages/” added as a prefix.

So far, the URL structure was the main issue to fix on the new site. The duplicate titles and H1s should be fixed when we eliminate those duplicated product pages.

I also found several page speed issues, mainly because the product images were over 1MB. This became worse on pages that needed to load 2 or more product images.

Before Launching the Migration

The URL structure I recommended to the development agency is the following:

• For product pages: “/products/product-category/product-x”
• For category pages: “/products/product-category”
• For normal pages: “/page-name”

Of course, the main shop page with all the products would be “/products”.

The development agency and I agreed that the category pages created by WordPress are not so useful and somewhat hard to customize.

Instead of trying to customize the default product category pages, they created new pages for each category so they could customize them with Elementor.

The category pages created by WordPress, as well as the product tag pages, were noindexed.

While the product category pages were being created, the design agency was optimizing the existing product images. Since the old product images weighed more than 100KB, the new product images weigh on average 35KB.

I used Sitebulb’s URL explorer to export all the URLs to Google Sheets and started to map the redirections that needed to be implemented.

Since the new website was going to be hosted in WordPress, I asked the development agency to install the Redirection plugin because implementing every single redirection on the .htaccess file was impossible due to the high amount of redirects.

The Google Sheets file looked like this:

This will then be exported as a .csv file that could be easily imported to the Redirections plugin and have the redirects implemented in a few seconds.

Normally, I would use Google Analytics and Search Console data during the Sitebulb crawl so I can identify the pages that were bringing the most organic traffic, the ones that have high impressions and CTR, etc, to identify which pages were going to be kept or eliminated.

This step was avoided because the client created the website in Shopify 3 months ago, no Google Analytics was installed and no SEO efforts were made at the time.

I asked the development agency for the URL of the testing environment so I could validate that the redirects were working correctly and fix anything that was wrong before launching the new site.

Unfortunately, the development agency was using a local server on their computer so it was impossible for me to crawl it and test the redirects behaviour, the new URL structure, missing pages, broken internal links, etc.

Launching the migration

We all agreed to launch the new site on Saturday because the client said that it was the day in which the traffic to the site was lower.

While the development agency was moving the domain to their server and installing WordPress to move the new site, I was waiting for confirmation on the live site so I could run a Sitebulb crawl and find any issues that needed to be fixed.

Once the site was live I only found a few broken internal links from the navigation menu and a few pages missing meta descriptions.

I used the HEADMasterSEO tool to validate the redirects, I only needed to upload a .txt file with all the URLs that were going to be redirected and another .txt file with the rules of the redirect. For example: /from-url-1 /to-url-2.

Once you upload these files to the tool, it starts to validate if the URLs in the first file are present in any redirect rule of the second file and validates that they redirect to the specified URL.

The first column indicates PASS or FAIL according to the URL behaviour, the URL that it is redirecting, the status code, response time and the URL that it redirects to.

There was only one URL that failed the test, the 301-redirect was implemented but on the wrong URL, it was a non-existing URL that returned a 404 error.

This way, I was able to quickly identify any errors and ask the development agency to fix them right away.

Conclusions

Even though this CMS web migration was done in a few days, it wasn’t that hard to do because the site is relatively small (excluding the fact that each product had different URLs).

It would’ve been harder if the site had more time of being live with a decent amount of organic traffic because that would have required an additional analysis to identify which pages to keep and which ones weren’t bringing any value.

The main challenge here was to deal with a web migration with two external agencies involved. Because of my technical background and experience, I was able to communicate well with the development agency by explaining what to do, how and on which URLs.

Now, the site is up and running with an optimized URL structure and a lower page speed. It was the first time that I had to deal with an external development team and I thought it was going to be very difficult but it turned out very well.

If the client would’ve never thought of SEO, I don’t know what URL structure would the development agency have used and the page speed would have been the same or higher.

The improvements made on the website made the client realize the importance of SEO, without me or any other SEO consultant the site would’ve not been optimized and these results wouldn’t have been achieved: