SEO Site Migration Checklist: Protect Your Rankings During Domain, Platform, and Redesign Changes

Site migrations destroy organic traffic when teams skip critical SEO steps during planning and execution. We've watched companies lose 40-70% of their search visibility in a single weekend because they treated migration as purely a technical exercise instead of the high-stakes SEO event it actually is. This guide delivers systematic checklists for every migration scenario—domain changes, platform migrations, HTTPS upgrades, site redesigns, and subdomain consolidations—with specific timelines, risk assessments, and recovery benchmarks you won't find in generic migration guides.

Different migration types require fundamentally different checklist priorities. A domain migration demands flawless 301 redirect mapping and DNS coordination. A platform change focuses on template-level SEO preservation. Site redesigns require content consolidation decisions and URL structure planning. Treating all migrations the same is how teams end up with ranking disasters three weeks post-launch. At Sharkly, we've seen this pattern repeat: companies download a one-size-fits-all checklist, skip steps that seemed irrelevant to their specific scenario, and watch their traffic evaporate because they missed the critical items unique to their migration type.

This comparison breaks down which checklist you actually need, what each migration type risks, and realistic recovery timelines based on real migration outcomes. You'll know exactly which baseline data to capture, which redirect patterns cause permanent ranking loss, and when temporary traffic dips become permanent problems. The framework includes hour-by-hour launch protocols and a comparison table that lets you evaluate complexity, timeline, and critical success factors before you commit resources. Before making any technical changes, you should when is the best time to schedule your migration for minimal disruption.

What Type of Site Migration Are You Planning and Which Checklist Do You Need?

Migration type determines everything about your checklist priorities, timeline, and risk profile. Domain migrations carry the highest traffic risk because every single URL changes, requiring comprehensive redirect mapping and dual Search Console management. Platform or CMS migrations often preserve your domain but change how pages render, shifting focus to template-level meta tags, structured data continuity, and page speed benchmarking. HTTPS migrations are technically simpler but absolutely critical—one misconfigured canonical tag can prevent your entire site from ranking on the secure version.

Site redesigns typically involve URL structure changes and content consolidation decisions. You're not just moving pages; you're deciding which pages deserve to exist at all. This requires content audits, strategic internal linking updates, and careful URL slug planning. Subdomain consolidations—moving blog.yoursite.com to yoursite.com/blog—require redirect mapping but usually affect a smaller percentage of your total pages, making them lower risk if executed correctly.

At Sharkly, we've audited migrations where teams used platform migration checklists for domain changes and completely missed the Search Console property verification steps for the new domain. Google didn't recognize the ownership change for six weeks. The site lost 60% of its visibility during that window because Search Console couldn't communicate indexing issues or manual actions. Choosing the wrong checklist isn't a minor inefficiency—it's the difference between controlled transition and traffic catastrophe.

Domain Migration Checklist Requirements

Domain migrations present the highest complexity because every URL in Google's index becomes invalid simultaneously. Your old domain—let's call it oldsite.com—needs to tell search engines that everything now lives at newsite.com. This requires 301 redirects for every meaningful page, not just your homepage. DNS propagation introduces timing variables you can't fully control. Some users and crawlers will see the old domain for hours or days after you flip the switch.

Search Console property verification becomes a dual operation. You need verified properties for both domains to monitor the transition. The old domain's Search Console will show you which pages Google is attempting to crawl and receiving redirects from. The new domain's property shows indexing progress and any errors on the destination URLs. Historical backlink preservation requires contacting major referring domains to update links, though 301 redirects will pass most link equity if implemented correctly.

Traffic risk is highest here because you're changing the fundamental identifier Google uses for your content. Even perfect execution typically causes 10-15% temporary traffic dips during the 30-day adjustment period. Flawed execution can result in 50-80% permanent losses. The mission-critical items: complete URL mapping before launch, redirect testing in staging, immediate Search Console sitemap submission for the new domain, and daily monitoring for the first two weeks.

