Before you start: build the inventory

You cannot protect what you have not listed. Before anyone touches the new site, gather four things from the old one and keep them somewhere the whole project can see.

  • A full crawl of the live site, exported with each URL's title, meta description, H1, canonical, status code and indexability. Any desktop crawler will do this.
  • The pages that earn traffic: the last twelve months of landing pages from analytics and the top pages and queries from Search Console. These are the URLs that must not break.
  • The pages that earn links: whatever backlink data you have access to. A linked page that returns 404 after launch is wasted equity you will not get back by asking.
  • Baseline measurements: indexed page count, Core Web Vitals status by template, and a dated screenshot of the Search Console performance graph. Without a baseline, every post-launch conversation becomes an argument about memory.

Do this early. The inventory also tells you how big the redirect job is, which affects the launch date more often than anyone expects.

URL mapping: Shopify decides more than you do

Shopify's URL structure is fixed. Products live under /products/, collections under /collections/, pages under /pages/ and blog posts under /blogs/<blog-handle>/. You choose the handle at the end; you do not choose the prefix. If the old site used /shop/blue-widget or /category/widgets/, every one of those URLs will change, and each needs a redirect.

Build the map as a two-column spreadsheet: old URL, new URL. Work from the inventory so that nothing with traffic or links is missed, and map to the most specific equivalent, not the homepage. A product that is discontinued should map to its nearest replacement or its collection, and you should note which it is so the decision is visible later. Where the old site had several URLs for one product, for example through filters or tracking parameters, decide which one is canonical and map the rest to the same destination.

Keep handles stable where you can. Shopify generates a handle from the product title and will happily append -1 when a title is reused, which creates duplicates you did not intend. If the old product slug is sensible, reuse it as the handle.

Redirects: what Shopify can and cannot do

Shopify's built-in URL redirects, under Online Store, Navigation, are one-to-one: one old path to one new path, imported in bulk from a CSV. They are reliable and they are what you should use for the bulk of the map. They also have rules that catch people out; these are the ones in Shopify's own documentation at the time of writing.

  • They only work from broken URLs. If the old path still loads a valid page on the new store, the redirect does not fire; you have to change or remove the page first. Shopify applies the same rule the other way: hide a collection and a redirect from it will work, make it visible again and the redirect is removed.
  • Certain paths cannot be redirected: anything beginning with /apps, /application, /cart, /carts, /orders, /services or /shop, the fixed paths /products, /collections and /collections/all, and collection tag URLs, which Shopify treats as valid even when no product carries the tag.
  • There is no wildcard or pattern matching in the admin tool. A rule like "everything under /category/ goes to /collections/" has to be expanded into individual rows, or handled with an app or at the domain level.
  • Query strings are unreliable: Shopify's documentation says URLs with query strings "might not work as expected". Map the clean path and test any that matter.
  • The limit is 100,000 redirects on standard plans, which is plenty for most stores but worth knowing if you are consolidating several old sites.
  • If the store uses market or language subfolders, check whether the redirects apply in each; Shopify's documentation says locale-specific redirects need their own entries.

Test the map before launch on the password-protected store, then again on the live site. The test you want is simple: request every old URL, follow the redirects, and record the final status code and the number of hops. The target is one hop to a page that returns 200. Chains, where A redirects to B which redirects to C, waste crawl budget and are a sign that an older redirect was never updated. Redirects to a 404 are the worst outcome, because they look fixed in the admin and are broken for the visitor.

If the domain is changing too, the old domain must keep redirecting to the new one for as long as you can keep the registration, and the change should be declared in Search Console's change-of-address tool once the redirects are live.

Canonicals and the duplicates Shopify creates

Shopify sets a canonical tag on every page automatically, and in general you should leave it alone. Two patterns are worth understanding. First, a product can be reached through a collection, at /collections/<collection>/products/<product>, as well as at /products/<product>; the collection version carries a canonical pointing at the plain product URL, which is correct. Themes that link to the collection version everywhere are not wrong, but it means the URL visitors share is not the canonical one, and a few older themes built the product page's structured data from the wrong URL.

