How to move your store without losing your Google rankings
The biggest fear before switching platforms is not about products or orders. It is that the morning after the migration the phone stops ringing, because Google can no longer find your store. The good news: it is a fear of one well-documented mistake.
Organic traffic disappears after a migration for one reason: the old URLs stop existing, and the new ones don't tell Google they are their successors. 1:1 URL mapping and 301 redirects take care of most of it on switch-over day. The rest is the order of steps - and looking after your URLs after the migration, because every product rename creates a new URL and the old one has to lead somewhere.
Why stores lose their rankings
Google doesn't punish you for changing platforms. Google gets lost when the URL where your best-ranking category has lived for three years suddenly returns a 404 error - or, worse, redirects to the home page.
All the search engine sees then is this: a page that had authority is gone. The new page at the new URL is, to Google, a new page - no history, no links, no rankings. Rebuilding takes months.
The whole art of migration is telling Google one sentence: "this is not a new page, it is the same page at a new address". A 301 redirect is how you say it.
Step 1: list everything that gets traffic
Before you move anything, pull the list of URLs that actually do something for you:
- Google Search Console - the performance report, every URL with impressions over the last 12 months.
- Analytics - landing pages with organic traffic.
- Sitemap - the full list of products, categories and posts.
Sort by traffic, descending. It usually turns out that a few dozen URLs bring most of the traffic - and those are the ones to be most careful about. The rest of the long tail matters too, but it won't decide whether the migration hurts.
Step 2: map 1:1, not "roughly"
Assign exactly one new URL to every old one. Not the parent category, not the home page, not "something similar".
| Old URL | New URL | Code |
|---|---|---|
| /product/black-oversized-hoodie | /black-oversized-hoodie | 301 |
| /category/mens-hoodies | /mens-hoodies | 301 |
| /blog/how-to-care-for-cotton | /blog/how-to-care-for-cotton | unchanged |
Redirecting a product to the home page is technically correct and practically useless. Google will treat it as "this page no longer exists", and a customer who clicked a search result looking for a specific hoodie lands on a welcome banner and leaves.
If the product really is gone - redirect to the category it was in. That is the closest to the truth you can get.
In DoSwiftly you upload this list as a CSV file with two columns - old URL and new URL - in the admin panel, in the store settings, on the URL redirects tab. The header row is optional, and uploading the same list again does not create duplicates, so you can build it up in batches. The platform also watches three things that are easy to miss in a spreadsheet: it rejects entries that would lead in a loop, it shortens chains (A leads to B, B to C - it stores A straight to C) and it triggers a redirect only when there really is no page at the old URL. An agency doing the migration for you can upload the same list via the API, with a key that has the redirects permission.
Step 3: 301, not 302
This one digit decides whether a page's authority moves to the new URL.
- 301 (permanent) - "this page has moved for good". Google transfers the history and rankings to the new URL.
- 302 (temporary) - "the old page will be back". Google keeps the rankings at the old URL and waits.
A platform migration is a permanent move. Always 301. A 302 during a migration is the single most common mistake that costs traffic - and the easiest to fix, because it is literally one number in the configuration. The redirects table in DoSwiftly only knows 301 - you can't get it wrong.
Step 4: test on a copy before you switch
The new store should be ready, filled in and tested before you touch DNS. On the copy, check:
- that people can buy - the full path, with a real test payment and a generated shipping label;
- that images and descriptions came over complete;
- that the redirects work - the list lives in the admin panel, not in the server configuration, so you upload it and check it before you touch DNS; take 20 random URLs from your list and check them by hand;
- that the sitemap generates and contains the new URLs.
Step 5: switch in a quiet window
Tuesday, 11 p.m. is a better moment than Friday at noon. Not because the switch takes long - it takes minutes - but because if something goes wrong you want a quiet night to fix it, not peak sales.
Right after the switch:
- submit your sitemap URL to Search Console - in DoSwiftly the sitemap is generated by the Sitemap app (install it in the admin panel): it refreshes itself once a day, and instantly with the "Regenerate" button, so new URLs get into it without adding them by hand;
- check a dozen or so URLs from the list - do the 301s really lead where they should;
- place one real order and check that it reached the admin panel, the mailbox and the courier.
Step 6: look after your URLs after the migration too
This is where most guides end and where the real loss begins. The migration is one day. The store lives for years - and during that time you rename products, tidy up categories, fix typos in URLs. Each such change creates a new URL. If the old one doesn't lead to the new one, to Google it looks exactly like a failed migration, only spread out over time: single pages drop out of the index one by one, without any alarm.
That is why a redirect after a URL change should not depend on someone remembering it. In DoSwiftly it is created automatically: when you change the URL of a published product, category, brand, collection, blog post or page, the old URL starts leading to the new one - with a 301, in a single hop, without entering anything in the table. Change it a second time? The oldest URL still goes straight to the newest, not through an intermediary. A draft that was never publicly visible gets no redirect, because there is nothing to protect.
The same applies to changing your whole URL convention - for example when a store moves from "/products/name" to "/p/name". The platform remembers previous URL patterns and old URLs keep landing on the right pages, without a thousand-row list. You see every redirect - uploaded from a file, added by hand and created automatically - in one table in the admin panel, labelled with where it came from.
One thing deliberately does not happen automatically: a product you delete is not redirected anywhere. Google treats redirecting a vanished page to the home page as a hidden 404, so an honest 404 is better - or a manual entry leading to the category the product was in.
What to expect after the migration
Even with a correctly done migration, Google needs time to re-index the store. Short ranking fluctuations lasting a few days are normal - it doesn't mean you broke something. It means the search engine is walking through your redirects.
What should alarm you is something else: a growing number of 404 errors in Search Console. It means some URLs fell out of the mapping. Then you go back to your list, find the missing ones, add them to the CSV file and upload it again - no duplicates are created, only the new rows are added.
In DoSwiftly you bring over products, customers and orders from Swell automatically, you upload the old URLs from a file into the redirects table, and after the migration the platform itself makes sure a rename doesn't cost you rankings. The old store keeps selling right up to the switch. See how the move works.
Try it on your own store
Top up your balance and sell - no subscription, no contract, no card to start.