The SEO Migration Checklist: A Phased Plan for Moving Platforms Without Losing Rankings

An SEO migration is any move that changes how Google finds your pages: a new platform, a new domain, a switch from HTTP to HTTPS, or a redesign that touches URLs. The mechanics are the same whether you’re moving off WooCommerce, BigCommerce, or Magento, or between any other real ecommerce platform, and Google publishes exactly what it wants to see at each step. This checklist follows that documentation phase by phase: baseline, redirect mapping, staging, cutover, and the monitoring window that comes after.

Every number, threshold, and quoted phrase below links to the page it came from, mostly Google’s own Search Central documentation and the platforms’ own help centers. Vendor claims are labeled as vendor claims. Nothing here is rounded up for effect.

Google splits site moves into two different guides, and the difference decides which playbook applies to your move. One guide covers moving your hosting or CDN when your URLs stay exactly the same, and Google is explicit about its narrow scope: “A change in hosting infrastructure means switching hosting providers or moving to a content distribution network (CDN). This guide is only for migrations that don’t affect the user-visible URL,” according to Google’s site-move guidance for infrastructure changes.

The other guide covers any move where the URL changes, and that’s the guide behind almost every platform replatform, most redesigns, and every domain change. Whether you call it a platform migration, a replatform, or a CMS migration, if your move changes even one segment of a URL path, you have an SEO migration on your hands, and you’re working from the second guide, not the first.

Is a redesign the same as a migration? Only if it changes your URLs. Google publishes no redesign-specific guidance, and a redesign that keeps every URL falls outside both site-move guides. A redesign that restructures blog paths, category paths, or product paths puts you squarely in the site-move-with-URL-changes guidance, with the same redirect map and the same monitoring window as a full platform switch.

Two more moves count as SEO migrations even when nobody thinks of them that way. Switching from HTTP to HTTPS, or from www to non-www, changes the canonical form of your URL, and Google’s instruction for both is the same: “use canonical tagging and/or redirects without using the change of address tool,” per Google’s Change of Address documentation. Google prefers HTTPS as canonical by default, “except when there are issues or conflicting signals” such as an invalid certificate, per Google’s guidance on consolidating duplicate URLs. The redirect and the canonical tag still have to exist either way.

The only figure Google ever published for HTTPS ranking weight is from 2014, and it was small even then. Google’s 2014 announcement called it “only a very lightweight signal,” one “affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content,” in its original HTTPS ranking-signal post. We could not find a newer Google document restating a weight, so treat HTTPS as correct practice and a security requirement, not as a source of ranking lift on its own.

A design experiment that runs on top of stable URLs isn’t an SEO migration, and treating it like one is a common mistake. Google’s own instruction for that case is the opposite of migration advice: use “a 302 (temporary) redirect, not a 301 (permanent) redirect” for test variations, and prefer “rel=’canonical’ rather than a noindex meta tag” over the variant URLs, per Google’s website testing guidance. Confuse the two and you’ll either get an experiment stuck in the index as a permanent move, or a real SEO migration treated as temporary and never fully credited.

A real SEO migration strategy starts with a baseline, not a redirect spreadsheet.

What should a baseline actually capture? Five things: a full URL inventory, your site architecture as it stands today, your Search Console verification method, your current Core Web Vitals scores, and your product structured data. Miss any of them and you have nothing to compare the new site against.

Search Console access is the first thing to protect, and it’s also the easiest thing to lose without noticing. Google’s own guidance says plainly that if you verify ownership with an HTML file or a meta tag, you have to carry that same file or tag into the new site’s templates, or “if you include in your content management system’s (CMS) templates a meta tag or Google Analytics to verify ownership, ensure the new CMS copy includes these as well,” per Google’s site-move guidance. Skip this and the property that’s been tracking your baseline for years goes unverified on the domain that now needs it most. Do it before the new site goes live.

