Launch-Day SEO Checklist and Rollback Plan for SaaS Migrations

The honest scope of this page

Google documents a launch step list for each of its two migration classes, and documents how to cancel a domain move. It publishes no rollback criteria, no launch-day thresholds, and no decision framework. Everything on this page about when to revert, who decides, and by when is ours, and is labelled as such. Treat the labelled parts as CoreAEX's operating position, not as platform requirements - the distinction matters when someone carries this into an engineering meeting.

Two Change of Address statements that look contradictory and are both true

Documented Google's help page says not to use the tool when Moving between www and non-www in the same domain - and, in the same page, that when moving between domains you should make sure to use this tool for all subdomain variants of the old domain, including www and non-www.

Both are correct because they describe different moves. Changing www.example.com to example.com is not a site move for this purpose. Moving example.com to example.net is - and the instruction is broader than it first reads. Documented Google's full sentence covers variants you may not think of as part of the site: make sure to use this tool for all subdomain variants of the old domain, including www and non-www (for example, from en.example.com, www.example.com, and example.com to new-example.net), even if you're not actively using these variants currently - followed by Ensure that you have all of these variants verified in Search Console. On a class-C launch the filings are plural, and the set is defined by what the move covers rather than by what is already set up in Search Console.

1. DNS TTL lowered, with a week's notice

Documented Google's hosting-move guide is specific about the timing: Consider lowering the TTL to a conservative low value (for example, a few hours) at least a week in advance of the move to refresh DNS caches faster.

The lead time is the whole point. Lowering the TTL an hour before cutover does nothing for resolvers that already cached the old record at the old value - they will keep serving it for as long as that value said. Which is also why this precondition reappears in the rollback section: the reduced TTL is what makes a DNS-level reversal fast.

Recommendation Treat the reduced TTL as a planning target, not a guaranteed ceiling. It governs how long a compliant cache ordinarily retains an answer; it does not bind everything between your record and a user. Documented The IETF standardised the clearest exception: RFC 8767, Serving Stale Data to Improve DNS Resiliency (Standards Track, March 2020), defines a method (serve-stale) for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data - If the data is unable to be authoritatively refreshed when the TTL expires, the record MAY be used as though it is unexpired, with a suggested maximum stale period between 1 and 3 days. That behaviour is scoped to refresh failure, not to normal operation: if authoritative DNS becomes unreachable or returns a qualifying failure during cutover, some resolvers may continue serving stale answers beyond the original TTL. A migration whose authoritative servers stay reachable throughout does not meet that condition. Application-level caches, load balancers and long-lived connections can also outlast the interval, for reasons that have nothing to do with DNS. Plan to the reduced TTL; do not promise it as a recovery time.

Pass rule: the reduced TTL has been live for longer than the previous TTL value, so that records cached at the old value have had time to expire; the old value, the new value and the authoritative record state are recorded in the runbook; and the new value has been confirmed from more than one resolver rather than only from the control panel. "We lowered it" is not the check.

2. Googlebot can reach the new infrastructure, and this has been tested

Documented Google names the failure directly: Check your firewall configuration or denial of service (DoS) protection. Make sure it does not block Googlebot's ability to reach the DNS or the hosting provider's servers.

Where the move brings a new WAF, new rate limits or new bot rules with it, the defaults in front of you were written to stop unwanted automated traffic rather than to admit crawlers, and they apply to Googlebot unless something exempts it. Phase 4 covers the configuration itself; what belongs here is that the test result is recorded before the window opens, not discovered during it.

Pass rule: a dated record exists showing a verified Googlebot fetch reaching the new infrastructure through the production edge configuration, not through a bypass, an allowlisted office IP or a direct-to-origin request.

3. Search Console verification survives the move

Documented Google flags the two ways this breaks. On file-based verification: make sure you don't forget to include your current verification file in your new copy of the site. On CMS-managed verification, if the method is a meta tag or Google Analytics, ensure the new CMS copy includes these as well.

