Replatform without losing search traffic: Google's 2026 migration rules, step by step

Summary. Google's site-move documentation, last updated 17 June 2026, sets out a 5-step procedure and two numbers most replatform plans get wrong. Redirects must stay in place "as long as possible, generally at least 1 year", and while Googlebot can follow up to 10 hops in a redirect chain, Google advises going straight to the final destination and keeping any chain to "ideally no more than 3 and fewer than 5". Its companion redirects page, updated 14 April 2026, ranks 6 permanent redirect mechanisms by how reliably Google interprets them, with HTTP 301 and 308 at the top and JavaScript redirects near the bottom. Meanwhile the ground has shifted underneath: Axios reported on 31 July 2026 that Google search traffic to publishers fell 34% over the past year, so a migration that costs 20% of remaining organic traffic hurts more in 2026 than the same mistake did in 2023. The good news is that Google published on 15 May 2026 that AI features need no special markup at all, which means a replatform does not have to solve AI search and redirect mapping in the same sprint. Get the 301 map right first.

The failure mode is almost never the new platform. It is shipping before anyone built a complete inventory of the URLs the old platform was ranking for.

What Google actually documents

Google's "Site moves and migrations" page covers three cases: HTTP to HTTPS, domain name changes including merging domains, and URL path changes such as example.com/page.php?id=1 becoming example.com/widget. A move that changes hosting but keeps URLs is a different document entirely.

The documented sequence is short: follow general best practices, prepare and test the new site, prepare a URL mapping, start the move by configuring redirects, then monitor traffic on both old and new URLs.

Three pieces of Google guidance inside that sequence contradict common agency practice.

Change one thing at a time. Google says to avoid moving a domain, changing the CMS and relaunching the layout simultaneously. Most replatform projects do all three in one release because the budget was approved once.

Move small and medium sites all at once. Google states that moving all URLs simultaneously "helps our algorithms detect the site move and update our index faster". Phased rollouts are for large sites where monitoring is the constraint.

Expect the crawl spike. Google warns that "after a migration, Google will temporarily crawl your new site more heavily than usual", because redirected crawls of old URLs land on top of normal crawling. Capacity planning for launch week has to account for that, and Google suggests telling large sites' hosting providers in advance.

John Mueller, Search Advocate at Google, has explained the underlying mechanism in plain terms: "search engines like Google store their index on a per page basis", so "if you change the address or the URL of a page that page's data has to be forwarded somehow otherwise it gets lost." Every rule below follows from that sentence.

The redirect rules, ranked

Google's redirects documentation orders redirect types by how likely Google is to interpret them correctly. That ordering is the practical spec for a migration.

Google frames the difference in one line: "Permanent redirects: Show the new redirect target in search results. Temporary redirects: Show the source page in search results." A migration launched on 302s tells Google the old URLs are still canonical, which is the opposite of the intent.

Two further constraints from the same pages. Chains cost latency and support: Googlebot follows up to 10 hops, but Google advises redirecting straight to the final destination and keeping any unavoidable chain to no more than 3, and fewer than 5. And the redirect retention rule is explicit: "Keep the redirects for as long as possible, generally at least 1 year. This timeframe allows Google to transfer all signals to the new URLs, including recrawling and reassigning links on other sites that point to your old URLs." Google adds that from the user's perspective you should consider keeping them indefinitely.

The four mistakes Google names

Google's own troubleshooting table lists the recurring failures. They are worth reading as a pre-launch checklist rather than a post-mortem.

Leftover blocks. noindex meta rules and robots.txt disallows added during staging survive into production more often than anyone admits. Google's advice is to decide in advance what robots.txt should look like at launch and to keep a list of every URL that needs its noindex removed.

Redirects to URLs that do not exist. Google's wording: "We frequently see people redirecting to the wrong (non-existent) URLs on the new site." A URL map is only useful if the destinations were tested against the built site, not against the spec.

Redirecting everything to the homepage. Google is unambiguous: "Don't redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site. This can confuse users and might be treated as a soft 404 error." Consolidating several old pages onto one genuinely equivalent new page is fine. Dumping 4,000 orphaned URLs on the homepage is not.

Insufficient server capacity and stale sitemaps. Both follow from the crawl spike above.

There is a fifth item Google does not list as a mistake but that decides outcomes: completeness of the inventory. Google's prescribed sources for the old-URL list are sitemaps, server logs and analytics, the links report in Search Console, and the CMS itself. It also says to include embedded assets, because "videos, images, JavaScript, and CSS files. These URLs need to be moved in the same way as all other content." Image URLs are the most commonly forgotten set, and image search traffic disappears quietly.

A migration sequence that survives contact with a deadline

Two details from Google's documentation that change this plan. The Change of Address tool applies to domain moves and Google states explicitly that "if you're moving your site from HTTP to HTTPS, you don't need to use the Change of Address tool"; for a domain move you submit it for every verified variant, including subdomains and the www and non-www forms, even ones you do not actively use. And redirect warnings on the old sitemap are expected: "Search Console may show warnings for the sitemap that contains the old URLs about the URLs redirecting; this is normal and you can ignore these warnings."

On timing, Google's own estimate is measured in weeks, not days: "As a general rule, a medium-sized website can take a few weeks for most pages to move in our index; larger sites can take longer." It also notes the move happens per URL, and that Googlebot has to visit every URL on both the old and new site at least once before the move counts as complete.

What AI search changes, and what it does not

This is where 2026 migration plans waste the most effort.

