Technical SEO Checklist for SaaS Website Migrations

Most of this checklist does not apply to your migration. That is the point of the first section: a hosting change, a framework rebuild that keeps every URL, and a move to a new domain are three different projects with three different risk surfaces, and Google documents them separately. Classify what you are actually doing before you work a single item.

Google's own guidance splits site moves on one line - whether user-visible URLs change - and runs a separate guide for moves that change URLs and one for infrastructure changes that do not. Everything below is organized around that split and around the sequence Google describes: prepare, map URLs, launch, monitor.

One thing worth settling before you start, because it shapes how you argue for time and budget internally. Gary Illyes of Google's Search Relations team, asked on Google's own podcast in February 2023 what to expect after a correctly executed move, answered: if you've done everything right, then there shouldn't be any loss of traffic, because it's just like this URL is moving to that URL - and, completing the thought after a colleague's interjection, there's a redirect in place. So technically, again, there shouldn't be anything lost. Earlier in the same conversation he had given the realistic half: I think in the majority of the cases, there will be something that you've done wrong.

Hold both halves. A well-executed migration should preserve the content and signals that support performance - permanent loss is not a fee you pay for moving. But movement during reprocessing can happen with nothing broken. Google's traffic-drop guidance puts it conditionally: If you change the URLs of existing pages on your site, you may experience ranking fluctuations while Google recrawls and reindexes your site, and the site-move guide tells you to Expect temporary fluctuation in site ranking during the move. Note what that does and does not say - fluctuation is possible during reprocessing. It is not a statement that most migrations lose traffic, nor that a loss you observe will return on its own.

So the working rule for this checklist: neither a drop nor a recovery is assumed. Movement in the first weeks is not by itself proof that anything was done wrong, and it is not proof that nothing was. Section 14 covers how to tell.

1. Which Migration Are You Actually Running?

Find your row. The right-hand column tells you which sections below matter most. Google's own list of what counts as a move with URL changes is worth reading first, because it is broader than most people assume: URL changes from HTTP to HTTPS, Domain name changes such as example.com to example.net or merging multiple domains or hostnames, and URL paths changes.

If You Are Combining Changes

Google's documentation is direct about this: Plan your changes to your site one after the other, not everything at the same time. For example, if you want to move your site to a new domain name, change your content management system (CMS), and update your site to use a new layout, do them one at a time.

Google has given two different reasons for that rule, and it is worth knowing both because they support different arguments with your engineering team.

• Error surface. Illyes, February 2023: with site moves, the smaller pieces you can break it into, especially if it's some complex stuff, the safer it is for you, and the more steps you introduce, the more potential errors you also introduce.
• Attribution. John Mueller, in a 2020 Reddit answer: If you need to do both, I'd try to split it time-wise so that you can recognize any negative effects in each part, and take action to improve them. If you do everything at once, you'll never know what to fix, and even if things end up "same as before", you won't know if one part went down, and was compensated by an improvement on the other part.

The second one is usually the more persuasive with a product team, because it is not a claim about risk - it is a claim about whether anyone will be able to diagnose the result.

Two smaller classification notes from the same conversation. On HTTPS-only moves, Illyes said I think for HTTPS, I wouldn't worry, and Mueller added that he had not seen one go weird in a long time. Google still classifies HTTP-to-HTTPS as a URL-changing move, so the redirect, canonical and monitoring work applies - treat it as a comparatively mature, usually lower-risk instance of the full process rather than an exemption from it. And if you are moving to a previously used domain, check its history before you commit: Mueller named this as one of the recurring problems he does still see, and suggested the obvious check - with archive.org, you can look at the old version of the site.

2. What Changes, and What Stays Stable

Fill this in before anything else. It is the artifact the rest of the project argues against, and it is the fastest way to catch a change nobody told you about.

3. Roles and Approval Gates

Assign these by name, not by team. Ownership gaps are a recurring migration failure mode - the item nobody checked is usually the one two people each assumed the other owned.

• Migration owner - accountable for the go/no-go decision and for calling a rollback.
• Redirect owner - owns the map as a file, owns its testing, owns it after launch.
• Platform/engineering owner - owns server responses, rendering, robots directives and the deploy.
• Measurement owner - owns analytics, consent, conversion tracking and Search Console continuity, and confirms measurement works before cutover, not after.
• Approver - signs off the go/no-go, usually not the same person as the migration owner.

