First 30 Days After a Site Move: A Monitoring Plan

After a site move, the first month is a monitoring exercise with one aim: separate temporary movement from a fault you can fix. Traffic will move. The question to ask each week is whether you can point to specific URLs, status codes or server problems that explain it. If you can, act. If you cannot, keep watching on a schedule instead of changing things at random. If you have just changed domains, hosting or URL structure, or you run the move for a client and the client is anxious, a weekly plan turns anxiety into a checklist.

What the first month looks like

Google's documentation on site moves with URL changes (Opens in a new tab) tells you to expect temporary fluctuation in how the site ranks during the move, and says visibility in Search may change for a while. For a medium-sized site, it says, it can take a few weeks or more before Google gradually starts showing the new URLs; larger sites take longer. The page also says that for the move to count as complete, Googlebot has to visit every URL on the old and new site at least once.

Two conclusions follow. A dip in the first days is not proof that something broke. And a quiet week with no recovery does not prove the move failed, because the page gives no fixed number of days and no guarantee. Check the current page before you present timing to anyone. Google's documents change.

The question that separates the two cases

Practical suggestion: ask whether you can produce a list. A list of old URLs that redirect to the wrong place, new URLs that return 404, pages blocked by robots.txt, requests that end in 5xx. A list means a fault. No list, and only a falling total on a chart, means you are still in the watching phase.

Before the move: the baseline you will compare against

Monitoring is comparison. Without a starting point the charts after the move have no meaning. Collect these before the switch:

• A Search Console export or screenshot of clicks and impressions, plus the list of pages that bring in the largest share of traffic.
• A screenshot of the Crawl Stats report with average response time and the response code breakdown.
• The full list of old URLs and the new address of every important one.
• A sample of Googlebot requests from the server logs.
• Daily visitor counts from your analytics.

Note the calendar as well. If the move lands in a campaign week or a holiday, later dips may come from the calendar and not the move. Google suggests timing a move for lower traffic where possible, since fewer users are affected and the server has more capacity for Googlebot. For preparation, the website migration guide lists the steps that come before the switch.

Reading Crawl Stats after a move

Google's Crawl Stats help page (Opens in a new tab) describes a report of Google's crawling history for your site: how many requests were made, when, what the server answered, and whether there were availability problems. It is available only for root-level properties (a Domain property or a root URL-prefix property), and the page says it is aimed at advanced users. Our own Crawl Stats report guide covers reading it in more depth. If your interface labels differ from these names, the interface may have changed.

Totals, download size and response time

Total crawl requests counts all requests for your URLs, successful or not, including failed DNS or connectivity attempts, redirect loops that were abandoned, and crawls that were never made because robots.txt was unavailable. Average response time is the mean across all resources fetched in the period. After a hosting move, a slower new server shows up here before it shows up in anyone's complaints.

Host status and its three categories

Host status shows whether Google ran into availability problems in the past 90 days. It has three levels: no significant issues, issues more than a week old, and a recent issue within the last week. Three categories feed it.

• robots.txt fetching. A 200 response (even an empty file) or a 403, 404 or 410 counts as successful; a 429 or any 5xx counts as unsuccessful. According to the page, after 12 hours of failures Google pauses crawling, from 12 hours to 30 days it uses the last good file, and after 30 days the behavior depends on whether the homepage is available.
• DNS resolution. Problems arise when DNS does not recognize the hostname or does not respond.
• Server connectivity. Problems arise when the server is unresponsive or sends an incomplete response.

After a move, these three categories map onto the three places where moves break: the new site's rules, the DNS switch, and the new server.

Responses, purpose and Googlebot type

The page groups responses. 200, 301 and 308, 302 and 307, other meta-refresh redirects and 304 are good; 404 is possibly good because it may be intended; robots.txt unavailable, 401 and 407, 5xx, other 4xx, DNS failures, fetch errors, timeouts and redirect errors are bad. Expect the redirect share to rise after a move. A growing bad share deserves a look. Crawl purpose separates Discovery, for URLs Google has never crawled, from Refresh, for recrawls of known pages. Practical suggestion: read a rising Discovery share in the first weeks as new URLs being found. The page gives no ratio to expect after a move. Googlebot type separates smartphone, desktop, image, video and other agents.

