Tags: web-dev concept

Site Migrations and SEO

Date: 2026-08-16

---

The highest-risk routine event in ecommerce. Everything that makes a site findable — URLs, rendering, redirects, internal links — changes at once, and the damage appears weeks later when nobody is still watching.

---

What it is

A site migration is any change altering how content is addressed or served: a replatform, a redesign with URL changes, a domain move, a protocol or host change, or a shift in rendering strategy.

The risk isn’t the migration. It’s that the feedback loop is weeks long. Traffic doesn’t collapse on launch day; it degrades over the following month as pages are recrawled, which is long after the launch team has moved on.

What actually goes wrong

In order of frequency and damage:

1. Incomplete redirect mapping. Old URLs 404, and every link earned over years points at nothing
2. Blanket redirects to the homepage instead of to equivalents. Treated as soft 404s, passing nothing — Redirects and Link Equity
3. Rendering strategy changed silently. Server-rendered becomes client-rendered because that’s what the new framework does by default. Content that was indexed instantly now waits on a rendering queue, and AI crawlers never see it at all — Rendering and SEO
4. Staging noindex shipped to production. Catastrophic, easy to do, and detectable in thirty seconds if anyone checks
5. robots.txt from staging blocking the whole site
6. Internal linking changed, orphaning pages that were previously reachable
7. Canonical tags pointing at the old domain, or missing entirely — Canonicalisation
8. Structured data lost in the template rewrite — Structured Data
9. Measurement continuity broken, so you can’t tell whether traffic fell or tracking did — Guide - Auditing a Tracking Plan

Number nine is the one that turns a recoverable problem into an unresolvable argument. If analytics changed at the same time, you cannot distinguish a traffic loss from a measurement loss — and both will be claimed.

The sequence

Before

• Crawl the old site fully and export every URL. Not the sitemap — the sitemap won’t contain the old URLs that accumulated links years ago. A crawl plus server logs plus Search Console’s indexed pages, unioned
• Export current performance per URL: impressions, clicks, position. This is your baseline and it’s unrecoverable afterwards
• Map every old URL to its new equivalent. Every one. The tail is where the links are
• Decide out-of-stock and discontinued handling in advance — Redirects and Link Equity
• Check rendering on staging with curl, not DevTools. What does a non-rendering crawler receive?
• Run a full crawl of staging for broken links, chains, missing canonicals, missing titles
• Freeze the tracking plan and verify it works on the new platform before launch, not after

At launch

• Verify robots.txt and the absence of noindex. First check, every time
• Spot-check redirects across templates, not just the homepage
• Submit the new sitemap; keep the old one available briefly so old URLs are recrawled and their redirects discovered
• Annotate the date everywhere — analytics, dashboards, Search Console — Annotation and Change Logs

After

• Watch Search Console coverage daily for a fortnight, then weekly. Crawl errors and index drops surface here first
• Reconcile analytics against the order system to separate a traffic problem from a tracking problem
• Recrawl and fix redirect chains that emerged from the mapping
• Expect a dip. Even a well-executed migration loses ground temporarily. Recovery over four to eight weeks is normal; no recovery by eight weeks means something is still wrong

Reducing the risk

• Don’t change everything at once. URLs, design, platform, rendering and tracking in one release makes diagnosis impossible. Sequence them if you can
• Keep URLs identical where the platform allows it. A replatform that preserves URL structure removes the largest risk entirely
• Run in parallel where possible — old and new serving different segments — so you have a comparison rather than a before-and-after — Rollouts as Experiments
• Assign an owner for the four weeks after launch, with time allocated. The absence of this is why migrations fail quietly

Measurement continuity

Worth its own attention because it’s the part CRO and analytics people are left holding:

• Keep the same analytics property through the migration if at all possible. A new property means no historical comparison
• Keep the event taxonomy identical, even if the new platform makes different names natural — Event Taxonomy Design
• Verify the tracking plan on staging and again at 1% of traffic before full cutover — Experiment QA
• Accept that some metrics will step change regardless — session definitions, bot filtering and consent implementations differ between platforms — and say so in advance, in writing, or the step will be read as performance — Metric Drift

See Replatforming for the wider commercial project this sits inside.