Core Web Vitals are the other number that has to exist before cutover, because there’s no baseline to compare against otherwise. Google’s current “good” thresholds are a Largest Contentful Paint of 2.5 seconds or less, an Interaction to Next Paint of 200 milliseconds or less, and a Cumulative Layout Shift of 0.1 or less, all measured at the 75th percentile of page loads, segmented across mobile and desktop devices, per web.dev’s Core Web Vitals reference.

Google’s page-experience FAQ is direct about the ranking weight. “Core Web Vitals are used by our ranking systems,” it says, but it also says “There is no single signal,” and that “Beyond Core Web Vitals, other page experience aspects don’t directly help your website rank higher in search results,” per Google’s page experience documentation. Record the current numbers before the new platform is live, because the Core Web Vitals report reflects real-world usage of indexed URLs, and a freshly launched URL set starts that measurement over, per Search Console’s Core Web Vitals report documentation.

Product markup is worth auditing too, because the requirements aren’t as forgiving as most people assume. For a product to be eligible as a plain rich result, Google requires only the product’s name plus one of review, aggregateRating, or offers, per Google’s product snippet documentation. For a merchant listing, the bar is higher: name, image, and offers are all required, and Google notes that “Unlike product snippets, merchant listing experiences require a price greater than zero,” per Google’s merchant listing documentation. If your ratings app doesn’t survive the move cleanly, you don’t lose the rich result outright, you lose the rating properties that made it show stars.

Every destination platform decides how much of your URL survives the move, and that decision is baked into the platform’s own architecture, not your SEO migration plan. Some platforms lock a path segment into every product URL and won’t let you remove it. Others leave the structure entirely configurable. Of the four below, one locks a segment into every product path, two leave the shape configurable at store level, and the fourth isn’t documented clearly enough to say.

Every cell above is the platform’s own documentation. Shopify documents its redirect rules, including the paths that can’t be used as a source, in its own help center, and Google’s own redirect guidance separately names Shopify as one of the platforms with built-in redirect tooling. WooCommerce documents its default product and category base slugs in its own permalinks documentation.

BigCommerce documents its store-level URL Structure setting and its Redirects API. Adobe Commerce documents the URL key and suffix configuration, the URL Rewrites tool, and the automatic redirect setting for URL key changes.

Shopify is the only one of the four that publishes a number, capping out at 100,000 redirects on standard plans and 20,000,000 on Plus. BigCommerce’s Redirects API documentation states no cap, and we didn’t check Adobe’s URL Rewrites documentation or WooCommerce core for one. Unpublished isn’t the same as unlimited, so confirm directly before you assume it.

Either way, the redirect map has to be built before development starts, not exported afterward as a formality.

Baseline checklist:

Building the redirect map starts with a literal list: every old URL matched to the URL that will replace it, done before a single page goes live on the new platform. Google’s own instruction is to prepare “a sitemap file containing the new URLs in the mapping” ahead of cutover, per Google’s site-move guidance, and to add a self-referencing canonical tag to each new URL as you build it.

A crawler that can export a full URL list and follow redirects to their final destination does the verification half of this job. Google names one by name in its own troubleshooting guidance: “You can use Search Console to see if there are an unusually high number of ‘Not found’ errors reported, or you can use other tools such as Screaming Frog to crawl your own site and see if the redirects work as expected,” per Google’s site-move guidance.

Shopify adds a gotcha that catches almost every SEO migration team once: “You can redirect only from broken URLs. Broken URLs display error messages, such as Page not found or 404, on a page or in the page title,” per Shopify’s redirect documentation. A redirect whose source path still resolves to something, even an empty placeholder page, silently fails. Build the map to point away from paths the platform will actually treat as broken, not away from paths that merely look old.