Check this specifically where verification was configured in the old CMS rather than committed to the repository - a rebuild copies the repository, and a setting that lives only in the system being replaced leaves with it.

Pass rule: for every property you will need during and after the move, the verification method is present in the new build and its continuity has been tested, not assumed. On a class-C move this includes the destination property and every old-domain variant the migration requires you to file from - which, per the box above, includes variants that are not currently in use and may not yet exist as properties at all. Losing verification does not only cost you reporting; it costs you the tools you would use to diagnose the launch.

4. The staging-only control inventory, with a tested removal path for each

Carried from phase 4, and the reason it is an inventory rather than a checklist item is in phase 3: Documented Google warns that When Google encounters the noindex tag, it may skip rendering and JavaScript execution, so a control that a deployment is expected to remove client-side may never be removed at all. Indexing state has to be decided server-side, which means the removal is a deployment or configuration change with an owner, not a tag someone deletes.

Two additions specific to launch day. First, if phase 3's crawlable exception was used - a staging URL temporarily made crawlable so Google's own tools could render it - that exception is a staging-only control too, and it needs its switch-back in the same inventory with the same owner. Second, the inventory must include controls that live outside the codebase: robots rules at the edge, WAF rules, environment flags, and X-Robots-Tag headers set by the server rather than the application.

Pass rule: every staging-only control is named in the inventory with an owner, a removal mechanism and a verification method, and the removal has been executed successfully at least once in a non-production environment. Not "no staging controls remain" - that condition is satisfiable by exposing staging, which is the opposite of what you want. Removal is verified on production, after cutover, in the sequence below.

5. The rollback decision structure, agreed and named

Recommendation Before the window opens, three things exist in writing: the trigger list (below), the person who can call a revert without convening anyone, and the time by which each decision must be made. A rollback plan that requires assembling a group is not a rollback plan; it is a meeting invitation with a deadline attached.

Pass rule: the trigger list, the named decision-maker, their named deputy, and a decision deadline for each trigger are recorded and circulated before the window opens. A trigger with no deadline is not a trigger.

Google's own guide is inconsistent about the old sitemap - and the resolution matters on the day

Documented The launch step says At this point you can remove your old sitemap, since Google will use the new sitemap going forward. The monitoring section of the same page says Submit the two sitemaps you saved earlier from the mapping, describes watching indexed counts move from one to the other, and adds that Search Console may show warnings for the sitemap that contains the old URLs about the URLs redirecting; this is normal and you can ignore these warnings. Meanwhile the mapping section lists only one sitemap file to save: A sitemap file containing the new URLs in the mapping.

Recommendation Read the old-URL sitemap as a monitoring instrument rather than a submission requirement. Keeping one submitted gives you a countable view of the old set draining as the new set fills, which is otherwise hard to observe cleanly; removing it is explicitly permitted and costs you that view. We keep it, accept the redirect warnings Google says to ignore, and remove it once the old set reaches zero. Whichever you choose, record the choice - a later reader should not have to infer it from the Sitemaps report.

1. robots.txt is cached, so removing a block is not instant

Documented Google generally caches the contents of robots.txt file for up to 24 hours, but may cache it longer in situations where refreshing the cached version isn't possible (for example, due to timeouts or 5xx errors). Google also may increase or decrease the cache lifetime based on max-age Cache-Control HTTP headers.

Two consequences for the window. A Disallow removed at cutover may not be acted on for hours, so a crawl that still respects it is not by itself evidence that the removal failed - check the file itself rather than inferring from crawler behaviour. And the reverse: a wrong robots.txt published at cutover does not stop being served the moment you fix it.

Pass rule: the production robots.txt is fetched and read directly after the switch, and its content matches the approved production file, including its Sitemap: lines and any Cache-Control header set on it. Confirm the intended rules are present, not only that the staging rules are gone - a file that lost both is also wrong.

2. Server errors during the window cost more than the errors themselves