Set the launch freeze here too: the date after which no further scope enters the release. A freeze that is agreed the week before launch is not a freeze.

More detail: SaaS migration planning - scope, baselines, owners and risk.

4. Pre-Migration Baseline

Record all of this while the old site still exists. Most of it cannot be reconstructed afterward, and without it you cannot tell a migration problem from a seasonality problem or an algorithm update.

• Full URL inventory with status codes (see §5).
• Organic sessions, conversions and revenue by landing page, for at least 12 months.
• Search Console performance export - queries, pages, clicks, impressions, position - for the maximum available window, saved as files rather than left in the interface.
• Indexed-page counts and the Page Indexing report's status breakdown.
• Ranking positions for your tracked set, dated.
• Backlinked URLs, ranked by referring domain count. These are the URLs where a redirect error is most expensive.
• Core Web Vitals field data by template. This is the production real-user baseline, and it stays the reference point after launch - it is not something staging can reproduce (§8).
• Crawl Stats - Google's report covers the past 90 days only, so export before you need it.
• Server and CDN logs for a defined pre-migration window - 30 to 90 days is the usual range - long enough to capture ordinary crawler activity across your priority templates and known legacy URLs. Record the dates, the crawler-verification method you used, and the URL coverage you actually achieved. Google publishes no fixed site-wide crawl cycle and different URLs are revisited on very different schedules, so "one full crawl cycle" is not an auditable criterion; a stated window and coverage figure is.

5. URL and Content Inventory

One source is never enough. Combine, deduplicate, and keep the result as a file under version control.

• A full crawl of the current site.
• XML sitemaps, including any that are stale or unlinked.
• Server and CDN logs - these surface URLs nothing links to any more but crawlers still request.
• Search Console pages data and the Page Indexing report.
• Analytics landing pages.
• Backlink data, for URLs that no longer exist internally but still receive links.
• Parameterized URLs, faceted paths, and anything paginated.
• Non-HTML assets: images, PDFs, downloads.

Full method, including the workflow for sites in the tens of thousands of URLs: URL inventory and redirect mapping for SaaS migrations.

6. Redirect and Canonical Plan

What Google documents, and what follows from it:

• Use server-side permanent redirects. Google lists 301 and 308 as permanent, and orders redirect methods by how reliably it can interpret them: a server side redirect has the highest chance of being interpreted correctly by Google. In its status-code documentation, a 301 is a strong signal that the redirect target should be processed; a 302 is a weak one; 308 is equivalent to 301 and 307 to 302.
• Map to the closest equivalent page, and document genuine consolidation. One-to-one is the safe default but not a rule - Google permits it explicitly: However, if you have consolidated content previously hosted on multiple pages to a new single page, you can redirect the older URLs to that new, consolidated page. What is not allowed is a convenient destination standing in for a real one: Don't redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site. This can confuse users and might be treated as a soft 404 error.
• Redirect to the final destination, and treat ten as a ceiling rather than a target. Google: While Googlebot can follow up to 10 hops in a "chain" of multiple redirects (for example, Page 1 > Page 2 > Page 3), we advise redirecting to the final destination directly. If this is not possible, keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5. Chaining redirects adds latency for users, and not all user agents and browsers support long redirect chains. Aim for no more than three hops and require fewer than five. Google's status-code documentation adds that specific products' crawlers may have different limits - limits vary, so do not assume Googlebot's ceiling applies to other crawlers, browsers or user agents.
• Update internal links; do not lean on the redirects. Change the internal links on the new site from the old URLs to the new URLs.
• Keep the redirects for at least a year. Keep the redirects for as long as possible, generally at least 1 year. This is the window Google gives itself to transfer signals to the new URLs. Mueller has said the same thing repeatedly, including in 2022: definitely keeping the redirects in place for at least a year. 3 months is too short for a site-move.
• Set canonicals deliberately. Google describes redirects and rel="canonical" as strong canonicalization signals and sitemap inclusion as a weak one - none of them a directive - and warns: Don't specify different URLs as canonical for the same page using different canonicalization techniques.

7. Rendering and Indexability

Relevant to every framework or platform migration, and the section most often skipped because the pages look fine in a browser.

