Post-Migration SEO Monitoring: The First 30 Days

What this page is not

This is detection and reporting. Diagnosis is phase 7 - it owns the symptom-by-symptom troubleshooting, the exclusion pass for causes that are not your migration, and the honest answer to "how long until it comes back." The launch window and the rollback decision are phase 5. The handoff between this page and phase 7 is a single thing: the escalation threshold. This page's job is to reach that threshold deliberately, or to reach day 30 without it.

"Verified Googlebot" means something specific

The log rows matter only if the requests are really Google's, and a migration is a period when unusual crawler traffic arrives for other reasons. Documented Google publishes two methods. Manually: Run a reverse DNS lookup on the accessing IP address from your logs, using the host command, verify the domain is googlebot.com, google.com, or googleusercontent.com, then Run a forward DNS lookup on the domain name retrieved in step 1 using the host command on the retrieved domain name and Verify that it's the same as the original accessing IP address from your logs. At scale: you can identify Googlebot by IP address by matching the crawler's IP address to the lists of Google crawlers' and fetchers' IP ranges, which Google publishes as JSON files in CIDR format.

Recommendation Decide which method your log pipeline uses before launch, not while investigating. An unverified user-agent string is not evidence of a Google crawl, and a log filtered on the string alone will report a crawl volume that nothing has checked.

Which pattern you should expect depends on the migration class

Phase 5 classifies the move as A (URLs unchanged - hosting, CDN, infrastructure), B (URLs change, domain does not) or C (domain or subdomain changes). That classification decides which of the shapes below apply to you, and Documented Google publishes two different crawl-rate expectations, one per guide. Reading the wrong one at your own launch produces a false alarm or a missed one.

Class A predicts a crawl-rate drop first. Class B and C predict heavier crawling. They are not two descriptions of one pattern, and neither generalises to the other class. Redirect-driven indexing categories and an old-versus-new sitemap crossover belong to B and C: on a class-A move the URL inventory is unchanged, so a rise in Page with redirect is a finding rather than an expectation - unless the implementation also changed URLs or sitemap membership, in which case it was not a class-A move.

Crawl rate moves - in opposite directions, depending on the class

Class A, URLs unchanged. Documented When you change hosting infrastructure, 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, potentially to rates that may be higher than before the move. Google gives the reason: This fluctuation occurs because we determine crawl rate for a site based on many signals, and these signals change when your hosting changes. So on a hosting move, the dip is the documented pattern, and treating it as a defect is reading the wrong guide.

Classes B and C, URLs changed. Documented After a migration, Google will crawl your new site more heavily than usual, because your site redirects traffic from the old to the new site, and any crawls of the old site will be redirected to the new site, in addition to any other crawling.

Either way the thing to watch in Crawl Stats is not the total but the composition - the response-code mix, and whether the host status for robots.txt fetching, DNS resolution and server connectivity stays clean. Documented Google publishes the consequence of getting that wrong: If the request doesn't return either a valid file (either populated or empty) or a 404 (file does not exist) response, then Google will slow or stop crawling your site until it can get an acceptable robots.txt response.

Watch for: a rising share of 5xx or 429 responses, or any host-status category leaving the healthy state. Not the crawl total by itself, in either direction.

On a class-B move - and in the old property for class C - redirect-related "not indexed" reasons can rise

Property scoping matters on a domain move. Documented Google's own coverage guidance describes the general shape a URL-change move produces: The graphs would reflect the site move, showing a drop in indexed URL counts on the old site and an increase of indexing on the new site. Recommendation On a class-B move that shape is visible within a single property, since the old and new URLs share one domain. On class C the old and new sites are different domains tracked in separate properties, so the same shape has to be read across two Index Coverage reports rather than one - which is why the redirect-related reasons belong principally to the old property there, while the new property is assessed on whether the destination URLs are being discovered and indexed at all. Reading class-C redirect growth in the new property, or expecting the new property to show the old property's shape, produces a confusing picture from correct data.

The total is the wrong number to read here, and a URL change is designed to increase it. Read the reasons instead. Documented Google's own definitions for the categories a URL change produces:

• Page with redirect - This is a non-canonical URL that redirects to another page. As such, this URL will not be indexed. Every mapped and consolidated old URL from phase 2 is supposed to land here.
• Alternate page with proper canonical tag - This page is marked as an alternate of another page (that is, an AMP page with a desktop canonical, or a mobile version of a desktop canonical, or the desktop version of a mobile canonical). This page correctly points to the canonical page, which is indexed, so there is nothing you need to do. Expected only where the inventory records an intentional duplicate or variant. A migration does not make this category automatically correct: a URL landing here that the inventory says should be canonical in its own right is a defect, and Google's reassuring wording applies to the arrangement it describes, not to the fact of a move.
• Not found (404) - This page returned a 404 error when requested, and Googlebot will probably continue to try this URL for some period of time. Your intentionally retired and no-equivalent dispositions belong here, and Google's point about the count not falling immediately is why it does not fall immediately.

Against those, the categories that deserve attention because they mean Google disagreed with you:

• Duplicate, Google chose different canonical than user - Google has indexed the page that we consider canonical rather than this one.
• Duplicate without user-selected canonical - Google has chosen the other page as the canonical for this page, and so will not serve this page in Search.
• Crawled - currently not indexed - The page was crawled by Google but not indexed. It may or may not be indexed in the future; no need to resubmit this URL for crawling. Note Google's own uncertainty; this is a status, not a verdict.
• Discovered - currently not indexed - The page was found by Google, but not crawled yet, and Google rescheduled the crawl.
• URL marked 'noindex' - When Google tried to index the page it encountered a 'noindex' directive and therefore did not index it. On a page you expected to be indexed, this is the phase 5 staging-control failure surfacing, and it routes straight to phase 7.

Watch for: growth in the second group, measured against the approved inventory rather than against the previous total. A URL appearing under Page with redirect is a match to its recorded disposition if the inventory said it would redirect, and a defect if the inventory said it would not. The category alone is not the finding; the category against the expected disposition is.

The example lists are not a URL-level reconciliation

Documented The category totals are Google's own count, but the URLs it shows you are a sample: Note that the list of example URLs in the report is limited to 1,000 items, and isn't guaranteed to show all URLs in a given status, even when less than 1,000 items. Read that second clause carefully - the list can be incomplete below the cap, so a URL's absence from it is not evidence of anything.

Recommendation Use the totals and their trends for aggregate monitoring. Reconcile the approved inventory URL by URL with your own crawl and log data plus targeted live URL Inspection checks on representative URLs - not by reading down the examples table. The examples cannot be relied upon to enumerate the affected set - they may happen to, and Google does not guarantee it - so treating them as complete produces a confident, unfounded "we checked every one."

And the two-week figure belongs to a different thing. Google's Validation typically takes up to about two weeks, but in some cases can take much longer, so please be patient describes the workflow that starts when you click Validate fix - it is not a statement about how current the report is. Do not use it to decide whether a report has caught up. Use the report's own last-updated date, and where that date predates the change you are evaluating, record the reading as not yet updated: neither a pass nor a fail.

On a class-B or class-C move where both sitemap sets are kept, the two curves cross over

Documented If you kept an old-URL sitemap submitted as a monitoring instrument, Google describes the shape you should see: Initially, the sitemap containing the new URLs would have zero pages indexed, while the sitemap of the old URLs would have many pages indexed. Over time the number of pages indexed from the old URLs sitemap would drop to zero with a corresponding increase of indexing of the new URLs. It also pre-empts the alarm: Note 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: you are, in fact, moving to new URLs after all.

Each curve carries partial evidence on its own; the paired view is more diagnostic, because it shows whether discovery of the destination URLs is happening alongside processing of the old inventory. That is the argument for keeping the old sitemap submitted even though phase 5 notes Google permits removing it. This shape does not apply to a class-A move, where the sitemap inventory did not change.

Watch for: the two curves moving in opposite directions. Both flat is a different situation from both moving, and worth distinguishing from the case where the new-URL sitemap has not been fetched at all.

Search performance fluctuates, and Google says so twice

Documented From the site-move guide: Note that 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. And, separately: Expect temporary fluctuation in site ranking during the move. From the traffic-drop guidance: If you change the URLs of existing pages on your site, you may experience ranking fluctuations while Google recrawls and reindexes your site.

Two things this does not license. It is not a reason to ignore performance data - a defect and an expected fluctuation can look identical early, which is an argument for a threshold, not for looking away. And it is not a duration: Google says fluctuation is expected and that things settle, without saying when.

Watch for: the shape rather than the day. A loss concentrated in one template group, one directory, or one disposition class is a different signal from a proportional dip across everything, and phase 7's diagnosis starts from that distinction.