Redirects and canonical tags aren’t interchangeable, and Google ranks them by how much weight each one carries. In order of strength: a redirect is “a strong signal that the target of the redirect should become canonical,” a rel=”canonical” annotation is also “a strong signal,” and sitemap inclusion is only “a weak signal,” per Google’s canonicalization guidance. That same guidance rules out two mistakes replatforms make constantly: “Don’t use the robots.txt file for canonicalization purposes,” and “Don’t specify different URLs as canonical for the same page using different canonicalization techniques.” Every new URL should carry its own self-referencing canonical, and every internal link on the new site should point at that canonical URL, not at a duplicate.

Product variants need their own decision inside the redirect map, not an afterthought. Google’s ecommerce URL guidance says to “avoid internally linking to temporary parameters, such as session-IDs, tracking codes, and user-relative values,” and if a variant is identified with an optional query parameter, “use the URL with the query parameter omitted as the canonical URL,” per Google’s ecommerce URL structure guidance. Decide this once, in the mapping spreadsheet, before the new platform starts generating its own variant URLs by default.

Not every redirect method carries the same weight with Google, and the difference matters more during a migration than almost anywhere else. Google groups redirects into two buckets: permanent, which includes HTTP 301, HTTP 308, an instant meta refresh, and a JavaScript location redirect, and temporary, which includes HTTP 302, 303, 307, and any delayed meta refresh, per Google’s redirect documentation. The methods are “ordered by how likely Google is able to interpret correctly,” with a server-side redirect at the top of that list. A JavaScript redirect sits at the bottom, and Google warns that rendering “may fail for various reasons,” meaning “if you set a JavaScript redirect, Google might never see it.”

That line comes directly from Google’s site-move documentation. The fear of losing link equity is the single most common reason SEO migrations get rushed or half-built. Google goes further, recommending you keep redirects in place “for as long as possible, generally at least 1 year,” and it adds: “From users’ perspective, consider keeping redirects indefinitely.” Even after a redirect resolves correctly, Google keeps a record of both URLs, and after a domain move, finding the old one reappear occasionally in results “is normal.”

Redirect chains have a real ceiling, and Google states it as a number. Google’s crawlers follow “up to 10 redirect hops” by default, per Google’s guidance on HTTP and network errors, but the site-move guidance is stricter: keep any chain “ideally no more than 3 and fewer than 5,” because “Chaining redirects adds latency for users, and not all user agents and browsers support long redirect chains.” The other named mistake is routing volume to the wrong place: “Don’t redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site.”

For a small or medium site, Google recommends moving every URL at the same time rather than section by section: “We recommend moving all URLs on your site simultaneously instead of moving one section at a time,” because it “helps our algorithms detect the site move and update our index faster,” per Google’s site-move guidance. Large sites are the exception, and Google adds that “Submitting a sitemap can help make the discovery process quicker, and it’s fine to move your site in sections.” Most platform replatforms fall into the first category, which means the redirect map has to be complete before launch day, not built in phases afterward.

Redirect map checklist:

Staging environments need real access control, not a folder buried in the site structure. Google’s own instruction is to “Create a testing environment, perhaps with IP-restricted access,” and if you need broader testing, to “Allow for public testing with a temporary hostname for your new infrastructure (like beta.example.com)” and “add the noindex robots rule to the HTML or the HTTP headers of your pages,” per Google’s site-move guidance. Whichever method you use, nobody outside your team should be able to find the new site through search before you’re ready.

In an SEO migration the mistake happens at the other end of staging, not the start. Google heads the teardown step “Remove any temporary blocks to crawling” in its guidance for infrastructure moves, and names “remove any noindex or robots.txt blocks that were only needed for the migration” as a post-move mistake in its guidance for moves with URL changes. Two separate Google documents make the same warning. A site launches with the noindex tag still in the theme, and nothing on the new site shows up in Search because nobody removed a single line.