Documented 5xx and 429 server errors prompt Google's crawlers to temporarily slow down with crawling, and on 500 specifically, Google decreases the crawl rate for the site. The decrease in crawl rate is proportionate to the number of individual URLs that are returning a server error. Recovery is documented as gradual: Once the server starts responding with a 2xx status code, Google gradually increases the crawl rate for the site. And on already-indexed URLs: For Google Search, already indexed URLs are preserved in the index, but eventually dropped.

Documented The robots.txt case is more severe again, because the file gates everything else: on server errors fetching robots.txt, For the first 12 hours, Google stops crawling the site but keeps trying to fetch the robots.txt file. If Google can't fetch a new version, for the next 30 days Google will use the last good version, while still trying to fetch a new version.

These mechanisms can make a brief launch failure outlast the visible outage, and they behave differently from one another. A broad 5xx across page URLs reduces the crawl rate in proportion to how many URLs are failing, and the rate returns gradually rather than immediately. A 5xx on robots.txt specifically stops crawling for the first twelve hours, after which Google may run on the last good version of the file - which means crawling can resume under the rules that were in place before your change, not under the new ones and not under a continued halt. How long any of this lasts depends on which endpoint failed, how broadly, and how quickly successful responses resume; Google states the mechanisms, not a duration. It is still the argument for sizing the cache purge below against tested origin capacity.

Pass rule: origin error rate and robots.txt availability are monitored as first-class launch signals with their own alert, not read later from a report. A sustained origin failure is on the rollback list; a handful of errors during propagation is not.

3. A full cache purge is a deliberate load event

Documented Cloudflare's own documentation on Purge Everything: Purging everything instantly clears all resources from your CDN cache in all Cloudflare data centers, and Each new request for a purged resource returns to your origin server to validate the resource. It warns: When a site with heavy traffic contains a lot of assets, requests to your origin server can increase substantially and result in slow site performance. And it states a preference: Cloudflare strongly recommends using single-file (by URL) purging instead of a complete cache purge.

The tension is real rather than resolvable in the abstract. A migration is one of the few situations where the cached corpus genuinely is stale across the board, which is what a full purge is for. It is also a situation where the origin is new, its caches are cold and its capacity is unproven. Read Cloudflare's preference as a reason to purge selectively where you can identify what changed, and to treat a full purge as a decision with a load consequence you have planned for.

Pass rule: the purge scope is decided and written down before the window, and if it is a full purge, origin capacity headroom has been tested at the expected post-purge request rate. Equivalent guidance from your own CDN vendor replaces Cloudflare's if you use a different one; do not carry one vendor's behaviour onto another's product.

4. Request indexing is not a launch-day bulk tool

Documented Google states the limit and the ceiling plainly: There is a daily limit to how many index requests you can submit, and Submitting a request does not guarantee that the page will appear in the Google Index. Its own instruction for volume points elsewhere: If you want many pages indexed, try submitting a sitemap to Google.

The launch-day version of this mistake is a team spending the window submitting individual URLs, which consumes the hours in which the observable failures are actually observable, and which Google's documentation does not support as a recovery mechanism.

Pass rule: the launch plan's discovery mechanism is the sitemap, with request-indexing reserved for spot checks on a handful of representative URLs. If someone proposes bulk submission as a remedy, that is a signal to re-read the failure, not to submit faster.

5. Change of Address is a filing, and on class C it is more than one

Documented What it does: it tells Google to emphasize crawling and indexing your new site over crawling your old site and forwards various signals from the old site to the new site. Its window: These actions continue for 180 days after you start migration in Search Console, and After the 180 day period, Google does not recognize any relationship between the old and new sites, and treats the old site as an unrelated site, if still present and crawlable. Its scope: You must be an owner of both the old and new properties in Search Console, it operates at the domain level, and The tool moves all protocols of your source property.

