--- title: 'How to migrate a website without losing your rankings' url: 'https://mountainairweb.com/blog/migrate-a-website-without-losing-rankings' markdown: 'https://mountainairweb.com/blog/migrate-a-website-without-losing-rankings.md' date: '2026-08-12' description: 'Short answer: a migration done properly dips 10–30% for two to six weeks and comes back. A migration done badly (missing redirects, a staging noindex pushed live, rewritten titles) can lose half its traffic for a year or more. Google’s own guidance is specific: permanent 301s for every old URL, kep…' taxonomy: category: - Migrations --- [Migrations](https://mountainairweb.com/blog/category:Migrations) August 12, 2026 7 min read # How to migrate a website without losing your rankings A 2025 study of 892 domain moves found the average site took 523 days to get its organic traffic back. The ones that recovered in weeks all did the same six things. Nicholas Murray Author **Short answer:** a migration done properly dips 10–30% for two to six weeks and comes back. A migration done badly (missing redirects, a staging `noindex` pushed live, rewritten titles) can lose half its traffic for a year or more. Google’s own guidance is specific: permanent 301s for every old URL, kept for at least a year, with no more than three hops. Everything else on this page is how you make sure that actually happens, plus the two things most checklists now miss: AI crawlers and sites that have no export. ## What "normal" looks like, and what a problem looks like Search Engine Journal’s June 2026 piece on the "migration hangover" draws the line clearly: a normal move sees a 10–30% dip that stabilises in two to six weeks; a hangover is a 50%+ decline that lasts 12–18 months ([SEJ](https://www.searchenginejournal.com/what-is-a-migration-hangover-traffic-drop-how-do-you-avoid-it/575102/)). A practical rule from Krawl Digital: if organic traffic is down more than 25–30% and hasn’t stabilised within a month, stop treating it as volatility and start treating it as a bug ([Krawl](https://krawl.digital/website-migration/traffic-drop-after-migration/)). The sobering number is from Dan Taylor’s January 2025 study of 892 domain migrations: on average it took **523 days** for the new domain to match the old one’s organic traffic, and 17% had not recovered after 1,000 days ([SEJ](https://www.searchenginejournal.com/how-long-should-an-seo-migration-take/531219/)). Domain changes are the hardest case; a platform change on the same domain is gentler, but the failure modes are identical. ## Why migrations lose traffic Almost every hangover traces back to one of these: | Cause | What happened | How you catch it | |---|---|---| | Missing or temporary redirects | Old URLs 404, or 302 instead of 301 | Crawl the old URL list after launch | | Redirect chains | http → https → www → trailing slash | Screaming Frog "All Redirects" report | | Staging `noindex` or robots block went live | The whole site vanishes in days | Check `robots.txt` and meta robots within an hour of launch | | Canonicals still point at old URLs | Google keeps the old page as canonical | Crawl for canonical mismatches | | Titles, metas and headings rewritten | Pages re-rank from scratch | Diff the post-launch crawl against the pre-launch baseline | | Internal links restructured | Link equity moves away from money pages | Compare internal-link counts per URL | | Image and PDF URLs not redirected | Image and document rankings lost | Include media in the URL map | | Structured data dropped by the new theme | Rich results disappear | Rich Results Test on every template | | Performance regression | Core Web Vitals fall, rankings follow | Benchmark CWV before, re-test after | Google’s guidance is blunt on the first two: use permanent redirects (301 or 308), keep them "for as long as possible, generally at least 1 year," and keep chains to "ideally no more than 3 and fewer than 5" ([Google Search Central](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes)). Googlebot will follow up to 10 hops, but a 302 is treated as a "weak signal" and may leave the old URL in results ([Google](https://developers.google.com/search/docs/crawling-indexing/http-network-errors)). The staging-`noindex` mistake deserves its own line because it is so common: a build is correctly hidden on staging, the settings come across at launch, and the site is de-indexed before anyone notices. Google’s checklist literally ends with "don’t forget to remove any noindex or robots.txt blocks that were only needed for the migration." ## The checklist we run ### Before anything is built 1. **Crawl the current site and keep the crawl.** Screaming Frog or Sitebulb, capturing every URL, status code, title, meta description, H1, canonical, hreflang and internal-link count. This is the baseline everything is compared against. 2. **Build the URL list from more than the crawl.** Add Search Console landing pages, analytics landing pages, server logs, XML sitemaps and backlink targets from Ahrefs or Majestic. The crawl misses old campaign pages, pagination (`/blog/page/2/`), filtered views and regional subfolders that still have links pointing at them. 3. **Benchmark traffic, rankings and Core Web Vitals** so "it got worse" can be proven or disproven. 4. **Decide what will not change.** Titles, metas, headings and URL structure stay unless there is a reason. "Nice to have" rewrites are the most common self-inflicted loss. ### Redirect map One old URL → one new URL, single hop, 301. No lazy "everything goes to the homepage." On larger sites this is hundreds of rules: our last enterprise rebuild shipped 402 of them, with 404 logging on from day one. In WordPress the Redirection plugin handles this well, including bulk-redirecting the 404s it logs after launch ([Redirection](https://wordpress.org/plugins/redirection/)). ### On staging Verify that every redirect fires, staging is blocked from search, canonicals point at the production URLs (not staging ones), and the sitemap contains no `noindex` pages. Validate structured data on every template type; as one 2026 checklist puts it, "migrations break schema markup more often than you’d think, especially if the new theme uses a different plugin" ([Khorana](https://gautamkhorana.com/blog/site-migration-seo-checklist-2026/)). ### Launch window Lower DNS TTL to 300 seconds a day or two before. Content freeze. Deploy redirects at the server level before DNS moves so the first crawler to arrive finds them. Keep the old site live until the new one is verified. Swap sitemaps in Search Console. If the domain is changing, use the Change of Address tool, and note Google’s June 2026 update: it now wants a separate request for every variant of the old domain (www, non-www, language subdomains), all verified first ([TechWyse](https://www.techwyse.com/news/platform-updates/google-domain-migration-seo-change-of-address-update)). ### First two hours Crawl the new site. Check `robots.txt` is the production one. Check no indexable page carries `noindex`. Check the home page with URL Inspection. Diff titles and metas against the baseline. Then crawl the *old* URL list in list mode with "Always Follow Redirects" on and read the "All Redirects" report for 404s, chains and temporary redirects ([Screaming Frog](https://www.screamingfrog.co.uk/audit-redirects/)). ### Next 90 days Watch Search Console coverage, traffic by landing-page type, rankings for the top 100 queries and the backlink profile. Review new 404s weekly for the first month, monthly after that, and redirect the ones with links or traffic. ## The case nobody writes checklists for: no export Plenty of corporate and non-profit sites run on a custom or legacy CMS with no export function and no developer who remembers it. The content still has to come across complete, because every missing page is a lost ranking and, often, a lost inbound link. The approach that works: crawl the rendered site to get the URL list, then write a scraper that targets the content container on each template (`DOMXPath` in PHP, or a headless browser for JavaScript-rendered pages), extracts title, body, images and any structured fields, downloads the original media, and writes it into the new CMS with the old URL recorded against every item for the redirect map ([Mavlers](https://www.mavlers.com/blog/web-scraping-content-migration-wordpress/)). We did exactly this for a conservation organisation whose legacy platform held a decade of pages and a 10,000-row wildlife-sightings dataset; the scrape also surfaced a privacy problem (reporter email addresses in page comments) the client did not know they had. You get the complete archive even if the rebuild never happens. ## The new wrinkle: AI crawlers Two things changed in the last eighteen months. First, volume: Cloudflare measured GPTBot requests up 305% between May 2024 and May 2025, making it the largest AI crawler at 30% of AI-bot traffic, with ClaudeBot at 21% ([Cloudflare](https://blog.cloudflare.com/from-googlebot-to-gptbot-whos-crawling-your-site-in-2025/)). Second, behaviour: a May 2026 analysis found GPTBot, ClaudeBot and PerplexityBot treat 301/308 as permanent like Google does, but the *search* bots (OAI-SearchBot, Claude-SearchBot) tolerate only about three redirect hops, and answers take 15–30 days to settle on new URLs versus 7–14 for Google ([CaptainDNS](https://www.captaindns.com/en/blog/ai-crawlers-redirects-handling-gptbot-claudebot-perplexitybot)). That `http → https → www → slash` chain that Google forgives can drop a page out of AI answers entirely. So the AI additions to the checklist are short: single-hop redirects (which you wanted anyway), a production `robots.txt` that explicitly allows GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot and Google-Extended if you want to be found there, and structured data that survives the theme change. An `llms.txt` file is cheap and harmless, but don’t expect it to do much: Google’s John Mueller compared it to the keywords meta tag, and a 90-day log study of 515 million AI-bot events found only 408 requests for `/llms.txt` ([SEJ](https://www.searchenginejournal.com/google-llms-txt-comparable-keywords-meta-tag/544804/), [limy.ai](https://limy.ai/blog/llms-txt-in-2026-the-full-guide)). Crawlable HTML and clean redirects matter; the manifest file is a courtesy. ## If you remember one thing The migrations that recover in weeks are not lucky. They have a complete URL list before the build starts, one 301 per URL at launch, a crawl in the first two hours, and someone watching 404s for three months. If you are planning a move, start with the crawl; if you want a second pair of eyes on an existing plan, the [free site audit](https://mountainairweb.com/free-audit) covers redirect and crawl hygiene, and the [migrations service](https://mountainairweb.com/services/migrations) page explains how we scope the rest. ## More from the journal [See all posts](https://mountainairweb.com/blog) MigrationsSep 2, 2026 ### The website migration SEO checklist: before, launch day, and the 90 days after A working SEO website migration checklist in three phases: what to capture before the build, what to verify… [The website migration SEO checklist: before, launch day, and the 90 days after](https://mountainairweb.com/blog/website-migration-seo-checklist) AI & SearchOct 7, 2026 ### What AI search optimization actually means (and what it costs to ignore) GEO, AEO and AI visibility are the same job with different labels. Here is how ChatGPT, Perplexity, Google… [What AI search optimization actually means (and what it costs to ignore)](https://mountainairweb.com/blog/what-ai-search-optimization-means) --- ## Navigation - Parent: [Blog](https://mountainairweb.com/blog.md) - Previous: [What actually gets a business cited by ChatGPT, Perplexity and Google AI](https://mountainairweb.com/blog/what-gets-a-business-cited-by-ai.md) - Next: [WordPress security in 2026: what your IT team will ask, and the honest answers](https://mountainairweb.com/blog/wordpress-security-for-marketing-teams.md)