How to protect your SEO through a Shopify theme migration

Changing your theme doesn’t damage rankings. Mishandling URLs, redirects and structured data does.

That distinction matters, because it tells you exactly where to put your attention — and it’s why most migration SEO advice, which focuses on the theme, misses the point.

This page is about a theme migration, where your URLs and content stay in Shopify. If you are moving platforms entirely, the risk profile is much wider — see how to preserve SEO during an ecommerce migration.

Does changing your Shopify theme affect SEO?

Changing a Shopify theme has no inherent effect on search rankings, because your URLs, your content and your products all live in Shopify rather than in your theme.

What a theme controls is how pages are rendered: the HTML structure, the heading hierarchy, the structured data emitted, the internal linking patterns, and how quickly the page loads. Each of those can influence performance, and each of them can be reproduced correctly or incorrectly in a new build.

The damage, when it happens, comes from the migration being executed badly rather than from the migration happening at all. Stores migrate themes every day without losing traffic. Stores also lose 30% of their organic sessions doing it. The difference is entirely in the handling.

What actually causes traffic loss during a migration?

Five specific failures account for nearly all post-migration traffic loss, and all five are preventable.

1
URL changes without redirects.

Any URL that changes and doesn’t redirect loses whatever equity it had accumulated. On a theme migration this most commonly happens with custom page templates and collection filter structures.

2
Dropped redirects.

Stores accumulate redirects over years — from old product URLs, retired collections, previous platforms, past campaigns. A migration that doesn’t carry the redirect table across breaks every one of them at once, and the affected URLs are usually the oldest and best-linked.

3
Missing structured data.

Product schema, breadcrumb schema, review markup, FAQ markup and organization data are emitted by the theme. If the new theme emits less, rich results degrade, and the decline in click-through happens without any ranking change to explain it.

4
Changed heading hierarchy.

A rebuild that moves the product title out of the H1, or that introduces multiple H1s on a template, changes how the page is understood. This is small individually and meaningful across thousands of pages.

5
Slower pages, or newly unstable ones.

Cumulative layout shift is the usual culprit here, because a new build often loads assets in a different order.

None of these is exotic. All of them get missed when SEO is treated as a launch-week checklist rather than a requirement from the start.

What needs to be preserved exactly?

Four things need to survive a migration unchanged unless there is a deliberate decision and a redirect behind the change.

URL structure

On every template type — products, collections, pages, blog posts, and any custom templates.

The full redirect table

Exported before the migration and verified as live afterward.

Every structured data type currently emitted

Not a reasonable equivalent. If your current theme outputs review markup with aggregate ratings, the new one needs to output review markup with aggregate ratings.

Canonical logic

Including any template-level overrides. Canonicals are easy to get subtly wrong on a rebuild, and subtle canonical errors are hard to diagnose later.

The reason to treat these as requirements rather than checks is that a requirement gets built deliberately. A check gets performed after the fact, when changing it is expensive.

What about structured data?

Structured data needs to be inventoried before the migration and reproduced type by type, because it’s emitted by the theme and does not carry across on its own.

Start by recording what your current storefront actually outputs — product, breadcrumb, organization, website, review, FAQ, article, and anything a specific app injects. Test real pages rather than assuming, because themes frequently emit less than their documentation implies and apps sometimes add types nobody knows about.

Then treat each type as a line item in the requirements document, with a testable acceptance criterion. Validating the new build against a live URL is the only way to be confident, and validating it before launch is the only way for that confidence to be useful.

One thing worth knowing: structured data problems produce no error and no ranking drop. They produce a quiet decline in click-through rate as rich results disappear from the search page, which is easy to attribute to almost anything else.

How do you handle redirects?

Export the full redirect table before the migration begins, confirm it’s intact after launch, and add new redirects for any URL that has deliberately changed.

Shopify stores URL redirects at the store level rather than in the theme, so they usually survive a theme change. Usually is not always, and the failure mode is silent, so exporting a copy before you start costs nothing and removes the risk entirely.

Any deliberate URL change needs a 301 redirect from the old address to the new one, mapped one to one rather than pointing everything at a category page or a homepage. Bulk redirects to a parent page are treated as soft 404s and lose the equity you were trying to preserve.

The delay is the danger

How long before you’d know something went wrong?

SEO damage from a migration typically becomes visible two to four weeks after launch, which is the single most important thing to understand about it.

Nothing looks broken on launch day. Pages load, products display, the site works. Crawling and re-indexing take time, and ranking changes lag the crawl. By the time a traffic decline appears in a weekly report, several weeks of other changes have happened and the cause is genuinely hard to isolate.

This delay is why post-launch verification matters more than launch-day verification, and why it should be scheduled rather than left to whoever notices something.

What should you check before launch?

Run these against the new build in a preview or sandbox environment, not after publishing.

  • Every template type renders with the same URL structure as today
  • Full redirect table exported and verified
  • Structured data validated on a real URL of each template type
  • One H1 per page, matching the page’s subject
  • Meta title and description logic reproduced, including template-level overrides
  • Canonical tags correct on paginated and filtered pages
  • robots.txt and sitemap configuration unchanged
  • Hreflang correct, if you run multiple markets
  • Core Web Vitals measured on the new build and compared to the current one
  • Image alt text preserved

The full pre-launch migration checklist →

What should you check on launch day and after?

Launch day

Submit the sitemap, verify indexing is not blocked, spot-check twenty URLs across every template type, confirm redirects resolve, and check that analytics and tag firing are intact.

First 48 hours

Watch crawl stats and coverage errors in Search Console. Watch for a spike in 404s, which is the earliest signal that something in the URL structure moved.

Two weeks

Compare rich result appearance to the pre-migration baseline. This is when structured data problems become visible, and it’s early enough to fix them cheaply.

Four weeks

Compare organic sessions and rankings against the baseline, segmented by template type. Segmentation matters — a problem confined to collection pages looks like a small overall decline and is actually a specific, fixable failure.

Who should own this?

SEO during a migration should be owned by someone with authority over the requirements document, not by someone reviewing the finished build.

The distinction is practical. A reviewer can find problems. Only someone writing requirements can prevent them, and preventing a canonical error costs a sentence in a document where fixing it after launch costs a week and some traffic.

Questions to ask a migration agency →

Frequently asked questions

Does changing your Shopify theme affect SEO?

Not by itself. URLs, content and products live in Shopify rather than in the theme. Traffic loss after a theme change comes from mishandled URLs, dropped redirects, or structured data that wasn’t reproduced.

Will I lose rankings if I migrate to Shopify Horizon?

Not if URL structure, redirects, structured data and canonical logic are preserved. Those are the four things that need to be treated as requirements rather than as post-launch checks.

Do Shopify redirects survive a theme change?

Shopify stores URL redirects at the store level, so they normally survive. Export the full table before migrating anyway — the failure mode is silent and the export costs nothing.

How long after a migration would I see an SEO problem?

Usually two to four weeks. Nothing appears broken on launch day, because crawling and re-indexing take time and ranking changes lag the crawl.

What’s the most commonly missed SEO item in a theme migration?

Structured data. It’s emitted by the theme, doesn’t carry across on its own, and its absence produces no error — just a quiet decline in click-through as rich results stop appearing.

See where your storefront stands on technical SEO today.

We’ll benchmark your store against three competitors on speed, accessibility and technical SEO. Free, two minutes, nothing to install.

Get your scorecard

Planning a migration already? The Readiness Audit includes a structured data and redirect inventory for your specific store.