Website migrations are where SEO gains and losses happen fastest. Change the platform, domain or URL structure without a plan, and Google has to work out where everything went from incomplete clues: old URLs return 404s, backlinks lose their target and rankings that took years to build can slip within weeks. With a plan, a migration can be the moment your site gets better.
Which kinds of website migrations put SEO at risk?
Any change that alters URLs, content, templates or how pages are rendered puts SEO at risk. The highest-risk migrations are domain changes, replatforming to a new CMS or ecommerce platform, URL restructures and site mergers. Redesigns on the same platform look safer but often change content, internal links and page speed more than teams expect.
| Migration type | What changes | Main SEO risk | Key safeguard |
|---|---|---|---|
| Replatforming, such as WordPress to Shopify | CMS, templates and often URL patterns | Platform-imposed URL formats, lost metadata and schema, new rendering behavior | Full URL mapping and template-by-template SEO checks on staging |
| Domain change or rebrand | Every URL's hostname | Lost link equity and brand recognition if redirects or signals break | Page-to-page 301s and Search Console's Change of Address tool |
| HTTP to HTTPS | Protocol | Mixed content, duplicate versions, canonicals still pointing to HTTP | Site-wide 301s and updated canonicals, sitemaps and internal links |
| URL restructure | Paths and folders | Missed redirects, redirect chains, broken internal links | A redirect map tested against a full crawl |
| Redesign | Templates, content and navigation | Removed copy, lost internal links, slower pages | A content and internal-link comparison of old and new templates |
| Site merger or consolidation | Several sites or sections become one | Pages competing with each other, mismatched redirects, thin merged pages | A content inventory and consolidation plan before mapping |
Combining several of these at once, say a new domain, platform and design launched on the same day, multiplies the risk and makes it much harder to diagnose what went wrong. When there's a choice, we recommend staging the changes.
Why do website migrations lose traffic?
Migrations usually lose traffic for preventable reasons: missing or wrong redirects, staging settings that go live, content and internal links dropped from new templates, and technical changes nobody checked, like JavaScript rendering or canonical tags. Google's site-move documentation notes some fluctuation is normal while it recrawls, but sustained drops usually trace back to specific mistakes.
Missing redirects
Old URLs return 404s, so their rankings and backlinks lead nowhere. Common culprits are old blog posts, PDFs, images and campaign URLs nobody thought to inventory.
Redirects to the homepage
Sending every old URL to the homepage feels safe but isn't. Google says redirecting many URLs to one irrelevant page might be treated as a soft 404, so the old page's signals don't carry over.
Staging settings left on
A site-wide noindex tag or a robots.txt Disallow copied from staging can quietly pull a new site out of search results.
Lost content and links
New templates often trim copy, drop FAQ sections or remove sidebar and footer links that were passing authority to key pages.
Rendering changes
A move to a JavaScript framework can leave content and links missing from the raw HTML, which slows Google down and can hide pages from AI crawlers.
Broken signals
Canonicals, hreflang, structured data and sitemaps still pointing at old or staging URLs send Google conflicting messages about which page to index.
Structured data is the one teams forget most easily, because nothing looks broken when it disappears. Our schema markup guide covers which types to carry over and how to test them.
How do you build a redirect map for a migration?
A redirect map lists every old URL worth keeping and the single most relevant new URL it should permanently redirect to. Building one starts with a complete inventory of old URLs from crawls, sitemaps, Search Console, analytics and backlink data, because no single source finds them all. Each URL is then mapped one-to-one.
- Use permanent redirects (301 or 308) for moved content, server-side wherever possible
- Map each old URL to its closest equivalent, not to the homepage or a generic category
- Redirect straight to the final URL, with no chains or loops
- Let pages with no equivalent, no traffic and no links return a 404 or 410 instead of redirecting them somewhere irrelevant
- Include URLs beyond HTML pages: PDFs, images with backlinks and old campaign landing pages
- Update internal links, canonicals, hreflang and sitemaps to point to new URLs directly
- Keep redirects in place for at least a year, as Google's site-move guidance recommends, and ideally for good
For large sites, we map by pattern first (every /blog/2021/post-name/ becomes /insights/post-name/, for example), then hand-map the exceptions and the highest-value pages. Our free redirect code generator turns a finished map into Apache, Nginx or WordPress rules, and the URL prefix remover helps split large URL lists by section.
What should you check before a migration goes live?
Before launch, test the new site on staging as closely as possible to how Google will see it: every redirect in the map, robots.txt and meta robots rules, canonicals, internal links, structured data, page speed and the rendered HTML of each template. Benchmark the old site's rankings, traffic and indexed pages too, so you can measure recovery against reality.
- A full crawl of the old site saved as the benchmark, with titles, meta descriptions, canonicals and internal links
- Rankings, organic landing pages and conversions exported for the last 12 months
- Every redirect in the map tested on staging for status code and destination
- Staging protected by a password or IP restriction, not just a noindex tag that could ship to production
- New templates compared with the old ones for missing copy, headings, links and schema
- Core Web Vitals and rendering checked on key templates
- Analytics, Search Console verification and conversion tracking ready on the new site
- A launch-day runbook with owners, a rollback plan and a launch window outside your peak traffic
Our technical SEO checklist covers each of these checks in more depth, and it doubles as a post-launch QA list.
What happens on launch day and after?
On launch day, we remove staging restrictions, crawl the full redirect list against production, submit new sitemaps and, for domain moves, file Google's Change of Address request. Then we monitor closely: Search Console indexing and errors, 404s, rankings for priority pages, organic traffic and conversions, until performance settles back to the benchmark or beyond.
- Go live. Remove password protection and noindex rules, confirm robots.txt, and spot-check the homepage and key templates with Search Console's URL Inspection tool.
- Verify redirects. Crawl the full list of old URLs against production and fix anything that returns a 404, a chain or the wrong destination.
- Tell Google. Submit the new sitemap in Search Console, and use the Change of Address tool for domain or subdomain changes. Google says it isn't needed for HTTP to HTTPS moves. Our XML sitemap generator helps if your platform's sitemap isn't ready.
- Watch the data. Track indexing, crawl errors, 404s, Core Web Vitals, rankings and conversions against the benchmark, and fix issues as soon as they appear.
- Update the outside world. Ask the sites behind your most valuable backlinks to update them, and update your Google Business Profile, social profiles and directory listings.
Google's site move documentation is the primary reference for every step above, and we follow it closely.
How long does it take traffic to recover after a migration?
For a well-executed migration, Google's site-move documentation says a small to medium-sized site can take a few weeks for most pages to move, with larger sites taking longer. Some ranking fluctuation during that window is normal. A drop that persists or deepens after the first month usually signals a specific problem to find.
Recovery speed depends on the type of move. HTTPS moves and simple domain changes with clean one-to-one redirects tend to settle fastest. Replatforms and URL restructures take longer, because Google is evaluating new templates and content as well as new addresses. Mergers can take longest, since consolidated pages have to earn their place again.
We report against the pre-launch benchmark until traffic is back, so you're never guessing whether a dip is normal turbulence or a real issue. If a migration has already gone wrong, the same diagnosis applies, and an SEO audit focused on the move is usually the fastest way to find what broke.
When should you involve SEO in a website migration?
Involve SEO at the planning stage, before the information architecture, URL structure and templates are final. That's when changes are cheap. Bringing SEO in two weeks before launch usually means accepting decisions that are expensive to undo, like platform-imposed URL patterns, missing content or a JavaScript framework that hides content from crawlers.
Our involvement scales with the project. For a WordPress redesign, we might review templates, build the redirect map and handle launch-day QA, alongside our WordPress SEO services. For a large replatform, we join planning, review each release for SEO impact and keep monitoring for months after launch.
Multi-location businesses need extra care with location pages, because each one usually backs a Google Business Profile listing. If your migration touches location URLs, we update profile links and citations alongside the redirects as part of our local SEO work. And because migrations are technical projects at heart, they sit within our technical SEO services.