robots.txt doesn’t hide a page from Google the way most people assume. Google states the limitation directly: “a page that’s disallowed in robots.txt can still be indexed if linked to from other sites,” and in that case “the URL address and, potentially, other publicly available information such as anchor text in links to the page can still appear in Google Search results,” per Google’s robots.txt introduction. The fix, in Google’s own words, is to “password-protect the files on your server, use the noindex meta tag or response header, or remove the page entirely.” robots.txt also has to sit at the root of the host it applies to; it can’t live in a subdirectory, per Google’s guidance on creating a robots.txt file.

noindex works, but only if Google can actually see it, and that’s the trap that catches a lot of staged SEO migrations. The rule tells Google to “drop that page entirely from Google Search results, regardless of whether other sites link to it,” but only once Googlebot crawls the page and reads the tag, per Google’s block-indexing documentation. Google flags this as “important”: “for the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file,” because if it’s blocked, “the crawler will never see the noindex rule, and the page can still appear in search results.” Putting noindex directly in robots.txt doesn’t work either, and Google states it plainly: “Specifying the noindex rule in the robots.txt file is not supported by Google.”

Google publishes a ranked list of methods for keeping content out of Search, and it scopes each one by content type. Password protection and the noindex rule are both listed as applicable to “all content types,” while “disallow crawling with robots.txt” is scoped to “images and video” only, per Google’s guidance on controlling what you share. That scoping is the cleanest argument for password-protecting a staging store rather than relying on robots.txt alone, on whatever platform it’s built on.

If a staging or beta URL does get indexed before you catch it, Search Console’s Removals tool is a bandage, not a fix. Google is explicit that “a successful request lasts only about six months,” that “blocking a URL does not prevent Google from crawling your page, only from showing it in Search results,” and that “using the tool alone won’t work,” per Google’s URL removals help page. The permanent fix is still one of the three methods above: remove the content, password-protect it, or noindex it, per Google’s guidance on removing information.

Staging checklist:

If your SEO migration involves a hosting or infrastructure change, and not every platform migration does, lower your DNS TTL before you touch anything else. Google’s guidance is specific about timing: “consider lowering the TTL to a conservative low value (for example, a few hours) at least a week in advance of the move,” so the new settings “propagate to ISPs faster,” per Google’s site-move guidance. Skip this step and the new settings take longer to propagate for every visitor and every crawler.

Expect Googlebot’s behavior to change right after launch, in two different ways depending on what kind of move you made. On an infrastructure move with no URL changes, Google says it’s “normal to see a temporary drop in Googlebot’s crawl rate immediately after the launch, followed by a steady increase over the next few days,” sometimes to a rate higher than before. On a move with URL changes, the opposite risk shows up: Google “will crawl your new site more heavily than usual” right after launch, and its explicit instruction is to make sure your infrastructure can handle it, per Google’s site-move guidance. Confirm your new platform can absorb a crawl spike before cutover, not during it.

For an infrastructure-only move, Google gives a concrete signal for when it’s safe to shut the old servers down: watch the server logs, and “once the traffic to the old provider reaches zero, you can shut down your old hosting infrastructure,” per Google’s site-move guidance. Don’t schedule that shutdown by the calendar. Schedule it by the logs.

Sitemaps do real work at cutover, not just at launch. Google’s instruction once the move is live is simple: “Submit the new sitemap in Search Console,” which “will help Google learn about the new URLs,” and only then do you remove the old sitemap, per Google’s site-move guidance. Google also documents a genuinely useful monitoring method: keep both sitemaps submitted for a while, because “Initially, the sitemap containing the new URLs would have zero pages indexed” while the old one is fully indexed, and over time that ratio flips, giving you a visual read on how the move is progressing.

Pick a low-traffic window if your traffic has one. Google’s own advice is plain: “Time your move to coincide with lower traffic, if possible,” and if traffic is seasonal or dips on certain weekdays, “it makes sense to move your site during the recurring traffic dips,” per Google’s site-move guidance. This has nothing to do with SEO mechanics and everything to do with giving your team room to catch and fix problems before they compound.

