The Reach Bureau

Shopify to WooCommerce Migration: The SEO Runbook

Automated conveyor belt system in a modern warehouse representing ecommerce SEO workflow automation at scale
Photo by Hyundai Motor Group on Unsplash

# Shopify to WooCommerce Migration: The SEO Runbook

Rankings survive a migration when the URL work is done properly and fail when it is not. Everything else — theme, plugins, data import — is a build problem. This is the SEO half, in the order it has to happen.

Assume the decision is already made. If it is not, start with should I move from Shopify to WooCommerce.

Before anything: capture the current state

You cannot prove a migration went well without a baseline, and you cannot rebuild one afterwards.

Export, dated and stored outside both platforms: every indexable URL with its organic traffic and revenue for the last twelve months; every ranking keyword with its landing page; the full crawl of the live site; and the current sitemap. Screenshot or export Search Console performance for the same window.

The crawl is the important one. It is the definitive list of what exists, and it will differ from the sitemap and from what the platform’s export claims.

Build the URL map, one row per URL

This is the job. A migration with a complete map is boring; a migration without one is an incident.

Shopify enforces path prefixes — products under `/products/`, collections under `/collections/`, blog posts under `/blogs/` — and WooCommerce does not have to keep them. Decide the destination structure once, then map every URL to its single closest live equivalent.

Rules that prevent most damage: one redirect, never a chain; never point a batch of products at the homepage or a category as a shortcut; retired products go to the closest live alternative, and only to the category when there is genuinely no alternative; keep query-parameter behaviour in mind, because Shopify variant and collection filter URLs exist in the index whether you intended them or not.

Where a page has no equivalent at all, a 410 is more honest than a redirect to something irrelevant, and it resolves faster.

URL mapping rules that decide whether rankings survive a migration: one hop, closest equivalent, no batch redirects, 410 where nothing matches

Preserve what the old platform did for you

Three things are easy to lose in the rebuild.

Canonical behaviour: Shopify products are reachable through collection paths, and the canonicals handle it. Confirm the new site’s canonicals are self-referencing and that no template writes the old domain.

Structured data: theme-generated `Product` and `BreadcrumbList` markup disappears with the theme. Rebuild it, and remember WooCommerce omits `brand` and identifiers by default.

Internal links: hard-coded links in content and menus will point at old paths after launch. Rewrite them in the database rather than relying on redirects, because a site that redirects internally on every click is slow and looks broken to a crawler.

Keep staging out of the index

Every migration has a staging site, and a share of them get indexed. Password-protect it at the server level rather than relying on `robots.txt` or a `noindex`, and check before launch that the staging host is not in the index. If it is, remove it before the new site goes live, or the two will compete.

Launch sequence

In order, on a quiet day, not before a peak:

  1. Freeze content changes on the old store.
  2. Final crawl, final export, final backup.
  3. Switch DNS, confirm HTTPS and the canonical host, and that only one host resolves.
  4. Deploy redirects and test a sample of at least a few hundred rows for status code and destination — automated, not by hand.
  5. Submit the new sitemap; leave the old one accessible until it stops being requested.
  6. Re-crawl the live site and compare against the pre-launch crawl.
  7. Check `robots.txt`, canonicals, structured data and analytics on the live domain, in that order.
The launch sequence in order, and the four things to monitor daily for the first fortnight

The first fortnight

Watch four things daily, then weekly.

Crawl errors and 404s in Search Console — new 404s with traffic are unmapped URLs, and they will appear no matter how careful the map was.

Indexed page count, which should fall then recover as the old URLs drop and the new ones enter.

Rankings for the top fifty pages by revenue, not the top fifty by volume.

Revenue by landing page against the baseline you exported, which is the only measure that answers the question everybody is asking.

Expect a dip. A two to four week wobble is normal while URLs are reprocessed; what is not normal is a decline that deepens after a month, which usually means unmapped URLs or a canonical fault.

What to tell the business before you start

Three expectations, set in advance, prevent the migration being judged as a failure while it is still working.

There will be a dip. Two to four weeks of unstable rankings and revenue is normal, not a sign of a mistake. Saying so beforehand is the difference between a fortnight of iteration and a fortnight of emergency meetings.

Some URLs will be missed. Even a careful map misses a handful, because the index contains URLs that no crawl or export knows about — old campaign paths, parameter combinations, pages linked from someone else’s site. The plan is to catch them in Search Console in week one and map them then.

Revenue by landing page is the measure, not total traffic. Traffic can fall while revenue holds if what was lost was thin informational visits. Agreeing the measure in advance stops the project being assessed on the metric that moves most easily.

Put those three lines in writing before the launch date is set. They are the cheapest risk management in the project.

The checklist

  1. Baseline exported and stored outside both platforms.
  2. Full crawl taken as the definitive URL inventory.
  3. One-row-per-URL map, single-hop redirects, no batch redirects to the homepage.
  4. 410 where nothing equivalent exists.
  5. Self-referencing canonicals; no template writing the old domain.
  6. Structured data rebuilt, including the fields WooCommerce omits.
  7. Internal links rewritten in the database, not left to redirects.
  8. Staging password-protected at server level and confirmed out of the index.
  9. Redirect sample tested automatically for status and destination.
  10. Daily monitoring of 404s, index count, revenue by landing page for two weeks.

Sources

Frequently Asked Questions

Expect two to four weeks of movement. A decline still deepening after a month indicates unmapped URLs or a canonical problem rather than normal reprocessing.
Only when there is genuinely no equivalent product. Batch redirects to a category or the homepage are treated as soft 404s and lose the equity.
No, and you usually should not. Just map every old path to exactly one new one, with a single hop.
An incomplete URL map, followed closely by an indexed staging site competing with the live one.
Leave it accessible until requests for it stop, then remove it. It helps the old URLs get reprocessed sooner.

Want this run against your store? Book a call with The Reach Bureau.

Share with AI

One-minute takeaway Summarize Explain like I'm a kid

Share this article

LinkedIn X Facebook Pinterest Email

Related articles

View all articles

Ready to scale your e-commerce?

Let's discuss your project and how we can help you achieve your growth goals.

Book a discovery call
Book a call with me, here is my schedule →