WordPress to Shopify migration: the timeline that doesn't lose your SEO

You are on WordPress, or WooCommerce, and the platform has become a tax. It is slow. The plugins break every quarter, your developer charges $200 an hour to keep it limping along, and every update is a small gamble. So you have decided to move to Shopify, and everyone says the migration will be fine.

Then you read three case studies of brands that lost 30 to 40 percent of their organic traffic in the 90 days after launch and never recovered. The fear is real. But the loss is not inherent to migration — it is inherent to how most migrations are run.

The brands that lose traffic skip specific things at specific stages. The brands that hold their traffic follow a sequence. A migration done correctly has five distinct phases, each with work that protects your SEO equity — and most agencies do phase three, the build, brilliantly while skipping phases one and five entirely. That gap is exactly where the traffic goes.

This post walks the whole timeline, all five phases, from the pre-migration audit through the 90 days after launch. At each phase you will see what should happen, what to verify, and what most agencies skip. By the end you will know whether the migration you have been quoted protects your traffic or just gets the store launched. Launching is the easy part; keeping everything that made the old store rank is the hard part.

Why most migrations lose traffic

When you migrate from WordPress or WooCommerce to Shopify, you are not just moving products. You are moving every URL Google has indexed, every backlink pointing at those URLs, every piece of structured data, and every signal Google uses to decide how authoritative your domain is. If those signals get severed at cutover and are not re-established within the first 30 to 90 days, you lose ranking.

Here is the part that surprises people: the loss is rarely a single catastrophe. It compounds. One URL does not redirect properly, so it 404s. The 404 tells Google that link is dead. The credibility of the page that linked to it slips a little. Multiply that across 200 URLs and the cumulative authority loss is real — and quiet. By the time it shows up in your traffic, three months have passed and recovery takes another six.

So the "20 to 40 percent traffic loss" you read about in case studies is not a Shopify problem. It is a process problem. Done correctly, organic traffic typically holds within about 5 percent of its pre-migration baseline through the cutover and recovers fully within 60 to 90 days. Done badly, you lose a quarter of your revenue channel for a year. The five phases below are how it is done correctly.

Phase 1: Pre-migration audit (weeks 1–2)

What is happening: before a single page of the new store is built, the existing store gets fully audited. This phase is invisible to you as the buyer, which is exactly why it is the first thing cut for time. It is also where SEO preservation succeeds or fails — everything in the later phases depends on what gets catalogued here.

What to verify or do. Run a complete URL crawl of the existing store — every product page, category, blog post, and landing page — with Screaming Frog or an equivalent, and export the full inventory. Pull the top 50 to 100 URLs by organic traffic over the last 12 months; these are non-negotiable, because if they break you lose the most measurable revenue. Pull the top 50 by backlink count separately; those carry the most authority into the new domain. Catalogue every piece of existing schema — product, organization, breadcrumb, FAQ, review — because each one has to be reproduced on the new store. And inventory every third-party integration: email, reviews, subscriptions, payment, analytics. Some will rebuild on Shopify; some are incompatible and need replacing.

