How to Migrate a Shopify Store Without Losing Rankings
The defining characteristic of this platform for a migration is that addresses follow a set pattern rather than one you choose. That makes some migrations considerably simpler than they would otherwise be, others harder. Working out which of those you are facing is most of the planning.
The Address Structure Is Largely Fixed
Addresses on this platform follow a prescribed pattern. That is neither a limitation nor an advantage. It is a constraint. Constraints make some things simpler and other things impossible.
What it makes simpler. A whole category of decision disappears.
Nobody has to agree an address structure, nobody can accidentally change it and no default can quietly override an agreement. On other systems that single setting is the largest migration risk there is. Here it does not exist, which removes an entire failure mode before anybody starts.
What it makes harder. Preservation.
You cannot keep addresses the platform will not let you choose. A store moving in from a system with a different pattern cannot preserve its existing addresses, which means every one of them changes and every one needs mapping.
Why that matters for planning. It settles the question early.
Moving between stores on the same platform, addresses may be largely unchanged. Moving in from elsewhere, assume they all change. Those are two entirely different projects and the answer is knowable on day one.
What it is not. A search consideration.
None of this says anything about how any platform performs. It describes what a migration involving it requires, which is a different subject entirely.
Product And Collection Addresses
Products and collections are the two things a store has most of. They behave differently enough during a migration to be worth separating.
Products. The individual items.
Each has its own address, generated from its name. Rename a product and the address generally follows, which means an editorial decision made for merchandising reasons can change an address that other sites link to. That is worth knowing outside a migration as well as during one.
Collections. The groupings.
Categories, ranges and curated groups. These frequently carry more search value than individual products, because people search for types of thing more often than for specific items. Somebody looking for a specific item usually knows the brand and goes straight there.
Why the collection point matters most. They get reorganised.
A migration is a natural moment to rethink how products are grouped. That rethinking changes collection addresses. Those are the addresses most worth protecting, so the reorganisation and the mapping have to happen together.
What to establish. Which collections earn the traffic.
From the audit, before anybody redesigns the grouping, per URL mapping for a site migration.
Variants And Duplicate Content
The same product can frequently be reached at more than one address, depending on the route somebody took to it. This is ordinary store behaviour rather than a fault. It is what the canonical annotation exists to resolve.
Why the duplicates arise. Multiple routes.
A product reached through one collection and the same product reached through another can produce different addresses for identical content. Nobody created them deliberately. They are a consequence of products belonging to several groups, which is exactly how a catalogue is supposed to work.
What resolves it. A statement of which address is the real one.
The annotation names the authoritative version, so that whatever the product has earned attaches to one address rather than being spread across several. That is the whole mechanism.
What we will not claim. A penalty.
Plenty of writing asserts that variant addresses are penalised. No published source supports that, so we do not repeat it. The reason to resolve them is concentration rather than avoidance of a punishment.
Why it matters during a migration. The annotations travel.
If they carry across still naming old addresses, they are asserting that the old version is authoritative, which is covered in types of site migration and on our tags guide.
Discontinued Products
Every store faces this constantly and most face it during a migration as well. What happens to the address of something no longer sold is a decision that has to be made, repeatedly, forever.
Why it is not a migration problem. It never stops.
Products are discontinued every month. A store that handles this well has a standing rule rather than a project decision. A migration is simply the moment the accumulated backlog becomes visible, because somebody is finally looking at every address the store has.
The three defensible answers. In order of preference.
Point it at the replacement product where one exists. Point it at the collection containing similar items where one does not. Or let the address stop working, which is sometimes correct and tells the truth.
The condition on the third. The same as everywhere else.
Never for an address carrying external links or traffic, then only ever as a recorded decision rather than by omission. A chosen retirement and a missed address look identical afterwards.
What the migration adds. A chance to set the rule.
Agreeing the standing policy during the project means the next hundred discontinuations are handled without anybody deciding again. Our ecommerce material covers the trading side of that.
Redirect Handling On This Platform
Redirects are handled within the platform itself rather than at server level. That has consequences worth establishing before a mapping is built rather than while somebody is trying to load one.
What is straightforward. Managing them.
They can be created and maintained by whoever runs the store, without needing access to anything underneath it. On a store with no technical staff that is genuinely valuable, because it means a broken address can be fixed the day somebody notices it.
What to establish. Volume and patterns.
How many the platform will hold, plus whether rules can be expressed as patterns rather than listed individually. A migration produces one redirect per old address, which on a mature catalogue is a large number.
Why the pattern question is the sharp one. Scale.
Where every old address has to be listed separately, a large catalogue becomes a manual exercise. Where a pattern can express thousands at once, the same job takes an afternoon.
What happens when it is discovered late. The map gets cut.
Something has to be dropped and it is usually the long tail, which is where the accumulated links sit. The mechanism is in how to implement 301 redirects.
Apps Generate Markup
Added applications produce a great deal of what a store asserts about itself. Removing or replacing one removes whatever it was quietly producing.
What they commonly generate. Assertions about products.
Machine-readable descriptions of items, availability, ratings gathered from customers and the structured information that supports enhanced appearances in results. On a store that is a considerable amount of what search sees.
Why a rebuild disturbs it. The set gets rechosen.
Nobody reproduces the exact collection of applications that existed before. Somebody selects what the new store needs. Anything the old set was producing that nobody knew about simply stops.
The ratings case specifically. Worth stopping on.
Where reviews were gathered by an application, moving away from it can leave assertions about ratings that are no longer connected to anything. Never migrate a rating that cannot be evidenced. Remove it and reconnect genuine reviews properly afterwards.
What to do. Inventory before rebuilding.
Establish what the current set produces so the new build reproduces it deliberately, ensuring anything no longer true gets removed rather than transferred.
What Migrating In Usually Means
Moving a store onto this platform from a different system almost always means every address changes. That is worth stating plainly at the start rather than discovering during the build.
Why it is close to inevitable. Block one.
The pattern is prescribed, so the old pattern cannot be reproduced. Unless the previous system happened to use the same structure, which is unlikely, everything moves. There is no configuration available that changes this and no supplier can arrange otherwise.
What that makes the project. A full mapping exercise.
Every product, every collection, every content page and every leftover address from any previous move. On a mature catalogue that is the largest single task in the migration.
Why saying so early helps. It sets the budget.
A project scoped as a design exercise, discovering in week eight that it also requires thousands of mapping decisions, ends badly. The same project scoped correctly on day one is entirely manageable.
What it does not mean. That the move is unwise.
Plenty of stores move for sound commercial reasons. The address change is a cost of the move rather than an argument against it. It is a cost that can be planned for.
What To Check After
The general launch checks apply as anywhere. Five things are worth verifying specifically because this is a store.
That the highest value collections resolve correctly. First.
These carry more search value than individual products. There are also few enough of them to check individually rather than by sample.
That product redirects behave. By sample and by priority.
Every product on the audit's priority list individually, plus examples of each product type, because failures cluster by type rather than spreading evenly.
That checkout works. The commercial one.
Obvious, urgent and the thing customers report fastest, which means it is also the failure least likely to go unnoticed.
That assertions about products are still produced. And still true.
Particularly availability, pricing and anything about ratings, since each of those is asserted as fact rather than offered as description.
That nothing is telling crawlers to stay away. Within the hour.
The check that outranks everything else on any launch list. The full series is on the website migration guide.
You cannot keep
what you cannot
choose.
The scope settled on day one because a prescribed pattern makes the answer knowable, the valuable collections identified before anybody reorganises the grouping, the platform's redirect volume and pattern support established before the map is built, a standing rule agreed for discontinued items, with any rating nobody can evidence removed rather than transferred.
What a migration engagement covers:
A migration is a one-off project rather than a monthly service, so it is scoped and quoted against the size of the site and how much is changing at once.
Every guide.
One practice.
What a migration is, the types, when to do it, planning, the checklist, auditing, mapping, redirects, internal links, tags, downtime, crawling, structured data, performance, notifying, monitoring, recovery and the mistakes.
