Shopify Migration SEO Checklist: 32 Checks Before You Flip DNS

Most migration SEO advice is written to be read a month before launch. This one is written for the two days before, when the store is built, the content is in, and somebody is about to change a DNS record.

That window is the last moment a mistake is cheap. After cutover, every one of these becomes a recovery job with a traffic chart attached. Run them as gates — anything unresolved is a reason to delay a day, because a day is worth considerably less than a quarter of rankings.

Redirects — 8 checks

This is where migrations are won or lost, and it is the section people rush.

1. You have a URL inventory from three sources, not one. Search Console, server logs and the old sitemap. Each finds pages the others miss; logs in particular surface old landing pages nothing links to internally that still take traffic.
2. Every old product, collection, blog and static page URL has a mapped destination. No blanks in the map.
3. Redirects are 301, not 302. A temporary redirect asks Google to keep the old URL indexed, which is the opposite of what a migration wants.
4. Nothing redirects to the homepage in bulk. A mass redirect to / is treated as a soft 404 and passes nothing. If a page has no equivalent, send it to the closest collection.
5. No redirect chains. Old URL to new URL, once. Chains of three or four appear when a store has been migrated before and the old rules were never flattened.
6. Trailing-slash and case behaviour is consistent and does not create a second redirect hop.
7. Parameterised URLs are handled — old filter and search URLs that accumulated links.
8. The map is tested against staging with an automated crawl, not by spot-checking ten URLs by hand.

Indexation controls — 5 checks

1. The staging password is still on until the moment of cutover, and the store was never publicly crawlable during the build.
2. robots.txt on the live store does not block anything you need indexed. Check the rendered file, not your intention.
3. No stray noindex left on templates from the build. Crawl staging and list every page returning a noindex directive; each one should be deliberate.
4. Canonicals are self-referencing and absolute on product, collection and blog templates — and they point at the URL you actually serve, with the same trailing-slash convention. A canonical that 301s is a canonical Google will not honour.
5. Collection pagination and filtered views do not generate thousands of near-duplicate indexable URLs.

Templates and on-page — 6 checks

1. Title tags carry across. Migrations frequently reset them to a theme default of "Product name – Store name", wiping years of tuning.
2. Meta descriptions carry across, or are deliberately regenerated rather than left blank.
3. Exactly one h1 per page, and it is the product or collection name rather than a logo.
4. Collection descriptions survived. These are often the only real text on a category page and they are easy to lose in a catalogue export.
5. Image alt text migrated. Rarely included in exports; worth checking on a sample rather than assuming.
6. Internal linking is rebuilt. Old hand-placed links inside descriptions may point at old URLs — they will redirect, but a store full of internal redirects is a store leaking crawl budget.

Structured data — 4 checks

1. One Product block per product page. Two competing blocks is the standard cause of lost rich results after a theme change.
2. Price, availability and currency are correct in the markup and match what the page displays.
3. Aggregate rating present where you have reviews, and the reviews are visible in the initial HTML rather than loaded on interaction.
4. Organization and breadcrumb markup validate without errors in the Rich Results Test.

Performance — 3 checks

1. Core Web Vitals measured on a real mobile device, not only in a desktop lab run. A migration is the moment a store either gets faster or quietly picks up three new apps' worth of script.
2. Images are sized and served in a modern format, and the hero is not a 2MB PNG.
3. No render-blocking app scripts added during the build that nobody has audited. Every app injects something; the total is what matters. Our note on Shopify speed covers what is worth removing before launch rather than after.

Analytics and tracking — 4 checks

1. GA4 fires on the new store and records a purchase on a test order.
2. Google Ads and Meta conversions are wired and tested — a migration that silently breaks conversion tracking hides the damage and the recovery equally.
3. Search Console has the new property verified and the domain change tool is ready to use at cutover.
4. You have a rankings and traffic baseline saved from the week before launch. Without it you cannot tell a normal re-crawl dip from a real loss, and you will argue about it for a month.

Commerce correctness — 2 checks

1. Tax, shipping and payment methods tested end to end with a real order in each of your main markets.
2. Inventory reconciles between the old store and the new one on the morning of cutover, not from a week-old export.

The cutover itself

Lower the DNS TTL a day or two ahead so the switch propagates quickly and a rollback is fast. Cut over on a low-traffic morning, not on a Friday evening, and have the person who can revert available for the hours after.

Immediately after: submit the new sitemap, use the Search Console change of address if the domain is changing, and run a full crawl of the live store looking for 404s and unexpected redirects. Then crawl your old URL list against the live site and confirm each one lands where the map says it should.

The first fortnight

Expect movement. Crawl volume rises, impressions wobble, some pages drop before they recover. What you are watching for is not the dip but its shape — a broad, progressive recovery is normal; a category or template that flatlines is a bug with an address.

Check 404s daily for the first week. Real gaps in the redirect map show up as traffic to pages you forgot, and they are trivial to fix on day two and expensive to notice on day forty.

If you would rather have this run by people who have done it repeatedly, it is the spine of our migration work, and we will run the same checklist over a store that has already moved and lost traffic — send us the URL and we will tell you which of the thirty-two was missed.