Website Migration SEO Checklist: Before, During, and After Launch

Website migrations are among the highest-risk SEO activities you can undertake. A single misconfiguration—a forgotten redirect, an overlooked canonical tag, or a premature robots.txt change—can cost you thousands of dollars in lost organic traffic. Yet migrations are often unavoidable. Whether you're moving to a new platform, consolidating domains, implementing a redesign, or upgrading your infrastructure, the stakes are real and the margin for error is thin.

At OSTER Tech, we've executed migrations for dozens of clients across various platforms: WordPress to headless architectures, legacy Magento systems to modern Shopify stores, domain consolidations affecting 50,000+ pages, and complex international site restructurings. We've also learned from our mistakes. We once forgot to update internal link anchors during a major WordPress redesign—traffic dropped 12% for three weeks before we identified and fixed the issue. That painful experience taught us that migrations require systematic planning, not just technical execution.

This guide provides a battle-tested, 40-point framework that de-risks the migration process. You'll learn exactly what to audit before migration, how to set up technical infrastructure correctly, what to monitor during execution, and how to verify success afterward. More importantly, you'll understand why each step matters and what happens when you skip it.

Why Website Migrations Fail (And How to Protect Your SEO)

The statistics on migration failures are sobering. Industry research indicates that approximately 40-60% of website migrations result in measurable organic traffic loss. Some of that loss is temporary and recovers within weeks. But many sites experience sustained ranking drops that persist for months, and some never fully recover the traffic they lost.

The consequences of failed migrations extend beyond immediate traffic loss. When migrations go wrong, you typically experience:

• Ranking drops across multiple keywords, sometimes affecting 30-50% of your previously ranked keywords
• Indexation delays where Google takes weeks to index new URLs, leaving your content invisible in search results
• Crawl errors and 404s that cascade through your site, wasting crawl budget on broken pages
• Loss of link equity when redirects aren't properly configured or when internal links point to old URLs
• Core Web Vitals degradation if new infrastructure isn't properly optimized for performance
• Structural data loss when schema markup isn't preserved or re-implemented on new pages
• Trust signal erosion as external sites continue linking to old URLs that may eventually be removed

Why are migrations so risky? Because they require simultaneous coordination of four complex systems: URL structure changes, redirect infrastructure, technical configuration (robots.txt, sitemaps, canonical tags), and content preservation. A mistake in any one system cascades through the others. Change your URL structure without updating internal links, and you've created unnecessary redirect chains. Implement redirects without updating your XML sitemap, and Google won't discover your new URLs quickly. Forget to preserve structured data, and you lose rich snippet eligibility.

This guide provides a systematic framework that addresses all four systems simultaneously. We've organized it into four phases—pre-migration planning, technical setup, execution, and post-migration verification—each with specific, actionable tasks.

The framework covers multiple migration scenarios: domain migrations (old.com → new.com), platform migrations (WordPress to Shopify), structural changes (blog.site.com → site.com/blog), HTTP to HTTPS transitions, and comprehensive redesigns with URL changes. Whether your migration is simple (a few hundred pages) or complex (50,000+ pages with international variations), this framework scales to your situation.

Phase 1: Pre-Migration Planning & Audit (4-6 Weeks Before)

The difference between successful migrations and failed ones often comes down to planning. We've noticed that clients who invest 4-6 weeks in comprehensive pre-migration audit and planning experience 60-70% fewer issues during execution. Those who skip this phase and rush into technical implementation face constant firefighting.

Conduct a Comprehensive SEO Audit of Your Current Site

Before you move a single page, you need to understand exactly what you're moving. Start by exporting your complete ranking data from Google Search Console. Go to Performance > Queries and export your full dataset (not just the top 1,000 rows). You need to see every keyword you're currently ranking for, including position, impressions, and click-through rate. This becomes your baseline for post-migration comparison.

Next, use a tool like Screaming Frog SEO Spider to crawl your entire current site. Document:

• Total number of URLs
• URL structure and patterns
• Redirect chains that already exist
• Broken internal links
• Pages with missing or duplicate title tags and meta descriptions
• Heading hierarchy issues
• Structured data implementation (schema markup)
• Internal linking patterns and link equity distribution

This audit serves two purposes: it identifies technical debt that you should fix during migration (not perpetuate), and it creates a baseline for post-migration comparison.

Create a Comprehensive URL Mapping Document

This is the single most critical document for your migration. You need a spreadsheet that maps every old URL to its corresponding new URL. This isn't optional or approximate—it needs to be complete and accurate.

For straightforward migrations (e.g., www.old.com → www.new.com with the same URL structure), you can automate this mapping. For more complex scenarios (e.g., changing your URL structure or consolidating pages), you need to manually review and create mappings.

Your URL mapping document should include:

• Old URL (complete, with protocol)
• New URL (complete, with protocol)
• Current ranking position (from GSC data)
• Current traffic (from Analytics)
• Redirect type (301 vs. 302 vs. canonical)
• Notes (e.g., "consolidating into parent category," "deleting low-traffic page," "splitting into two pages")

This document becomes the source of truth for your redirect implementation. Without it, you'll inevitably miss pages or create incorrect redirects.

Analyze Your Backlink Profile

Use a tool like Ahrefs or SEMrush to export your complete backlink profile. Identify:

• High-authority external links (Domain Authority 40+)
• Links from competitor sites
• Links from industry-relevant sites
• Anchor text distribution (which keywords are you getting linked for)
• Referring domains (quantity and quality)

The reason this matters: when you migrate URLs, you need to ensure that external links continue to pass authority to your new URLs. If an external site links to old-url.com/page-1, that link needs to redirect to new-url.com/page-1. If you're changing your URL structure, that old link will redirect to a different new URL, which might not be ideal but is better than losing the link entirely.

Document any high-authority links that are particularly valuable. These are the pages you absolutely cannot afford to break during migration.

