How can you successfully migrate a website without losing your SEO rankings?

Why does Google emphasize separate declaration in Search Console?

When you migrate a site, Search Console treats each property as a distinct entity. If you only redirect without declaring the new URLs as an independent property, you lose the granularity of diagnostics.

Coverage reports, indexing errors, and performance data remain attached to the old property. Creating a new property allows Googlebot to quickly discover the new structure and alert you to potential configuration errors.

What’s the reasoning behind using both redirects AND canonicals?

301 redirects transfer PageRank and indicate a permanent move. Canonicals indicate which version of a URL should be indexed if multiple variants exist temporarily.

During a migration, you might have transitory duplicates or test URLs still accessible. The combination of both mechanisms covers these scenarios and speeds up the consolidation of signals. Googlebot understands faster which version to prioritize.

Is it necessary to migrate to HTTPS at the same time?

Google believes that overlaying HTTPS with a domain or structure migration does not add significant complexity for its crawlers. On the contrary, handling two successive migrations doubles the recognition time.

If you delay HTTPS, you will re-trigger a cycle of discovery, intense crawling, and signal reevaluation a few months later. It’s best to do everything at once, even if it requires heavier preparation on the infrastructure and QA side.

• Declare a new Search Console property at the start of the migration to isolate diagnostics.
• Implement 301 redirects and canonical tags to cover all cases of duplicates or transitory URLs.
• Switch to HTTPS during the migration if it hasn’t been done already, to avoid a later recognition cycle.
• Monitor coverage reports from both properties for at least 6 months to detect any anomalies.
• Keep old URLs active with redirects for at least 12 months to ensure full signal consolidation.

Is this statement aligned with field observations?

On paper, combining migration and HTTPS makes sense to reduce the total duration of instability. In practice, it has been observed that 30 to 40% of migrations that overlap these two projects experience more considerable traffic losses in the first 3 months.

Why? Because teams underestimate the validation load. Testing redirects, SSL certificates, canonicals, and new architecture simultaneously requires a discipline that many projects do not achieve. [To verify] if your technical setup and QA processes are solid before launching everything at once.

What nuances should be added to Google’s recommendation?

Google mentions “linking new URLs” without clarifying the arbitration between chained and direct redirects. On sites with several million pages, chained redirects (old URL → temporary → final) degrade the crawl time and dilute PageRank.

Always prioritize direct redirects, even if this complicates your migration plan. Canonicals should point to the final HTTPS version from day one, not an intermediate step. Otherwise, you create conflicting signals that slow down consolidation.

In what scenarios does this rule not apply?

If your site generates fewer than 10,000 organic visits per month, decoupling migration and HTTPS can reduce risks. You have the luxury of validating one transformation at a time and correcting mistakes without immediate economic pressure.

Conversely, an e-commerce site generating several million in revenue cannot afford two periods of instability. Size and business stakes dictate the strategy, not just Google’s doctrine. Let’s be honest: John Mueller speaks for the algorithm, not for your financial director.

What practical steps should you take before launching the migration?

Map out your entire current structure using a crawler (Screaming Frog, OnCrawl, Botify). Identify traffic-generating URLs via Search Console and GA4, and prioritize them in your redirect plan.

Prepare a URL mapping file (old → new) and validate it with the dev and product teams. Set up the SSL certificate in staging and test self-referencing canonicals on HTTPS before going live. Create the new Search Console property and submit an XML sitemap of the new URLs as soon as the pre-production environment is stable.

What mistakes should you avoid during the transition phase?

Do not remove the old Search Console property immediately after the migration. Keep it active for at least 6 months to compare metrics and detect missing redirects or 404 errors.

Avoid temporary redirects 302 or 307: only 301 effectively transfers PageRank. Never redirect to the default homepage if the thematic equivalent exists elsewhere in the new structure. And above all, do not initiate the migration on a Friday night or during peak seasonal periods.

How can you verify that the migration is going smoothly?

Monitor coverage and indexing reports daily in both Search Console properties. Compare the volume of indexed pages before/after, and track impressions and clicks over time.

Use a crawler to ensure that 100% of old URLs return a 301 status, and that the canonicals point to HTTPS. Check the server logs to identify URLs still crawled by Googlebot on the old domain: this indicates backlinks or sitemaps that have not been updated. Prioritize correcting these.

• Create a separate Search Console property for the new URLs before migration.
• Implement direct 301 redirects (no chains) to the new HTTPS URLs.
• Add self-referencing canonicals in HTTPS on all pages of the new structure.
• Submit a complete XML sitemap of the new URLs as soon as you go live.
• Keep the old Search Console property active for at least 6 months to compare diagnostics.
• Monitor server logs and indexing reports daily for 3 months.