• Compare the raw server response for a sample of templates, old versus new - not the browser view. What is in the initial HTML is what a non-rendering client receives.
• Then compare the rendered output. Google describes processing JavaScript in three phases - Crawling, Rendering, Indexing - and notes that a page may stay on this queue for a few seconds, but it can take longer than that. Its own recommendation for checking: use the Rich Results Test or the URL Inspection Tool and look at the rendered HTML.
• Confirm no JS or CSS needed for rendering is disallowed. Google: Google Search won't render JavaScript from blocked files or on blocked pages.
• Interaction-dependent primary content is a fail, not a note. Google's lazy-loading guidance states it plainly: Google won't load content that requires user interactions (for example, swiping, clicking, or typing) to load. The same page warns against lazy-loading anything "likely to be immediately visible when a user opens a page," and says its recommended methods don't rely on user actions, such as scrolling or clicking, to load content, which is important as Google Search does not interact with your page. The pass rule: critical indexable content and crawlable links must be in the rendered HTML without a click, swipe or keystroke. Viewport-triggered lazy loading is fine - Google's own instruction is to make sure the implementation loads all relevant content whenever it is visible in the viewport.
• Check tabs, accordions, "load more" controls and infinite scroll against that rule specifically. On pagination Google is explicit: Google's crawlers don't "click" buttons and generally don't trigger JavaScript functions that require user actions to update the current page contents, and when crawling Google generally crawls URLs found in the href attribute of <a> elements. A "load more" button with no underlying links is a discovery dead end.
• If the rendering model itself is changing, Google's standing note applies: server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript.

Detail, including hydration failure modes and how to test parity: Rendering and indexability for React, Vue and headless migrations. For how non-Google crawlers behave with JavaScript, see our AI crawlability pillar.

8. Staging Acceptance Tests and Go/No-Go

Crawl staging, crawl production, diff the two. Eyeballing a few pages is not this step.

• Status codes: no unintended 3xx, 4xx or 5xx; no soft 404s. Google's definition of the latter: a page that returns a user-friendly 'not found' message but not a 404 HTTP response code.
• Content parity per template - main content present, in the initial response where it was before.
• Titles, meta descriptions and heading structure, compared as a set, not sampled.
• Canonical tags resolving to the intended URLs.
• Robots directives - and specifically, a written inventory of every staging-only control: noindex tags, X-Robots-Tag headers, robots.txt rules, WAF rules and environment flags. Each one needs a tested removal path in the production release. Do not remove them from staging to satisfy a checklist - see the go/no-go note below.
• Hreflang, if used. Google: If two pages don't both point to each other, the tags will be ignored. Reciprocity breaks silently when URLs change.
• Structured data validity and parity.
• XML sitemaps built from the new canonical URLs. Google: Include the URLs in your sitemap that you want to see in Google's search results. Limits are 50MB or 50,000 URLs per file.
• Internal links resolving to final destinations.
• Assets - images, CSS, JS, PDFs - present and reachable at their new paths.
• CDN, WAF and bot management not blocking legitimate crawlers. Cloudflare's own SEO checklist, for example, asks you to confirm that WAF custom rules, rate limiting rules and bot protection settings are all allowing verified bots.
• Performance measured on staging as lab and synthetic tests - repeatable runs per template, per device profile, per build - plus load and origin-capacity testing where the move changes hosting. Add controlled RUM if you have a real user population on staging, which most teams do not.
• Analytics, consent and conversion tracking firing correctly.

Go / No-Go

Write the pass conditions down before the test window opens, and have the approver sign them. "The crawl looks clean" is not a criterion. Something like this is:

• Zero unintended non-200 responses across the top 500 URLs by traffic and the top 200 by referring domains.
• Zero missing or incorrect canonicals across the template set.
• Critical content present in the rendered HTML for every template, with no interaction dependency.
• Staging is still protected - authenticated or IP-restricted - and every staging-only crawl or index control is inventoried with a tested production removal path.
• Measurement - analytics, consent, conversion tracking - confirmed firing on staging.
• Lab performance within the agreed tolerance of the previous build, per template.

Full test matrix: Staging SEO QA checklist before launch.

9. Launch-Day Sequence

In order, with a named owner against each line:

1. Confirm the freeze held - nothing entered the release after go/no-go.
2. Deploy.
3. Remove every temporary crawl and index block, then verify by fetching. Google's hosting-move guidance lists removing any temporary blocks to crawling, robots.txt rules and noindex tags included. Work from the inventory you built in §8 and confirm each removal against the live production response - headers, HTML and robots.txt - rather than asking whether it was done. This is the step the staging gate deliberately deferred to.
4. Activate redirects. Spot-check the top URLs by traffic and by backlinks immediately, following redirects to their final destination and checking the status of each hop.
5. Verify DNS and CDN are serving the new origin, and purge cache deliberately rather than reflexively - a full purge sends every subsequent request back to origin, which is exactly the wrong load profile during a cutover.
6. Confirm the production robots.txt is the production robots.txt.
7. Submit the new XML sitemaps in Search Console.
8. Domain moves only: file the Change of Address request. See below.
9. Confirm Search Console verification still works on both properties.
10. Confirm analytics and conversion tracking are recording.
11. Optionally, notify the engines that support IndexNow. Its FAQ states the migration case explicitly: If your entire site has been recently updated, such as after a migration or redesign, it is acceptable to submit all URLs using IndexNow - and that you should also submit redirected URLs and pages returning 404 or 410. Submission does not guarantee immediate indexing.

Full cutover runbook and rollback triggers: Launch-day SEO checklist and rollback plan.

10. First 24 Hours

• Server error rate. Google's crawlers respond to problems here: 5xx and 429 server errors prompt Google's crawlers to temporarily slow down with crawling.
• Redirect spot-checks across every template, not just the ones you tested at launch.
• Search Console URL Inspection on a handful of key pages - live test, checking the rendered HTML.
• Crawl the live site and compare against the staging crawl you signed off.
• Analytics recording sessions and conversions at plausible volumes.
• A first log check: are crawlers arriving, and what are they receiving?

11. First 7 Days

• Search Console Page Indexing report on both properties - watch for pages moving into Not found (404), Soft 404 or Duplicate, Google chose different canonical than user.
• Crawl Stats: response mix, file types, and host status for robots.txt fetching, DNS resolution and server connectivity.
• Crawl rate against the pattern your migration type predicts. For a URL-changing move, Google says After a migration, Google will temporarily crawl your new site more heavily than usual. For a hosting move, the documented pattern is the opposite: 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. A drop after a domain move, or a sustained drop after a hosting move, is worth investigating.
• Sitemap processing status.
• Logs on both old and new infrastructure. Google's advice for hosting moves - Keep an eye on the server logs on both new and old servers - applies to any move where the old environment is still up.
• Ranking movement against the §4 baseline, read as a trend, not day by day.

12. First 30 Days

• Weekly indexed-coverage trend on both properties.
• Organic traffic and conversions by template against baseline.
• Redirect log review - which old URLs are still being requested, and are any of them now failing?
• Backlink migration: has anything you asked to be updated actually been updated? Google's guidance includes contacting them: Try to contact the sites in the saved list of sites linking to your current content, asking them to update their links to your new site.
• Core Web Vitals field data, once enough real-user data has accumulated.
• A second full crawl, compared against week one.

Expect movement while this settles. Google's own framing: Expect temporary fluctuation in site ranking during the move, and the visibility of your content in Search may fluctuate temporarily during the move. This is normal and a site's rankings will settle down over time.

Thresholds, cadence and escalation rules: Post-migration SEO monitoring - the first 30 days.

13. Rollback Triggers and Escalation

"We have a rollback plan" is not a plan. A trigger is a measurable condition, agreed before launch, with a named owner and a decision deadline. And it needs to be two lists, not one - because the signals that justify reverting within the hour and the signals that justify opening an investigation are different kinds of evidence arriving on different timescales.

Immediate Rollback Candidates

Things you can observe directly, now, and that are unambiguously broken:

• Sustained availability failure - server error rate above a defined threshold, beyond a defined window.
• Material routing errors: a defined proportion of the top-traffic or top-linked URL set returning anything other than the intended status.
• Critical content absent under the rendering criteria you agreed in §8, across a defined proportion of templates.
• Essential transaction or measurement failure - checkout, signup, or conversion tracking not recording after a defined interval.

SEO Escalation Candidates

Things that warrant investigation and a decision review, and that do not automatically trigger a rollback:

• Indexing or crawl-coverage changes beyond pre-agreed thresholds.
• Ranking or organic traffic changes beyond pre-agreed thresholds.
• Persistent template-specific losses that do not recover on the expected recrawl timeline.