Platform and CMS Migration Priorities

Platform migrations—moving from WordPress to Shopify, Drupal to custom builds, legacy systems to headless CMS architectures—create technical SEO variables that domain-only migrations don't face. Your URLs might stay identical, but the underlying code generating title tags, meta descriptions, schema markup, and canonical tags changes completely. Template-level elements that were SEO-optimized in your old system need manual recreation in the new one.

Structured data continuity deserves specific attention. If your old platform automatically generated product schema or article markup, does your new platform replicate that functionality? We've seen e-commerce migrations where structured data vanished because the new theme didn't include it by default, costing the site rich snippets and featured positions. Page speed benchmarking pre- and post-migration identifies performance regressions early. New platforms often introduce heavier JavaScript frameworks or different image compression, changing Core Web Vitals scores dramatically.

URL structure often changes even when the domain stays constant. WordPress might use /category/post-name/ while your new system defaults to /post-name/. This turns a platform migration into a URL migration requiring the same redirect discipline as domain changes. The checklist priority here: audit every template type (homepage, category pages, product pages, blog posts) for SEO element preservation, and benchmark page speed before making any changes so you have concrete comparison data.

Site Redesign and URL Structure Changes

Redesigns introduce content and URL decisions that pure technical migrations don't require. Which pages should merge? Which deserve deletion versus 301 redirects to relevant alternatives? URL slug changes—even minor ones like shortening /our-services/consulting-services/ to /consulting/—break existing links and require redirect planning. Internal linking structure often gets completely rebuilt during redesigns as navigation changes and new page hierarchies emerge.

Content consolidation demands strategic thinking. You might have twelve blog posts about similar topics that should become one comprehensive guide. Do you 301 all eleven old URLs to the new consolidated page? Do you pick the highest-traffic URL as the canonical and redirect others to it? These decisions impact how Google understands your topical authority. Canonical tag strategy becomes critical when you're creating new content hierarchies or combining pages.

The redesign checklist focuses on content audits first, technical implementation second. Before any design work begins, you need a spreadsheet mapping old URLs to new destinations with clear reasoning: exact match redirect, topical redirect to relevant page, or 410 gone status for truly obsolete content. Internal linking structure updates require crawling your staging site to identify broken links before launch. At Sharkly, we tell clients that redesigns fail most often when design teams and SEO teams don't collaborate from day one—by the time SEO reviews the staging site, URL patterns are locked in and expensive to change.

Migration Type Comparison: Complexity, Risk, and Checklist Focus

Migration Type | Traffic Risk Level | Primary SEO Challenge | Redirect Complexity | Typical Timeline | Critical Checklist Items

• Domain Migration | High | Every URL changes; requires perfect redirect mapping and dual Search Console management | Very High | 60-90 days planning, 90+ days recovery | Complete old-to-new URL mapping with zero gaps Search Console property setup for both domains DNS propagation timing and monitoring Backlink outreach to major referring domains

• Platform/CMS Migration | Medium-High | Template-level SEO elements must be preserved; page rendering changes | Medium (if URLs change) to High | 45-60 days planning, 60 days recovery | Template audit for meta tags, schema, canonicals Page speed benchmarking pre and post Mobile rendering verification Structured data continuity validation

• HTTPS Migration | Low-Medium | Protocol change from HTTP to HTTPS; canonical and redirect configuration | Low (but critical) | 14-30 days planning, 30 days recovery | SSL certificate installation and validation HTTP to HTTPS 301 redirects site-wide Canonical tags pointing to HTTPS versions Search Console HTTPS property verification

• Site Redesign | Medium | URL structure and content hierarchy changes; internal linking rebuilds | Medium to High | 30-60 days planning, 45-60 days recovery | Content consolidation strategy and mapping URL slug change documentation Internal link structure audit and updates Top-converting page preservation

