The Reluctant Guide to Shopify Migrations

Act V: The Appearance of Completion

The 4-6 Week Danger Zone

Four weeks after launch, the SEO team pulls the rankings report, and the room does the thing rooms do when a number is wrong: it gets very quiet and then very loud. Non-brand traffic is down twenty-eight percent. Brand traffic looks fine—people who already know your name are still finding you, still typing it into the search bar, still arriving. So the dashboard that an executive glances at on the way to a meeting looks survivable. It is the other dashboard, the one nobody glances at on the way to anything, that is on fire.

There are six days until the monthly executive review. Somebody is going to have to stand up in that room and explain a number, and the honest version of the explanation is that the body lost a quarter of its blood supply three weeks ago and nobody noticed because the patient was still talking.

We have stood in versions of this room more than once, and we would prefer not to stand in another. So this is the chapter that exists to keep you out of it. Not to scare you—the dip is preventable, which is a much more useful thing to know than that it is common—but to be honest with you about where the danger actually lives, which is almost never where the panic points.


Here is the first and most counterintuitive thing, and it is going to sound like an evasion until you have lived through the alternative. SEO fails less often in code editors than in project plans. The redirect map is rarely the thing that breaks. What breaks is the decision, made cheerfully in a planning meeting eight weeks earlier, to improve the URL structure while we’re in there—to consolidate the blog, to rename the category taxonomy, to finally fix the product-handle convention that has annoyed everyone since 2019. Each of those is a fine idea. Each of them is, individually, an improvement. And every one of them, shipped on the same day as the platform migration, is a way of changing so many things at once that when the traffic moves you will have no way of knowing which change moved it.

So here is the motto, and it is the one this chapter is built around, and you should write it on something you will see again. Change as few things as possible during the migration. Fix the rest later, when the changes are safe to make in isolation and you can actually read what they did.

If that sounds familiar, it should. It is the same warning that ran through the discovery chapters and the scoping chapters earlier in the book, wearing different clothes. Back then it was the while we’re at it problem—the wishlist that became a loyalty program, the someday-portal that became a line item, the way every migration grows a second migration inside it the moment someone says “while we’re at it.” SEO is where the while we’re at it impulse does its quietest and most expensive damage, because the cost doesn’t show up in the build. It shows up four weeks later, in the report nobody glances at, in the twenty-eight percent.

The discipline is the whole chapter. Everything below is just the discipline, applied to the specific places it gets violated.


You cannot protect what you have not measured, and the single most common reason a migration’s SEO goes sideways is that the team never wrote down what “fine” looked like before they touched anything. So before launch—well before, while the old platform is still happily serving every page it has ever served—you build the baseline. Treat baselines as a contract with the business: this is what we had, dated and signed, and here is what we have now, and the difference between those two numbers is the conversation, not a vibe.

The baseline is not one number. It is traffic and revenue broken down by template, by channel, by market, by device, so that when something moves you can see which something. It is rankings, head terms and long-tail both, captured per template so a category-page problem doesn’t hide behind a healthy homepage. It is a crawl and a Google Search Console export that together tell you what is indexable and what isn’t, where your canonicals point, which duplicates are being collapsed, which parameterized URLs and paginated series exist, and how much index bloat you are quietly carrying. And—this is the part that turns a spreadsheet into a strategy—it is the ten-to-twenty percent of URLs that drive eighty percent of your organic value, named explicitly, alongside the external backlinks you cannot afford to break. Date every report. A baseline without a date is a rumor.

Two hands pressing flat a large, heavily-creased paper map on a wooden table, one corner damp and curling upward.
The baseline. Dated, signed, and nothing like a vibe.

The reason to do all of this before launch, rather than reconstructing it afterward from memory and grief, is that afterward you will be doing it in a hurry, with an executive review on the calendar, trying to prove a negative about a number that has already moved.


Once you know what you are protecting, the protection itself is mostly one thing done with enormous care. Your URL structure is your site’s skeleton. Change it without a precise redirect plan and the body collapses—and a redirect plan is precise only when it is one-to-one. Every old URL that earned anything points at the single new URL that now does that job. The old product page goes to the new product page. The old category goes to the new category. The old article goes to the new article.

