Replatforming Without Losing Traffic: A Migration Playbook

Why replatforming tanks traffic, and why it does not have to

I have moved sites off Magento, off custom PHP, off aging WordPress builds, and onto Shopify, headless stacks, and modern CMS platforms, and I can tell you the single most common outcome of a replatform that nobody planned carefully: a traffic cliff two weeks after launch that the team did not see coming. The new site looks better. It is faster. The founder is proud of it. And organic sessions are down 40 percent because the migration quietly severed the thousand small connections that made the old site rank. None of that had to happen. A migration that keeps its traffic is not luck, it is a checklist executed with discipline, and that checklist is what this piece is.

The mechanism is straightforward, and once you understand why traffic drops you can prevent every cause. Search engines do not rank your brand, they rank specific URLs that have accumulated trust, links, and ranking history over years. When you replatform, three things tend to change at once: the URLs move, the on-page signals (titles, headings, schema, internal links) get regenerated by a new template, and the technical characteristics (speed, crawlability, rendering) shift. Each of those is a lever that can cost you rankings. Do all three carelessly on the same day and you have not launched a new site, you have launched a different site that Google has never seen, pointed at addresses that used to work and now 404.

The URL change is the big one. Every ranking page on your old site is an address that Google has indexed, that other sites link to, and that lives in someone's bookmarks and in the search results themselves. Change the URL without telling Google where the content went and you throw away the entire ranking history of that page. The link equity pointing at it evaporates. The engine finds a 404 or a soft-404 where a ranking page used to be, drops it from the index, and the traffic goes with it. This is the number-one cause of migration traffic loss, and it is completely preventable with a redirect map, which is why I spend more time on URL mapping than on anything else.

The second cause is subtler and it fools people because the content "looks the same." A new platform regenerates your pages through new templates, and in that regeneration the title tags revert to a generic pattern, the H1 changes, the meta descriptions get auto-filled, the structured data that earned you rich results disappears because the old theme emitted it and the new one does not, and the internal links that passed authority around your site get rebuilt into a different, weaker shape. The words on the page might be identical, but the signals Google used to rank that page are gone. You migrated the content and lost the SEO, and the two are not the same thing.

The third cause is technical: the new site renders content with JavaScript that Googlebot struggles with, or the crawl gets trapped in faceted URLs, or Core Web Vitals regress because the shiny new theme ships three megabytes of script. These are real, and I cover them, but they are usually secondary to the first two. Most catastrophic migrations I have been called in to rescue died on URLs and lost on-page signals, not on rendering.

So the frame for this entire playbook is simple and it is the opposite of how most teams approach a replatform. They treat the migration as a design-and-build project with SEO as a box to tick near the end. I treat it as an SEO-preservation project that happens to involve a new platform. The build is the easy part. Keeping every ranking page's identity, address, and signals intact through the move is the hard part, and it is the part that decides if your organic traffic survives. Get that right and a replatform can actually lift you, because you inherit the old rankings on a faster, better-structured site. Get it wrong and the best-looking site of your career becomes the quarter you explain to your board.

The pre-migration audit and baseline: measure before you touch anything

You cannot protect what you have not counted, and the number-one reason teams cannot tell if a migration succeeded is that they never wrote down what the old site was doing before they broke it. The first phase of any replatform, weeks before a single new page ships, is a full inventory and a baseline. If you do nothing else in this playbook, do this, because it is the difference between diagnosing a drop in an afternoon and arguing about it for a month.

Start with a complete crawl of the existing site. I use Screaming Frog or a comparable crawler to pull every indexable URL, its status code, its title tag, its meta description, its H1, its canonical, its word count, and its internal-link count. Cross-reference that crawl with three other sources: your XML sitemap (what you think you have), Google Search Console's Pages and Performance reports (what Google actually has indexed and which URLs earn clicks), and your server logs or analytics (what actually gets traffic). The union of those lists is your true inventory. The crawl alone misses orphaned pages that still rank; Search Console catches those. This is the master list every later step maps against.

Now baseline the performance so you have a before picture to compare against. Export from Search Console, ideally sixteen months of it, your top pages by clicks and impressions, your top queries, and your average positions on the terms that matter. Export from analytics your organic sessions and conversions by landing page. Record your current Core Web Vitals field data. Snapshot your indexed page count. Note your top backlinked pages from Ahrefs or Semrush, because those are the URLs where a broken redirect costs you the most link equity. Save all of this with a date stamp. When someone asks in week three if traffic is down, you will have the exact answer instead of a feeling.

The most important artifact that comes out of this phase is a prioritized list of what actually matters. Not every URL is equal. A handful of pages usually drive the majority of your organic traffic and revenue, and a different handful hold the majority of your backlinks. Those are your protected pages, and they get individual human attention through the migration: a hand-checked redirect, a verified title and schema, a QA pass of their own. The long tail gets handled by rules and patterns. Spending equal effort on a page that gets two clicks a month and your top money page is how migrations run out of time and cut corners on exactly the pages they cannot afford to lose.

While you are auditing, document the technical baseline too, because these are the things that silently change on a new platform. Record the current URL structure and any patterns (trailing slashes, case, parameters, subfolder versus subdomain). Record which pages carry which schema types and confirm they validate. Record the robots.txt rules and which parameters are blocked. Record the canonical strategy. Record how pagination and faceted navigation are handled. Each of these is a decision the old site made that the new platform will make differently unless you tell it not to, and each one is a place a migration leaks traffic.

