Platform change on Friday. Monday morning you open Search Console and your heart sinks: organic traffic is down 60%. The keywords you spent years nurturing have dropped off the first page. The traffic that used to convert is gone.
This isn’t science fiction. We’ve seen it hundreds of times at SEOCOM. Companies that, after a well-intentioned migration, lost months or years of SEO work in a single night. And in most cases, the error was avoidable.
A well-planned SEO migration doesn’t lose traffic. Not a single point. But a badly executed migration is one of the most destructive technical events that can happen to a digital project. The difference between both scenarios is avoiding these 10 errors.
1. Going live without a complete 301 redirect map
The most expensive and the most frequent error. The old URL stops existing, users land on a 404, Google stops finding the content. In 2-4 weeks those URLs disappear from the index and with them all the organic traffic they generated.
The redirect map must be exhaustive: every indexed URL of the old site needs its equivalent on the new one. Not just the “important” URLs. All of them. Old product pages, 2015 blog posts, category pages you intended to delete, URLs with parameters that generated canonical versions.
The upfront work is identifying every indexed URL (full crawl with Screaming Frog + cross-reference with Search Console data from the last 12 months) and deciding the destiny of each: 301 to the new equivalent, consolidation of several old URLs into one new, or definitive removal with redirect to a parent category or home as last resort.
2. Chained redirects or multiple hops
If the old URL redirects to an intermediate one, which redirects to the final one, you lose authority in each hop. Google may stop following the chain if it detects more than 3-4 consecutive jumps.
Every redirect should go directly from old URL to final URL. No intermediaries. If your history accumulates past migrations with old redirects, now is the moment to clean and redirect everything directly to the final new URL.
3. Forgetting to redirect parameters and URL variations
URLs with parameters (?utm_source, ?color=red, ?page=2) are usually forgotten in redirect maps. If your site had thousands of indexed URLs with parameters (typical in ecommerce and marketplaces), losing those authority signals has direct impact.
The trick is to work with real Search Console data, not with what “should have existed”. The indexed pages you see in Search Console are the URLs to account for, even if they “technically didn’t exist” in the original plan.
4. Not validating on staging before the jump
A migration should be fully validated on a staging environment before going live. Complete crawl, one-by-one redirect validation, schema review, Core Web Vitals check, robots.txt and sitemap verification.
If this is done on production on go-live day, any error is exposed to Google immediately. One week crawling errors is enough to lose significant traffic that later takes months to recover.
Our internal rule at SEOCOM: minimum 2 weeks of exhaustive validation on staging before the jump to production. If the client is in a rush, that rush is theirs, not yours.
5. Losing critical SEO elements in a platform migration
Title tags, meta descriptions, H1s, structured data, image alt text, internal linking, canonicals, hreflang. All of this exists on your current site and must transfer correctly to the new one.
In platform migrations (WordPress to Shopify, Magento to custom, etc.), these elements don’t migrate automatically. Data has to be exported, formats adapted, and re-implemented on the new system. It’s manual or semi-automated work that requires attention.
The typical mistake: “we’ll rewrite everything after the migration”. The reality: a small percentage gets rewritten and the rest ends up with generic CMS-generated titles. Months of silent decline.
6. Ignoring schema markup
Structured data (Product, Article, Organization, BreadcrumbList, FAQ) is one of the most important signals for Google and especially for generative engines. If your old site had well-implemented schema and the new one doesn’t, you lose rich snippets, categorization, signal.
Schema doesn’t migrate automatically between platforms. Every CMS has its own implementation. If the old site had manual schema or plugin-specific schema, you need to rebuild it on the new one. This work is frequently forgotten until someone checks Search Console and sees drops in enriched results.
7. Misconfigured robots.txt and sitemap on the new site
The day after go-live, Google crawls your new site following robots.txt instructions. If you accidentally have “Disallow: /” (common after copying from staging without removing the block), Google indexes nothing. Seems obvious, happens often.
The sitemap.xml must be updated with new URLs from day one, submitted manually to Search Console to accelerate discovery, and must not include old URLs that no longer exist.
Day-1 post-migration checklist: robots.txt allows crawling, sitemap is uploaded and valid, critical URLs are crawlable, no accidental blocks.
8. Not monitoring the first 14 days intensively
The critical post-migration window is the next 2-4 weeks. If there’s a problem, it shows up in that period. If you don’t detect it, the damage consolidates.
Daily monitoring for 2 weeks of:
- 4xx/5xx errors in Search Console.
- Abrupt indexing changes.
- Traffic drops by URL/category.
- Core Web Vitals compared to pre-migration.
- Main keyword rankings.
An error detected on day 3 can be fixed with minimal impact. The same error detected on day 45 may have cost thousands in lost traffic.
9. Not communicating the change to Google
When there’s a domain change, Google has specific tools to accelerate the migration: the “Change of address tool” in Search Console. Not using it when possible slows the process needlessly.
You also have to re-verify ownership in Search Console for the new domain, connect the new sitemap, and in complex cases notify Google of main URLs through the indexing API.
These steps aren’t mandatory for the migration to work. But they shorten recovery from weeks to days in some cases.
10. Treating the migration as a closed project on go-live day
The migration doesn’t end when the new site is online. It ends when 4-8 weeks go by without detected incidents and Google has stabilized the index with the new structure.
During that post-go-live period you still need to monitor, detect minor issues (forgotten redirects, pages with specific drops, schema errors) and fix them. Without this consolidation phase, loose ends remain that later are much harder to locate.
At SEOCOM the migration always includes 4 weeks of post-go-live monitoring as part of the project. Not an extra. Part of the service.
If you’re in the middle of a problematic migration
If you’re reading this because the migration already happened and things aren’t going well, not all is lost. Post-migration recovery is possible in most cases, but each week that passes makes the work longer and more expensive.
Immediate actions:
- Crawl the current site with Screaming Frog and compare with the old site state if you have a snapshot.
- Review Search Console for pages with abrupt traffic drops.
- Validate that all redirects are working (manually test the 50 most-visited URLs pre-migration).
- Check that robots.txt, sitemap and schema are correct.
- Prioritize fixes by traffic impact.
The difference between a safe migration and a catastrophic one
Exhaustive planning, intense staging validation, IT coordination throughout the process, daily post-go-live monitoring. It seems obvious and it is.
The problem isn’t technical or conceptual. It’s judgment and time. Migrations that fail are usually migrations in a hurry, without senior SEO involved from the start, where the development team executes without visibility of the implications of each decision on organic ranking.
If you have a complex migration ahead and aren’t certain the plan is right, let’s talk before go-live. Request a migration diagnosis and have SEOCOM review the plan before it’s too late.