An anatomical skeleton assembled from metal pipe sections and road-sign arrows, standing upright with one arm extended, casting a long shadow.
Your URL structure is your site's skeleton. Treat it accordingly.

What it does not do—what is, in fact, the rank-killer that shows up by name in every post-mortem we have ever read—is dump. Blanket-redirecting a few thousand orphaned product URLs to the homepage because it was easier than mapping them, or sending an entire deprecated category to its parent because “close enough,” is not a redirect plan. It is a way of telling the search engine that all of those pages were interchangeable and none of them mattered, and the search engine will believe you. Homepage and category dumps are rank-killers. The shortcut feels like cleanup. It reads, to a crawler, like a mass extinction.

The fiddly bits matter too, and they fail silently, which is worse than failing loudly. Normalize trailing slashes, casing, and file extensions, and pick one canonical form rather than letting three versions of every URL coexist and compete with themselves. Preserve UTM parameters through the redirect chain so the marketing team’s attribution doesn’t quietly go dark the same week the traffic does. None of this is glamorous. All of it is the skeleton.


There is a second category of damage that is sneakier than redirects, because it doesn’t announce itself even in the crawl. Content is the oxygen of SEO, and content is exactly what gets accidentally pruned when templates change. A new product template that forgets to render the long description. An H1 that was hand-tuned on the old platform and comes across as the bare product title on the new one. Alt text that lived in a field the migration script didn’t map. Meta titles that get regenerated from a default pattern because nobody told the theme otherwise. Each omission is small. In aggregate they are the difference between a page that ranks and a page that is technically present.

And here is where the motto earns its keep again, because the instinct, upon discovering that the old product descriptions were mediocre, is to fix them while we’re at it. Don’t. If there are content fixes to make—and there always are—do not make them during the migration. Note them. Park them in the post-launch roadmap where you can make them deliberately and measure what they did. Rewriting two thousand product descriptions in the same release that moves the platform is not an improvement; it is a way of guaranteeing that when something moves you will never know whether it was the platform or the prose. Change as few things as possible. Then, later, change the next thing, and watch it.


Some of what looks like a constraint when you arrive on Shopify is actually a gift, provided you stop fighting it. Treat platform-native constraints as upgrades. Shopify’s URL structure is fixed—you do not get to invent your own pathing convention, and engineers arriving from a bespoke stack mourn this for about a week. But the fixed structure is also one fewer thing to get wrong, one fewer place for the redirect map to develop a creative interpretation. Spend the energy you would have spent customizing URLs on the thing that actually compounds: lift your Core Web Vitals. The platform hands you a fast, predictable foundation; the work is not to redecorate the skeleton but to make the whole body quick on its feet.

A few more things belong in this pass, and they belong before launch, not after. Generate clean, modular XML sitemaps rather than one monolith that times out on crawl. If you sell internationally, validate your hreflang annotations until they are boringly correct, because hreflang that is subtly wrong is worse than none at all—it tells the search engine to serve the German page to the French market with great confidence. And recreate your structured data: the JSON-LD that powered your rich results on the old platform does not migrate itself, and a product that loses its price-and-availability markup loses the thing that made it stand out in the results page.


There is a Shopify-specific trap here that has bitten enough teams to deserve its own warning, because it makes the most diligent move on this list—auditing the staging site before launch—fail in a way that looks like the audit is the problem. For a long time Shopify could not reliably distinguish a legitimate crawler from a malicious one, which meant the SEO tools you would naturally point at your store to validate it—the crawlers, the audit suites, the rank trackers—could find themselves blocked at the door alongside the bad actors. You would run the audit, get a garbled or empty result, and have no idea whether your site was broken or merely defended against its own inspector.

Shopify has since shipped support for Web Bot Auth, which gives well-behaved crawlers a way to prove they are who they say they are, so the better tools can now complete their audits. The practical instruction is to confirm your audit tooling actually authenticates and actually completes against the store before you trust a clean report—a clean report from a crawler that got turned away at the door is not a clean report, it is a closed door.