Audit Your Internal Linking Structure

Export a complete list of all internal links on your current site. Document:

• Which pages link to which pages
• Anchor text used in internal links
• Pages with the most internal links (high link equity pages)
• Orphaned pages (pages with no internal links pointing to them)

This analysis helps you understand link equity flow. During migration, you want to preserve this flow as much as possible. If a page currently has 50 internal links pointing to it, you want those links to follow to the new URL without unnecessary redirect hops.

Establish Success Metrics and Baseline Data

Before you migrate, define what success looks like. Document:

• Current organic traffic (month-over-month average)
• Current ranking distribution (how many keywords in top 3, top 10, top 20)
• Current indexation rate (number of pages indexed in GSC)
• Current crawl errors (4xx, 5xx errors in GSC)
• Current Core Web Vitals scores
• Current conversion metrics (if applicable)

These baselines allow you to measure migration impact objectively. Post-migration, you'll compare these metrics to determine whether the migration was successful.

Align Stakeholders and Document Migration Goals

Migrations require coordination across multiple teams: marketing, development, infrastructure, content, and leadership. Before you begin technical work, ensure everyone understands:

• Why the migration is happening (platform change, domain consolidation, performance improvement, etc.)
• What the timeline is (when planning starts, when technical setup begins, when execution happens)
• What success looks like (specific metrics that will be measured)
• What the risks are (potential for temporary traffic loss, ranking fluctuation)
• Who is responsible for each task
• How communication will happen during execution

This alignment prevents mid-migration surprises and ensures everyone is working toward the same goal.

Phase 2: Pre-Migration Technical Setup (2-4 Weeks Before)

With planning complete, you now prepare the technical infrastructure for migration. This phase is where most technical mistakes happen. Rushing through it or skipping steps creates problems that cascade during execution.

Set Up New Hosting and Infrastructure

Your new infrastructure should meet or exceed the performance specifications of your current site. This means:

• Server response time comparable to or better than current site
• Adequate bandwidth and server resources to handle your traffic
• Geographic distribution (CDN) if your current site uses it
• SSL certificate (HTTPS) properly configured
• Server-side monitoring and error tracking enabled

Many migrations experience Core Web Vitals degradation because the new infrastructure is slower than the old one. This is preventable with proper setup.

Implement 301 Redirects on the Old Server (Before Migration)

This is critical: implement and test all redirects on your old server before you migrate. Don't wait until migration day to discover that your redirect logic is broken.

Create a redirect map based on your URL mapping document. For each old URL, implement a 301 (permanent) redirect to the corresponding new URL. Why 301 and not 302? A 301 tells search engines that the page has permanently moved, and link equity should transfer to the new URL. A 302 tells search engines the move is temporary, and they should keep crawling the old URL. For migrations, you almost always want 301 redirects.

Test these redirects thoroughly in a staging environment before they go live. Use a tool like Screaming Frog to verify:

• All redirects return 301 status codes (not 302 or other codes)
• No redirect chains exist (old URL should redirect directly to new URL, not through intermediate URLs)
• Redirect destinations are correct (spot-check 50+ random redirects)
• No redirect loops exist (URL A redirects to URL B, which redirects back to URL A)

We once implemented a redirect system that accidentally created redirect chains for 5,000 pages. Pages that should have been old → new were instead old → intermediate → new. This wasted crawl budget and slowed page load times for users clicking old links. The fix took two days and could have been prevented with proper testing.

Configure New Site Structure and URL Patterns

If you're changing your URL structure (e.g., from /blog/category/post-title to /posts/post-title), make this decision consciously and document the logic. Changing URL structure loses some semantic SEO value from the old URLs, so only do it if there's a strategic reason.

If you're keeping the same URL structure, ensure the new site implements it identically to the old site. Inconsistencies (trailing slashes, capitalization, parameter order) create unnecessary redirect complexity.

Preserve and Improve On-Page SEO Elements

Your new site should preserve all valuable on-page SEO elements from your old site:

