What to check in the first month after a site migration

The hours and weeks after a migration are when small faults become expensive. A noindex left on one template, a redirect rule that only half deployed or a server struggling under the extra crawl can all be fixed in an afternoon if someone spots them early. Spotted a month later, they have cost a month of traffic. This is the schedule I would follow, and the evidence I would use to decide whether a drop needs fixing or patience.

It picks up where launch day ends. The planning, the redirect map and the launch checklist are covered in the website migrations guide.

On launch day the only useful question is whether anything is blocking Google from the new site or from the redirects. Remove any noindex or robots.txt blocks that were only needed for the migration.¹ Check the live robots.txt by hand, then check several templates for a noindex. Look at the HTML and the response headers, because a noindex can be sent as an X-Robots-Tag HTTP header and never appear in the page source.²

• Run the full old URL list through a crawler against production. Every moved URL should return a single 301 or 308, the two status codes the HTTP standard defines as permanent redirects, to its mapped destination.³ Screaming Frog’s SEO Spider, for example, can follow each one to its final destination and export the hops and loops.⁴
• Request the top pages with a Googlebot user agent and with a normal browser. Bot protection or a firewall rule on new infrastructure can treat the two differently. It can also treat the real Googlebot differently from your test: Cloudflare’s bot rules, for example, let verified bots such as Googlebot skip custom challenges,⁵ which a request you send with a Googlebot user agent will not count as. Confirm in the logs that genuine Googlebot requests are getting 200s and 301s.
• Run a live test in the URL Inspection tool on a few new URLs. It fetches the page in real time, though a passing live test does not guarantee indexing.⁶
• Submit the new sitemap and the sitemap of old URLs. Redirect warnings on the old URL sitemap are expected and can be ignored.¹
• For a domain change, tell Bing as well, through the Site Move tool in Bing Webmaster Tools.⁷
• Confirm analytics and conversion tags fire on every template. Missing tracking looks like a traffic collapse.

Also watch the server. Google crawls a moved site more heavily than usual for a while, so the new site needs the capacity to cope.¹

In the first week, judge the move on process. Ask whether Google is finding the redirects, following them and indexing the new URLs. Rankings and clicks will move about during this period, and temporary fluctuation in visibility is expected.¹ The migration guide on Bing’s webmaster blog is blunter: even the best planned migration brings fluctuations and likely a temporary decline in visibility.⁷

Page indexing report

The indexing graphs should show indexed URLs falling on the old site and rising on the new one.¹ In the old property, expect old URLs to move into "Page with redirect". In the new property, look at the reasons for pages not being indexed, and filter by the new sitemap so you are only looking at URLs you want indexed. The report can be filtered to all submitted pages or to a single sitemap.⁸ These reasons each point to a specific fault after a migration:

The Sitemaps report helps here too. It shows whether each sitemap was fetched and read successfully, and links through to indexing status for the URLs in that sitemap.⁹ Compare the old URL sitemap with the new one over time: at first the new sitemap has few pages indexed and the old one has many.¹

Crawl Stats report

The Crawl Stats report breaks crawl requests down by response code, file type, purpose and Googlebot type, and shows host status for robots.txt fetching, DNS and server connectivity.¹⁰ Most responses should normally be 200, but during a move a large share of 301 or 308 responses is what you want to see.¹⁰ The purpose breakdown separates discovery of URLs Google has never crawled before from refreshes, so you can see whether Google is discovering the new URLs. The report is only available for root-level properties.¹⁰

Server logs

Logs are the closest you get to watching Googlebot work in real time. Filter to verified Googlebot requests first. User agents can be spoofed, so confirm requests with a reverse DNS lookup or against Google’s published IP ranges.¹¹ Log tools can do this in bulk. Screaming Frog’s Log File Analyser checks Googlebot and Bingbot against their published IP lists, and its documentation notes that a load balancer or CDN such as Cloudflare can hide the real client IP unless the log format records it.¹² The migration guide on Bing’s blog suggests checking the logs daily for at least three months after the move.⁷ Then look at three things.

• Old URLs requested by Googlebot and the status they return. They should be 301s or 308s. Any 404 for a URL that had traffic or links is a gap in the map.
• New URLs being requested and returning 200. If Googlebot is following redirects but not yet requesting the new URLs directly, give it time. If it is not requesting them at all after a week, check internal links and sitemaps.
• Any 5xx or 429 responses. These make Google’s crawlers slow down, and indexed URLs that keep failing are eventually dropped.¹³ A 429 means the server is rate limiting the client,¹⁴ so check whether a new bot or rate-limit rule is catching crawlers.

From the second week, start comparing performance with the benchmark, template by template. Search Console assigns clicks and impressions to the canonical URL Google selects for each page.¹⁵ As the new URLs become canonical, their numbers should rise as the old URLs’ numbers fall. Compare the totals for each template across both properties, so a category template on the new site is set against the same template on the old one.

For context, look at the last 16 months in the Performance report and compare the last three months with the previous period or with the same period a year earlier.¹⁶ That separates a migration effect from seasonality you would have seen anyway.

If you fix a problem the Page indexing report flagged, use Validate fix. Validation typically takes up to about two weeks, and can take longer.⁸

Some movement is expected. Site moves are one of the listed causes of traffic drops, and changing the URLs of existing pages can bring ranking fluctuations while Google recrawls and reindexes the site.¹⁶ A medium-sized site can take a few weeks or more for Google to start showing the new URLs instead of the old ones, and larger sites even longer.¹ That is all the timeline Google gives, and it is about URLs, not traffic. The published traffic data is less comforting. SALT.agency’s 2026 study of 1,052 domain migrations, some its own and the rest crowdsourced from other SEOs, found a median of 304 days for the new domain to match the old one’s pre-migration organic traffic, with roughly one in four getting there within 90 days.¹⁷ It covers domain changes only and does not analyse which practices sped recovery up, so it says little about any one site. I would treat anyone offering a precise recovery date with suspicion.

It helps to separate a small drop in position, such as moving from position 2 to 4, from a large drop, such as falling from the top 10 to position 29 across a wide range of terms.¹⁶ Small shifts across the site in the first weeks fit normal fluctuation. Large drops concentrated in one part of the site need investigating.