If cutover genuinely requires taking the site offline, both the status code and the duration matter, and Google is stricter about duration than most teams expect. For an urgent disable of 1-2 days, Google’s instruction is to “return an informational error page with a 503 HTTP response status code instead of all content,” and for anything longer, to keep “an indexable home page as a placeholder” with a normal 200, per Google’s guidance on pausing an online business. A full blackout is “an extreme measure that should only be taken for a very short period of time (a few days at most),” and Google’s FAQ warns that even closing a site “for just a few weeks can have negative consequences on Google’s indexing,” recommending you limit functionality instead of closing entirely.

A 503 has its own rules, and getting them wrong defeats the point of using one at all. Google says to keep the robots.txt file itself crawlable, since you should not “return a 503 HTTP response status code for the robots.txt file”; to avoid disallowing all crawling, which “may remove the website’s content, and potentially its URLs, from Google Search”; and to never pair the outage with a 403, 404, 410, or noindex, all of which “will remove the website’s URLs from Google Search” rather than just pausing them. One more limitation worth planning around: while a page returns 503, “it’s not possible for Google’s systems to refresh titles, descriptions, metadata, or structured data,” so any metadata changes you make during the outage won’t register until the page is live again.

Cutover checklist:

Monitoring starts with verifying every property involved, not just the new one. Google’s instruction is to verify “both the old and new sites in Search Console,” including “all variants of both,” HTTP, HTTPS, www, and non-www, and to check each property separately, per Google’s site-move documentation. The Index Status report and the Sitemaps report are the two Google names for this: one gives the broad look, the other shows how many URLs submitted in a sitemap have been indexed.

Google names the mistakes it sees most often during this window, and every one is checkable: incorrect redirects, where “We frequently see people redirecting to the wrong (non-existent) URLs on the new site,” a spike in other crawl errors that Google tells you to watch for in the Index Coverage report, insufficient server capacity, and sitemaps that were never updated, per Google’s site-move documentation. Against that list, Google also sets the expectation correctly: “With any significant change to a site, you may experience ranking fluctuations while Google recrawls and reindexes your site,” and separately, “This is normal and a site’s rankings will settle down over time.” A dip that matches this pattern is not the same thing as a lost SEO migration.

How long does it take for rankings to recover? For a medium-sized site, Google’s own timeline for the move itself is “a few weeks for most pages to move” in the index, with larger sites taking longer, stated with no fixed number of days anywhere in Google’s documentation. If specific pages are slow to reappear, requesting a recrawl helps within limits Google states directly: “crawling can take anywhere from a few days to a few weeks,” and “requesting a recrawl multiple times for the same URL won’t get it crawled any faster,” per Google’s recrawl guidance. Submitting a sitemap does more work than repeated manual requests, and Google says as much: a sitemap “can be very helpful if you just launched your site or recently performed a site move.”

If a handful of old URLs are still showing up months later, that’s usually a per-URL effect, not a failed SEO migration. Google’s own explanation for a slow-to-drop page is that “depending on the importance of the page on the internet, it may take months for Googlebot to revisit a page,” per Google’s block-indexing documentation. That’s a statement about how Google prioritizes crawling one specific low-value page, not a statement about migrations in general, and it shouldn’t be read as one.

A lot of alarming numbers circulate about how much traffic an SEO migration costs and how long recovery takes, and most of them don’t trace back to a published study with a stated sample and method. What Google actually documents is considerably less dramatic: a redirect doesn’t cost you PageRank, a fluctuation is expected and settles, and the published timeline for most pages to move is measured in weeks. Treat any recovery number you can’t trace to a primary source the way you’d treat an unverified stat anywhere else in the business.

Monitoring checklist:

Not every SEO migration looks the same, and the label matters because it decides which Google guidance and which Search Console tools actually apply. A replatform, moving your storefront to a new ecommerce platform, is usually the biggest of the three, because it changes URL structure, page templates, and often the whole checkout flow at once. A domain change is its own category entirely, with its own tool.