• Title tags (copy from old site unless you're improving them)
• Meta descriptions (copy from old site unless you're improving them)
• Heading hierarchy (H1, H2, H3 structure should be preserved)
• Schema markup (copy structured data from old site, update URLs as needed)

This is an opportunity to improve weak on-page elements. If you have title tags that are too short or meta descriptions that aren't compelling, update them during migration. But don't change them indiscriminately—changes to high-traffic pages can temporarily impact rankings.

Update All Internal Links to Point to New URLs

This is the step that many teams skip, and it's a costly mistake. If your new site has internal links pointing to old URLs, those links will trigger redirects. Each redirect adds latency, wastes crawl budget, and creates unnecessary hops in your link equity flow.

Before migration, update all internal links in your new site to point to new URLs. This requires:

• Identifying all internal links in your new site (use Screaming Frog)
• Updating link destinations to new URLs
• Testing that all internal links work correctly
• Verifying no broken internal links exist

This is particularly important for navigation menus, footer links, and other sitewide elements that appear on every page.

Implement Canonical Tags Correctly

On your new site, implement self-referential canonical tags on every page:

<link rel="canonical" href="https://new-domain.com/new-url/" />

The canonical tag should point to the new URL, not the old URL. The purpose of the canonical tag is to tell search engines which version of a page is the "official" version. If you point canonical tags to old URLs, you create confusion about which version should be indexed.

Do not use canonical tags to redirect from old URLs to new URLs. That's what 301 redirects are for. Canonical tags are for managing duplicate content, not for migrations.

Create Updated XML Sitemaps

Create new XML sitemaps for your new site that include all new URLs. Your sitemaps should:

• Include every important page on your new site
• Exclude low-value pages (thin content, duplicate content, admin pages)
• Be valid XML (test with Google's Sitemap Validator)
• Be submitted to Google Search Console
• Be referenced in your robots.txt file

Do not include old URLs in your new site's sitemaps. The purpose of sitemaps is to help Google discover your new URLs quickly.

Update robots.txt for Your New Site

Your new site's robots.txt should:

• Allow crawling of all important pages
• Disallow crawling of admin pages, staging environments, duplicate content
• Reference your XML sitemap location
• Be tested to ensure it doesn't accidentally block important pages

A common mistake: teams migrate to a new site and implement an overly restrictive robots.txt that accidentally blocks important content. Always test your robots.txt against your URL structure to ensure it's not blocking pages you want indexed.

Set Up 404 Monitoring and Error Tracking

Before migration, set up monitoring to catch 404 errors immediately:

• Configure server-side error logging to capture all 404s
• Set up alerts that notify you when 404 rate exceeds a threshold
• Create a process for identifying missed redirects and implementing fixes quickly

This is your safety net. Despite careful planning, you'll inevitably miss some redirects or have edge cases that weren't accounted for. Quick detection and remediation minimize impact.

Test Everything in a Staging Environment

Before anything goes live, test your entire migration in a staging environment:

• Verify all redirects work (spot-check 100+ random redirects)
• Verify all internal links work
• Verify canonical tags are correct
• Verify structured data is valid (use Google's Rich Results Test)
• Verify robots.txt allows crawling of important pages
• Verify XML sitemaps are valid and complete
• Verify page rendering is correct on desktop and mobile
• Verify Core Web Vitals scores meet targets
• Verify no crawl errors appear in GSC when you crawl the staging site

The goal of staging testing is to find and fix problems before they affect your live site. Any issue discovered in staging is easy to fix. The same issue discovered after migration is a crisis.

Verify Core Web Vitals Performance

Before migration, benchmark your Core Web Vitals scores. Your new site should meet or exceed these scores. Use tools like:

• PageSpeed Insights (Google's official tool)
• Web Vitals Chrome extension
• Your hosting provider's performance monitoring tools

If your new site's Core Web Vitals are worse than your old site's, optimize before migration. Core Web Vitals are ranking factors, and degradation post-migration will impact your rankings.

Phase 3: Migration Execution & Monitoring (Migration Day + First 48 Hours)

Migration day is when all your planning either pays off or falls apart. The key to successful execution is preparation and real-time monitoring. This phase is short (48 hours), but it's intense.

Create a Final Complete Backup

Before anything changes, create a complete backup of your old site. This includes:

• Full database backup
• Complete file system backup
• Configuration files and environment variables
• SSL certificates
• DNS records

Store this backup in multiple locations. If migration goes catastrophically wrong, you need to be able to restore your old site within hours.

Plan Your DNS Cutover Strategy

DNS changes are the moment of truth for domain migrations. Plan this carefully:

• Choose a time when your team can monitor continuously (not Friday afternoon, not before a holiday)
• Plan the exact steps you'll take to change DNS records
• Identify who will make the DNS changes
• Have a rollback plan (revert DNS to old site if critical issues emerge)
• Notify your hosting provider and any CDN providers
• Set TTL (Time To Live) on DNS records to a low value (300-600 seconds) before migration, so changes propagate quickly

For platform migrations (not domain migrations), DNS usually isn't involved. Instead, you're redirecting at the application level or server level. The principle is the same: have a clear cutover plan and be ready to rollback if needed.

Monitor Google Search Console in Real-Time

For the first 48 hours post-migration, check GSC every 2-4 hours. Look for:

• Coverage report: Are new URLs being discovered and indexed?
• Crawl errors: Are there 4xx or 5xx errors? (Some errors are normal; spikes are concerning)
• Mobile usability: Are there mobile rendering issues?
• Core Web Vitals: Have performance metrics degraded?
• Security issues: Are there security warnings?
• Rich results: Are structured data issues appearing?

If you see concerning trends (e.g., hundreds of 404 errors, coverage dropping instead of growing), investigate immediately. These are signs that something went wrong and needs fixing.

Spot-Check Redirect Functionality

Pick 50-100 random old URLs and verify they redirect correctly to new URLs. Use a tool like:

• Screaming Frog (crawl old site, verify redirects work)
• Browser address bar (manually test critical pages)
• Redirect checker tools (online tools that verify redirects)

If you find broken redirects, fix them immediately. Each broken redirect is a page that will 404, waste crawl budget, and potentially lose ranking.

Verify Indexation Rate and Speed

Monitor how quickly Google indexes your new URLs. In GSC Coverage report, you should see:

• Rapid growth in "Valid" URLs (indexed pages)
• Minimal or zero "Excluded" URLs (unless you intentionally excluded them)
• Minimal "Error" URLs (some errors are normal during migration; significant errors are concerning)

Indexation should accelerate over the first 48 hours as Google discovers your new URLs through redirects and sitemaps. If indexation is stalled (e.g., only 10% of URLs indexed after 48 hours), there's likely an issue with your redirects, sitemaps, or robots.txt.

Monitor Server Errors and Response Times

Watch your server logs for errors:

• 5xx errors (server errors) should be near zero
• 4xx errors (not found) should be limited to pages you intentionally removed
• Response times should be consistent with pre-migration performance
• Traffic patterns should match expectations

If you see unusual error spikes or response time degradation, investigate immediately. These can indicate infrastructure issues or redirect logic problems.

Verify Structured Data Implementation

Use Google's Rich Results Test to verify that your schema markup is correct on new pages. Check:

• Product schema (if you have e-commerce)
• Article schema (if you have content pages)
• Organization schema (if you have it)
• Other structured data relevant to your site

Structured data issues don't break your site, but they do prevent rich snippets from appearing in search results. Fix any validation errors within the first 24 hours.

Check Mobile Rendering

In GSC, check the Mobile Usability report for issues:

• Text too small to read
• Clickable elements too close together
• Content wider than viewport
• Unplayable media

Mobile rendering issues are usually caught in staging testing, but verify they didn't reappear in production.

Set Up Real-Time Analytics Alerts

Configure alerts in Google Analytics 4 for traffic anomalies:

• Alert if organic traffic drops more than 20% compared to the previous day
• Alert if bounce rate increases more than 25%
• Alert if conversion rate drops more than 15%

These alerts help you catch migration-related issues immediately rather than discovering them days later.

Communicate Status to Stakeholders

Send status updates to your stakeholder group:

• Initial update: migration is live, initial monitoring looks good
• 4-hour update: indexation progress, any issues found and fixed
• 24-hour update: comprehensive status on redirects, indexation, traffic, errors
• 48-hour update: final status, any remaining issues, next steps

Clear communication prevents panic and keeps everyone aligned on what's happening.

Prepare for Rollback

If critical issues emerge (e.g., 50%+ traffic loss, widespread 404 errors, complete indexation failure), you may need to rollback to your old site. Have a rollback plan prepared:

• DNS revert procedure (if domain migration)
• Application-level revert procedure (if platform migration)
• Estimated time to rollback (should be under 1 hour)
• Communication plan (how you'll notify stakeholders)

Rollback should be a last resort, but it's better to have the option and not need it than to need it and not have it.

Phase 4: Post-Migration Verification (First 2-4 Weeks)

Migration execution is complete, but verification continues for 2-4 weeks. This phase is where you confirm that the migration was successful and address any emerging issues.

Understand Ranking Recovery Timeline

Expect rankings to fluctuate post-migration. Most sites experience:

• Days 1-3: Significant fluctuation as Google re-crawls and re-indexes pages
• Days 4-7: Stabilization of most rankings, though some volatility continues
• Weeks 2-3: Most rankings settle into their new positions (which may be slightly different from pre-migration)
• Weeks 4-8: Final stabilization

Some rankings may improve (if your new site is faster or has better content), and some may decline (if you made changes that weren't beneficial). This is normal.

The important metric is overall trend: is your traffic recovering toward pre-migration levels? Or is it continuing to decline? A V-shaped recovery (dip then recovery) is normal. A sustained decline is concerning.

Compare Traffic to Pre-Migration Baseline

Compare your post-migration traffic to your pre-migration baseline, accounting for seasonality. If your baseline was 10,000 organic sessions per week, and you're seeing 9,500 sessions in week 1 post-migration, that's a 5% dip—probably acceptable. If you're seeing 7,000 sessions, that's a 30% drop—concerning and worth investigating.

Use Google Analytics to compare:

• Organic traffic (sessions, users, sessions per user)
• Conversion rate
• Bounce rate
• Average session duration
• Pages per session

Compare week-over-week to account for daily fluctuations. Day-over-day comparisons can be misleading due to traffic variance.

Analyze Crawl Budget Efficiency

In GSC, check the Crawl Stats report:

• How many URLs is Google crawling per day?
• Is the crawl rate appropriate for your site size?
• Are you seeing unnecessary crawl of 404s or redirects?

If Google is crawling 5,000 URLs per day but you only have 2,000 URLs on your site, that indicates redirect chains or 404s that are wasting crawl budget. Fix these immediately.

Verify Indexation Rate

In GSC Coverage report, check:

• What percentage of your URLs are indexed?
• Are important pages indexed?
• Are unimportant pages correctly excluded?

You should see 90-95%+ of important URLs indexed within 2 weeks. If you're below 80%, there's likely an issue with your redirects, robots.txt, or sitemaps.

Identify and Fix Missed Redirects

Despite careful planning, you'll inevitably miss some redirects. Use your 404 monitoring to identify them:

• Check your server logs for 404 errors on old URLs
• Check GSC Coverage report for URLs with "Not Found" errors
• Check your monitoring tools for 404 spikes

For each missed redirect, determine:

• Should this URL be redirected to a new URL?
• Should this URL be deleted (410 Gone status)?
• Should this URL be kept as-is (if it's already a 404)?

Implement fixes for important pages within the first week.

Audit for Redirect Chains

Use Screaming Frog to crawl your old site and verify that no redirect chains exist:

• Crawl old site with settings to follow redirects
• Verify each redirect goes directly to a final destination (not through intermediate redirects)
• Look for redirect chains like: old URL → intermediate URL → new URL

If you find redirect chains, fix them by updating the intermediate redirect to point directly to the final destination.

Scan for Broken Internal Links

Use Screaming Frog to crawl your new site and identify broken internal links:

• Crawl new site
• Look for internal links that return 404 or 5xx errors
• Identify pages with these broken links

For each broken link, determine whether it should be:

• Updated to point to the correct new URL
• Removed entirely
• Redirected to a related page

Fix important broken links within the first week.

Verify External Links Are Working

Use GSC to check Links report:

• Are external links being recognized on your new URLs?
• Are referring domains linking to your new site?
• Is link equity transferring correctly through redirects?

If you see a significant drop in recognized external links, there's likely an issue with your redirects or domain migration setup.

Monitor Core Web Vitals

Check PageSpeed Insights or your hosting provider's monitoring to verify Core Web Vitals:

• Largest Contentful Paint (LCP)
• First Input Delay (FID) or Interaction to Next Paint (INP)
• Cumulative Layout Shift (CLS)

Compare post-migration scores to pre-migration scores. If scores have degraded significantly, optimize your new site's performance.

We've found that many migrations experience Core Web Vitals degradation because teams optimize for functionality but not performance during the transition. This is preventable with proper performance monitoring during Phase 2 setup.

Check Search Appearance

In GSC, check how your pages appear in search results:

• Are title tags displaying correctly?
• Are meta descriptions showing?
• Are rich snippets appearing?
• Are featured snippets showing?

If appearance has changed negatively (e.g., rich snippets disappeared), there's likely an issue with your structured data or title/meta tags.

Monitor Competitor Activity

While you're managing your migration, competitors may be gaining ground. Use tools like SEMrush or Ahrefs to check:

• Did competitors gain rankings during your migration window?
• Did competitors gain traffic?
• Are there new competitors targeting your keywords?

This helps you understand whether any traffic loss is due to your migration or due to competitive activity.

Continue Monitoring for 4-8 Weeks

Don't declare the migration "complete" after 2 weeks. Continue monitoring for 4-8 weeks to ensure:

• Rankings have stabilized
• Traffic has recovered to pre-migration levels (or improved)
• No new issues are emerging
• Crawl errors have been resolved
• Indexation rate remains stable

Many post-migration issues emerge slowly over weeks, not immediately. Ongoing monitoring helps you catch and fix these issues before they become major problems.

Critical Checklist: The 40-Point Migration Framework

Use this checklist to track progress and assign ownership. Each item should be completed and verified before moving to the next phase.

Pre-Migration Phase (Items 1-10)

1. Export GSC Performance Data: Export complete ranking data from Google Search Console (all keywords, positions, impressions, clicks)
2. Crawl Current Site: Use Screaming Frog to crawl entire current site and document technical baseline
3. Export Backlink Profile: Export complete backlink data from Ahrefs/SEMrush and identify high-authority links
4. Create URL Mapping Document: Document every old URL → new URL mapping with ranking and traffic data
5. Analyze Internal Linking: Document current internal linking structure and link equity distribution
6. Establish Success Metrics: Define baseline metrics (traffic, rankings, indexation rate, Core Web Vitals) for post-migration comparison
7. Audit Current Technical SEO: Document current Core Web Vitals, mobile-friendliness, structured data, robots.txt, sitemaps
8. Identify Content Gaps: Document pages to consolidate, thin content to improve, new pages to create
9. Stakeholder Alignment: Ensure all stakeholders understand migration goals, timeline, risks, and success metrics
10. Document Migration Goals: Clearly articulate why migration is happening and what success looks like

Technical Setup Phase (Items 11-20)

11. Set Up New Infrastructure: Configure new hosting/platform with performance specifications equal to or better than current site
12. Implement 301 Redirects: Create redirect map based on URL mapping document and implement on old server
13. Test Redirects in Staging: Verify all redirects work correctly, no chains, correct destinations (spot-check 100+ redirects)
14. Configure New URL Structure: Ensure new site implements URL structure consistently (if changing structure, document rationale)
15. Preserve On-Page SEO: Copy title tags, meta descriptions, heading hierarchy, schema markup to new site
16. Update Internal Links: Update all internal links in new site to point to new URLs (not old URLs)
17. Implement Canonical Tags: Add self-referential canonical tags to every page on new site
18. Create XML Sitemaps: Create new sitemaps for new site with all important URLs listed
19. Update robots.txt: Configure robots.txt for new site to allow crawling of important pages
20. Set Up Error Monitoring: Configure 404 monitoring and error tracking for new site

Additional Setup Phase (Items 21-25)

21. Create Staging Environment: Set up staging version of new site and test all changes before production
22. Verify Structured Data: Use Google Rich Results Test to verify schema markup is valid and complete
23. Test Mobile Rendering: Verify new site renders correctly on mobile devices
24. Benchmark Core Web Vitals: Measure Core Web Vitals scores and ensure they meet or exceed current site
25. Create Backup: Create complete backup of old site before migration day

Execution Phase (Items 26-30)

26. Execute DNS Cutover (if domain migration): Change DNS records according to plan, monitor propagation
27. Monitor GSC Real-Time: Check Google Search Console every 2-4 hours for 48 hours, watching for crawl errors and indexation
28. Spot-Check Redirects: Verify 50-100 random old URLs redirect correctly to new URLs
29. Monitor Server Performance: Watch server logs for errors and response times, ensure no spike in 5xx errors
30. Send Status Updates: Communicate migration status to stakeholders at regular intervals

Post-Migration Phase (Items 31-40)

31. Verify Indexation Rate: Check GSC Coverage report, confirm 90%+ of important URLs are indexed within 2 weeks
32. Identify Missed Redirects: Check 404 monitoring, server logs, and GSC for missed redirects
33. Fix Redirect Chains: Audit for redirect chains and fix any found within first week
34. Scan for Broken Internal Links: Use Screaming Frog to identify broken internal links and fix important ones
35. Verify External Links: Check GSC Links report to confirm external links are being recognized on new URLs
36. Monitor Core Web Vitals: Compare post-migration Core Web Vitals to pre-migration baseline
37. Check Search Appearance: Verify title tags, meta descriptions, rich snippets display correctly in search results
38. Compare Traffic Baseline: Compare post-migration traffic to pre-migration baseline, accounting for seasonality
39. Analyze Ranking Recovery: Check if rankings have stabilized and recovered to pre-migration levels
40. Plan Ongoing Monitoring: Set up 4-8 week monitoring schedule to catch any emerging issues

Common Migration Mistakes & How to Avoid Them

We've made these mistakes ourselves or seen them made by clients. Learning from these failures will save you significant headache.

Mistake #1: Using 302 Redirects Instead of 301 Redirects

The difference between 301 and 302 redirects seems minor but has major SEO implications:

• 301 (Permanent): Tells search engines the page has permanently moved. Link equity transfers to the new URL. Google updates its index to show the new URL.
• 302 (Temporary): Tells search engines the page has temporarily moved. Link equity does NOT transfer. Google keeps crawling the old URL.

For migrations, you almost always want 301 redirects. If you use 302 redirects, you lose link equity from external links, and Google takes much longer to recognize that pages have moved. Rankings suffer as a result.

How to avoid it: Explicitly specify 301 redirects in your redirect implementation. Verify redirect status codes with Screaming Frog (should show 301, not 302).

Mistake #2: Creating Redirect Chains

Redirect chains happen when old URL redirects to an intermediate URL, which redirects to the final URL. Example:

• old-url.com/page → intermediate-url.com/page → new-url.com/page

Redirect chains waste crawl budget (Google has to follow multiple hops), slow down user experience (extra network requests), and distribute link equity inefficiently. We once had a client with 5,000 pages caught in redirect chains. It took two days to identify and fix.

How to avoid it: When implementing redirects, verify that each redirect goes directly to its final destination. Use Screaming Frog to audit for redirect chains. If you find chains, update the intermediate redirect to point directly to the final destination.

Mistake #3: Forgetting to Update Internal Links

If your new site has internal links pointing to old URLs, those links will trigger redirects. Each redirect adds latency and wastes crawl budget. Example:

• Navigation menu has link to /old-page
• User clicks link, browser requests /old-page
• Server redirects to /new-page
• Browser loads /new-page

This works but is inefficient. The correct approach:

• Navigation menu has link to /new-page
• User clicks link, browser requests /new-page directly
• No redirect necessary

How to avoid it: Before migration, update all internal links in your new site to point to new URLs. Use Screaming Frog to find all internal links and verify they point to correct destinations.

Mistake #4: Not Updating XML Sitemaps

If your XML sitemaps still list old URLs after migration, Google will try to crawl those old URLs. If they're not properly redirected, you'll see 404 errors in GSC. Even if redirects are working, Google wastes crawl budget on old URLs.

How to avoid it: Create new XML sitemaps for your new site with new URLs. Submit updated sitemaps to Google Search Console. Remove old sitemaps from your robots.txt.

Mistake #5: Changing robots.txt Too Aggressively

A common mistake: teams migrate to a new site and configure robots.txt to block too much content. Example:

• robots.txt disallows /category/ pages (thinking they're low-value)
• But /category/ pages are important for internal navigation and have external links
• Google can't crawl them, so they don't get indexed
• Rankings for those pages disappear

How to avoid it: Test your robots.txt thoroughly before migration. Use Google's Robots.txt Tester to verify it allows crawling of important pages. Be conservative—only disallow content you're absolutely certain should be blocked.

Mistake #6: Not Monitoring GSC Post-Migration

If you don't monitor Google Search Console after migration, you won't see crawl errors, indexation issues, or other problems until days or weeks later. By then, damage is done.

How to avoid it: Set up real-time monitoring of GSC immediately post-migration. Check Coverage report, Crawl Errors report, and Mobile Usability report every 2-4 hours for the first 48 hours. Set up alerts for concerning metrics.

Mistake #7: Changing URL Structure Without Strategic Reason

Changing your URL structure (e.g., from /category/post-name to /posts/post-name) loses some semantic SEO value from the old URLs. URL structure contributes to SEO, so unnecessary changes can hurt rankings.

How to avoid it: Only change URL structure if there's a clear strategic reason (e.g., old structure is illogical, new structure better serves user experience, new platform requires different structure). If you keep the same structure, you avoid this risk entirely.

Mistake #8: Migrating Without a Rollback Plan

If migration goes catastrophically wrong and you don't have a rollback plan, you're in crisis mode with no recovery option. We've seen clients lose days of traffic trying to fix issues that could have been resolved by reverting to the old site.

How to avoid it: Before migration, create a detailed rollback plan. Document exactly how you'll revert DNS, application configuration, or database changes. Practice the rollback procedure in staging to ensure it works. Have the plan documented and accessible during migration.

Mistake #9: Not Preserving Structured Data

Structured data (schema markup) enables rich snippets in search results. If you lose structured data during migration, you lose rich snippet eligibility, which can reduce click-through rate from search results.

How to avoid it: Before migration, audit all structured data on your current site. During migration, copy structured data to new site and update URLs as needed. After migration, use Google Rich Results Test to verify structured data is valid on new pages.

Mistake #10: Rushing the Timeline

Migrations always take longer than expected. If you rush the timeline, you skip testing, miss edge cases, and create preventable problems. We've seen clients try to migrate in one week and spend the next month fixing issues that could have been prevented with proper planning.

How to avoid it: Plan for 4-6 weeks of pre-migration planning, 2-4 weeks of technical setup, and 4-8 weeks of post-migration monitoring. Build in buffer time for unexpected issues. Don't try to compress the timeline—the time you save in planning gets lost (multiplied) in post-migration firefighting.

Migration-Specific Scenarios: Platform-by-Platform Guidance

Different platforms and migration types have specific considerations. Here's guidance for common scenarios.

WordPress to Headless/Modern Framework Migration

When migrating from WordPress to a headless architecture (e.g., Next.js, Nuxt, Astro):

• Initially preserve WordPress URLs to minimize redirect complexity
• Implement headless frontend that mirrors WordPress URL structure
• After stabilization, gradually migrate to new URL structure if desired
• Preserve all WordPress metadata (custom fields, post meta) that might be relevant to SEO
• Ensure RSS feeds are preserved or properly redirected
• Update any WordPress-specific integrations (plugins, webhooks, APIs)

Shopify Migration Considerations

When migrating to Shopify or between Shopify stores:

• Product URL changes require careful redirect planning (products often have variants with different URLs)
• Preserve product reviews and ratings through Shopify's import tools or third-party services
• Update canonical tags for product variants (variants often have duplicate content)
• Implement proper hreflang tags for multi-currency/multi-language product pages
• Preserve product schema markup (price, availability, rating, review)
• Test product filtering and sorting URLs to ensure they don't trigger unnecessary redirects

Magento to Shopify Migration

Magento to Shopify migrations are complex due to significant structural differences:

• Magento category URLs often don't map directly to Shopify collections
• Product attribute URLs in Magento may not exist in Shopify
• Implement comprehensive redirect strategy for categories and attributes
• Preserve product descriptions and metadata during import
• Test and verify all product images and media migrate correctly
• Update any custom URLs or URL rewrites from Magento configuration

Custom Platform Migration

When migrating from a custom-built platform to another custom platform:

• Create comprehensive URL mapping for all pages and dynamic content
• Test redirect logic thoroughly before implementation (custom redirects often have bugs)
• Verify all database migrations are complete and accurate
• Test all dynamic content generation (ensure URLs generate correctly)
• Implement extensive monitoring for 404s and errors (custom platforms often have edge cases)

Domain Migration (old.com → new.com)

When changing domains entirely:

• Implement 301 redirects from all old domain URLs to corresponding new domain URLs
• Update Google Search Console to reflect new domain property
• Update all internal links to point to new domain
• Request reindexing of new domain in GSC
• Update XML sitemaps to reference new domain
• Update robots.txt on both old and new domains (old domain should redirect, new domain should allow crawling)
• Update canonical tags to point to new domain
• This is one of the highest-risk migration types; plan for 4-8 weeks of monitoring

Subdomain to Subdirectory Migration (blog.site.com → site.com/blog)

When consolidating a subdomain into a subdirectory:

• Implement 301 redirects from all blog.site.com URLs to site.com/blog URLs
• Consolidate link equity (subdirectory will benefit from parent domain authority)
• Update internal links to point to new subdirectory URLs
• Verify sitemaps are updated to reflect new structure
• This typically results in ranking improvements due to authority consolidation

HTTP to HTTPS Migration

When upgrading from HTTP to HTTPS:

• Implement 301 redirects from all HTTP URLs to HTTPS equivalents
• Install SSL certificate on new HTTPS infrastructure
• Update all internal links to use HTTPS
• Update XML sitemaps to reference HTTPS URLs
• Update robots.txt to reference HTTPS URLs
• Update canonical tags to point to HTTPS URLs
• This is typically one of the lower-risk migrations if executed properly

Tools & Resources for Migration Success

These tools are recommendations based on our experience, not endorsements. Choose tools based on your platform, budget, and specific needs.

Google Search Console (Free)

Google Search Console is your primary tool for monitoring migration. Use it to:

• Monitor crawl errors and coverage
• Check indexation rate
• Review search appearance
• Track rankings through Performance report
• Submit XML sitemaps
• Request reindexing

Screaming Frog SEO Spider (Paid, approximately $99-199 per year)

Screaming Frog is invaluable for migration audits:

• Crawl old and new sites to identify technical issues
• Verify redirects work correctly
• Find broken internal links
• Audit on-page SEO elements
• Export comprehensive data for analysis

The free version is limited to 500 URLs; paid version crawls unlimited URLs.

Ahrefs or SEMrush (Paid, approximately $99-500+ per month)

These tools help with backlink analysis and competitive research:

• Export backlink profiles to identify high-value links
• Track ranking changes post-migration
• Monitor competitor activity
• Identify technical SEO issues

Both are comprehensive SEO platforms; choose based on your specific needs and budget.

Google PageSpeed Insights (Free)

Monitor Core Web Vitals before and after migration:

• Measure Largest Contentful Paint (LCP)
• Measure First Input Delay (FID) or Interaction to Next Paint (INP)
• Measure Cumulative Layout Shift (CLS)
• Get optimization recommendations

Google Rich Results Test (Free)

Verify structured data is valid and recognized:

• Test schema markup
• Identify structured data errors
• Preview how rich snippets will appear

Redirect Mapper Tools (Varies)

Depending on your platform, you may need specialized tools:

• Apache/Nginx redirect testers
• Platform-specific redirect builders (e.g., Shopify apps, WordPress plugins)
• Custom scripts to generate redirect maps

Analytics Platforms (Free or Paid)

Track traffic changes post-migration:

• Google Analytics 4 (free)
• Hotjar (paid, for user behavior analysis)
• Your hosting provider's analytics

Error Monitoring Tools (Free or Paid)

Monitor server errors and performance:

• Sentry (paid, approximately $29+ per month)
• New Relic (paid, approximately $50+ per month)
• Your hosting provider's built-in monitoring

Spreadsheet Templates

We recommend creating spreadsheets for:

• URL mapping (old URL → new URL)
• Redirect tracking (URL, redirect type, destination, tested)
• Migration checklist (task, owner, deadline, status)
• Pre/post-migration metrics (baseline comparison)

We've created downloadable templates for these spreadsheets that you can customize for your migration.

When to Call in Professional Help: Migration Complexity Assessment

Not every migration requires professional help, but some do. Here's how to assess your situation.

Simple Migrations (Can Often Be Handled In-House)

• Small sites (fewer than 1,000 URLs)
• Straightforward URL structure
• No domain authority (most small sites)
• Minimal technical debt
• Clear redirect mapping

For simple migrations, this guide should provide sufficient framework. You can execute migration in-house with careful planning and monitoring.

Medium Complexity (Consider Professional Audit)

• 5,000-50,000 URLs
• Multiple content types (blog, products, docs, etc.)
• Domain authority 20-40
• Some technical debt or platform limitations
• Complex internal linking structure

For medium complexity migrations, we recommend at least a professional SEO audit before execution. A professional can review your migration plan, identify risks, and provide specific recommendations.

High Complexity (Strongly Recommend Professional Management)

• 50,000+ URLs
• Domain authority 40+
• Complex platform migration (e.g., legacy system to modern platform)
• International sites with hreflang complexity
• Significant technical debt or performance issues
• Multiple stakeholders with conflicting priorities

For high complexity migrations, professional management is worth the investment. The cost of professional help (typically $5,000-25,000+ depending on scope) is small compared to the cost of losing 30-50% of organic traffic for months.

Red Flags That Professional Help Is Needed

• You're uncertain about your URL mapping accuracy
• You don't understand the difference between 301 and 302 redirects
• Your current site has significant crawl errors or indexation issues
• You don't have a documented rollback plan
• Your team lacks experience with migrations
• Your site has high traffic or revenue dependent on organic search
• You're changing domain authority or domain structure significantly

Value of Professional Migration Management

Professional help provides:

• Risk assessment and mitigation planning
• Technical expertise in your specific platform
• Real-time monitoring and incident response
• Documentation and post-migration reporting
• Accountability for results
• Peace of mind during a high-stakes process

OSTER Tech Migration Services

We offer several services related to migrations:

• Pre-Migration Audit: Comprehensive review of your current site, migration plan, and risk assessment ($2,000-5,000)
• Migration Planning & Execution: Full management of migration from planning through post-migration verification ($5,000-25,000+ depending on scope)
• Post-Migration Recovery: If your migration resulted in traffic loss, we can diagnose issues and implement recovery plan ($3,000-10,000+)
• Technical SEO Optimization: Ongoing optimization to improve performance and rankings after migration ($1,000-3,000 per month)

If you're uncertain whether professional help is needed, we offer free 30-minute consultations to assess your situation and provide recommendations.

Executing Your Migration: Your Next Steps

You now have a comprehensive framework for executing website migrations successfully. Here's how to move forward.

Step 1: Conduct Your Pre-Migration Audit

Using Phase 1 guidance, conduct a comprehensive audit of your current site. Export your GSC data, crawl your site with Screaming Frog, analyze your backlinks, and document your current technical baseline.

Step 2: Create Your URL Mapping Document

This is the most critical document. Create a spreadsheet that maps every old URL to its corresponding new URL, including current ranking position and traffic data. Accuracy here prevents mistakes during implementation.

Step 3: Assess Migration Complexity

Based on your site size, domain authority, and platform changes, assess whether your migration is simple, medium, or high complexity. If it's medium or high complexity, consider requesting a professional audit.

Step 4: Plan Your Timeline

Don't rush. Plan for:

• 4-6 weeks pre-migration planning and audit
• 2-4 weeks technical setup and staging testing
• 1-2 days migration execution
• 4-8 weeks post-migration monitoring

Build in buffer time for unexpected issues.

Step 5: Get Stakeholder Buy-In

Share your migration plan, timeline, success metrics, and risks with leadership and relevant stakeholders. Ensure everyone understands what you're doing and why.

Step 6: Execute Phase 2 Technical Setup

Using Phase 2 guidance, set up your new infrastructure, implement redirects, update internal links, and test everything in staging. Don't move to Phase 3 until you've thoroughly tested.

Step 7: Execute Phase 3 Migration

When ready, execute your migration according to your plan. Monitor in real-time for the first 48 hours. Be prepared to rollback if critical issues emerge.

Step 8: Execute Phase 4 Post-Migration Verification

Monitor for 4-8 weeks post-migration. Track traffic, rankings, indexation, and errors. Fix any issues that emerge.

Step 9: Document Lessons Learned

After migration is complete, document what went well, what could be improved, and lessons for future migrations. This creates institutional knowledge that makes future migrations smoother.

Key Takeaways: Your Migration Success Formula

Website migrations are high-risk but manageable with proper planning and execution. Here's what determines success:

1. Planning is 80% of success: Invest 4-6 weeks in comprehensive pre-migration audit and planning. This prevents 90% of migration failures.
2. Documentation is critical: Create detailed URL mapping, redirect strategy, and rollback plan. These documents are your insurance policy.
3. Testing prevents disasters: Test everything in staging before it goes live. A problem found in staging is easy to fix. The same problem found in production is a crisis.
4. Monitoring catches issues early: Monitor Google Search Console and analytics in real-time post-migration. Early detection allows quick remediation.
5. Redirect strategy matters: Use 301 redirects, avoid redirect chains, update internal links. These technical details determine whether you recover rankings or lose them.
6. Patience pays off: Expect 1-3 weeks for rankings to stabilize. Don't panic if you see temporary fluctuation. Most sites recover fully if migration is executed correctly.
7. Professional help is worth considering: If your site has significant traffic or authority, professional review or management reduces risk significantly.

The framework in this guide—the 40-point checklist, the four phases, the common mistakes to avoid—is battle-tested across dozens of migrations. Follow it, and you'll dramatically increase your chances of successful migration with minimal traffic loss.

Website migrations don't have to be disasters. With proper planning, technical precision, and monitoring, they can be executed smoothly. Your organic traffic, rankings, and revenue are too important to leave to chance.

Ready to execute your migration? Start with the checklist. Document your current state. Create your URL mapping. Plan your timeline. Then execute methodically, monitor continuously, and celebrate when your migration is complete.

If you need help, we're here. If you're planning a major migration or architectural change, our team provides a dedicated SEO-focused website rebuild service to ensure the transition protects your rankings, traffic, and revenue.

Plan Cloudflare before changing DNS

OSTER inventories URLs, redirects, origin dependencies, DNS records, certificates, cache behavior, robots rules, and sitemaps before cutover. The redirect map is tested against real legacy URLs, including parameters and trailing-slash variants. We lower DNS TTL only when appropriate, validate the new Worker or Pages deployment on a controlled hostname, and confirm that preview responses cannot be indexed. This turns launch day into an execution step rather than a discovery exercise.

A zero-downtime cutover sequence

At launch, Cloudflare routes traffic to a verified origin or Worker version while preserving host, protocol, locale, and canonical behavior. Redirects are single-hop and return permanent status codes only when the mapping is final. Cache is warmed selectively for priority pages, stale content policies are explicit, and form, analytics, consent, and file-download paths are tested from the public domain. A previous Worker version and DNS configuration remain available for rollback.

Monitor the signals that expose migration loss

After cutover, OSTER watches 404 and 5xx routes, redirect volume, Worker exceptions, origin latency, cache performance, sitemap fetches, Core Web Vitals, and search-console coverage. High-value old URLs are sampled directly instead of waiting for aggregate reports. We compare rankings and conversions by landing-page group, so a local problem is not hidden by sitewide averages. Fast diagnosis and reversible Cloudflare releases reduce both downtime and organic recovery time.