Website Migration Checklist: How to Move Your Site Without Tanking SEO

What a Website Migration Is and Why It Requires a Checklist

⠀

A website migration is any change to a website's structure, platform, URL structure, or domain that has the potential to impact how search engines discover, index, and rank your pages. The scope of migrations ranges from a domain change (moving from old-domain.com to new-domain.com) to a platform change (WordPress to Shopify) to a protocol change (HTTP to HTTPS).

What makes migrations hazardous from an SEO perspective is that search engines have spent months or years building a model of your site: which pages exist, what they contain, how they relate to each other, and how authoritative they are. A migration can disrupt this model if not executed with precision, causing temporary or permanent ranking losses.

The checklist approach to website migration is not bureaucratic caution — it's the systematic application of lessons learned from thousands of migrations. Every item on a well-designed checklist represents a mistake that has caused real ranking losses for real businesses. Following the checklist doesn't guarantee a perfect migration, but it eliminates the most common and most preventable failure modes.

⠀

Phase 1: Pre-Migration Audit and Baseline ve Website Migration

⠀

The pre-migration phase is the most critical. Decisions made (or not made) here determine the risk level of the entire operation.

Step 1: Document current organic performance.

Export your Google Search Console performance data (clicks, impressions, average position) for the past 12 months. Export from a third-party rank tracker (Semrush, Ahrefs) your current keyword rankings. This baseline allows you to detect post-migration regressions.

Step 2: Crawl the current site.

Use Screaming Frog or a similar crawler to crawl your existing site and export a complete list of all indexed URLs. This becomes your migration source list — every URL that exists on the current site needs a deliberate decision: migrate as-is, migrate to a new URL (with redirect), or retire (with redirect to closest equivalent).

Step 3: Identify high-value pages.

Cross-reference your URL list with your analytics traffic data and Search Console keyword data to identify your highest-value pages. These are the pages that require most care during migration: any disruption to their URLs or content could have disproportionate SEO impact.

Step 4: Document inbound backlinks.

Export your backlink profile (Ahrefs, Semrush, or Moz provide this data). Pages with significant inbound links have accumulated authority — their URLs need either preservation or 301 redirects. Pages with no inbound links have less at stake if their URLs change.

Step 5: Map existing redirects.

If your current site already has redirects in place, document them. The new site's redirect implementation will need to either replicate these or consolidate them into direct redirects (avoiding chains).

⠀

Phase 2: Planning the Migration

⠀

With the audit complete, you can now plan the migration with full information about what you're moving and what's at stake.

⠀

⠀

Step 6: Define the URL structure for the new site.

Decide which existing URLs will be preserved and which will change. Document the new URL format, naming conventions, and hierarchy. Get this decision approved by all stakeholders before any development work begins — changing URL decisions mid-migration creates chaos.

Step 7: Build the redirect map.

For every URL that changes, document the mapping: old URL → new URL. This spreadsheet is the implementation guide for your redirects. It should cover:

• Every page URL from your crawl that is changing

• Every URL in your inbound backlink profile

• Every URL currently returning a 404 (clean up old broken redirects)

⠀

Step 8: Plan the content migration.

Decide which content migrates exactly, which requires updates, and which will be consolidated or retired. Assign responsibility and timeline for content updates.

Step 9: Identify technical dependencies.

Document all third-party integrations (analytics, marketing tags, chat widgets, payment processors) that will need to be reconfigured for the new site. Build a configuration checklist for each.

⠀

Phase 3: Building and Testing on Staging

⠀

Never build a migration site directly on the live domain. Always use a staging environment.

Step 10: Implement the staging environment.

Configure staging with a blocked robots.txt or noindex tag to prevent search engine crawling. Staging URLs should not appear in Google's index.

Step 11: Implement all redirects.

Apply every entry in the redirect map to the new site. For platform changes, this may require server configuration, .htaccess rules, or a redirect management plugin.

Step 12: Verify redirects systematically.

Use Screaming Frog to spider your redirect map and verify that every old URL correctly 301 redirects to its intended destination. Check for redirect chains (A→B→C instead of A→C) and resolve them.

Step 13: Audit internal links.

Crawl the new site and identify any internal links pointing to old URLs that should be updated to new URLs. Internal links through redirects work but are suboptimal — direct links to canonical URLs are preferable.

Step 14: Verify technical SEO elements.

Check that all migrated pages have appropriate title tags, meta descriptions, canonical tags, and hreflang (for multilingual sites). Verify structured data markup is in place and valid.

Step 15: Test all conversion paths.

Test every form, checkout process, and conversion mechanism on staging. Ensure analytics tracking is configured for the production environment (not pointing to staging properties).

⠀

Phase 4: Launch

⠀

Step 16: Schedule migration for a low-traffic period.

If your site has traffic patterns (lower on weekends, for example), schedule the migration for your lowest-traffic period to minimize potential exposure.

Step 17: Back up everything.

Back up the live site (files and database) before making any changes. If something goes catastrophically wrong, you need a rollback option.

Step 18: Execute the DNS/server change.

Point the domain to the new server. DNS propagation can take up to 48 hours, though most resolvers update within a few hours.

Step 19: Verify robots.txt.

Immediately after launch, verify that robots.txt on the live domain is NOT blocking search engine crawlers. A robots.txt disallow mistake has caused major ranking losses for dozens of high-profile sites.

Step 20: Verify canonical tags.

Confirm canonical tags on all pages point to the live production domain, not to staging URLs.

⠀

Phase 5: Post-Launch Monitoring

⠀

⠀

⠀

Step 21: Submit updated sitemaps.

Submit an updated XML sitemap to Google Search Console immediately after launch. This accelerates the re-crawl and re-indexing process.

Step 22: Request indexing for priority pages.

Use the URL Inspection tool in Search Console to request indexing for your highest-priority pages (homepage, main service pages, top traffic pages). Don't request indexing for every page — focus on the ones where ranking recovery matters most.

Step 23: Monitor for 404 errors.

Watch the Coverage report in Search Console daily for the first two weeks. New 404 errors indicate missing redirects. Fix immediately by adding the redirect in your implementation.

Step 24: Track keyword rankings.

Compare rankings weekly against your pre-migration baseline. Some fluctuation in the first 1-2 weeks is expected. Sustained significant drops on specific pages warrant investigation of those pages specifically.

Step 25: Monitor organic traffic trends.

Compare week-over-week organic sessions to detect systemic issues. Blakfy recommends daily monitoring for the first 14 days and weekly monitoring for 90 days following any significant migration.

⠀

Frequently Asked Questions

⠀

How long does it take for rankings to stabilize after a website migration?

With a clean migration following all best practices, most ranking fluctuations resolve within two to four weeks. Google's crawl and re-indexing rate determines the timeline — larger sites with more content take longer. If significant drops persist beyond six weeks, there are likely specific technical issues requiring investigation.

Is it safe to migrate from HTTP to HTTPS without losing rankings?

Yes, if done correctly. HTTP to HTTPS migration requires: valid SSL certificate, 301 redirects from every HTTP URL to its HTTPS equivalent, updating internal links to use HTTPS, updating the preferred domain in Google Search Console, and updating the sitemap to reference HTTPS URLs. Done properly, this migration typically shows no lasting ranking impact.

Should you migrate CMS platforms and redesign visually at the same time?

Avoid combining multiple changes where possible. Separating a CMS platform migration from a visual redesign allows you to isolate the cause of any ranking changes that occur. If you must do both simultaneously, the checklist remains the same — the redirect map, pre-migration audit, and post-launch monitoring are essential regardless of scope.