A replatform puts your search visibility at risk for a predictable window, and the size of that window is decided before you launch, not after. Google's own documentation is blunt about the timeline: for a medium-sized site it takes "a few weeks or more" for new URLs to start replacing old ones in results, and redirects should stay up for "at least 1 year". Map your URLs properly and you ride that out. Map them loosely and you spend the following two quarters buying back traffic you already owned. What has changed recently is that Google is no longer the only index you can fall out of, and the AI engines have no track record of handling a changed URL pattern as gracefully.
The part every migration plan already covers
The core of a safe store migration has been settled for years, and any competent team will already be doing it: every old URL gets a permanent redirect to its closest equivalent on the new site, one hop, no chains. Google's guidance asks for 301 or 308 rather than temporary redirects, and warns to keep redirect chains short — "ideally no more than 3 and fewer than 5" hops, even though Googlebot will follow up to 10.
The part that gets skipped is the unglamorous half: building the map itself. A store that has been trading for five years has product URLs that no longer appear in any menu, old campaign landing pages, category pages that were renamed twice, and a blog with posts that earn steady traffic nobody on the current team remembers writing. None of that shows up when you export a product list from the admin. It shows up when you pull every URL that has earned an impression or a backlink in the last year and reconcile it against what the new site will actually have.
We build that map before a single template gets styled, and it routinely runs to several times the number of rows a client expects, because the live product catalogue is only ever part of it. The rows that cause arguments are the ones with no clean destination: a discontinued product that still ranks, three near-duplicate category pages that need to collapse into one, a campaign URL with real backlinks pointing at an offer that ended in 2023. Each of those is a judgement call about where the value should go, and it is worth making at the spreadsheet stage, where a wrong answer costs an hour — not four months later when a category that used to bring in orders is returning a 404 to everyone including Google.
The other timing decision worth making deliberately: keep the old platform's data accessible somewhere you can query, and do not cancel the old hosting the week you launch. Recovering a redirect target from a database you still have is trivial. Reconstructing one from the Wayback Machine is not.
The risk that migration checklists have not caught up with
Here is what is genuinely new, and it is the reason we now treat a replatform as an AI-search event rather than only a Google event.
The major AI crawlers do not execute JavaScript. Vercel's analysis of crawler traffic across its network with MERJ, published in December 2024, found that none of them render it: OpenAI's crawlers fetched JavaScript files in around 11.5% of requests and Anthropic's in around 23.8%, but neither ran them. Neither company has announced JavaScript rendering for their crawlers since. The practical meaning is unsentimental — if your product copy, specifications, or pricing only exist in the page after client-side JavaScript has fetched and mounted them, those crawlers see an empty shell.
Google is the exception that makes this easy to miss. Googlebot renders JavaScript, and Google's AI features inherit that rendering, as Microsoft's do from Bing. So a client-rendered storefront can look completely healthy in Search Console while being invisible to ChatGPT, Claude and Perplexity. You can pass the test you know how to run and fail the one you don't.
This matters at migration time specifically because replatforming is exactly when rendering strategy changes. A move from a server-rendered theme on a hosted platform to a modern headless storefront is a move into a framework where client-side rendering is a default you have to consciously opt out of. The performance and flexibility gains are real — it's why we build this way — but "renders on the server for crawlers" is a decision someone has to make on purpose. Left to defaults, a team can ship a faster, better-looking store that quietly drops out of the answers their buyers are now asking for. Our note on what AI systems need from product and category pages covers what those pages have to contain; this is the prior question of whether they can be read at all.
The second half of the problem is that these crawlers already spend a lot of effort on URLs that are not there. In that same analysis, roughly 35% of OpenAI's crawler fetches and a similar share of Anthropic's landed on 404s — mostly stale build assets rather than moved content, and Vercel is careful to say the exact cause remains unclear. That is a narrower finding than it first looks, so take it for what it is: these crawlers are not running the patient, decade-tuned re-crawl and consolidation machinery Google has built, and there is no published evidence that they reconcile a changed URL pattern as gracefully. A sloppy redirect map degrades your Google results temporarily. Assume less forgiveness elsewhere until someone demonstrates otherwise.
What we do differently because of it
Three changes to a standard migration plan, in the order they matter.
First, decide rendering explicitly and verify it the boring way. Before launch, fetch key pages with JavaScript disabled and read what comes back. If the product name, description, price and specifications are not in that raw HTML, the page is not ready, regardless of what it looks like in a browser. This check takes minutes and catches the failure mode that costs the most.
Second, treat structured data as migration-critical rather than a later enhancement. Product, breadcrumb and organisation markup frequently lives in platform-specific templates or apps that simply do not come across with your data. Rebuilding it after launch means a gap precisely when engines are re-reading your site and deciding what it is.
Third, keep your canonical strategy stable across the move. Replatforming tends to spawn new duplicate-URL patterns — filter and sort parameters, new pagination, a staging domain that escaped into the index. Migrating while your canonicals are ambiguous means Google and every other crawler consolidate signals onto URLs you did not choose, and you inherit that mess on day one. We wrote a practical guide to canonical problems on SME sites that applies directly here.
None of this replaces the redirect map. It sits alongside it, because the old checklist optimised for one reader and there are now several, with different capabilities.
The Singapore-specific part that breaks
Store migrations here carry an integration burden that generic migration advice underestimates, and it is worth planning for separately from anything search-related.
A typical Singapore store is wired into a local stack: a payment gateway configured for local cards and PayNow, a logistics integration with a regional courier, GST handling that has to keep producing correct tax invoices, and often a marketplace sync to Shopee or Lazada. Those connections are usually platform-specific apps rather than portable standards. When we scope a migration, the integration inventory is a separate document from the URL map, and it is the one that more often determines the launch date. A store that redirects perfectly but cannot issue a compliant tax invoice on Monday morning has not had a good migration.
What we will not promise
Migration outcomes get oversold, and the numbers in circulation deserve scepticism. Most published figures for "traffic lost in a bad migration" come from agencies and platform vendors with an obvious interest in the answer, and few rest on a controlled sample. Treat any tight number, from anyone, as directional: migrations handled carelessly lose meaningful organic traffic and take months to recover.
What can be said honestly is narrower. A well-mapped move usually sees a dip and a recovery over weeks to a few months, with larger and older sites taking longer, consistent with Google's own description of how long reprocessing takes. Some ranking movement is normal and not evidence of a mistake. A poorly mapped move can take much longer and sometimes never fully recovers, because links pointing at dead URLs stop passing anything and nobody goes back to fix them at scale. What a team can actually commit to is not a number but a method — that the decisions which cause loss get made deliberately and verified before launch, rather than discovered in a traffic chart afterwards.
The honest version of the pitch is that this is a risk you can size and largely manage, not eliminate, and that the managing happens in the weeks before launch. By the time traffic drops, the decisions that caused it are already shipped. That is the argument for spending real money on the preparation, and it is how we scope ecommerce migrations — with the mapping, rendering and structured-data work priced in rather than offered as an upsell after the numbers move.
If you are weighing up the platform decision itself rather than the move, our comparison of headless builds against Shopify and WooCommerce is the better starting point.
Frequently asked questions
How long does it take to recover search traffic after a store migration? Google says a small to medium-sized site takes a few weeks for most pages to move across, and larger sites take longer. In practice, expect a visible dip around launch and a recovery over several weeks to a few months when redirects are mapped one-to-one. If traffic has not stabilised after a few months, the problem is usually a redirect or indexing fault rather than a waiting game.
Do I need to keep the old URLs redirecting forever? Google recommends keeping redirects for at least a year, and there is no real downside to keeping them longer. Links and bookmarks pointing at old URLs do not expire on a schedule, so removing redirects early throws away whatever those links were still contributing.
Will moving to a headless store hurt my rankings? Not inherently, but it changes what has to be checked. The risk is rendering: if content only appears after JavaScript runs, Google can usually still read it while AI crawlers cannot. Server-rendering the important content removes the problem, which is why the decision belongs in the build spec rather than a post-launch audit.
Should I use Search Console's Change of Address tool? Only if you are changing domain or subdomain. It does not apply to a platform change on the same domain, where redirects and an updated sitemap do the work.