A domain change is the one case where Search Console’s Change of Address tool actually applies. Google states its scope directly: it works “only on properties at the domain level,” not “at the path level,” and it doesn’t move subdomains “below the specified domain (including www),” per Google’s Change of Address documentation. Once submitted, the tool’s effects run for 180 days, and Google is explicit that after that window, “Google does not recognize any relationship between the old and new sites,” so the redirects need to already be doing the real work by then.

Google tightened this guidance recently. Its current instruction for domain migrations is to submit Change of Address requests “for all subdomains and the www and non-www variants of the old domain name, even if you’re not actively using these variants,” and to make sure every one of those variants is verified in Search Console first, per Google’s site-move documentation. Skipping a variant isn’t a small gap. It’s a domain’s worth of signal that never gets told where to go.

Most of what BLKDG builds falls into the replatform category, and the redirect and URL mechanics differ enough by destination platform that a single generic mapping doesn’t cover every case. If you’re moving a WooCommerce catalog, the product ID mapping and review-app mechanics get their own breakdown in our WooCommerce to Shopify migration guide, and the build itself is covered on our WooCommerce to Shopify migration page. The same applies coming from BigCommerce or Magento: each source platform has its own default URL shape, and we cover those moves specifically on our BigCommerce to Shopify migration page and our Magento to Shopify migration page.

How do you know an agency is handling this correctly? Ask for four things before you sign anything: the redirect map itself, not a promise that one exists, the staging plan for keeping the beta environment out of Google before launch, the sitemap swap plan for the cutover moment itself, and a written commitment to a monitoring window after cutover. Every phase above produces a real artifact. An agency that can’t show you the redirect spreadsheet, or can’t describe how staging will be kept noindexed, hasn’t done this enough times to have the artifacts on hand.

This is the standard we hold our own migration work to. BLKDG has migrated more than 40 stores to Shopify, with 0% traffic loss and 100% redirect coverage across those projects, in a typical build window of 8 to 16 weeks, backed by 90 days of post-launch monitoring after cutover. Details on how we structure that work live on our Shopify migration services page. Redirect mapping and canonical strategy specifically, the work covered in Phase 2 above, is its own discipline separate from the platform build, and it’s covered on our SEO migration services page.

Artifacts to demand from any agency:

What does this actually cost? We found no published, verifiable benchmark for what an SEO migration costs across platforms, and anyone quoting you a number before seeing your site is guessing. Cost scales with the size of the redirect map, the number of third-party apps that need to be re-matched, and how much content has no automated import path on the destination platform. A five-page brochure site and a ten-thousand-SKU catalog aren’t the same project, even on the same two platforms.

Timeline is a more honest number to anchor to than cost, because Google publishes a figure for the part it controls. For most pages on a medium-sized site, Google says the move itself takes “a few weeks” to fully register in the index, with larger sites taking longer and no fixed month figure attached anywhere in its documentation, per Google’s site-move guidance. That’s the reindexing timeline, not the build timeline. The build itself, the part before Google ever sees a new URL, is where BLKDG’s own 8-to-16-week range comes from, driven by catalog size and app complexity, the same two variables that drive cost.

The fastest way to get an actual number is a real audit of your current site, not a generic quote. Our technical SEO audit inventories what a migration would need to carry over before any build work starts, and our Core Web Vitals work resets the performance baseline once the new platform is live. Post-launch, ongoing work on variant URLs and duplicate content is covered by our ecommerce SEO services.

Every phase in this checklist produces something you can point to: a baseline you captured, a redirect map you can hand to a crawler, a staging environment that stayed out of Google, a cutover that followed Google’s own sequence, and a monitoring window that ran the full 90 days instead of stopping at week two. That’s the difference between an SEO migration that gets defended with data and one that gets defended with hope. If you want a second set of eyes on your redirect map, your staging setup, or your Core Web Vitals baseline before you move, start with a Free Visibility Audit: a real look at what an SEO migration would touch on your site, not a sales call.