What Google publishes about timing, and what it does not

Documented On how long processing takes: The time it takes Googlebot and our systems to discover and process all URLs in the site move depends on how fast your servers are and how many URLs are involved, and As a general rule, a small to medium-sized website can take a few weeks for most pages to move, and larger sites take longer.

That is a processing estimate - how long until Google is showing the new URLs instead of the old ones. It is not a recovery estimate, and it is not a deadline. The pillar keeps those three ideas separate on purpose, and phase 7 holds the evidence position on recovery time, including which circulating statistics do not survive checking. Nothing on this page converts Google's "a few weeks" into a date by which something must have happened.

One exception: a live technical failure escalates on a single corroborated observation

Recommendation Requiring persistence for every signal is right for lagged, aggregated ones and wrong for a running outage. Widespread 5xx, production crawling blocked at robots.txt or by an inverted indexing control, or a direct fetch failing - these escalate immediately, on one observation corroborated by a second instrument.

But the corroborating instrument has to be a live one. Documented Crawl Stats is retrospective, covering the past 90 days; the Sitemaps report records the outcome of Google's own last request, and where a sitemap is unavailable Google will retry for a few days, and then stop if the sitemap continues to be unavailable or has critical errors. Neither is an alert. A Search Console report can support an immediate escalation once it refreshes, and can open an investigation on its own - but the trigger has to be something you can observe now: your origin telemetry, a DNS or HTTP check, the server log, a direct fetch of robots.txt or the sitemap.

The distinction is the same one phase 5 draws for its rollback list: signals you observe directly and immediately are on a different clock from signals that arrive aggregated and lagged. Waiting for a second scheduled reading before acting on an outage applies a lagged-signal rule to a live one - and putting a lagged report on an immediate trigger makes the same mistake in the other direction.

1. Is the report actually populated yet?

Phase 5's distinction carries through the whole month: a Google-controlled report that has not refreshed is showing you an absence of data, not an absence of activity. Record "not yet populated" as its own state. Escalating on an empty report is escalating on nothing.

2. Is it a known Search Console data anomaly?

Documented Google maintains a page for exactly this: On rare occasions, there might be an event in Search Console that could affect your report data. It lists dated entries by affected report and separates logging errors - where the data was under-recorded - from actual index changes. Checking your drop date against that list is a two-minute exclusion, and it is the cheapest one available.

This is the same reasoning phase 7 applies at length when ruling out causes that are not your migration. Here it is a routine step in the cadence rather than a diagnosis.

3. Are you reading the right property, with the right dates?

After a domain move you have at least two properties reporting on two different sets of URLs. Monitor both through the transition, and read each for what it can actually show. The old property may keep showing historical and transitional performance while current clicks and impressions for the old URLs decline as Google processes the destination. That decline can be consistent with the expected transfer - particularly where indexing and performance are rising in the new property at the same time - but it is not proof of it on its own. Documented Google frames it as paired movement: you should expect to see traffic drop on the old site and rise on the new site. One half of that pair, read alone, is compatible with a transfer working and with a site simply losing visibility. And do not read continued old-property performance as evidence that the redirects are live. Redirect operation is tested directly, against phase 2's recorded dispositions, and a quiet old property is not by itself a sign that anything broke.

A flat line on the new property has several possible causes, and they are worth separating rather than assuming. Documented A newly added property is not instantly populated: Data collection for a property starts as soon anyone adds the property to their Search Console account, even before verification, and Data should begin to appear in your property in a few days. So check, in order: the property type and URL scope - Documented a domain property Includes all subdomains (m, www, and so on) and multiple protocols (http, https, ftp) while a URL-prefix property Includes only URLs with the specified prefix, including the protocol (http/https); the date the property was added; the report's last-updated date; your launch date; and whether the destination URLs had any Search activity at all in the period you selected. Record which of those applies. A newly launched destination with no pre-launch history is a different fact from a property added yesterday, and both are different from a real problem.

Day 30 is a reporting date, not a verdict

Nothing in Google's documentation makes thirty days meaningful. It is a management interval, chosen because it is long enough for the expected shapes to appear and short enough to keep a named owner engaged. Documented Google's own framing is that processing can take a few weeks for most pages to move, and larger sites take longer - so a site that has not finished at day 30 may be entirely normal.

Say that in the report explicitly. The alternative is a stakeholder who reads a thirty-day document as a result and asks why the migration failed, when what the document shows is a migration still being processed.