Google published guidance on 15 May 2026 stating that appearing in AI Overviews and AI Mode requires no special preparation. Its wording: "You don't need to create new machine readable files, AI text files, or markup to appear in these features. There's also no special schema.org structured data that you need to add." Search Engine Journal's read of the same guide was that Google is calling answer engine optimisation and generative engine optimisation "still SEO". There is no separate AI migration checklist to build.

What has changed is the stakes. Axios reported on 31 July 2026 that Google search traffic to publishers fell 34% over the past year, and Press Gazette has reported projections that pageviews delivered by Google to leading UK publishers could halve by the third quarter of 2027 if the current trajectory holds. When the baseline is already falling, a self-inflicted migration loss compounds with a decline you did not cause.

The practical conclusion is unglamorous. Preserve the URLs, preserve the content, preserve the internal link graph, and keep the structured data you already had because it still earns rich results. Do not delay a migration to add AI-specific markup that Google says it does not use. Our notes on structured data and AI search citations and on whether llms.txt helps in Google cover that ground, and the AI search optimisation guide sets out what does move the needle.

Headless replatforms have three extra failure points

Moving from a monolithic CMS to a headless stack adds problems that a like-for-like CMS swap does not.

Rendering. If pages that were server-rendered become client-rendered, Google has to execute JavaScript to see the content. Google's own redirect guidance flags the general risk: a JavaScript redirect "might never" be seen if rendering fails. The same exposure applies to primary content. Static generation or server rendering removes the question entirely, which is the main reason a static-first framework pairs well with a headless CMS.

Trailing slashes and case. Headless frameworks often normalise URL forms differently from the old platform. A site that served /product/widget/ and now serves /product/widget has changed every URL on the site, and every one of them needs a mapped 301 rather than a platform-level guess.

Asset URLs. Images move to a CDN with new paths, which is exactly the case Google calls out as needing the same treatment as any other content. Our work on headless content platforms built on Sanity and Astro treats the URL contract as a first-class deliverable rather than an implementation detail, and the Core Web Vitals engineering service covers the performance parity check that belongs in the same launch gate.

India-specific considerations

Indian replatforms carry two extra constraints.

Multilingual and multi-region sites are common, and rel-alternate-hreflang annotations break silently when URLs change. Google's site-move documentation says directly that these annotations must be updated to the new URLs. A Hindi or Tamil variant pointing at a dead English URL removes both pages from the pairing.

Personal data moves with the content. Under India's Digital Personal Data Protection Act 2023, a replatform is a good moment to audit what personal data the old CMS accumulated in form submissions, comments and user profiles, and to decide what is migrated rather than copying the database wholesale. Migrations are one of the few times a team looks at every record it holds.

How we run a replatform migration

eCorpIT, founded in 2021 and based in Gurugram, builds and migrates content platforms with the URL contract treated as the first deliverable rather than a launch-week task. Our senior engineering teams work under CMMI Level 5, MSME and ISO 27001:2022 practices, and we are partners of AWS, Microsoft and Google.

A typical engagement runs in four stages. We start with a baseline: a full crawl, Search Console and log-file export, and a ranked inventory of every URL with traffic. We then produce the mapping as a reviewable artifact, one row per old URL, with the destination and the expected status code, and we test it against the staging build rather than the specification. Launch is a gated release with the redirect layer, canonicals, hreflang and sitemaps landing together, and staging blocks removed by checklist. Then we monitor for 12 weeks against the pre-migration baseline, because Google's own guidance says the move completes per URL over weeks rather than at the moment of release.

This is for teams replatforming a content site, moving to a headless CMS, consolidating domains after an acquisition, or finishing an HTTP to HTTPS move that was never completed properly.

FAQ

How eCorpIT can help

eCorpIT plans and executes replatform migrations end to end: baseline crawl and log analysis, a reviewable URL map, the redirect layer, canonical and hreflang updates, and 12 weeks of monitoring against your pre-migration numbers. We build headless content platforms on Sanity and Astro, and we design systems aligned with DPDP requirements for Indian deployments. If you have a replatform dated in the next quarter and no URL inventory yet, talk to our technical SEO and platform team before the build is finished, not after.

References

1. Site moves and migrations, Google Search Central, updated 17 June 2026 — the 5-step procedure, redirect retention, crawl spike and troubleshooting table.

1. Redirects and Google Search, Google Search Central, updated 14 April 2026 — permanent versus temporary redirect types and Google's ordering.

1. AI features and your website, Google Search Central — Google's statement that no special markup or files are needed for AI Overviews and AI Mode.

1. Change of Address tool, Search Console Help — when and how the tool applies.

1. How Google responds to a site move, Search Engine Journal — John Mueller on per-page indexing and forwarding URL signals.

1. Google explains SEO site migrations are hard because URL signals need to be forwarded, Search Engine Roundtable — the same Google explanation, reported independently.

1. Google's new AI search guide calls AEO and GEO "still SEO", Search Engine Journal — analysis of the May 2026 AI features guidance.

1. Publishers are losing Google traffic as AI answers replace links, Axios, 31 July 2026 — the 34% year-on-year decline in search traffic to publishers.

1. Google search traffic to leading UK publishers set to halve by Q3 2027, Press Gazette — the projection behind the falling baseline.

1. Google's site move guide now covers www and non-www domain variants, PPC Land — reporting on the 2026 update to the site-move documentation.

1. Impact of AI Overviews and how publishers need to adapt, Search Engine Journal — context on the traffic environment a migration lands in.

1. Google highlights links from subscribed publications in new AI Overviews update, Nieman Lab — the 2026 changes to how AI Overviews surface links.

Last updated: 4 August 2026.