Second, collection pages with sort and filter parameters, tag pages at /collections/<collection>/<tag>, and paginated pages all exist and can all be crawled. Shopify handles canonicals for most of these, but tag pages in particular can create a large number of thin, near-duplicate URLs if the theme links to them freely. Decide whether tag pages should be indexable at all. If not, the theme can add a noindex to them, and the robots.txt template can be edited to keep crawlers out of parameter URLs.

Metadata, headings and the content that falls off the back of the lorry

Titles and meta descriptions do not migrate themselves. Product and collection imports carry them if the CSV has the right columns and someone filled them; page and blog content often arrives with none. After the import, crawl the staging store and compare against the inventory: every page that had a description should still have one, and every page should have exactly one H1 that is not the shop name.

Image alt text is the other common casualty. It is attached to the image in Shopify, so images re-uploaded during migration lose it unless the import includes it. Alt text matters for accessibility first and image search second, and writing it after the fact for a few hundred images is a day's work that is better planned than discovered. On one migration we documented, the post-launch checks found missing descriptions, images without alt text and pages without a main heading, all of which were fixed in the first week; the anonymised case study lists the checks.

Internal links need the same review. Content copied from the old site carries old absolute URLs in product descriptions, blog posts and navigation. Each of those now goes through a redirect, or to a 404 if the mapping missed it. Crawl the staging store for links that return anything other than 200 and fix them at source.

Structured data

Most Shopify themes output Product, Organization and BreadcrumbList structured data as JSON-LD, and some output Article for blog posts. Check what the new theme produces on each template using Google's Rich Results Test and the Schema Markup Validator, and compare it with what the old site had. The usual problems after a migration are: two sets of Product data on one page because an app adds its own on top of the theme's; Organization data with the wrong name or no logo; and review data from an app that no longer exists, still referenced in the theme.

Do not add structured data for things that are not on the page. FAQ markup on a page with no visible questions, or review markup without visible reviews, is a guideline violation, and rich results are never guaranteed in any case. The aim is accurate data that matches what the visitor sees.

Launch day: the checks to run before anyone goes home

The password comes off, the DNS changes, and for the next hour the only job is verification. Work through the list in order and write down what you saw; that note becomes the record you will want when a question comes up weeks later.

  1. robots.txt: fetch it and read it. The staging store's rules must not have come across, and nothing important is disallowed.
  2. Index status: view source on the homepage, a product, a collection and a blog post and confirm there is no noindex meta tag left over from staging.
  3. Redirects: run the full old-URL list against the live domain. Every row should end at a 200 within one hop.
  4. Sitemap: open /sitemap.xml, follow the child sitemaps, and request a sample of URLs from each. All should return 200.
  5. Templates: on each template type, check the title, meta description, canonical, H1 and structured data against the inventory.
  6. Analytics and tags: confirm the analytics property is receiving page views from the live domain on each template type, and that any conversion tags fire on the thank-you page with a test order.
  7. Search Console: add and verify the new property if the domain changed, submit the sitemap, and if the domain changed, file the change of address.

The weeks after: what to watch in Search Console

Google will recrawl the site over days and weeks, not hours, so the picture in Search Console changes gradually. Watch three reports.

  • Pages (indexing): the count of indexed pages should move towards the new site's total. A rising count of "Not found (404)" or "Page with redirect" URLs is normal at first, as Google discovers the redirects, and should settle. "Crawled, currently not indexed" rising steadily on product pages is not normal and wants investigating.
  • Performance: compare clicks and impressions against the dated baseline, by page and by query. Expect some movement; look for specific pages that have dropped rather than reacting to the total.
  • Core Web Vitals: a new theme can be slower than the old one even when it looks better. If the mobile status gets worse, treat it as a performance job, not an SEO job.

One honest caveat. The checks in this article reduce avoidable risk; they do not guarantee that rankings stay where they were. Rankings depend on far more than the technical migration, and a provider who promises otherwise is promising something they cannot control. What you can control is that nothing was lost through carelessness, and that you have the evidence to show it.