What breaks when you migrate to Shopify, and how do you redirect the old URLs?

Last updated: 28 October 2026

Moving to Shopify breaks the old product, category and content paths, because Shopify serves products, collections, pages and blog posts under fixed prefixes. List every old URL, map each to its Shopify path, add the redirects, and request every old URL on the new store to confirm they land. Run the final check once the store is open.

Related guides: the website migration testing checklist, finding broken pages after a migration, and the platform guides for WordPress to Webflow and Drupal to WordPress.

What changes in the URLs

Shopify serves these content types under the following paths, with a handle chosen by the site owner. The prefixes are fixed by the platform, so a site that moves in keeps its handles at best and never its old prefixes.

• Products: /products/<handle>
• Collections: /collections/<handle>, and a product viewed within a collection at /collections/<handle>/products/<handle>
• Pages: /pages/<handle>
• Blog posts: /blogs/<blog>/<handle>

The origin platform uses its own shapes for the same content, such as a product path under /product/ or /shop/, categories under their own prefix, content pages at the site root and posts under /blog/. Take the real shapes from your old site’s sitemap and a crawl rather than from this list: they are defaults a site owner may have changed.

Every old product, category, content page and post therefore moves to a new path, and each old path needs a redirect to its Shopify path or a deliberate retirement.

Build the redirect map

1. Collect the old URLs. Take them from the old store’s sitemap.xml, the Sitemap: lines in its robots.txt and a crawl, and add the product and category pages that receive search traffic or inbound links. The website migration testing checklist covers this inventory.
2. Map each old path to its Shopify path. Match products by name or SKU, categories to collections, content pages to /pages/ and posts to /blogs/. Put the old path in one column and the new path in the next.
3. Handle products that no longer exist. Redirect a discontinued product to its closest replacement or its collection, or let it answer 410 on purpose. A redirect to the homepage answers 200 and hides the loss.
4. Enter the redirects as permanent (301). Shopify offers a per-URL redirect list that maps one old path to one new path. Check whether your list accepts patterns before you rely on one; if it does not, list each path.
5. Request every old URL on the new store. Read the final status of each and check that it lands on the matching product or page. The guide finding broken pages after a migration shows how to read each result.
6. Repeat once the store is open to the public, with its production settings in place.

What usually goes missing

• Product and category pages whose old paths were never mapped, because they sat outside the sitemap.
• Query-string variants: filter, sort and tracking parameters on old links. A redirect list that matches paths only does not match them; confirm how yours treats a query string.
• Paginated listings, whose page numbering rarely matches the new store’s.
• Images and downloadable files that other sites and old emails link at the old domain.
• Trailing-slash and upper-case variants of paths that were linked inconsistently.

Two results that look like failures

• A store that is not yet open. A store that is not yet open answers every path with a redirect to its password page. DiffiCat follows it, so every old URL ends on the same page: it passes “Exists” and fails “Content”. Run the check again once the store is open.
• Bot protection. A store or its network can answer an automated client with a block. DiffiCat reports it as a request that bot protection blocked, not as a missing page.

What DiffiCat automates

DiffiCat compares each page at the same path on both sites. Enter the site you are moving from as Site A and the site you are moving to as Site B. It requests each old URL on the new site and follows redirects hop by hop: a correct redirect passes “Exists”, a missing redirect fails it, and a redirect that lands on the wrong page fails “Content”, because the title and body text no longer match.

• The URL list. DiffiCat reads the old site’s sitemap.xml and the Sitemap: lines in its robots.txt, and falls back to a crawl of the homepage. You can also supply a sitemap URL.
• Three checks on every page. “Exists” compares the HTTP status of both versions. “Content” compares the title, H1, meta description, canonical, robots meta, hreflang and body text, with a 90% word-overlap threshold for the body. “Visual” compares screenshots pixel by pixel at 375 px, 768 px or 1440 px, or any width from 320 px to 2560 px.
• A report you can act on. Pages are listed worst first, and each failure names the site at fault, such as A: 200 → B: 404.

Building the redirect map stays yours: DiffiCat shows which old URLs fail and why, and you add the redirects.

What this does not catch

• Behaviour: forms, search, checkout, sign-up flows and other interactive features need their own functional tests.
• Speed and server load: a page can match exactly and still be slower.
• Pages nobody listed: if a URL is missing from the inventory, no tool checks it.

DiffiCat has its own limits. Both sites must resolve on the public internet: localhost, loopback and private-network addresses are refused, so deploy staging to a public URL (password protection is fine). Pages are rendered in headless Chromium only. Sign-in with a username and password is supported, but sign-ins that need a code (MFA), a CAPTCHA or single sign-on are not.

Run the check on your sites

Enter your old and new site in the try-it form, or open app.difficat.com and start the free trial: 500 captured pages once when signed in, 100 without signing in, with every check and viewport width and no card needed.