The right-hand column is practical reading, not a threshold published by Google; the page gives none.

Server logs: what the host sees that Google does not report

Crawl Stats shows what Google experienced; logs show what your server experienced. Google's documentation on site moves says to check server access and error logs for Googlebot crawling and unexpected HTTP error codes, and the hosting-move page says to watch the logs of both the new and the old server. Totals in Crawl Stats can exceed log totals when robots.txt was unavailable for too long, because Google counts crawls it might have made. If the two do not agree, check that first.

In the logs, look for the status codes Googlebot receives, URLs that return 404 again and again, how many steps each redirect chain takes, and response times against the old server. Do not trust the user agent string alone to identify Googlebot. For what each code means, use the HTTP status codes guide.

The first 72 hours

In the first three days, ask whether everything works, not whether traffic is up.

1. Open the important old URLs and confirm each reaches its new address in a single step.
2. Confirm the new site's robots.txt is reachable and does not block everything by mistake.
3. Confirm the sitemap lists the new URLs and is valid.
4. Read the logs for 5xx codes and unexpected 404s, and note the URLs.
5. After a hosting change, check DNS propagation with several public DNS lookup tools.

The documentation for moves without URL changes (Opens in a new tab) adds details for hosting moves. It says to lower DNS TTL to a conservative value, for example a few hours, at least a week in advance, so new settings reach ISPs sooner. It says to keep the old hosting running until its traffic falls to zero, and to shut it down only once you are confident every user, Googlebot included, gets correct content from the new infrastructure. And it describes a temporary drop in Googlebot's crawl rate right after launch as normal, followed by a rise over the next few days, possibly higher than the earlier level, because crawl rate depends on signals that change with hosting. The page gives no fixed retention period for the old server. The hosting change checklist turns this into steps.

A five-minute daily check

For the first three days, run the same check daily and write one line: do the home page and two key pages open, does one old URL reach the right place, is robots.txt reachable, are there new error clusters in the logs, is host status clean? A written record turns "when did this start" from a guess into an answer.

A week-by-week plan

Google gives no schedule that says what should have happened in which week, so no numeric thresholds are given: watch direction and order.

Old site, new site: traffic and redirects

The site-move page says you should expect traffic to drop on the old site and rise on the new one. If the old site falls and the new one does not rise, look at the redirects. The same page says sitemap warnings about redirecting old URLs are normal and can be ignored.

Redirect questions to ask: does each old URL reach its new equivalent in one step? Are pages with no equivalent being swept to the home page? Do the new pages return 200? The page says to keep the redirects for as long as possible and names at least one year as its benchmark; it also notes that redirects slow users down, so update links where you can. Protecting link equity is a separate task; see preserving backlink value during a migration.

Page groups instead of totals

A total compresses very different parts of a site into one line. Practical suggestion: split the site into four or five groups and watch them separately. If one group is healthy while another lags, the problem is in a URL pattern. If every group falls together, suspect server or crawl access.

Two kinds of move, two sets of watch points

Google publishes separate guidance for moves that change URLs and moves that do not, and the monitoring emphasis differs.

A move that does both, a new host and a new URL structure, needs both columns. Run the checks from each, and keep a note on which change a symptom belongs to. Mixing the two without notes is how a simple DNS problem gets blamed on a redirect map.

Questions to settle before launch day

• Who reads the logs on launch day, and on which server?
• Who may change redirect rules in the first week, and how is a change recorded?
• Which two pages stand in for the whole site in your daily check?
• Who tells the client that a short dip is expected, and which Google page do they cite?
• When will the old server be switched off, and who confirms its traffic is zero?

Settling these in advance costs an hour. Settling them during a drop costs a day of confused messages, because nobody wants to touch a rule that might make things worse.

The second pass: links, canonicals, sitemaps and assets

