A site migration—whether replatforming, domain change, or HTTPS switch—can preserve or destroy years of SEO equity in a matter of hours. This checklist walks through the essential pre-launch, launch, and post-launch steps to ensure technical continuity, preserve rankings, and avoid catastrophic traffic loss.
Most migration disasters trace back to incomplete URL mapping. When you move from one CMS to another, change domain names, or switch protocols, every indexed URL in Google's cache must resolve cleanly to its new home via a 301 redirect. Miss a category archive, a paginated product page, or a legacy blog post, and you hand Google a 404—signaling that the content no longer exists. The search engine then drops that URL from the index, and any backlinks pointing to it lose their equity.
The second failure mode is redirect chains: old URL → temporary redirect → another temporary → final destination. Each hop dilutes link equity and slows crawl budget. Googlebot may abandon the chain entirely if it exceeds three hops. Equally damaging is the mixed-content trap on HTTPS migrations—images, scripts, or iframes still loading over HTTP trigger browser warnings and break the secure lock icon, eroding trust signals that influence rankings. A rigorous pre-launch audit catches these issues in staging; fixing them post-launch under traffic pressure is exponentially harder.
Start by crawling the live site with Screaming Frog, Sitebulb, or DeepCrawl. Export the full URL list, HTTP status codes, title tags, meta descriptions, canonical tags, hreflang annotations if bilingual, and structured data markup. Capture the current XML sitemap and compare it against the crawl to identify orphaned pages that exist but are not linked internally. Pull a complete backlink profile from Ahrefs, Majestic, or Semrush—note which legacy URLs have the most referring domains, because those are the redirects you cannot afford to break.
In Google Analytics, snapshot organic traffic by landing page for the trailing twelve months; export the data as CSV. Do the same in Search Console: download queries, impressions, clicks, and average position for every URL. Freeze your Google Business Profile insights if you have local presence. For Canadian sites serving Quebec, verify that French-language pages are properly tagged with hreflang and that any province-specific content is catalogued. This baseline becomes your source of truth when validating the new site—if a high-equity URL disappears from the export, you know you missed a redirect.
Build a spreadsheet with two columns: legacy URL in the left, new URL in the right. Every single URL that has ever been indexed—product pages, blog posts, category archives, tag pages, author pages, paginated series—must appear. For pages that no longer have a direct equivalent, map to the closest thematic parent rather than the homepage; a discontinued product should redirect to its category, not the root domain, to preserve contextual relevance.
Implement 301 redirects at the server level—Apache .htaccess, Nginx conf, or Cloudflare Workers—rather than relying on plugin-based redirects in WordPress or Shopify, which add latency and break if the plugin is disabled. Test the redirect file in a staging environment by feeding the legacy URL list into a redirect validator script or using a batch curl command to confirm every entry returns HTTP 301 and the correct destination. Avoid wildcard redirects unless URL structures are perfectly parallel; regex mistakes can send dozens of pages to the wrong target. For large migrations with thousands of URLs, segment the redirect file by content type and validate each segment independently to isolate errors quickly.
Deploy the new site on a staging subdomain or behind HTTP basic authentication. Update your hosts file to point the production domain at the staging IP so you can crawl it as if it were live. Re-run Screaming Frog against this staging version, checking that internal links use the new URL structure, canonical tags point to the correct HTTPS version, and no legacy URLs appear in the crawl. Verify that robots.txt is not blocking critical sections—staging environments often ship with a blanket disallow that developers forget to remove.
Inspect the XML sitemap: it should list only new URLs, not legacy ones. If you are migrating to a headless CMS or JavaScript framework, ensure server-side rendering or pre-rendering is active so that Googlebot sees full HTML, not empty divs waiting for client-side hydration. Run Lighthouse and PageSpeed Insights on key templates to confirm Core Web Vitals have not regressed; a migration that tanks Largest Contentful Paint or Cumulative Layout Shift will hurt rankings even if redirects are perfect. For Canadian e-commerce sites, test checkout flows end-to-end to ensure payment gateways, shipping calculators, and tax logic—especially GST/HST/PST/QST handling—work correctly on the new platform.
Schedule the DNS or CDN cutover during your lowest-traffic window—typically early Sunday morning in the site's primary geography. Immediately after propagation, submit the new XML sitemap in Search Console and request indexing for a handful of high-priority URLs to accelerate discovery. Monitor server logs in real time: watch for 404 spikes, which indicate broken redirects, and 500 errors, which suggest server misconfiguration or resource limits.
Keep Google Analytics and Search Console open in adjacent tabs. Organic traffic should dip modestly for a few hours as Google re-crawls and re-indexes, but a freefall beyond 20 percent within the first day signals a critical error—often a robots.txt block, noindex tag left in place, or a redirect loop. Use Chrome DevTools Network panel to trace a sample of legacy URLs: confirm the 301 fires, the destination loads, and no redirect chains exceed two hops. If you have a local business and the migration includes address or NAP changes, update Google Business Profile, Apple Maps, Bing Places, and Canadian directories like YellowPages.ca and 411.ca within hours of launch to maintain citation consistency.
Leave the old server running in read-only mode for at least two weeks. Configure it to log all requests so you can identify any external links, bookmarks, or third-party integrations still hitting legacy URLs. Parse the logs daily and add missed redirects incrementally—this catch-all phase closes gaps that spreadsheet mapping inevitably overlooks. In Search Console, check the Coverage report for new 404 errors and redirect errors; fix these immediately by adding the missing redirect rules.
Track Core Web Vitals in the CrUX dashboard and PageSpeed Insights; regressions here can delay ranking recovery even if redirects are flawless. Compare organic landing-page traffic in Analytics week-over-week: URLs that previously drove significant traffic but now show zero sessions likely have broken redirects or were accidentally noindexed. Re-crawl the live site after one week to verify that Google has discovered the new URLs—check the Index Coverage report to see how many pages are indexed versus submitted. If indexation lags, fetch-and-render a few URLs in Search Console's URL Inspection tool to diagnose rendering or canonical issues. For bilingual Canadian sites, confirm that hreflang tags are firing correctly and that French-language pages are being indexed by Google.ca.
WordPress to Shopify migrations require careful SKU and slug alignment; Shopify auto-generates URLs based on product titles, so you must either customize handles in bulk CSV import or build a redirect map that accounts for Shopify's /products/ prefix. Wix and Squarespace migrations often involve hash-based URLs or dynamic parameters that cannot be preserved, forcing you to redirect legacy URLs to new clean slugs and accept that some link equity will scatter.
Headless CMS setups—Next.js, Gatsby, Nuxt—demand server-side rendering or static generation for every route; client-side navigation is fine for users but invisible to crawlers. If you are moving to a CDN-heavy architecture like Netlify or Vercel, ensure edge redirects are configured in _redirects or vercel.json and tested with HTTP header inspection. For enterprise migrations on AWS or Google Cloud, implement health checks and canary deployments: route a small percentage of traffic to the new infrastructure first, validate metrics, then roll out fully. Canadian hosting considerations include latency to major metros—Ottawa, Toronto, Montreal, Vancouver—and compliance with provincial privacy laws if you are collecting personal data; some sectors require Canadian data residency, which influences CDN and origin-server selection.
Planning and URL mapping can take two to six weeks depending on site size and complexity. The actual cutover is a single event, but post-launch monitoring and redirect refinement extend another two to four weeks. Full ranking stabilization often requires two to three months as Google re-crawls, re-indexes, and re-evaluates the new URLs against the old equity signals.
Always use 301 permanent redirects for migrations. A 302 tells search engines the move is temporary, so they continue indexing the old URL and do not transfer link equity to the new one. The only exception is a true temporary redirect, such as a maintenance page during a brief outage, which is not part of the migration itself.
Missed redirects result in 404 errors, which signal to Google that the content no longer exists. The search engine will eventually drop those URLs from the index, and any backlinks pointing to them lose their ranking value. Post-launch log monitoring helps catch these gaps so you can add the missing redirects before significant equity is lost.
Yes. Submit the new XML sitemap in Google Search Console immediately after cutover to help Google discover the new URL structure quickly. Remove or update any old sitemaps listed in Search Console to avoid confusion. Resubmitting accelerates re-indexing and reduces the window during which the old URLs remain in the index.
Yes, provided you preserve hreflang annotations on all language pairs and ensure French URLs redirect cleanly to their new French equivalents. Verify that the new site declares the correct lang attribute in the HTML tag for each language and that Search Console property settings match your targeting. Avoid redirecting French pages to English versions, as this breaks language signals and collapses distinct index entries.
If the new platform does not use parameters, strip them in your redirect rules and map the base URL to its new clean equivalent. If parameters are required for filtering or tracking, configure URL parameter handling in Search Console to tell Google which parameters to ignore for indexing purposes. Test parameter-heavy URLs individually to ensure redirects fire correctly and do not create redirect loops.