Short answer: after a migration a site usually disappears for one of five reasons: a noindex left on from staging, a staging robots.txt with Disallow: /, redirects that are missing or point to the wrong place, canonical tags or a sitemap that still name the old URLs, or a firewall that blocks Googlebot. Google itself says a move takes "a few weeks or more" for a medium-sized site to settle, so some fluctuation is normal. A sudden drop to near zero is not, and the checklist below finds the cause in under an hour.
Is the drop normal, or is something broken?
| What you see | Likely meaning |
|---|---|
| Clicks down by a third for a few weeks, impressions roughly stable | Normal settling after a move; keep monitoring |
| Impressions fall towards zero within days | Something tells Google not to index or not to crawl: start with items 1 to 3 below |
| Search Console fills with "Excluded by 'noindex' tag" | A noindex went live with the site |
| "Blocked by robots.txt" or "Indexed, though blocked by robots.txt" everywhere | The staging robots.txt went live |
| "Page with redirect" and "Not found (404)" on the new URLs | Redirect map errors; the new addresses themselves redirect or 404 |
| "Blocked due to access forbidden (403)" or "Server error (5xx)" | The host or a firewall is refusing Googlebot |
The checklist
- Is the new site noindexed? View the source of the home page and search for
noindex. Then check the response headers withcurl -Ifor anX-Robots-Tag, because a header noindex never shows in the CMS; the free noindex checker does both steps and reads every redirect hop. In WordPress, Settings → Reading, untick "Discourage search engines from indexing this site". Google's own site-move guide lists a leftover noindex as one of the mistakes it sees most. - Does robots.txt allow crawling? Open
https://your-site/robots.txt. A staging file withDisallow: /is another mistake Google's guide lists. Replace it with the production file and keep theSitemap:line. - Can Googlebot fetch the site at all? In Search Console, URL Inspection, "Test live URL" on the home page. A failed fetch means a firewall, bot protection or the host is blocking Google. Google's guide for moves without URL changes warns about exactly this: firewalls and denial-of-service protection that block Googlebot after a change of hosting. A Cloudflare setting is a common case; our free Cloudflare check reads the robots.txt and headers for you.
- Do the old URLs redirect, once, to the right new URL? Take ten old addresses from the old sitemap and fetch each one. Google asks for 301 or 308 redirects straight to the final page, no chains, and says to keep them for at least a year. Google also says not to send many old pages to one unrelated page such as the home page; those pages lose the rankings they had.
- Do canonical tags and the sitemap name the new URLs? A canonical that still points at the old domain tells Google the new page is a copy. Submit a sitemap that lists only new, 200-status URLs, and remove the old one.
- Did you tell Google about the move? For a change of domain, use Settings → Change of address in the old domain property, after the redirects are live. It is not for HTTP to HTTPS, www changes or new paths; those need only redirects. Google treats the sites as related for 180 days.
- Is the HTTPS certificate valid on every hostname? Including the old domain, so that the redirects from it still work for a year.
- Are internal links updated? Links that go through a redirect still work, but Google recommends pointing them at the final URL.
How long does recovery take?
Google's guidance for a site move with URL changes says the move "can take a few weeks or more" for a medium-sized site, longer for larger ones, with fluctuations in the meantime. That is the healthy case. If the cause was a noindex or a robots.txt block, recovery starts when Google recrawls after the fix: a page requested in URL Inspection comes back in days, a whole site over the following weeks as crawling catches up. Validation of a reason in the Page indexing report typically takes up to about two weeks.
Which Search Console reasons are not problems?
Two reasons look alarming after a migration and are usually fine. "Page with redirect" means the old URL is a non-canonical address that redirects somewhere else, which is what you want; check the target is the new page. "Alternate page with proper canonical tag" means the page points at the indexed canonical correctly. "Not found (404)" is fine for pages you removed on purpose, and a problem for pages that moved; those need a 301.
How do I make sure nobody finds out from the client?
Most of the causes above are a single line somewhere: a meta tag, a header, a robots.txt rule. They are easy to fix and easy to miss, and they tend to be noticed weeks later when the traffic report lands. quietwatch checks noindex, robots.txt, the sitemap and crawler access on each client site every day and emails only when something changes, so a staging rule that goes live on Friday is in your inbox on Saturday. You can check a site for free before and after the migration.