Read every item on the second list against reporting lag, seasonality and expected recrawl behavior before acting. Search Console reports are aggregated rather than live, and its own fix-validation process typically takes up to about two weeks, but in some cases can take much longer - which tells you something about the timescale these reports operate on. You cannot distinguish normal post-move fluctuation from a real defect inside 48 hours, and reverting a URL move does not undo it: it creates a second migration on top of the first, with more ambiguity, not less.

14. How Long Until Traffic Comes Back - What the Evidence Actually Supports

This is the question every stakeholder asks, and the answers in circulation are worse-sourced than they appear.

What Google Publishes

A processing estimate, not a recovery estimate. 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). That describes how long Google takes to swap old URLs for new ones in its results. It is not a statement about when your traffic returns to its previous level, and it should not be quoted as one.

The One Google Statement About Waiting

Illyes, in February 2023, answering what to do when a move has not recovered: Practically, I think there's a limit to how much time you should wait. And after that, there's not that much that can happen from search engine perspective... And specifically speaking of Google, that limit is not exactly, but about one year. He hedged it twice more: it's not like 365 days or whatever. It's like a ballpark there. And if you waited about one year, and then you still haven't recovered the traffic to that site, then you probably want to think about other strategies, or even before that actually.

Read that as a ceiling on waiting rather than an expected duration. It answers the more useful question: at what point does continuing to wait stop being a strategy and start being avoidance.

What Is Not Supported

• "Rankings recover in two to four weeks." We could not locate any study, dataset or platform statement behind this figure. It appears in practitioner and vendor content without a cited source, sample or method.
• "Nine out of ten migrations fail." Appears unsourced on a vendor blog that separately, and correctly, cites a published 892-migration analysis for recovery timelines - an analysis that measured days to recovery and reported no success or failure rate at all. The figure borrows credibility from a citation that is not attached to it.
• "Poor migrations cost 20-40% of traffic and take 6-12 months." From an August 2026 vendor press release, which is explicit about its own basis: the figures come from an August 2026 Optimum7 analysis of 1,000 buyer prompts and 4,000 AI responses across ChatGPT, Gemini, Claude, and Grok. That measures what chatbots say about migrations, not migration outcomes.

The One Dataset With a Method, and Why Its Headline Number Misleads

Dan Taylor has published a recovery analysis twice - in Search Engine Journal in January 2025 (n=892, mean 523 days to return to prior traffic, 17% not recovered after 1,000 days) and on SALT.agency in June 2026 (n=1,052, median 304 days, mean 489 days, 13.9% not fully recovered after three years).

The methodology disclosure is what matters, and the two publications differ. The 2026 study detected its cases through a collapse in estimated traffic: A migration event was flagged at the first month where the prior six-month rolling average exceeded 50 visits per month and current month traffic fell below 40% of that average. Its figures therefore describe a severe-collapse cohort - migrations already identified by having lost roughly 60% or more of estimated monthly traffic - and cannot be generalized to migrations without a comparable collapse, which by construction cannot appear in that data at all. The 2025 publication describes a crowdsourced sample gathered through an open request to the SEO community and discloses no such threshold, so that caveat belongs to the 2026 cohort only. Their data sources differ too: the 2025 article states it used third-party tools, while the 2026 publication does not identify its traffic-data provider, so that dataset's source limitations cannot be fully assessed from its published method. The 2026 study also states that it does not run regression analysis against migration quality factors. They are two related analyses by the same author, not replications of each other - do not combine their distributions.

As of August 2026, our search did not identify peer-reviewed research measuring organic-search recovery across a representative population of site migrations. That is the result of a search, not a proof that none exists.

What About AI Answers and Citations?

Very little is documented. In the provider documentation we reviewed for this article in August 2026 - OpenAI's, Anthropic's and Perplexity's published crawler pages - we did not find migration guidance comparable to Google's site-move documentation, and none of those pages addressed redirects, HTTP status codes or URL changes. Documentation changes, so treat that as what a review found on a date rather than a standing fact. The one adjacent statement is Google's: to be shown as a supporting link in AI Overviews or AI Mode, a page must be indexed and eligible to be shown in Google Search with a snippet. A reasonable inference - and it is an inference, not a finding - is that whatever damages your indexing during a migration also affects that eligibility. That reasoning does not extend to ChatGPT, Claude or Perplexity, where no equivalent statement exists.

