Shopify migration SEO checklist: freeze, map, redirect, verify

A migration is a mapping problem, and Google's move guide starts with the mapping

Google's guide to moving a site lists five steps: prepare the new site, prepare a mapping from current URLs to their new equivalents, configure server-side redirects, monitor both sets of URLs, and wait. Four of the five are about URLs. Design, copy and theme are not in the list.

That is the right frame for a move onto Shopify. Every old URL that earned a link, an impression or a bookmark either answers on the new store with a permanent redirect to its closest equivalent, or it stops being a page. The checklist below is ordered by when you can still do something about each item: what to freeze before the move, what to build while the new store is still private, what to check on launch day, and what to read afterwards.

Freeze the URL inventory before anything else changes

Google suggests four places to find the old URLs that matter, and a migration needs all four because each misses pages the others catch:

• Sitemaps. The URLs you submitted are the ones you consider important.
• Server logs or analytics. The URLs that actually receive visits, including ones that are not in any sitemap.
• Search Console, Links report. Pages that other sites and your own pages link to.
• The CMS itself. Your current platform can usually export every URL that hosts content.

Merge them into one sheet with a row per old URL. Add three columns while the old site is still live: the title tag, the canonical, and the status code. The new store will be compared with this sheet, and after launch the old title tags and canonicals can no longer be fetched.

Google also asks you to include images, PDFs and other files you host. They may already rank and carry links, and they move the same way as pages.

Keep the sheet as the single source. Everything that follows, from the redirects to the post-launch audit, is a query against it.

Change one thing at a time, even when the brief says otherwise

Google's guide says to plan changes one after another: if you want to change domain, platform and layout, do them in sequence. A rebuild that also renames every URL and rewrites every title leaves you unable to tell which change moved a ranking.

On a Shopify migration the practical version is to keep titles, headings and body copy as close to the old pages as the new theme allows, and to change them in a second phase once the redirects are settled. Where the old URL structure can be kept, keep it. Where the platform forces a change, that change is the mapping, and the mapping is the work.

Map each old URL to its nearest equivalent, and let the rest return 404 or 410

Google's rule for deleted content is plain: if you are not moving everything, URLs for content that no longer exists should return a 404 or 410 on the new site. A redirect to an unrelated page, usually the home page, is not a substitute.

For each row in the sheet, pick one of three outcomes:

Shopify's side of this is deliberately constrained. A product's address is /products/ plus its handle and a collection's is /collections/ plus its handle, so the old structure rarely survives as it was, and the canonical URL post shows what Shopify writes as the canonical for each variant of those paths. Build the mapping against the final handles, not the working titles from the import, because a redirect to a handle you rename later is a redirect you must fix.

Use permanent redirects. Google's page on redirects separates the two kinds by what they do in results: a permanent redirect (301 or 308) tells Google the target should be canonical and the new URL is shown; a temporary one (302, 303, 307) keeps the source URL in results. A migration is the permanent case.

Load the redirects into Shopify as a file, not by hand

Shopify stores a redirect as two strings. The UrlRedirect object has a path, the old path a visitor requests, and a target, the location they are sent to. The Admin API creates one at a time with urlRedirectCreate, which needs the write_online_store_navigation access scope.

For a migration you want the bulk route. urlRedirectImportCreate takes a CSV and links to a sample redirect template. The import it creates reports its own outcome: the UrlRedirectImport object carries the number of rows in the file, how many redirects were created, how many were updated, how many failed, whether it has finished, and up to three previews of what will be imported.

Treat those counts as the acceptance test for the load. The row count in the file must equal created plus updated plus failed, and failed must be zero or each failure must be explained. A load that "mostly worked" leaves a tail of old URLs that return 404 for reasons nobody wrote down.

Shopify's own example of a redirect uses short paths on both sides, /thepath to /thetarget, so write the path column as the part of the URL from the first slash. Point each row at its final destination rather than at another redirect that itself redirects; the sheet makes it easy to resolve those before loading.

Update everything on the new store that points at the old URLs

Google's guide lists what to update on the new site before the move: each new URL needs a self-referencing rel="canonical", any hreflang annotations must use the new URLs, and internal links must point at the new addresses rather than relying on redirects.

On Shopify the canonical is written by the platform, as the canonical URL post shows, so the check is that your theme still contains the line and no app adds a second one. Hreflang is covered in its own post. Internal links are the item that is yours: menus, footer links, links in page and blog bodies imported from the old site, and links in transactional emails. A body imported from the old CMS often contains absolute links to the old host.

Also prepare the files Google asks for on launch day: a sitemap of the new URLs, and the list of sites linking to the old ones. Shopify writes the sitemap for you; what is in it is worth reading before you submit it.

Clear the development blocks before launch, on the day, from a written list

Google's guide warns that many site owners block crawling while the site is under development. If you did, prepare the list in advance: the robots.txt rules that will apply once the move starts, and every URL carrying a noindex that must lose it. A store launched with a password page, a leftover noindex in the theme, or a robots.txt that still disallows everything is the most expensive mistake on this list, because it is a single line that makes the whole site invisible.

On launch day, in this order:

1. Open /robots.txt on the live domain and read it.
2. View source on the home page, a product page and a collection page, and search for noindex.
3. Request twenty URLs from the old inventory sheet, picked across the types, and confirm each returns a 301 to the intended target with a single hop. The browser's network panel or curl -I shows the status and the Location header.
4. Confirm the canonical on each landing page is the URL you expect.
5. Submit the new sitemap in Search Console.

Verify Search Console for both properties and keep the old one

Google asks you to verify both the old and new sites in Search Console, including every variant of the host: with and without www, and http and https if both were ever in use. Verification tokens can change when the platform changes; an HTML-file verification does not carry over to a new CMS unless you add the file, and a tag verification does not unless the theme includes the tag.

Keep the old property for as long as you are watching the move. Google notes that the move happens per URL, that Googlebot must visit each old and new URL at least once, and that medium-sized sites can take a few weeks or more for the new URLs to replace the old ones in results, longer for larger sites. Ranking fluctuation during that period is expected.

Make sure the store can take the crawl. Google warns that it temporarily crawls a migrated site more heavily than usual, because it requests the old URLs, follows the redirects and also crawls the new ones.

Read three things after launch, and compare them with the frozen sheet

Check the following at day three, day fourteen and day thirty, in Search Console:

• Pages report. The count of indexed pages on the new property should climb as the old property's falls. Read the reasons for pages not indexed and match them against the sheet: an old URL listed as redirecting is expected, "Not found (404)" on a URL you mapped is a defect.
• Performance report. Compare clicks and impressions for the old and new properties combined with the same period before the move. A dip is expected; a flat line that does not recover is a mapping or a block.
• URL Inspection. Inspect the five most valuable old URLs and five most valuable new ones. For each, the user-declared and Google-selected canonical should agree on the new URL.

Then crawl the live site with a crawler that reports redirect chains and 404s, and diff the result against the sheet. Every row should land in one of the three outcomes in the table above. Any URL that appears in neither the redirects nor the 404 list was missed.

What to fix first, and how long it takes

Fix in this order: the launch-day blocks (an hour, and they can wipe out everything else), then the redirect load and its counts (a day for a few thousand URLs, mostly spent building the mapping, not importing it), then internal links that point at old addresses (a day or two for a store with imported bodies), then the title and canonical comparison against the frozen sheet (an afternoon). The monitoring is slow by design: Google's own estimate is weeks, so decide before launch what a failure looks like in the day-thirty read, and who looks.

If you would rather have the mapping and the post-launch comparison done by someone who has done them before, a Store Teardown of the current store is how we start, and our services say what happens after.