What to monitor after a site migration

The first days after a site migration can feel noisy as rankings move, traffic changes and Search Console begins to report old and new URLs. Some movement is expected while search systems revisit the site, while other changes point to faults that need quick action.

The useful question isn’t simply ‘Has traffic fallen?’ It’s ‘Which signal first stopped matching the migration plan?’, which requires a clear order of checks to answer.

Read migration signals in order

A migration creates a chain of dependencies. Search systems must reach the old URL, follow its redirect, then receive and crawl the intended new page before deciding how to index it. Visibility can change only after those earlier steps.

This order matters because the four groups don’t move at the same speed. Server responses can be checked as soon as the migration goes live. Crawl and indexing data arrive later. Rankings and organic visits sit furthest from the technical change, so they usually need more context.

Start with the earliest reliable evidence and move forward only when that layer looks healthy.

Establish the baseline before launch

Post-migration monitoring is easier when the expected result is written down first, so record which URLs will move, where each one will land and which pages should remain indexable.

At minimum, keep:

• A list of important old URLs and their intended destinations.
• Pre-launch response codes, canonicals and indexability rules.
• XML sitemap counts for each important page type.
• Search Console clicks, impressions and indexed-page trends.
• Organic sessions and useful actions by landing-page group.
• Crawl data for the old and new hosts, where logs are available.

Group pages by template or purpose rather than watching only the site total because product pages, guides and location pages may behave differently after the same migration. A steady total can hide a broken section, while a small decline can look worse than it is when low-value URLs were removed on purpose.

The redirect map is part of this baseline, and every important old URL should have a clear outcome. A moved page needs the closest matching new destination, while content with no replacement should return 404 or 410 rather than being sent to an unrelated page. Google’s site move guidance recommends permanent redirects for moved canonical URLs and clear error responses when content has been removed.

Layer 1: redirects and responses

Redirects provide the first live evidence because you can test them at once, so sample the whole redirect map with extra attention on high-traffic pages and every major template.

Check that:

• Each old URL returns one permanent redirect to the intended new URL.
• Redirects preserve useful paths and parameters where required.
• The final page returns the expected 200 response.
• There are no loops, chains or unexpected hops.
• Removed pages return the planned 404 or 410 response.
• Canonical links on new pages point to the final preferred URL.

Status codes alone aren’t enough because a 301 can lead to the homepage, a soft 404 or the wrong locale. Save the final destination and response body so a valid redirect can’t hide a poor mapping.

Watch server errors and response time as well. A migration can increase crawler demand just as new infrastructure is settling. Google notes that it may crawl the new site more heavily after a move. A rise in 5xx responses or timeouts at this point can slow the transfer of signals.

If this layer fails, pause deeper diagnosis. Rankings can’t explain a redirect that points to the wrong place.

Layer 2: crawling

Once redirects and final responses are sound, check whether search crawlers are finding and revisiting the new URLs.

The Crawl Stats report can show request volume, host availability, response codes and response time. It’s useful for trends, although its example URLs aren’t a complete list of every request, while server or CDN logs provide more detail when they’re available.

Look for a shift from old URLs towards new ones. Requests to the old site should continue because redirects must be discovered and refreshed, while requests to the new site should grow across the important page groups.

Investigate patterns such as:

• Googlebot repeatedly reaches old URLs but rarely requests their destinations.
• Important new sections receive little or no crawl activity.
• Crawl volume rises alongside slower responses or more server errors.
• Robots.txt, firewall or CDN rules block the new host or key resources.
• Internal links and XML sitemaps still favour old URLs.

A lack of crawling doesn’t automatically mean the site needs more submission tools. First check discovery. New URLs should appear in updated sitemaps and ordinary crawlable links. IndexNow can notify participating search engines about changed URLs, but notification doesn’t guarantee crawling or indexing.

Layer 3: indexing and canonical selection

Indexing evidence becomes useful after crawlers have reached the new pages. The aim isn’t to make every URL indexed, but to confirm that important canonical pages are replacing their old versions in a sensible pattern across each page group.