Documented Two boundaries that are easy to blur. It does not remove the old site: Google does not erase the old site from the index, and URLs from the old site can continue to be shown in Search results if they are available and don't have an equivalent page on the new site. And its 180 days is not the redirect guidance - the same page says Maintain the redirects for at least 180 days--longer if you still see any traffic to them from Google Search, while the site-move guide says to keep them for as long as possible, generally at least 1 year. Two different numbers for two different things; phase 2 holds the redirect-retention decision.

Pass rule: on a class-C move, the inventory lists every old-domain and subdomain variant covered by the move, including variants that are not in use, and every one of them is verified in Search Console and has a Change of Address request submitted and confirmed. The boundary is the migration plan, not the current property list: "it was never set up as a property" is a gap to close, not a reason to exclude a variant. Any variant excluded is recorded with the reason it falls outside this move. On class A and B, no filing exists, and the runbook records that this is deliberate rather than forgotten.

Why the middle column has no deadline attached to it

Documented Google describes these processes as taking variable time and does not attach an hour to any of them. On the move itself: As a general rule: for medium-sized websites, it can take a few weeks or more for Google to gradually start showing the new URLs instead of the old ones (and for larger sites, even longer), and how long it takes depends on the number of URLs and the speed of the servers. On sitemaps, the fetch is prompt but what follows is not: The sitemap should be fetched immediately. However, it can take some time to crawl the URLs listed in a sitemap, and, plainly, There is no guarantee that a page URL discovered in a sitemap has been or will be crawled or indexed by Google. If a sitemap is unavailable or broken, Google will retry for a few days, and then stop if the sitemap continues to be unavailable or has critical errors.

Recommendation Read those together and the operating rule follows: sitemap read status is a reasonable thing to look for in the first day, because the fetch is documented as immediate. Sitemap indexed counts are not, because what they measure is documented as taking time and as not guaranteed at all. Two numbers on one screen, on two entirely different clocks.

The live URL test belongs at T+0 - with two limits

Documented Google's live test is a real-time operation, not a report: This is a live test: the tool fetches and examines the URL in real time. On a production URL inside a property you own, it can be run within minutes of cutover, and it is the same artefact phase 3 and phase 4 could not obtain against protected staging. Launch is the moment that constraint lifts. There is a per-property daily limit of live inspections, which is a separate quota from the index-request limit, so spend it on representative templates rather than on volume.

Documented Two limits to hold on to. It is not an indexing result: Even if you get a valid or warning verdict in the live test, your page must still fulfill other conditions in order to be indexed. And it is not a redirect test - The test first follows any redirects implemented by the page, then tests the page. However, the test does not indicate that it has followed a redirect, nor will it display the final URL that was tested. A URL that redirects will therefore return a clean live result for its destination, silently. That is the reason the chain check in the left-hand column stays with your own server-side script: it is the only one of the two that can tell you a URL redirected at all.

The T+0 gate is a presence check, not an absence check

Recommendation Write every item in the gate as "the expected thing is there", not "the wrong thing is gone". A page that lost its canonical entirely satisfies "no contradictory canonical". A robots.txt that lost every rule satisfies "no staging Disallow". A template that lost its gated content satisfies "content is not exposed". Each of those passes an absence check and fails the migration. The expectation comes from the approved inventory and the phase 4 gate, not from what the production site happens to contain at the moment you look.

Google documents how to cancel a domain move

Documented A domain move has a documented reversal procedure, with a stated window: You can cancel a change of address request for 180 days after it was made. The steps Google gives, in order:

1. Remove any 301-redirect directives previously set up on your server. If you don't do this, Google will see those directives the next time it crawls your site and might continue to redirect the URLs as instructed by the directive.
2. Add 301 redirects from the new site to the old site.
3. Open the Change of address tool in the old site and click Cancel Move. Repeat for every old site that you no longer want to move.

Two things worth reading closely. Step 1 comes before step 2 because of the reason Google gives: leaving the original rules in place while adding reverse ones is how you build a loop or a chain rather than a reversal. And step 3's Repeat for every old site mirrors the plural filing on the way out - if you filed from four variants, you cancel four.