Migration & Replatforming SEO

Migration SEO is the planning and quality control that protects your rankings when you change domain, platform, URL structure or site architecture.

The goal is continuity. Google has to understand the new site as the same entity as the old one, which means every URL that carried traffic or links needs a clear destination, the content on those pages has to remain recognisably the same, and the technical signals have to point in one direction rather than several.

It is preventive work, which makes it unusual. Most SEO adds something. Migration SEO stops you losing something you already had, and its value only becomes visible when nothing goes wrong.

Redesigns count, even when URLs stay the same. Changing templates, cutting copy from top-performing pages or restructuring navigation can all move rankings without a single URL changing. The most expensive version of this work is the retrospective one, where a migration has already gone live and we are diagnosing what broke.

Before URL decisions are locked and before templates are finalized. Realistically that means four to six weeks before launch on a small site, and considerably earlier on a large one.

The reason is that the most expensive mistakes are architectural. A URL structure that drops a useful directory level. A template with no field for a meta description. A navigation redesign that buries category pages four clicks deep. All of those are cheap to change at wireframe stage and expensive to change after development.

Early involvement also means the baseline gets captured properly. You cannot demonstrate that a migration succeeded without a clean record of rankings, traffic, index coverage and top pages from before it happened.

If you are already mid-build, it is still worth talking. The redirect map, staging QA and launch monitoring all remain valuable, and much of the value sits in the final two weeks anyway. If you have already launched and traffic has dropped, that becomes a diagnostic project rather than a migration one.

Missing or incorrect 301 redirects, redirect chains, wrong canonical tags, a noindex left over from staging, robots blocks, and internal links still pointing at old URLs.

Two failures account for most catastrophic cases, and both are staging artifacts. The first is a noindex meta tag applied during development and never removed at launch. The second is canonical tags still referencing old URLs, which tells Google the new pages are duplicates of pages that no longer exist. Either one can strip a site out of the index within days, and neither is visible to anybody browsing the new site.

The subtler cause is content change. Teams often take a redesign as an opportunity to shorten copy, and a top-performing page that loses half its content loses the relevance that earned its ranking. That is a content parity failure, an on-page problem introduced by a technical project, and URLs can be mapped perfectly while traffic still falls.

Which is why launch day is a verification exercise. We test the highest-value URLs manually before anyone announces the new site.

A clean migration usually dips 5 to 15 percent and returns to baseline within four to twelve weeks. Larger sites and bigger structural changes sit at the slower end of that range.

The dip itself is normal and not a sign of failure. Google has to recrawl the old URLs, process the redirects and transfer the signals across, and on a large site that simply takes time because of crawl capacity. Panicking and rolling back mid-recovery causes more damage than waiting does.

What is not normal is a drop past 30 percent, or a decline that keeps deepening after week two. That indicates something broke rather than something processing, and the cause is almost always somewhere in the list of staging artifacts and redirect errors.

Domain changes take longest, even with Change of Address filed in Search Console. Platform changes come next, then redesigns on the same URLs. Post-launch monitoring runs daily for the first week and weekly through 90 days, so the difference between a recovery in progress and a genuine problem shows up early rather than in hindsight.

Yes. Shopify, WordPress, Webflow, Magento, headless builds and custom platforms, for Toronto businesses and Canada-wide. The plan adapts to the CMS and the deployment workflow, but the priorities never change.

Each platform carries its own risks. WordPress migrations often bring plugin-generated URLs and archive pages nobody knew existed until the crawl ran. Shopify has fixed URL patterns that limit how closely a new structure can mirror an old one, which makes the redirect map more important rather than less. Webflow handles redirects cleanly but needs careful attention to collection URL structure and staging settings. Headless builds carry the highest rendering risk, because content that renders for a user may not render for a crawler.

What stays constant is the sequence. Complete URL inventory, one-to-one redirect mapping prioritized by traffic and links, staging QA with a crawl validation pass, controlled launch, then monitoring.

We also ask for a rollback plan before launch. It is rarely needed, but the migrations that go badly are usually the ones where nobody agreed in advance what would trigger reversing it.