Symptom-by-symptom diagnosis: Diagnosing and recovering from migration traffic drops.

15. The Master Checklist

Sources

Sources: Google Search Central, Site moves with URL changes - the move sequence, changing one element at a time, processing period, redirect retention, the full chain-length recommendation, the consolidation and homepage-redirect guidance, the PageRank-retention statement, internal links, contacting linking sites, crawl-rate expectation. The page currently carries a "Last updated 2026-08-20" stamp, but Google's documentation-updates log has no matching August 2026 entry for site moves (its most recent is 17 June 2026, on Change of Address subdomain variants) - cited here for its current wording, not for a confirmed change date. Google Search Central, Site moves without URL changes - hosting and CDN scope, testing environment, crawler access, Search Console verification continuity, server logs, crawl-rate drop, removing temporary blocks. Google Search Central, Redirects and Google Search - redirect types and the server-side recommendation. Google Search Central, HTTP status codes, network and DNS errors - the 10-hop limit, 301/302/307/308 signal strength, 4xx handling, 5xx and 429 crawl slowdown. Google Search Central, How to specify a canonical URL - canonicalization signals and conflicting-signal guidance. Google Search Central, Build and submit a sitemap - canonical-URL guidance and file limits. Google Search Central, Localized versions of your pages - hreflang reciprocity. Google Search Central, JavaScript SEO basics - crawl, render and index; the rendering queue; testing rendered HTML; blocked resources; the pre-rendering recommendation. Google Search Central, Fix lazy-loaded content - viewport-based loading, and why content requiring user interaction is not loaded. Google Search Central, Pagination, incremental page loading, and Search - crawlers do not click buttons; link discovery through <a href>. Google Search Central, Debugging drops in Google Search traffic - ranking fluctuation during recrawl and reindex after URL changes. web.dev, Getting started with measuring Web Vitals (last updated 9 September 2025) - real-user data as the basis of Core Web Vitals assessment, and the 28-day and calendar-month reporting periods. Google Search Central, Introduction to robots.txt - what robots.txt does not do, and what to use instead. Google Search Central, AI features and your website - indexing and snippet eligibility as the condition for appearing as a supporting link. Google Search Central, Search documentation updates - the 17 June 2026 entry adding subdomain-variant guidance to the site move guide. Google Search Console Help, Change of Address tool - scope, subdomain variants, the 180-day window, redirect maintenance. Reviewed 27 August 2026; the page carries no publication date. Google Search Console Help, Page Indexing report - status definitions including the soft 404 definition, and report scope. Reviewed 27 August 2026; no publication date shown. Google Search Console Help, Crawl Stats report - report scope and host status. Reviewed 27 August 2026; no publication date shown. Google Search Console Help, Removals and SafeSearch reports tool - duration, scope, and its own list of uses it is not intended for. Reviewed 27 August 2026; no publication date shown. Google Search Relations, Search Off the Record, episode 56: "Site moves: Are they getting any easier?", 23 February 2023, with Gary Illyes, John Mueller and Lizzi Sassman - the source of every quotation attributed to that date, checked directly against the episode transcript, including the one-year waiting ceiling, the "if you've done everything right" position, the main-content parsing explanation, the redesign-within-existing-HTML distinction, the HTTPS assessment, the used-domain check and the users-but-not-Googlebot redirect escalation. John Mueller on redirect-chain auditing, Reddit, February 2026, as reported by Search Engine Roundtable; on redirect retention, X, March 2022, as reported by Search Engine Roundtable; on combining changes, Reddit, July 2020, as reported by Search Engine Journal. IndexNow FAQ - the post-migration submission case, redirected and deleted URLs, and the absence of an indexing guarantee. Reviewed 27 August 2026; the page carries no publication date. Cloudflare, Improve SEO (last updated 20 April 2026) - verified-bot allowances in WAF, rate limiting and bot protection; and Purge everything (last updated 16 April 2026) - origin load after a full purge. Dan Taylor, "How Long Should An SEO Migration Take?", Search Engine Journal, 9 January 2025 (n=892); and "Only 27% of domain migrations recover in 90 days", SALT.agency, 26 June 2026 (n=1,052) - including the migration-detection threshold quoted above. Industry research, not peer-reviewed.

---