Use the Page Indexing report for site-level trends and URL Inspection for important examples, then compare declared canonicals with Google’s selected canonicals and check whether old URLs are dropping out while their intended replacements appear.

The following patterns deserve investigation:

Observation	What to check next
Old URLs remain indexed	Confirm the redirect is permanent, direct and stable.
New URLs are crawled but not indexed	Review canonicals, robots rules, duplication and content returned to Google.
Google selects an old or unrelated canonical	Compare internal links, sitemap entries, redirects and page similarity.
One template lags behind the others	Test its rendered HTML, indexability rules and shared dependencies.
Indexed counts fall after planned removals	Compare the change with the migration inventory before treating it as a fault.

Immediate replacement isn’t expected. Google’s documentation says indexing can take days or weeks, while its traffic-drop guidance says a medium-sized site may take a few weeks to move in Google’s index. Larger sites can take longer, so treat these figures as context rather than deadlines.

Layer 4: visibility and outcomes

Clicks, impressions, rankings and organic sessions matter, but they are lagging signals. They reflect the combined effect of crawling, indexing, demand, competition, layout changes and measurement choices.

Use Search Console as the main source for Google Search performance and analytics to understand what visitors did after reaching the site. Google explains why clicks and sessions differ, which is why exact agreement between the two systems isn’t a useful success test.

Compare trends by page group, query type, country and device, keeping brand and non-brand demand separate where possible. A new site structure may change which pages earn impressions even while the total remains stable.

Watch for:

• A broad decline that follows crawl or indexing failures.
• A sharp loss isolated to one template or directory.
• Impressions recovering while clicks remain lower because query mix changed.
• Stable Search Console clicks but fewer analytics sessions, which may point to tracking or consent changes.
• Traffic reaching the new pages without the expected enquiries, sales or other useful actions.

Visibility is most helpful when linked back to earlier evidence. A page group with healthy redirects, crawling and indexing needs a different investigation from one that search engines can’t reach.

Use a time-aware triage view

Not every signal should trigger the same response on the same day, so record the observation first and then note how far it sits from the migration itself.

Signal	Earliest useful check	Strong reason to investigate
Redirect destination	Immediately	Important URLs land on the wrong page, loop or fail.
Final response	Immediately	New pages return persistent errors, challenges or empty content.
Crawl activity	After bots can revisit the change	Important sections remain undiscovered or host errors rise.
Indexing and canonicals	After crawling begins	New canonical pages stay excluded or old URLs remain preferred.
Search visibility	As recrawling and indexing progress	Losses persist in a clear page or query group and align with an earlier fault.
On-site outcomes	Once visits reach the new pages	Users arrive but key actions fall because journeys or tracking changed.

This table doesn’t set fixed recovery times; it sets a diagnostic order. The right response depends on site size, crawl demand, migration scope and the effect a fault has on important pages.

Keep redirects and ownership signals in place

Monitoring shouldn’t stop as soon as new URLs appear in search. Redirects must remain stable while users, links and search systems continue to request old addresses.

For domain moves, Google’s Change of Address guidance says redirects should stay in place for at least 180 days. Keep them longer while they continue to receive traffic. Google also recommends keeping the old domain for at least a year. The Change of Address tool is meant for domain or subdomain moves. It doesn’t apply to every type of migration.

Keep both old and new Search Console properties verified, then check links, referral traffic and crawl requests to the old site before deciding a redirect is no longer needed.

Find the first broken signal

A migration dashboard can contain dozens of charts without providing a diagnosis, so a smaller set of ordered signals is often more useful.

When a result looks wrong, trace it backwards: if visibility fell, check indexing; if indexing stalled, check crawling; if crawling didn’t move to the new URLs, check redirects, discovery and responses. Stop when you find the first layer that doesn’t match the plan.

This approach doesn’t remove doubt, but it narrows it. You can watch expected movement without panic while keeping genuine faults tied to the earliest evidence that can explain them.