And do the audit on staging with a production-like robots.txt, as a dry run, before launch. The staging environment will have been locked down to keep it out of the index—as it should be—but a staging crawl run against a permissive or a fully-blocked robots configuration tells you nothing about how the live site will be crawled. Make the dry run resemble the real thing closely enough that its results mean something. (This is a near cousin of a warning that gets its own chapter shortly: the staging store that looks like production and isn’t. The SEO version is simply that a robots.txt which differs between staging and production turns your final pre-launch crawl into a rehearsal of the wrong play.)


Then you launch, and the chapter’s title arrives. The first four-to-six weeks after launch is the danger zone, and it has that name because it is the window in which everything that is going to go wrong has already gone wrong but has not yet finished showing up in the numbers. Search engines need time to recrawl, to re-evaluate, to redistribute the authority you either preserved or squandered. The damage is done on day one. The evidence arrives on day twenty-eight.

The Migration Newt, a small anxious salamander with huge worried eyes, perching on the edge of an oversized coffee mug and staring at a wall calendar with one week circled.
Day twenty-eight. The evidence arrives on schedule. The newt has known for weeks.

So you watch, daily at first and then weekly, with a specific list and not a general anxiety. Crawl errors, because a spike means the search engine is hitting walls you didn’t know you’d built. Redirect health, because a redirect that worked in the staging dry run can break under real traffic and real edge cases. Indexation, because the count of indexed pages climbing or collapsing tells you whether the new site is being absorbed or rejected. Rankings, watched per template so a problem can’t hide. Sitemap status. Core Web Vitals under real load rather than synthetic.

And watch non-brand first. This is the single instruction that would have saved the team in the cold open. Brand traffic—people searching your name—is loyal and slow to react and will keep arriving for weeks after the floor has fallen out from under everything else, which means brand often masks issues. A topline traffic number that blends brand and non-brand can look reassuring while the non-brand half, the half that represents people discovering you for the first time, quietly craters. Split them on day one. Then watch the half that can actually hurt you.

Paranoia and precision protect SEO. Not optimism, not a good vendor, not a clean-looking dashboard. The willingness to look at the uncomfortable number every day for a month, and the precision to have set up the redirects so there is nothing for the paranoia to find.


Assume, because you did the work, that the danger zone passes without incident. The traffic holds. The non-brand line is flat or climbing. You are through. This is the moment the migration tempts you to declare victory and walk away, and it is exactly the wrong moment, because launch day isn’t the finish line—it’s when the real work begins. The platform is now stable enough that you can finally do, safely and one at a time, all the things you were so wisely forbidden from doing during the migration.

That is the post-launch SEO roadmap, and it is where the parked improvements go to finally happen. Internal linking refinement, now that the new structure is settled and you can see how authority flows through it. Backlink reclamation, the liturgy’s tedious final verse—emailing the humans whose links a redirect could not save. Content re-optimization, the two thousand product descriptions you did not touch on launch day, rewritten now in deliberate batches you can actually measure. Schema enrichment, extending the structured data you preserved into the places you didn’t have time to before. Technical hardening, the long tail of small fixes that compound. Ninety days of changing one thing at a time and watching what it does—which is the thing you could never do in the chaos of a launch, and which is, finally, where the step-change in organic growth actually comes from.

Because that is the wager the whole chapter has been describing. Replatforming is one of those moments that can either unlock a step-change in organic growth or erase years of SEO equity overnight, and the difference between those two outcomes is almost entirely a matter of restraint—of changing as few things as possible when the ground is moving, and then changing everything you want, carefully, once it’s still. The teams that lose their traffic are not the careless ones. They are the ambitious ones, the ones who saw a migration and thought while we’re at it. Hold the line through the move. Then go build the thing you were dreaming of, one measured change at a time, on a foundation you can finally trust.

To the SEO lead who has been in the room for all of this and quietly sidelined for most of it—who raised the redirect map in week three and got told it could wait, who asked for the baseline and got a shrug, who is reading this chapter to find out whether the unease was justified: it was. You were right. Print the motto, tape it to the wall above the project plan, and when someone proposes improving the taxonomy on launch day, point at it. Change as few things as possible during the migration. You are not being timid. You are being the only person in the room who can read the report that nobody glances at on the way to anything.