• Subdomain Consolidation | Low-Medium | Moving content from subdomain to subfolder; affects smaller page subset | Low to Medium | 21-45 days planning, 30-45 days recovery | Subdomain page inventory and mapping Redirect rules from subdomain to main domain paths Search Console property consolidation Analytics view and filter updates

This comparison reveals why one-size-fits-all migration advice fails. Domain migrations require obsessive redirect discipline and long recovery timelines. HTTPS migrations are comparatively simple but non-negotiable for ranking in modern search results. Platform changes demand template-level technical audits that domain migrations don't need. Your checklist must match your specific scenario, or you'll waste time on irrelevant tasks while missing critical ones.

Traffic risk levels reflect both likelihood of problems and magnitude of impact. Domain migrations carry high risk because even small redirect errors affect large percentages of your pages. Subdomain consolidations affect narrower page sets, limiting downside. Redirect complexity correlates with the number of unique redirect rules you need—domain migrations often require thousands, while HTTPS migrations might need a single wildcard rule if your URL structure stays identical.

Timeline expectations matter for resource planning. Domain migrations need 60-90 days of preparation because redirect mapping, backlink documentation, and stakeholder coordination take weeks. HTTPS migrations can execute in 14-30 days if your site architecture is simple. Recovery timelines represent realistic periods for traffic restabilization—these aren't aspirational goals, they're observed patterns from successful migrations. Plan your post-launch monitoring windows accordingly.

How Do You Prepare for Any Site Migration 30-60 Days Before Launch?

Pre-migration preparation determines success more than launch-day execution. You need comprehensive baseline documentation before changing anything because post-migration analysis is impossible without pre-migration data. At Sharkly, we've seen migration teams skip this phase, launch successfully from a technical perspective, then have no way to prove SEO impact when stakeholders ask "did this work?" Documentation isn't bureaucracy—it's your evidence trail.

The universal pre-migration checklist applies regardless of migration type. Comprehensive site crawls using Screaming Frog or Sitebulb capture your current URL inventory, status codes, redirect patterns, meta tag implementation, and internal linking structure. This crawl becomes your source of truth for redirect mapping. Traffic and ranking baseline documentation in Google Search Console and Google Analytics establishes what normal performance looks like. Export your top 100 organic landing pages by traffic and the keywords driving visits to each.

Backlink profile exports from Ahrefs, Semrush, or Moz preserve your external link data. You'll need this to identify which referring domains to contact post-migration and to verify that 301 redirects are passing link equity correctly. XML sitemap verification ensures your current sitemap is accurate and complete—many sites discover during migration planning that their sitemap was broken or outdated for months. Identification of top-converting pages protects revenue. These pages get priority treatment in redirect mapping and post-migration monitoring.

Staging environment setup with proper robots.txt blocking prevents premature indexing of your new site. Your staging site needs a noindex directive or robots.txt disallow to ensure Google doesn't start indexing the new version before launch. We've seen staging sites outrank production sites because someone forgot this step, creating duplicate content chaos. The staging environment also serves as your redirect testing ground—never deploy redirect rules directly to production without validation.

Baseline Data Collection and Benchmarking

Specific baseline data points enable post-migration comparison. Export all organic keyword rankings from your rank tracking tool of choice—you need position data for at least your top 500 keywords before migration. Document Core Web Vitals scores from Search Console's Experience report, capturing Largest Contentful Paint, First Input Delay, and Cumulative Layout Shift for both mobile and desktop. These metrics often regress during platform migrations, and you need pre-migration scores to identify the degradation.

Capture screenshots of key SERP features your site owns—featured snippets, People Also Ask boxes, local pack appearances, knowledge panel elements. These visual records prove ownership when you're assessing post-migration impact. SERP features often disappear during migrations because the content formatting or schema markup changes. Download complete Google Analytics traffic data for your top 100 pages covering at least 90 days pre-migration. This becomes your benchmark for evaluating traffic recovery patterns.