Updating the profiles and listings you control reduces dependence on redirects. Links on other people's sites cannot be edited by you, so the redirects must stay in place. If the move came with a redesign, finish the work in the website redesign SEO checklist first, otherwise two causes of a traffic dip blur together.

Example scenario: an antique shop that only changed hosts

Example scenario: a small antique shop kept its domain and URLs but moved to a faster host. Under the no-URL-change documentation it lowered TTL a week ahead, kept the old server running, and watched logs on both machines. On launch day Googlebot's crawl requests dipped, and the owner worried. The documented pattern said a short dip is normal. Three days later requests had climbed, but Crawl Stats showed one wrinkle: a growing number of 5xx responses on the product image folder, which had not been copied to the new server. That was a list, so it was a fault. The folder was copied, the errors stopped, and the old server was switched off only after its traffic reached zero.

A fortnight later the owner saw impressions wobble on the porcelain category with no errors in any report. This time the decision was to wait and recheck weekly. The difference between the two cases was whether there was a list of URLs.

Intervene or wait: decision rules

Decision rule: if you can show a list of URLs, act; if you cannot, record and recheck each week. No percentage or day count is attached, because the documents publish none.

Recrawl requests and reporting

For a few important pages, URL Inspection and a recrawl request can be used, although it is not a speed button. Updated page recrawl, URL Inspection and sitemaps explains which tool fits which situation. Pick two pages to track: the top page on the old site and an ordinary page in the new structure.

For a client or manager, a one-page weekly report is enough: checks made, faults found and their status, items under watch and why. Do not write "traffic fell" without saying which pages, which source and which comparison. Change one thing at a time, so you can tell which fix worked.

Keep one more habit in mind through the month: write down every decision to wait. A note such as "total clicks wobbling, no fault list, recheck Friday" shows later that waiting was a decision and not neglect. If a fault shows up in the meantime, the note also shows what you knew at each point, which helps when a client asks why nothing was changed earlier.

Tempting conclusions and what to check first

Anxiety pushes people toward the scariest reading of a chart. Pair each tempting conclusion with the check that tests it.

When the answer is still unclear

Practical suggestion: if a symptom fits two rows, run the cheaper check first. Opening five old URLs and reading the redirect target takes minutes; waiting a week to learn the same thing does not. Record which check you ran, what it showed and when you will look again, so the next person does not repeat it.

Decision rule: a conclusion is allowed only when a check supports it. Until then the entry in your notes reads "watching", with a date.

Checklist for the month

• Baseline records were taken before the move.
• Single-step redirects for key old URLs were verified on day one.
• robots.txt and sitemap were verified on the new site.
• Logs of the old and new server are watched together.
• Host status is read across its three categories.
• Old and new traffic are tracked side by side, by page group.
• Faults with a URL list are fixed at once and watch items are reviewed weekly.
• Redirects are planned to stay for at least a year, and longer where possible.

Frequently Asked Questions

Is a traffic drop after a move normal?

Google's site move page tells you to expect temporary fluctuation during the move. It gives no guarantee on duration, so check specific URLs for faults as well.

How long does a move take?

For medium-sized sites it can take a few weeks or more before the new URLs start to show gradually, and longer for larger sites. The move counts as complete when Googlebot has visited every URL on the old and new site at least once.

Is an early drop in crawling a problem?

The documentation for moves without URL changes calls a temporary drop in crawl rate right after launch normal, with a rise over the following days. If 5xx errors climb at the same time, check the server.

My sitemap shows redirect warnings. What should I do?

According to the move page, sitemap warnings about redirecting old URLs are normal and can be ignored.

How long should I keep the redirects?

The page says to keep them as long as possible and names at least one year as its benchmark.

Do all properties show the Crawl Stats report?

No. According to the help page, it exists only for root-level properties, meaning a Domain property or a root URL-prefix property.

Conclusion

Split the thirty days into weeks. Start with access and redirect health in the first three days, then the index and fault list in week one, then old and new traffic and key pages in the following weeks. Act at once on anything you can show with a list of URLs, and treat unexplained wobbles as the temporary effect the documents describe, rechecking weekly.

To bring quality links to the new addresses of a moved site, take a look at our guest post service.