Finally, set the success criteria before launch, in writing, because after launch everyone's memory gets creative. Agree on what "no traffic loss" means (I use: organic clicks recover to within a few percent of baseline within 4 to 8 weeks, and no protected page loses more than one position permanently), agree on who watches which dashboard, and agree on the rollback trigger. A migration with a defined rollback plan and a named owner for each metric is a migration that gets caught early when something goes wrong. A migration where everyone assumed someone else was watching Search Console is how a 40 percent drop runs for three weeks before anyone notices.

URL mapping: the one-to-one redirect map that saves the migration

If the new site keeps the exact same URLs as the old one, you can skip most of this section and thank whoever made that decision, because unchanged URLs are the safest migration there is. But most replatforms change URLs, sometimes by choice (a better structure) and sometimes because the new platform forces its own conventions. The moment a single ranking URL changes, you need a redirect map, and the quality of that map is the single biggest determinant of how much traffic the migration keeps.

A redirect map is a spreadsheet with two columns that matter: old URL and new URL. Every indexable URL from your pre-migration inventory goes in the old column, and every one gets a new-column destination. The rule that governs the destination is the one people get wrong under time pressure: redirect each old URL to the new URL that most closely matches its content and intent, one to one, not to the homepage. A redirect to the homepage is barely better than a 404 in the eyes of a search engine, because it tells the engine the specific content is gone and passes almost none of the old page's relevance forward. The homepage redirect is the classic migration mistake, and it is usually the result of running out of time and taking the lazy bulk option.

Build the map in layers, because you rarely need to hand-map thousands of URLs individually. Most URL changes follow patterns: the old site used /product.php?id=123 and the new one uses /products/marlow-weekender, or the old blog lived at /2024/06/post-title and the new one at /blog/post-title. Where a clean pattern exists, a regex or rule-based redirect handles hundreds of URLs at once, and you should use it. But the pattern rules never cover everything. There is always a tail of one-off pages, merged pages, retired pages, and special cases, and those get hand-mapped. Critically, your protected pages, the top traffic and top backlink URLs from your audit, get individually verified even if a rule would have covered them, because those are the ones you cannot afford to have a pattern quietly misroute.

Handle the awkward cases deliberately, because they are where maps go wrong. When one old page splits into several new ones, redirect it to the best single match, usually the most comprehensive one. When several old pages merge into one, redirect all of them to the merged page, and make sure the merged page actually covers what each old page ranked for. When a page is genuinely retired with no replacement, decide between a 301 to the closest relevant page (preserves some equity, my usual default) and a clean 410 Gone (honest, and appropriate when the content is truly dead and you do not want it in the index). Do not leave retired pages as soft 404s or as redirects to irrelevant pages, because both waste crawl budget and confuse the engine.

A few technical rules keep the map clean. Use 301 (permanent) redirects, not 302 (temporary), because 301 tells the engine to transfer ranking signals and update its index to the new URL, while a 302 tells it to keep the old URL indexed and expect the change to reverse. Avoid redirect chains: if A used to redirect to B and now B moves to C, update the A redirect to point straight at C, because every hop in a chain loses a little equity and slows the crawl, and chains longer than a couple of hops can stop being followed. Watch for redirect loops, which will make a page uncrawlable entirely. And preserve the redirects from any previous migration: if your old site already had a redirect layer from a move three years ago, those old-to-older mappings still carry equity and must be carried forward, chained down to the final destination.

The deliverable at the end of this phase is a complete, reviewed redirect map covering one hundred percent of your indexable old URLs, with the protected pages hand-verified, ready to be loaded into the new platform or the server config on launch day. I treat this map as the most important document in the entire migration. When I audit a failed migration, the map is the first thing I ask for, and about half the time it either does not exist, covers only the pages someone remembered, or points everything at the homepage. A complete one-to-one map is boring, tedious work, and it is the work that saves the traffic.

The 301 redirect strategy: implementing the map without leaks

A perfect redirect map is worthless if it is implemented badly, and implementation is where good maps die. The map lives in a spreadsheet; the redirects have to live in the server, the CDN, or the platform, and every layer has its own quirks that can break a redirect you thought was working. This section is about turning the map into redirects that actually fire, in the right order, without introducing the chains, loops, and 302s that quietly bleed equity.