Each data point serves a specific comparison function. Keyword rankings show whether you maintained positions for money terms. Core Web Vitals reveal performance regressions that hurt rankings. SERP feature screenshots prove you lost (or kept) valuable real estate. Traffic data quantifies the business impact. Without these baselines, post-migration analysis becomes subjective guesswork. You'll argue with stakeholders about whether traffic is "down" or "within normal variance" instead of showing objective before-and-after comparisons.

URL Mapping and Redirect Planning

URL mapping is the single most critical pre-migration task for any scenario involving URL changes. Create a spreadsheet with these columns: Old URL, New URL, Redirect Type (301, 410), Redirect Status (exact match, topical match, consolidated), and Page Value (traffic, conversions, rankings). This spreadsheet becomes your redirect implementation blueprint. Every page currently indexed needs a decision: where does it redirect, or does it return a 410 gone status?

Identify which pages deserve 301 redirects versus 410 gone responses. Truly obsolete content with no modern equivalent gets 410 status. Everything else gets a 301 to either an exact match on the new site or a topically relevant alternative. Plan for redirect chains before they happen—if URL A currently redirects to URL B on your old site, your migration should create a direct redirect from A to the final destination C, not chain A to B to C. Redirect chains waste crawl budget, slow page loads, and dilute link equity.

Test redirect logic in your staging environment using multiple methods. Manually visit old URLs and verify they redirect correctly. Use Screaming Frog's redirect chain report to identify multi-hop redirects. Check HTTP status codes with browser developer tools (Network tab) or command-line tools like curl. Prepare redirect rules in the correct file format for your server type—Apache uses .htaccess with mod_rewrite syntax, Nginx uses different configuration formats, and CDNs like Cloudflare have their own redirect interfaces.

The critical warning about Excel-based mapping: spreadsheets often miss URL parameters, trailing slashes, and case sensitivity variations. A URL like yoursite.com/page?utm_source=google might exist in dozens of variations with different parameters. Your redirect rules need to handle these intelligently—either by redirecting the base URL and preserving parameters, or by explicitly mapping high-traffic parameter combinations. To ensure DNS changes propagate correctly during domain migrations, check your DNS status across multiple global locations before declaring migration complete.

Stakeholder Communication and Timeline Lock

Non-technical preparation prevents the rushed launches that destroy SEO. Get written approval from your development team on SEO requirements before any code changes begin. This document should list non-negotiable items: redirect implementation method, robots.txt status at launch, canonical tag strategy, Analytics tracking verification. Written agreements prevent "we didn't know that was important" conversations post-launch when traffic is tanking.

Establish rollback criteria before launch day. Under what conditions do you abort the migration and revert to the old site? Specific triggers might include: more than 20% of pages returning 404 errors, Analytics showing zero traffic, Search Console reporting manual actions, or Core Web Vitals scores degrading by more than 50%. Having pre-agreed rollback criteria prevents panic decisions and ensures you can reverse course quickly if something catastrophic happens.

Schedule migrations during low-traffic periods when possible. For e-commerce sites, avoid holiday shopping seasons, major sales events, and month-end conversion peaks. For B2B sites, mid-week launches allow immediate monitoring while teams are fully staffed. Weekend launches often mean problems go unnoticed for 48 hours. Create a communication plan for stakeholders if rankings or traffic drop post-migration—who gets notified, what updates they receive, and how often.

At Sharkly, we've audited migrations that failed because developers and SEO teams never aligned on priorities. Developers focused on design and functionality. SEO assumed redirects would be handled. Nobody documented the agreement. The site launched with a noindex tag in the template, and 30,000 pages deindexed over two weeks before anyone noticed. When developers and SEO teams aren't aligned, migrations get rushed, corners get cut, and organic traffic pays the price.

What Must Happen on Migration Launch Day Hour by Hour?