What most agencies skip: the URL-by-URL inventory. They take a sample, build the store, generate pattern-based redirect rules like /product/* to /products/*, and call it done. But pattern rules miss every URL that does not fit the pattern — and those odd URLs are where your long-tail traffic lives. Without the full inventory you cannot verify the redirect map is complete, and without verification you discover the gaps a month after launch, when ranking has already dropped.

Phase 2: Architecture and redirect planning (weeks 2–4)

What is happening: the new Shopify architecture gets designed in parallel with the redirect strategy. This is where the team sets the URL structure for the new store, maps every old URL to its new equivalent, and decides which content carries over and which gets replaced.

What to verify or do. Design the new URL structure deliberately — Shopify's defaults are not automatically right for SEO. If your WordPress URLs were keyword-rich, like /best-protein-powder-for-women/, Shopify's /products/ pattern is shorter but loses that keyword density unless the handle preserves it. Build the full redirect map, one old URL to one new URL wherever possible, and load it through Shopify's bulk redirect tool or a CSV. Verify each redirect is a 301, not a 302 — a 302 passes only partial authority, a 301 passes it in full. Plan the content migration rather than auto-importing it: review each blog post and page, update what is stale, and preserve the internal linking. Map every schema type to its Shopify equivalent. And decide what to leave behind — sometimes the cleanest path is moving the store to Shopify while keeping a content-heavy blog on WordPress under shared navigation.

What most agencies skip: the deliberate URL-structure decisions. They accept Shopify's defaults because changing them is fiddly, and the result is a new URL pattern that no longer matches the keywords your old URLs ranked for. Nothing looks broken. The ranking signal just quietly weakens, and you spend the next two quarters wondering why.

Phase 3: Build and content migration (weeks 4–10)

What is happening: the new Shopify store gets built. This is the most visible phase to you, and the one agencies do best, because the deliverables are tangible — you can watch the store take shape. It is also where the SEO work either happens or does not, behind the visible build.

What to verify or do. Implement the redirect map before launch, not after, so it can be tested against the live old store; loading redirects at cutover means you find the errors when real traffic hits them. Reproduce every schema type on the new store — product schema with reviews, organization schema with sameAs, breadcrumb, FAQ — and validate each page type before launch. Set up the new sitemap and confirm it includes everything you want indexed and excludes what you do not, like archived collections and test products. Check canonical tags, especially on filtered collection pages, where canonicalization breaks most often. Set up tracking — GA4, Tag Manager, Meta Pixel — on staging and confirm events fire before go-live, because most post-migration analytics gaps come from rushed cutover setup.

What most agencies skip: the internal-link audit on imported content. Auto-imported WordPress posts carry dozens of internal links to old URLs, unchanged. The moment the old domain is decommissioned, those become internal 404s — and that is the single most common reason a migrated blog section loses its ranking. Every old-to-old internal link has to be rewritten to point at the new equivalent. It is tedious, it is never demoed, and it is the difference between a blog that holds its traffic and one that quietly bleeds it.

Phase 4: Cutover and launch day (week 10–11)

What is happening: the new store goes live, DNS switches, and the old store either redirects to the new one or stays as a fallback. This phase is short — usually under 24 hours from go-live to stable — but it is where panic lives, and rushed decisions under panic are what damage SEO.

What to verify or do. Run the cutover at a low-traffic time: not weekday US business hours, not Friday afternoon, never during a high-spend campaign or a product launch. The moment DNS propagates, verify the redirect map is firing — crawl the top 100 URLs from your original inventory and confirm each one 301s to its new home and returns a 200, not a 404 or a 302. Submit the new sitemap to Search Console immediately rather than waiting for Google to notice the change, which can take weeks. Confirm analytics is recording on the new store, ideally with a test purchase to check conversion tracking. And keep the old store, or at least its analytics and Search Console history, accessible for at least 90 days — you will need that data to confirm traffic is recovering.

What most agencies skip: real-time monitoring of the first 48 hours. They launch, declare victory, and move on. But the errors that surface in those first two days — the redirect gaps the audit missed, the schema that did not transfer — are precisely the ones that compound into traffic loss if they are not caught immediately. Watch Search Console for crawl errors and 404s in real time while the change is fresh.

Phase 5: Post-launch monitoring (the first 90 days)

What is happening: this is the phase that decides whether your traffic actually recovers, and the one most agencies treat as someone else's job. The contract ends at launch, the team moves on, and no one watches the 90 days that determine whether traffic recovers.

What to verify or do. Track organic traffic against the pre-migration baseline weekly; a swing of 10 percent in week one is normal, sustained loss after week four is not. Watch Search Console daily for the first two weeks, then weekly — coverage, redirect status, indexation rate, and Core Web Vitals are the four signals that matter. Track which old URLs are still pulling inbound traffic and where they send people; a top backlinked URL that 404s is a redirect gap, and you fix it the day you find it. Monitor ranking for your top 20 commercial-intent keywords weekly, because a sustained drop means that page's URL or schema did not transfer cleanly. Resubmit any URL that falls out of the index through URL Inspection. And at the 60-day mark, run a full re-crawl and compare it against the pre-migration crawl — no orphan pages, no broken internal links, no missing schema.

What most agencies skip: the entire phase. The brand is handed the keys at launch and left to monitor on its own, usually without the tools or the experience to spot a recovery problem. By the time anyone notices traffic is down 30 percent, it is three months later and the damage has compounded. The fix that would have taken a week at day 14 takes six months at day 90.

What this means if you're evaluating a migration quote

Seeing the migration as a timeline changes how you read a quote.

Ask the agency for their phase-one deliverables specifically. If they cannot show you a URL inventory and a redirect-map template, they are skipping the audit — and you now know what that costs. Ask what their post-launch monitoring includes; if the answer is "we hand it off at launch," they are skipping phase five, which is exactly where most traffic is lost.

Listen to how they talk about time. An agency that quotes "we will migrate you in six weeks" is usually pricing phase three alone — the build. An agency pricing the full job talks about the pre-audit, the cutover monitoring, and the 90-day window after launch, because that is where the work actually is.

And be suspicious of a number that looks too low. A sub-$10K quote for a substantive migration is almost always priced for the build only. The phase-one and phase-five work either does not happen, or it gets billed later when the problems surface and you are paying to recover traffic you should never have lost. The cheap migration is rarely the cheap migration.

Realistic timeline expectations

Cost is one filter on a quote. Time is the other.

In calendar time, a real migration runs roughly like this. A small store — under 100 SKUs, light content, standard integrations — is 8 to 10 weeks for phases one through four. A medium store — 100 to 1,000 SKUs, a real blog, custom integrations — is 12 to 16 weeks. A large store — 1,000-plus SKUs, heavy content, B2B or subscription complexity — is 16 to 24 weeks. Phase five monitoring then runs 90 days past launch regardless of store size.

Use those numbers as a filter. Anyone quoting under six weeks for a substantive migration is skipping work, and you now know which phases. Anyone quoting over 24 weeks for a standard DTC migration is probably overcomplicating it. Most legitimate migrations land in the 10-to-16-week window — long enough to do phases one and five properly, short enough that the build does not sprawl.

Where to start

If you are evaluating a migration and the agency cannot give you clear answers on phases one and five, that is where your traffic will go. We run migrations end to end on this timeline — including the pre-audit and the 90-day post-launch monitoring most agencies skip — because losing your organic traffic in the middle of a replatform is the most expensive way to launch a new store. If you want a real read on whether your migration plan protects your traffic or just gets the store live, the next step is a migration risk assessment: a 15-minute fit call where we tell you honestly what we would do differently, before anything moves.