Decide first where the redirects will live, because different platforms give you different options and some are far more reliable than others. A server-level redirect (in nginx config, an Apache .htaccess, or a CDN edge rule at Cloudflare or Fastly) is the fastest and most robust, because it fires before the application even loads and cannot be broken by a theme update. A platform-level redirect (Shopify's URL redirects, a WordPress redirect plugin, a Next.js redirects config) is more convenient and often the only option on hosted platforms, but it can be slower and, on some platforms, capped in number or order-sensitive. My preference where I have the choice: handle the bulk pattern redirects at the edge or server level for speed, and use the platform's native redirect tool for the hand-mapped tail where I want it version-controlled with the site. Whatever you pick, the redirect must return an actual 301 status code, which you verify with a header check, not a browser that shows you the destination and hides the status.

Order and specificity matter more than people expect. If you have both a broad pattern rule and specific one-off redirects, the specific ones must win, which usually means they need to be evaluated first or matched more precisely. A common failure is a greedy pattern rule that catches a URL you meant to hand-map, sending it to the pattern destination instead of the correct one. Test the protected pages explicitly after implementation to confirm each one lands where the map says, not where a broad rule swept it. On platforms that evaluate redirects top-down, sequence the specific rules above the general ones.

The HTTPS and www and trailing-slash normalizations deserve their own attention because they are redirect chains hiding in plain sight. If your old site served http and non-www, and the new site is https and www, a single old URL can now require http-to-https, then non-www-to-www, then old-path-to-new-path: three hops where there should be one. Collapse them. The redirect from any old URL should reach the final canonical new URL in a single 301 wherever possible. Configure the protocol, host, and trailing-slash canonicalization so they compose into one hop rather than stacking. This is the most common source of accidental chains I find in post-launch audits.

Do not forget the assets and the non-HTML URLs. Images that rank in image search, PDFs that earn links, old XML sitemaps, and RSS feeds all have URLs that may change, and they all deserve redirects. Losing the URL of a PDF that has accumulated backlinks over five years is throwing away link equity just as surely as losing a page. Redirect the old XML sitemap location if it moves, and submit the new sitemap immediately on launch so Google recrawls the new URLs and sees the redirects fast rather than discovering them slowly.

Keep the redirects forever, or at least far longer than feels necessary. There is a persistent myth that you can remove 301s after a few months once Google has "processed" them. Remove them too early and you re-break every external link and every lingering index entry that still points at the old URL, and those can persist for years. Backlinks from other sites do not update because you migrated. I keep migration redirects in place indefinitely, and I only prune them when I can prove from logs that nothing, no crawler and no human, has hit the old URL in a very long time. The cost of keeping a redirect is a config line. The cost of removing it early is re-losing the traffic you worked to preserve.

Preserving on-page signals: titles, metadata, headings, and internal links

URLs are the address, but the signals on the page are what actually earned the ranking, and a new platform will happily regenerate every one of them into something different unless you make preservation an explicit requirement. This is the migration cause that fools people, because the content reads the same and everyone assumes the SEO came along for the ride. It did not. The title tag, the meta description, the heading structure, and the internal links are all things the old templates produced and the new templates will reproduce their own way. Preserving them is a deliberate act.

Title tags and meta descriptions are the first casualties. A new CMS or store platform typically has a default title pattern, something like "Page Name | Brand," and unless you migrate the custom titles you wrote, every page reverts to that generic pattern on launch. If your top pages ranked partly because their titles were carefully written with the right keyword in the right position, and the migration reverts them to a template default, you lose that on-page relevance across your whole site at once. The fix is to carry the exact title and meta from your pre-migration crawl into the new page's SEO fields, and to verify it on the protected pages after launch. Treat your old crawl as the source of truth for what every page's title and meta should be, and reconcile the new site against it.

Heading structure matters more than its reputation suggests. The H1 tells the engine what the page is about, and the H2 and H3 hierarchy maps the content's structure. New templates love to change this: they turn your H1 into a styled div, or they wrap the whole page in an H1 that is the site name, or they demote your real heading to an H2 and promote a navigation label to H1. When you QA the new pages, check that each page has exactly one meaningful H1 that matches its topic, and that the sub-heading hierarchy survived. This is cheap to check and cheap to fix, and it is exactly the kind of thing that silently degrades ranking because nobody looks at the rendered heading tags.

Structured data is the signal most likely to vanish entirely, because it was often emitted by the old theme or an SEO plugin and the new platform has no idea it existed. If your product pages earned star ratings from Product and Review schema, your articles earned rich results from Article schema, or your FAQs showed up as expandable results from FAQPage schema, all of that disappears the moment you launch a platform that does not emit it. Migrating schema is not automatic. Inventory which pages carried which schema types in the audit, make sure the new platform emits the equivalent (natively, through a plugin, or through custom template code), and validate every type with the Rich Results Test before and after launch. A store that loses its Review schema in a migration loses its star ratings in the results, and the click-through drop from that alone can look like a ranking loss.

Internal links are the signal people forget entirely, and they carry a surprising amount of weight. Your old site had a specific internal-link graph: the navigation, the breadcrumbs, the contextual links inside body content, the related-product and related-article modules. That graph told search engines which pages were important and how they related. A new platform rebuilds navigation and modules from scratch, and the contextual links inside your migrated content often break, because they were hard-coded to old URLs that now 301 (a chain) or 404 (a dead link). Update the internal links inside your content to point at the new URLs directly, not through redirects, so the internal-link graph is clean and no equity is lost to chains. Rebuild the navigation and breadcrumbs to express the same hierarchy the old site did, or a better one. The pages that were well-linked internally should stay well-linked internally, or you will watch them slip.

One more preserved signal that is easy to overlook: the canonical tags and the media. Confirm the new site self-canonicalizes correctly and does not accidentally canonicalize everything to the homepage or leave stale canonicals pointing at old URLs, which I have seen a template do. And carry the image alt text and descriptive filenames forward, because they feed both accessibility and image search, and a migration that renames every image to a hash and blanks the alt text throws away visual-search ranking that took years to build. The theme of this whole section is one sentence: the content coming across is necessary but not sufficient, and the signals wrapped around that content are what you are actually migrating.

Staging and QA: catch the failures before the world sees them

Everything up to now happens on paper and on staging, and staging is where a disciplined team catches the problems that a rushed team discovers in production with real traffic watching. A staging environment is a full copy of the new site, not yet public, where you can crawl, test, and QA the migration end to end before anyone flips the switch. If your migration plan does not include a staging phase with a real QA pass, it is not a plan, it is a hope.

The first and most dangerous staging mistake is letting Google index the staging site. A staging environment full of duplicate content, if crawlable, can get indexed and create a genuine duplicate-content mess, and worse, if the staging robots.txt blocks everything and that robots.txt accidentally ships to production on launch, you deindex your entire live site in one move. This is not hypothetical, it is one of the most catastrophic migration failures there is and it happens regularly. Protect staging with HTTP authentication (a password prompt) rather than relying only on robots.txt or a noindex tag, and put a hard checklist item on launch day to confirm the production robots.txt allows crawling and the noindex tags are gone. The single line "Disallow: /" surviving from staging to production has killed more migrations than any algorithm update.

Crawl the staging site the same way you crawled the old one, and compare. Point Screaming Frog at staging and pull the same fields: URLs, status codes, titles, metas, H1s, canonicals, word counts. Now diff it against your pre-migration crawl. This comparison is where the migration's health becomes visible. Are the titles the ones you wrote or the template defaults? Does every page have one H1? Are the canonicals self-referential and correct? Are there pages returning 404 or 500 that should exist? Is the word count on your key pages roughly what it was, or did content get truncated or dropped in the move? A side-by-side crawl diff turns a vague "does it look right" into a concrete list of pages that regressed.

Test the redirects against staging or a redirect-testing setup before launch, because the redirect map is only proven when it fires. Take your list of old URLs, especially the protected pages, and confirm each one 301s to the correct new URL with a single hop. Many teams write a perfect map and never test that it was implemented correctly, then discover on launch day that a quarter of the redirects point at the wrong place or chain through three hops. Automate this: a script that takes the old-URL column, requests each one against the new environment, and flags any that do not return a single 301 to the mapped destination. Run it until it is clean.

Render the pages the way Googlebot will, because a beautiful new site can be invisible to a crawler. If the new platform renders content client-side with JavaScript, test what the raw HTML contains before JavaScript runs, using the URL Inspection tool's rendered-HTML view or a crawler in JavaScript-rendering mode. Content that only appears after client-side hydration is content Google may not see reliably or may see slowly, and a migration from a server-rendered site to a client-rendered one is a classic silent traffic killer. Confirm the main content, the internal links, and the structured data are present in the rendered output the crawler receives.

Run the full QA checklist across the protected pages by hand, because automation catches structure and humans catch meaning. On each top page, confirm: the title and meta match what you intended, the H1 is right, the content is complete and not truncated, the schema validates in the Rich Results Test, the internal links work and point at new URLs, the images load with alt text, the canonical is correct, and the page passes a Core Web Vitals spot check. Do this on staging, fix what is broken, and re-check. The whole point of staging is that these failures cost you an afternoon of fixing instead of a quarter of traffic, and the teams that skip it always pay the higher price.

Performance and Core Web Vitals: do not trade rankings for a slower site

One of the quiet ironies of replatforming is that teams migrate to a modern platform expecting it to be faster, and then ship a new site that is slower than the old one because the new theme is heavier, the app stack grew, and nobody measured. Core Web Vitals are a confirmed ranking and page-experience signal, and a migration is exactly the kind of wholesale change that can regress them across your entire site at once. Since you baselined your field data in the audit, you have the before picture. The job now is to make sure the after is at least as good, and ideally better, because a faster site is one of the few migration outcomes that can lift rankings rather than just preserve them.

LCP, the moment the main content appears, is the metric most often wrecked by a new theme. The usual culprits are a hero image shipped at desktop resolution to phones, a render-blocking chain of theme CSS and JavaScript in the head, and the single most common self-inflicted wound: lazy-loading the largest above-the-fold image so the browser deprioritizes the very thing the metric measures. On the new site, serve the LCP image as a properly sized next-gen format (WebP or AVIF), add fetchpriority high to it, never lazy-load it, preload it, and use responsive srcset so phones get phone-sized images. These are the same fixes on any platform, and a migration is the ideal moment to build them in from the start rather than retrofit them.

INP, responsiveness to interaction, is where modern JavaScript-heavy platforms regress hardest. A migration to a framework that hydrates the whole page, or a store that inherited a graveyard of half-used apps each injecting main-thread script, will fail INP even when it feels snappy on your fast laptop and fast connection. The discipline is the same everywhere: break up long tasks, defer non-critical JavaScript, load analytics and chat widgets after interaction rather than on load, and audit every third-party script the new platform pulls in. A replatform is a rare chance to shed the accumulated script debt of the old site, and it is a waste to carry it all forward or, worse, add to it.

CLS, visual stability, is the cheapest to protect and the easiest to break in a redesign. New templates that lazy-load banners, inject cookie bars and promo strips after paint, swap web fonts, and ship images without width and height attributes will shift the layout and rack up CLS. Set explicit dimensions or aspect-ratio on every image so the browser reserves space, reserve space for any late-loading widget, and handle font loading so text does not reflow. Because you are building the templates fresh, you can bake stability in rather than patch it later.

The measurement subtlety that trips teams up is the difference between lab and field data, and it matters doubly during a migration. The Lighthouse score from a single run is a lab number under one simulated condition, and it bounces around. The number Google actually uses is the field data, the real-user measurements in the Chrome User Experience Report surfaced in Search Console. After a migration, the field data resets to reflect the new site and takes weeks to accumulate enough real sessions to be meaningful. So do not panic at a bad single Lighthouse run on launch day, and do not declare victory on a good one. Fix the systemic issues, the LCP image handling, the script weight, the layout shifts, and watch the field data trend over the following month.

There is a crawl-budget dimension to performance that specifically bites migrations. A faster, cleaner site gets crawled more efficiently, and during a migration you want Google to recrawl and reprocess your entire URL set as fast as possible so it sees the redirects, indexes the new URLs, and transfers the signals. A slow new site with crawl traps (endless faceted URLs, calendar archives, session parameters) makes that reprocessing drag on for weeks longer than it should, extending the vulnerable window where rankings are in flux. Clean crawl paths and a submitted, accurate sitemap speed the whole recovery. Performance is not just a ranking signal here, it is the throttle on how fast your migration settles.

The launch-day runbook: the sequence that keeps you safe

Launch day is where a well-prepared migration becomes calm and a poorly prepared one becomes chaos, and the difference is a written runbook: an ordered checklist of exactly what happens, in what sequence, by whom, with a clear rollback trigger. I do not launch a migration on vibes and a deploy button. I launch it against a document that anyone on the team could execute, because the whole point of the preparation was to make launch day boring.

Pick the timing deliberately. Launch during a low-traffic window, not your peak season and not a Friday afternoon when nobody will be around to watch the first crucial hours. I like a mid-week morning, when the team is fresh, Google is crawling actively, and there is a full business day to catch and fix problems before traffic peaks. Never launch a migration the week before your biggest revenue event of the year, because if something goes wrong you want weeks of buffer to recover, not days. The calendar choice is a risk-management decision, and it is free.

The launch sequence itself has an order that matters. Deploy the new site and immediately confirm the redirects are live and firing (run the redirect-test script against production, not just staging). Confirm the production robots.txt allows crawling and no staging noindex tags survived, because this is the moment that specific catastrophe strikes. Submit the new XML sitemap in Search Console and use the URL Inspection tool to request indexing on your top protected pages, so Google starts recrawling immediately rather than waiting to discover the change. Verify the new site in Search Console if the domain or protocol changed, and if you moved domains, use the Change of Address tool, which explicitly tells Google the whole site relocated and speeds the transfer. Confirm analytics is tracking on the new site so you do not go blind on the one day you most need data.

Run the smoke test on the protected pages the moment the site is live. Load each top page and confirm it renders, its redirects landed correctly, its title and schema are intact, and it is not throwing errors. Check a handful of old URLs from memory and confirm they 301 to the right place. Check that the search-critical templates, product pages, category pages, article pages, all work, not just the homepage that everyone naturally looks at first. This is a fifteen-minute pass that catches the deploy-level disasters, the broken template, the missing redirect layer, the robots.txt block, while they are still fixable in minutes.

Have the rollback plan written and the trigger defined before you launch, because the worst time to invent a rollback plan is while the site is on fire. Decide in advance what conditions cause you to roll back (the redirects did not deploy, a critical template is broken site-wide, robots.txt is blocking everything and cannot be fixed forward quickly) versus what you fix forward (individual page issues, cosmetic bugs, a few bad redirects). Keep the old environment available and restorable for the first stretch after launch, so rollback is a real option rather than a bluff. A migration you cannot roll back is a migration you are betting the whole quarter on with no hedge.

Assign owners and keep a live channel open for the launch window. One person watches the redirect and crawl health, one watches analytics and Search Console for the first signals, one owns the platform and can push fixes, and one makes the go or rollback call. Keep a running log of what was checked and what was found, because in the days after launch you will want a record of exactly what state the site was in at launch time. The calm migrations I have run all felt almost anticlimactic on launch day, and that is the goal: all the hard thinking happened in the weeks before, so launch is just executing a checklist and confirming the site behaves the way staging promised it would.

Post-launch monitoring and recovery: the first thirty days decide it

The migration is not done when the site launches, it is done when the traffic has recovered and stabilized, and the window between those two points is the most important monitoring period of the whole project. Rankings and traffic almost always wobble in the first weeks after a migration even when everything was done right, because Google needs time to recrawl every URL, process every redirect, and transfer the signals to the new addresses. Your job in this window is to separate the normal, temporary flux from the real problems that need fixing now, and to catch the real problems fast.

Watch the crawl first, because it is the leading indicator of everything else. In Search Console, watch the Pages report and the Crawl Stats: is Google discovering and crawling the new URLs? Are the old URLs showing up as redirected (good, it is processing the map) or as 404 errors (bad, redirects are missing)? A spike in 404s in the days after launch is the fastest signal that part of your redirect map did not fire, and it points you straight at the URLs to fix. Watch the index count too: a healthy migration sees the old URLs drop out of the index and the new ones enter it over a few weeks, roughly in balance. A collapse in indexed pages with nothing replacing them means Google cannot find or cannot index the new site, and that is a five-alarm problem.

Monitor the errors and the redirects continuously for the first month. Crawl your own site weekly and check for broken internal links, redirect chains that slipped through, pages returning the wrong status code, and schema that stopped validating. Set up or watch your 404 log, because real users and crawlers hitting 404s are telling you exactly which old URLs you missed, and every one of those is a redirect you should add. I treat the post-launch 404 log as a live to-do list: every unexpected 404 on an old URL gets a redirect added within days, before the equity bleeds away.

Track the performance metrics against your baseline, but read them correctly. Organic clicks and impressions will dip in the first week or two as the recrawl churns, and this is expected. What you are watching for is the shape of the recovery: impressions and rankings should stabilize and begin climbing back toward baseline within a few weeks, and your protected pages should recover their positions. Compare against the baseline you saved, page by page for the top pages. If a specific important page has not recovered its ranking after several weeks while the rest of the site has, that page has a specific problem, a bad redirect, a lost signal, thin migrated content, and it needs individual diagnosis. Do not average your way past an individual page's failure.

The recovery diagnosis, when a page or the site does not bounce back, follows a checklist. Is the old URL redirecting with a single clean 301 to the right new URL? Does the new page have the title, H1, content, and schema it should? Are the internal links pointing at it intact? Is it being crawled and indexed? Is the new page as good as or better than the old one, or did content get lost in the move? Nine times out of ten a page that fails to recover fails on one of those, and they are all fixable. The tenth time it is a genuine content-quality issue that the migration merely exposed, and that is a content problem, not a migration problem.

Keep the redirects and the monitoring running long after launch, because migration effects have a long tail. External links update slowly if ever, so old URLs keep getting hit for months. Google reprocesses gradually, so rankings can keep shifting for weeks. I keep a close watch for the first month, a lighter watch for the second and third, and I keep the redirects and the baseline comparison available indefinitely. The migrations that recover fully are the ones where someone stayed on the monitoring past launch week, caught the missed redirects and the lost signals in the 404 log and the crawl diff, and fixed them while they were still cheap to fix. The migrations that end in a permanent traffic loss are almost always the ones where everyone moved on to the next project the day after launch and nobody was watching when the cliff appeared.

Platform-specific gotchas: Shopify, WordPress, and the usual suspects

Every platform has its own migration traps, the quirks in how it structures URLs, emits schema, and handles redirects that will bite you specifically because you moved to or from it. The general playbook applies everywhere, but knowing the platform-specific landmines saves you from stepping on the ones that recur. Here are the ones I run into most, roughly by platform.

Shopify forces a rigid URL structure you cannot fully change, and this catches people migrating in from a flexible platform. Product URLs must live under /products/, collections under /collections/, blog posts under /blogs/, and pages under /pages/. You cannot flatten a product to the root or nest it under a custom path. So a migration from a platform where products lived at /product-name or /category/product must redirect every one of those to the new /products/product-name, and there is no avoiding the prefix. Shopify also generates the collection-scoped /collections/x/products/y duplicate URLs I have written about elsewhere, canonicalized correctly by default but still crawlable, so make sure product links point at the canonical /products/ path. Its native URL redirect tool is where your map lives, it handles the 301s well, but it is worth confirming it does not cap out on a very large catalog.

WordPress migrations live and die on permalinks. The permalink structure (the setting that decides if posts live at /post-name, /category/post-name, /year/month/post-name, or the dreaded /?p=123) is a site-wide URL decision, and changing it silently changes every post URL at once. If you are moving hosts or rebuilding but keeping WordPress, match the old permalink structure exactly unless you have a deliberate reason to change it and a redirect map ready. If you are migrating off WordPress, its date-based and category-based permalink patterns are usually clean enough to handle with pattern redirects, but watch for the /?p=123 query-string URLs that some old links use, and for attachment pages, author archives, and tag pages that WordPress generates and that may or may not have earned any equity worth preserving. Also confirm the new platform emits the schema your old SEO plugin (Yoast or RankMath) was quietly producing, because that markup does not come along by default.

Headless and JavaScript-framework migrations introduce the rendering risk more than the URL risk. Moving to a headless Next.js, Nuxt, or similar stack gives you total URL control, which is good, but it introduces the client-side rendering question: is the content in the HTML the crawler receives, or does it only appear after JavaScript runs? Use server-side rendering or static generation for anything that needs to rank, and test the rendered output. The framework's redirects config (like Next.js redirects) is a fine place for your map, but confirm it returns real 301s and not client-side JavaScript redirects, which do not pass equity the same way.

Domain changes and HTTPS migrations are their own category of gotcha that can ride along with a replatform. If you change domains, use Search Console's Change of Address tool, keep the old domain and its redirects alive for a long time, and expect a slightly longer recovery than a same-domain move. If you are finally moving from http to https, or consolidating www and non-www, treat those as canonicalization changes that must compose into single-hop redirects rather than stacking on top of the path redirects, as I covered in the redirect strategy. Migrating platform and domain and protocol all at once is possible, but each simultaneous change adds risk and makes diagnosis harder, so where you can, avoid stacking a domain move onto a platform move onto a protocol change in a single launch.

The cross-platform lesson underneath all of these is the same: find out, before you build, exactly how the new platform structures URLs, emits schema, renders content, and handles redirects, and design your migration around those constraints rather than discovering them on launch day. Every platform is opinionated about something, and the opinion you did not know about is the one that costs you traffic. Read the platform's URL and SEO documentation, crawl a test build early, and treat the platform's quirks as known constraints in your redirect map and your QA, not as surprises.

The recovery timeline: what to expect week by week

One of the most useful things I can give a founder before a migration is a realistic timeline, because unrealistic expectations cause bad decisions. Someone who expects zero disruption panics at a normal week-one dip and starts changing things that were fine, making the diagnosis harder. Someone who expects a full recovery in three days gives up when it takes six weeks. The honest picture is that even a well-executed migration goes through a predictable curve of temporary disruption followed by recovery, and knowing the shape of that curve keeps you steady.

The first few days after launch are the churn window. Google starts recrawling, encounters the redirects, and begins the slow work of reprocessing your URL set. Rankings can bounce around, some pages temporarily drop, impressions can dip, and this is normal even when everything was done correctly. The mistake here is to interpret every wobble as a failure and start making changes. What you are actually watching for in this window is not ranking recovery yet, it is the absence of catastrophe: no flood of 404s, no deindexing, no robots.txt block, no broken template. If those fundamentals are clean, the early ranking flux is just Google doing its job, and the right move is to hold steady and keep monitoring.

The first two to four weeks are the recrawl-and-reprocess phase, and this is where the recovery becomes visible if the migration was clean. Google works through your URLs, processes the redirects, transfers the signals from old URLs to new, and updates its index. Rankings on your protected pages should start climbing back toward their baseline positions, the old URLs should be dropping out of the index as the new ones enter, and organic impressions should stabilize and begin recovering. For a smaller site this can substantially resolve in a few weeks; for a large site it takes longer because there are simply more URLs to reprocess. By the end of this phase you should be able to look at your baseline comparison and see most of the site trending back.

Weeks four through eight are where a clean migration substantially recovers, and where you diagnose the pages that did not. Most of the traffic should be back to within a small margin of baseline by this point on a well-executed move. This is when you go page by page through the protected list: the ones that recovered, you leave alone, and the ones that did not, you diagnose individually with the recovery checklist, bad redirect, lost signal, thin content, crawl or index problem. Fixing those laggards is the difference between recovering to ninety-something percent of baseline and recovering fully, and it is worth the effort because those are usually your important pages.

Beyond two months, you are in the long tail of the recovery, and mostly you should be back to baseline or above with only stragglers left. If the whole site is still meaningfully down after two to three months on a same-domain migration, that is not normal migration flux anymore, it is an unresolved problem, and it needs a real diagnostic pass rather than more patience. Domain changes run a bit longer than same-domain moves, and very large sites run longer than small ones, but the principle holds: a clean migration recovers on the order of weeks to a couple of months, not indefinitely. Persistent, unexplained loss past that window means something is still broken, most often a redirect gap, a rendering problem, or a signal that never came across.

The reason a good migration can actually end up ahead of where it started is worth stating, because it reframes the whole exercise from damage control to opportunity. If the new site is faster, cleaner in its architecture, better structured internally, and richer in schema than the old one, then once the recovery settles you are not back to baseline, you are above it, ranking with all your old equity intact on a better site. I have seen migrations end with organic up meaningfully, on the order of the kind of gains a good SEO program produces over the same period, precisely because the replatform was used as the occasion to fix the structural problems the old site had. The migration did not create that lift, the improvements did, but the migration was the moment they could be built in at the foundation. Survive the recovery curve with your equity intact, and the upside is a better site that keeps everything the old one earned.

The migration mistakes that cost the most traffic

I have been called in to rescue enough botched migrations to know the failures cluster into a short, predictable list, and almost every one traces back to treating the migration as a build project instead of an SEO-preservation project. Here are the ones that cost the most, roughly in the order of how much damage they do.

No redirect map, or an incomplete one. This is the number-one killer. The team changes URLs and either forgets the redirects entirely, maps only the pages someone remembered, or redirects everything to the homepage to save time. Every unmapped ranking URL becomes a 404, loses its history, and takes its traffic with it. A complete, tested, one-to-one redirect map is the single most important migration deliverable, and its absence is the most common cause of the traffic cliff.

Blocking the whole site from crawling. The staging robots.txt with "Disallow: /" or the staging-wide noindex tag survives to production, and the entire site gets deindexed within days. This is catastrophic and it is entirely preventable with one launch-day checklist item: confirm production allows crawling and no noindex survived. It happens constantly because the staging protection and the production configuration are the same file and nobody checked.

Losing the on-page signals. The content migrates but the titles revert to template defaults, the schema disappears because the new platform does not emit it, the H1s change, and the internal-link graph gets rebuilt weaker. The page looks the same and ranks worse because everything Google used to rank it changed. Carrying the exact titles, metas, headings, schema, and internal links across is not automatic and must be an explicit requirement.

Redirect chains and 302s. The redirects exist but they chain through three hops (http to https to www to new path) or use temporary 302s instead of permanent 301s. Chains leak equity and slow the crawl; 302s tell Google to keep the old URL indexed and not transfer signals. Both quietly suppress the recovery even when the map looks complete on paper.

Skipping staging and QA. The team launches straight to production without crawling a staging copy, testing the redirects, or checking that JavaScript-rendered content is visible to crawlers. Every problem that a staging QA pass would have caught in an afternoon instead gets discovered in production with real traffic and real rankings on the line, and some of them are not cheap to fix after the fact.

Removing redirects too early. Someone decides a few months after launch that the 301s have done their job and removes them, re-breaking every external link and lingering index entry that still points at the old URLs. Backlinks do not update because you migrated. Keep the redirects for years.

Migrating everything at once with no rollback and nobody watching. The team stacks a platform change, a domain change, and a redesign into one launch, has no way to roll back, and moves on to the next project the day after go-live. When the cliff appears in week two, nobody is watching, there is no clean before-picture because nobody baselined, and the diagnosis takes weeks because too many things changed at once. Change fewer things per launch, keep a rollback option, baseline first, and stay on the monitoring past launch week.

A worked example: moving a catalog site off a legacy platform

Let me make this concrete with the shape of a migration I have run more than once, because the pattern is consistent enough to serve as a template. Picture a mid-sized catalog site on an aging platform: a few thousand indexed URLs, solid organic traffic that had plateaued, a URL structure full of query strings and inconsistent patterns, no structured data to speak of, and Core Web Vitals that failed on mobile because the old theme was heavy. The business wanted to replatform for the commerce features and the speed. The risk was obvious: a few thousand ranking URLs about to change addresses, with real revenue riding on the organic traffic.

The first four weeks were entirely preparation, no new site visible to anyone. We ran the full audit: crawled the old site, cross-referenced Search Console and the server logs, and built the true URL inventory. We pulled sixteen months of Search Console data and saved the baseline: top pages, top queries, positions, organic sessions and conversions by landing page, and the top backlinked URLs. From that we drew the protected list, the pages driving the majority of traffic and holding the majority of links, and flagged them for individual attention. We wrote down the success criteria and the rollback trigger. None of this touched the new build; all of it made the build safe.

The redirect map was the center of gravity. Every one of the several thousand old URLs got a new destination. The old query-string product URLs followed a clean enough pattern to handle most of them with rules, mapping /product.php?id patterns to the new /products/slug structure, but the tail of retired products, merged category pages, and special cases got hand-mapped, and every protected page was verified by hand. Retired products with no replacement went to their closest relevant category with a 301 rather than to the homepage or a 404. We carried forward the redirects from a previous migration years earlier, chaining them down to the final new URLs so no old equity was orphaned.

On the new build we made preservation an explicit requirement, not an afterthought. The exact title tags and meta descriptions from the old crawl were loaded into the new pages rather than left to the template default. Product and BreadcrumbList schema, which the old site never had, were built into the new templates, so the migration actually added rich-result eligibility rather than losing it. The internal navigation and breadcrumbs were rebuilt to express the category hierarchy, and the contextual internal links in content were repointed at the new URLs directly to avoid chains. And because we were building templates fresh, we baked in the Core Web Vitals fixes from the start: sized WebP heroes with fetchpriority, deferred non-critical script, and dimensions on every image.

Everything got proven on staging before launch. Staging sat behind HTTP auth so it could never be indexed. We crawled it and diffed it against the old-site crawl page by page, catching a batch of pages where the template had reverted titles and a set that were missing their H1, and fixed them. We ran the redirect-test script against staging until every protected old URL returned a single clean 301 to the right place. We confirmed the content rendered server-side and that the schema validated. By launch day there were no unknowns left; staging had already answered the questions.

Launch was deliberately boring. We deployed on a mid-week morning, confirmed the redirects fired in production, confirmed robots.txt allowed crawling and no staging noindex had survived, submitted the new sitemap, and requested indexing on the top pages. The smoke test on the protected pages came back clean. Then we watched. The first ten days showed the expected churn, a dip in impressions and some ranking wobble, and we held steady rather than reacting. The 404 log surfaced a couple of dozen old URLs we had missed, mostly old images and a few legacy landing pages, and we added redirects for each within days. By week four the protected pages had recovered their positions, and by around the eight-week mark organic was back to baseline and then continued past it, because the new site was faster, carried schema the old one never had, and was structured more cleanly for both crawlers and shoppers. The recovery was not magic and it was not luck. It was the audit, the complete redirect map, the preserved signals, the staging QA, the calm launch, and the post-launch monitoring, applied in that order, which is the whole playbook.

What is next: migrations in an AI-search world

The core migration playbook, baseline, map, preserve, QA, launch, monitor, has been stable for years and it is not going anywhere, because it is grounded in how search engines process URLs and signals, which changes slowly. But the surfaces your traffic comes from are widening, and that changes what a migration has to preserve. It is no longer only Google's blue links at stake. It is your visibility in AI Overviews, your citations in ChatGPT and Perplexity and Gemini, your presence in the Shopping graph, and your entity consistency across the web. A migration now has to keep all of that intact, not just classic rankings.

The encouraging part is that the same fundamentals protect all of it. AI answer engines and Shopping assistants read the same structured data, the same clean content, and the same accurate metadata that Google's classic ranking uses. So the schema you preserve through a migration is not only defending your rich results, it is defending your eligibility to be cited by an AI assistant that reads that markup to decide what to recommend. The clean URLs and unbroken redirects that keep your Google rankings also keep the citations, because an AI engine that cited your old URL needs to find the content at the new one. Preservation is preservation across every surface, which means the discipline in this playbook pays off more broadly than it used to.

There are a few migration considerations that are genuinely newer. Entity consistency matters more as engines build knowledge graphs around your brand: if a migration changes how your organization, authors, and products are described in structured data, or breaks the sameAs links that connect your entity across the web, you can confuse the graph that AI engines rely on. Carry your Organization and entity markup across intact. Machine-readability matters more too: as more of your traffic comes from engines that parse rather than render, a migration to a client-side-rendered platform that hides content behind JavaScript is riskier than it used to be, because you are now invisible to a wider set of readers, not just the classic crawler. And emerging conventions like files that guide AI crawlers are worth carrying forward or adding during a migration rather than dropping.

The strategic shift is to stop thinking of a migration as a Google-preservation exercise and start thinking of it as a preservation of your presence everywhere your audience finds you. The URL that a person bookmarked, the page Google ranks, the source an AI assistant cites, the product a Shopping graph lists, these are increasingly the same content surfaced in different places, and a migration that breaks the address or the signals breaks all of them at once. The upside is that you do not need a separate playbook for each surface. Do the fundamentals right, complete redirects, preserved signals, clean structured data, machine-readable content, and every surface inherits the protection.

The part that will keep changing is the tooling and the speed. Recrawl and reprocessing will get faster as engines improve, monitoring will get better at flagging exactly which URLs regressed, and platforms will get smarter about handling redirects and schema natively. But none of that removes the human judgment at the center of a good migration: deciding which pages matter most, mapping each old URL to its best new home, and staying on the monitoring until the traffic has settled. Tools make the work faster; they do not make the decisions. A migration is still, at its heart, a promise to keep every page's identity and equity intact through a move, and the teams that keep that promise are the ones that come out the other side faster, cleaner, and ahead.

If you take one thing from this playbook, take the reframe: a replatform is not a design project with an SEO checklist bolted on, it is an SEO-preservation project that happens to ship a new design. Run it that way, baseline before you touch anything, map every URL, preserve every signal, prove it on staging, launch calm, and watch it recover, and a migration stops being the quarter you dread and becomes the moment you upgrade the foundation without losing what you built on it.