Launch day is a supervised process requiring real-time monitoring, not a "deploy and walk away" event. The first three hours post-launch reveal most critical failures. Your launch checklist should follow a specific sequence with timing estimates for each task. This isn't paranoia—it's pattern recognition from hundreds of migrations where early detection prevented permanent damage.

Begin with a final staging environment audit within 24 hours of launch. Crawl the staging site completely to verify redirect implementation, confirm robots.txt allows crawling (if it's about to become production), validate that Analytics tracking codes fire correctly, and spot-check meta tags on key page types. This is your last chance to catch errors in a controlled environment. Once you deploy, every mistake is public and affects real users and crawlers.

Redirect implementation happens first on launch day. Deploy your redirect rules to production servers and immediately spot-check at least 20 diverse URLs manually. Visit old URLs from different page types—homepage, category pages, product or blog post pages, pagination URLs. Verify each redirects to the correct new URL with a 301 status code, not 302 (temporary) or meta refresh redirects. DNS changes occur next for domain migrations—update DNS records to point the old domain to redirect infrastructure and the new domain to your new hosting.

Robots.txt updates are critical but easy to forget. If your new site has a restrictive robots.txt blocking search engines (common in staging), replace it with production rules that allow crawling. Immediately verify this change by visiting yoursite.com/robots.txt and confirming the file contains "Allow" directives. XML sitemap submission to Search Console should happen within the first hour post-launch. Submit your new sitemap through the Sitemaps report for your new domain property.

Google Analytics and Tag Manager verification prevents data gaps. Load your site, trigger Analytics events, and confirm data appears in real-time reports within five minutes. Verify that goal conversions and e-commerce tracking still function if applicable. Initial crawl of the live site using Screaming Frog or Sitebulb identifies immediate errors—404s, redirect chains, broken images, slow page loads. Run this crawl within the first two hours while you can still make emergency fixes.

Monitoring dashboard setup centralizes critical metrics. Create a shared dashboard (Google Data Studio, Tableau, or even a shared spreadsheet) that displays: Search Console coverage errors, Analytics traffic compared to previous week, keyword ranking changes from your rank tracker, and page speed scores. This dashboard becomes your single source of truth for the next 90 days. Estimated timing: final audit (2 hours), redirect deployment and testing (1 hour), DNS changes (30 minutes), robots.txt and sitemap updates (15 minutes), Analytics verification (30 minutes), initial crawl (1-2 hours depending on site size), dashboard setup (1 hour).

Critical Launch Hour Testing Protocol

The first three hours post-launch require intensive manual testing beyond automated crawls. Test at least 20 redirects from old URLs spanning all page types and site sections. Don't just click links—use browser developer tools to verify HTTP status codes are 301, not 302 or 307. Verify that every major page type returns 200 status codes when accessed directly via new URLs: homepage, top category pages, best-selling products or popular posts, contact and about pages.

Confirm Google Analytics is tracking by visiting several pages and checking the Real-Time report. You should see your own pageviews within seconds. Test conversions if possible—submit a test form, complete a checkout (refund it later), or trigger whatever goal events your business relies on. Analytics gaps discovered three weeks post-migration are nearly impossible to backfill. Check that structured data validates using Google's Rich Results Test tool. Schema markup often breaks during migrations when template code changes.

Ensure mobile rendering works by visiting your site on actual mobile devices or using Chrome DevTools device emulation. Platform migrations sometimes break mobile-specific templates or introduce viewport issues. Test site search functionality if you have internal search—URL structure changes often break search result pages. Verify CDN and caching configurations aren't blocking crawlers. Some CDN rules aggressively cache and serve cached versions to all visitors, including Googlebot, preventing fresh content from being crawled.

This three-hour window is your highest-leverage troubleshooting period. Problems identified now take minutes to fix. The same problems discovered three days later might require days to diagnose and weeks to recover from rankings-wise. At Sharkly, we staff migrations with dedicated monitors during this period because we've seen too many launches where teams deployed, celebrated, and went home—only to discover Monday morning that the site had been serving 404s all weekend.

How Do You Monitor Migration Success in the First 30-90 Days?

Post-migration monitoring follows distinct phases with different priorities. Week one demands daily attention. Week two through four shifts to every-other-day monitoring with automated alerts. Days 30-90 transition to weekly check-ins focused on trend analysis rather than emergency response. Each phase has specific metrics and thresholds that determine whether your migration succeeded or needs intervention.

Week one priorities include daily Search Console checks in the Coverage report for newly excluded pages—any spike in excluded pages signals indexing problems. Traffic monitoring in Google Analytics compares current daily traffic to the same weekday from previous weeks (compare Tuesday to Tuesday, not Tuesday to Saturday). Manual searches for your top ten keywords confirm pages are still ranking and appearing in results. Many migrations maintain keyword positions but temporarily lose SERP features, which destroys click-through rates even when rankings seem stable.

Four-oh-four error identification and fixing prevents permanent link equity loss. Check Search Console's Coverage report and your server logs for 404 errors on URLs that should redirect. Create redirects for any that appear. This is normal—no redirect mapping catches 100% of URLs, especially if your site has dynamic parameters or user-generated content. Week one is when you discover and fix these gaps before too much link equity dissipates.

Weeks two through four shift focus to redirect chain identification and cleanup. Crawl your site with Screaming Frog's redirect chain report active. Any redirect chain longer than one hop (A→B→C instead of A→C) should be flattened to a direct redirect. Indexing progress tracking uses Search Console's Index Coverage report to monitor how many pages Google has successfully indexed on your new site versus how many were indexed on the old site. For domain migrations, expect gradual transition—the old domain's indexed pages decline while the new domain's climb.

Backlink monitoring identifies links that broke during migration. Check your backlink tool weekly for new broken backlinks (404 destinations) or redirecting backlinks. Redirecting backlinks are fine—they pass link equity through 301s—but broken ones need outreach. Contact referring domains to update links to your new URLs. Page speed comparison to baseline uses the Core Web Vitals scores you documented pre-migration. Compare current scores in Search Console to your baseline. Any degradation above 20% warrants investigation and optimization.

Days 30-90 transition to outcome assessment. Ranking recovery assessment compares current keyword positions to pre-migration baselines. Full recovery might take 60-90 days, but you should see clear upward trends by day 30. Traffic pattern analysis looks for sustained recovery or persistent deficits. If traffic is still down 20% on day 60 with no recovery trend, you have permanent problems requiring deeper intervention.

Content re-optimization for pages that dropped in rankings becomes productive at this phase. Some ranking loss is algorithmic adjustment, not technical failure. Google might re-evaluate your content quality post-migration. Update thin content, add depth to pages that dropped, improve internal linking to pages that lost visibility. Post-migration SEO wins documentation captures successes for stakeholder reporting—pages that gained rankings, improved Core Web Vitals scores, or increased conversion rates due to improved UX in the redesign.

At Sharkly, we tell clients that 60 days is the realistic window for re-stabilization of organic traffic. Rankings might fluctuate daily, but traffic trends should show clear recovery direction within two months. Setting this expectation prevents panic when traffic dips in week two or three. Temporary volatility is normal. Sustained losses beyond 60 days indicate execution failures that need systematic diagnosis. Maintaining proper internal link preservation site migration practices prevents link equity loss during URL structure changes.

Search Console Monitoring Priorities

Specific Search Console reports deserve daily or weekly attention during migration recovery. The Coverage report shows pages Google discovered, indexed, excluded, or encountered errors with. Daily checks during week one identify newly excluded pages—these often indicate noindex tags that weren't removed, canonical tags pointing to old domain URLs, or redirect loops. Any increase in excluded pages requires immediate investigation.

The Experience report tracks Core Web Vitals performance. Weekly checks identify regressions in Largest Contentful Paint, First Input Delay, or Cumulative Layout Shift. Platform migrations commonly cause Core Web Vitals degradation when new themes introduce heavier JavaScript or unoptimized images. Manual Actions checks are rare but critical. Check weekly for the first month to ensure Google hasn't applied spam penalties or security alerts. Manual actions during migrations are unusual but catastrophic if missed.

Mobile Usability issues often surface post-migration when responsive designs don't render correctly on mobile devices or when clickable elements are too close together. Weekly monitoring prevents mobile ranking losses. The Index Requests queue shows which URLs you've asked Google to crawl via the URL Inspection tool. For important pages that aren't indexing quickly, use this feature to request priority crawling.

Interpretation thresholds determine when to act. A 5% increase in excluded pages might be normal discovery of low-value thin content. A 30% increase signals systematic indexing problems. Core Web Vitals degradation under 10% is acceptable; above 25% requires optimization intervention. Any manual action requires immediate response regardless of magnitude. These thresholds prevent both panic over normal variance and complacency about real problems.

Traffic and Ranking Recovery Benchmarks

Realistic recovery timelines prevent premature panic and identify genuine failures. Branded traffic—searches including your company or product names—should recover within seven days. Branded searches have strong user intent and aren't algorithmically complex. If branded traffic remains depressed beyond one week, you likely have technical issues preventing your homepage or brand pages from ranking. Check for noindex tags, verify your homepage is indexed, and confirm brand searches return your site in position one.

Non-branded traffic requires 14-30 days for recovery because Google needs time to re-crawl, re-index, and re-evaluate content quality on new URLs. This timeline assumes technically correct execution. Perfect 301 redirects, clean indexing, and no template-level SEO errors. Even under ideal conditions, rankings fluctuate during the transition period as Google's algorithm adjusts to new URL signals. Full ranking stabilization takes 60-90 days. Daily rank tracking will show volatility—positions jumping up and down by 5-10 positions—before settling into steady-state patterns.

Acknowledging that 10-15% temporary traffic dips are normal even with perfect execution sets realistic expectations. Several factors cause this: delayed indexing of new URLs means some pages don't appear in search results for days or weeks, SERP feature loss when content formatting changes, click-through rate depression when new title tags or meta descriptions differ from old ones, and algorithmic re-evaluation where Google treats new URLs as partially new content. These factors normalize within 30 days.

Temporary drops become permanent problems when traffic shows no recovery trend by day 45. Stabilized traffic 20% below baseline at day 60 indicates execution failures. Common causes: incomplete redirect coverage leaving old pages as 404s, canonical tags pointing to wrong URLs or old domains, template-level noindex tags on key page types, or dramatic content quality reduction during redesigns. Diagnosis requires systematic technical audits—crawl your site for indexing directives, verify redirect coverage, and compare indexed page counts pre- and post-migration.

What Are the Most Common Migration Mistakes and How Do You Prevent Them?

Redirect chains create cumulative performance and SEO costs. A redirect chain occurs when URL A redirects to URL B, which redirects to URL C—each hop adds latency and dilutes link equity. They happen during migrations when teams implement new redirects without auditing existing ones. Your old site might already have redirects from previous changes. Adding migration redirects on top creates chains.

The SEO cost is measurable. Each redirect hop loses approximately 1-5% of link equity according to industry testing, though Google's Gary Illyes has suggested equity loss is minimal. More concretely, redirect chains add 200-400ms to page load time per hop—two hops can add nearly a second. Crawl budget gets consumed following chains, reducing how many new pages Google can discover. Testing redirect chains requires crawler tools like Screaming Frog's redirect chain report or manual inspection using browser developer tools.

The fix is simple: flatten all chains before launch. If you discover that URL A currently redirects to URL B, and your migration requires redirecting B to C, create a new redirect from A directly to C. Eliminate the intermediate hop. Post-migration chain discovery should trigger immediate fixes. Every chain identified in week one monitoring gets flattened within 24 hours. The prevention method: comprehensive redirect auditing before implementation. Crawl your current site, identify existing redirects, and plan migration redirects as direct paths to final destinations.

Forgotten Indexing Directives

The most common technical mistake costs weeks of indexing delays. Noindex tags, robots.txt disallow directives, or X-Robots-Tag HTTP headers that were intentional in staging environments don't get removed at launch. Your new site goes live, but Google can't index it because indexing directives block crawlers. This creates a silent failure—the site loads correctly for users, Analytics shows traffic, but organic search traffic vanishes because pages deindex over 7-14 days.

Audit methods include Search Console monitoring—if the Coverage report shows growing numbers of excluded pages due to "Noindex tag" or "Blocked by robots.txt," you have indexing directive problems. Crawler tools like Screaming Frog report noindex meta tags and robots.txt blocks during site crawls. Manual spot-checks involve viewing page source and searching for "noindex" in meta tags, and visiting yoursite.com/robots.txt to verify it contains "Allow" directives or no restrictive "Disallow" rules for important sections.

Canonical tags pointing to old domain URLs cause similar indexing failures. Your new site loads at newsite.com/page, but the canonical tag in the HTML points to oldsite.com/page. Google sees this as a duplicate and might not index the new URL, continuing to show the old domain in search results. This mistake persists until someone manually inspects canonical tags on the new site. Prevention requires template-level audits before launch—verify canonical tags use relative URLs or dynamically generate with the new domain.

Missing Analytics Tracking and Tag Management

Analytics failures don't destroy rankings directly—but they make recovery impossible to diagnose. When migration problems surface in week two or three, your ability to identify causes depends entirely on having clean data from day one.

The most common failure pattern: your old platform had Google Analytics hardcoded in the template. Your new platform expects a GTM container. Nobody configured the triggers. You lose all behavioral data at launch—the exact moment you need it most.

Verification takes twenty minutes. Install GA4, publish your GTM container, open Real-Time reports, and load your site from a separate browser. Then test your conversion events. If you can't see pageviews and conversion events firing before launch, don't launch.

What Separates Migration Mistakes from Disasters

Most migration failures we've audited weren't caused by ignorance. Teams knew redirects mattered. They planned to verify robots.txt. They intended to monitor rankings. The problem was execution—the gap between intending to do something and building a system that guarantees it happens.

The items that get skipped are almost never the ones nobody thought of. They're the ones that seemed covered, assumed, or assigned to someone who assumed it was assigned to someone else. Written checklists with named owners close this gap. They feel like bureaucracy until they prevent two weeks of deindexed pages and the revenue loss that comes with it.

Before you touch a single line of code, confirm four things: you have a complete URL inventory of every indexed page, you have a documented baseline of traffic and rankings, your rollback plan has actually been tested, and every stakeholder has confirmed their requirements in writing.

Migrations don't have to destroy traffic. The companies that lose 40-70% of organic visibility in a single weekend weren't being reckless—they were skipping steps that seemed redundant and assuming handoffs that were never confirmed. Follow this checklist precisely, own every step, and your migration becomes a controlled transfer of search equity instead of a gamble on execution speed.

How Sharkly Helps You Execute Migrations Without the Guesswork

Migration timing isn't just about picking a date on a calendar. It's about having the data, tools, and confidence to know you're ready. Sharkly provides AI-powered site analysis that identifies technical issues before they become migration disasters—baseline crawls, indexation reports, and performance benchmarks built around how Google actually works.

Every recommendation is grounded in published research, Google's own patent filings, and data specific to your site. If you're planning a migration and want to minimize risk while protecting the rankings you've built, explore how Sharkly makes complex SEO accessible and actionable.