The 90 days after a migration: what to monitor, and how often.

After a site migration, redirect errors and new 404s are monitored daily in the first week, indexing and impressions weekly in the first month, and old and new addresses are compared at the end of the third month; the redirects stay in place for at least a year. The point of monitoring is not to wait for rankings but to catch, early, every address missed on launch day.

A migration seems finished on launch day: the new site goes live, the redirects work, the team relaxes. But Google does not learn the new addresses in a day. Google’s site move documentation says that for a medium-sized site it can take a few weeks or longer for the new addresses to replace the old ones, and that rankings may fluctuate in the meantime. During those weeks, you can only see that something has gone wrong by reading the right report at the right frequency. That is why monitoring is the last section of the migration checklist and a delivered part of site redesign and migration work.

What should you measure on launch day?

Launch day has one job: testing the map live, line by line. Three questions are asked for each old address: is the code of the first response correct, is the address reached at the end of the chain the one in the map, does the destination page return 200? Google’s documentation also recommends verifying redirects on sample addresses with the URL Inspection tool. Add to this submitting the new sitemap and confirming that the search engine blocks left over from the staging environment have been removed.

Why should a redirect check look at the destination address?

We learned this on our own site in three steps. On September 10, 2026, our live verification tool was following redirects and reporting the 200 at the end, and it showed a working redirect as broken. When we changed it to read the first hop, the hop it caught this time was not our redirect but the first hop from the non-www address to the www address. The rule that came out of both: the right measure is the end of the chain.

The second lesson came on September 22, 2026, and it was quieter. For an address expected to return 200, the tool looked only at the final status code. In production, that address went to another page with a 301; because the destination page returned 200, the tool counted the line as “passed.” In other words, a redirect going to the wrong place showed up green. Since then, the destination address is tested on every line too, and the destination of a redirect line must actually differ from the requested address — if the redirect had never been set up, the destination would be the same as the requested address and the line would have passed silently.

The status code says the redirect works; only the destination address says it goes to the right place.

What should you check every day in the first week?

• Search Console › Page indexing: new addresses on the “Not found (404)” row. Every new 404 after a migration is a row forgotten in the map; handle it with the decision order from the 404 error guide.
• The “Redirect error” row in the same report: an overly long chain, a loop or an empty target. Why chains are kept short is explained in the redirect chain entry.
• The “Soft 404” row: error pages that return 200, or old addresses redirected in bulk to the homepage (soft 404).
• Server errors. According to Google’s documentation, 5xx responses cause Google to temporarily slow down crawling; if the new server throws errors under load during migration week, the discovery of the new addresses is delayed.
• The sitemaps report: is the submitted sitemap being read, is the number of discovered addresses close to what you expect?

What should you check every week in the first month?

• Impressions of old and new addresses in the performance report. The expected picture: impressions for the old ones decrease, those for the new ones increase. If both fall together, look at the content of the new pages as well as the redirects.
• The number of indexed pages. Are the new addresses getting indexed, are the old addresses moving to the “Page with redirect” row? Search Console’s help page defines this row as an expected state: the redirecting address is not indexed.
• The “Crawled - currently not indexed” row. An increase on this row is usually a content question, not a redirect question.
• Manually retest the destinations of the twenty or thirty old addresses with the most traffic and links.
• If the domain changed, monitor both properties together; the change of address notice is visible in both properties for 180 days (domain change guide).

What do you compare at the end of three months?

At the end of the third month, compare with the period before the migration: total impressions and clicks, the number of indexed pages, the 404 and redirect error rows. The comparison should use two windows of the same length; for a seasonal business, the same period last year is a fairer comparison. By this point, the remaining 404s should have been decided one by one, and important sites that link to you should have been told the new address. There is no guarantee that Google’s recrawl, which can take weeks or even months, will be finished by this date; 90 days is the end of the monitoring schedule, not of the process. The comparison is written up as a report and kept together with the redirect map.

How far behind are Search Console reports?

Reports are not real-time, and this is the most easily forgotten rule of monitoring. When this site started getting indexed, Search Console showed 10 pages as indexed on August 14, 2026, and 57 a day later. On August 22, the same report showed 13 pages on the “Crawled - currently not indexed” row; the diagnosis was thin content, as none of the site’s pages exceeded 800 words that day. In the September export, the breadcrumb report showed an error for an unnamed item, yet none of the pages generated that day had this error: the report was describing an old crawl. After a fix, starting the report’s “Validate fix” step is faster than waiting for the report to update.

If you had the migration done for you, what should you ask?

If you had an outside team carry out the migration, you are entitled to see the results of the monitoring, and a few questions show whether the work was really done:

• Do we have the old address list and the redirect map, and in which file?
• Is there output from the launch-day verification: the status code and destination address for every line?
• Whose list are the 404s that appeared after the migration on, and what was decided for each one?
• On which server or in which settings screen do the redirects live; how will they be moved if the infrastructure changes again in the future?
• Who has access to Search Console; until when will the old domain’s property and registration stay open?

If the answers to these questions are a table and a file name, the migration is in a state that can be monitored. If the answer is “no problem, it works,” monitoring has not started yet.

When can redirects be removed?

Google’s site move documentation recommends keeping redirects in place for as long as possible, generally at least a year; the reasoning is that it takes time for old links on other sites to be recrawled and passed on to the new addresses. For a domain change, the Search Console help page says at least 180 days, and longer as long as traffic keeps coming from Google Search. In practice, the longer of the two is the baseline. The cost of keeping a redirect in place is low; unless there is a concrete reason to remove it, do not.

Does Bing need anything separate?

The same redirects work for every search engine; no separate map is needed. There is a way to notify Bing and other engines that support IndexNow of changed addresses directly: this site reports its addresses via IndexNow after every deployment. How it is set up is explained in the IndexNow and Bing guide.

If you don’t want to lose traffic while relaunching your site, website redesign and migration inventories the old addresses, builds a chain-free 301 map and monitors the site for 90 days after the move.