What to monitor after a site migration
Site migration SEO monitoring means checking, from launch day until Google has recrawled every old and new URL, that redirects resolve in one hop, new URLs are indexed with the canonical you chose, sitemaps are being read, and clicks move from old URLs to new ones instead of leaking away. In Google Search Console that means URL Inspection, the Sitemaps and Page indexing reports, and page-level Performance comparisons; in Bing Webmaster Tools, crawl stats and HTTP status counts. Watch daily for the first week, weekly for the first two months, and keep checking until old URLs have dropped out of the index.
What you monitor depends on the type of move. Google’s site move guide covers moves with URL changes; a hosting or CMS change that keeps every URL the same follows a separate, much lighter process.
| Migration | Search Console | Change of Address? | Bing Webmaster Tools |
|---|---|---|---|
| Domain move (example.com → example.net) | New property; keep the old one verified | Yes, from every variant of the old domain | New site to add and verify |
| HTTP → HTTPS | A Domain property covers both; URL-prefix users need an https:// property | No | Same property; Bing doesn’t separate http and https |
| URL restructure or replatform that changes URLs | Same property | No | Same site |
| Hosting, CDN or CMS change, URLs unchanged | Same property | No | Same site |
If you can, follow Google’s advice to change one thing at a time. A domain move, a new CMS and a new information architecture shipped together make it very hard to tell which change caused a problem.
What you still do by hand
Our hosted Google Search Console MCP server is read-only. It can read Search Console and Bing data for an AI assistant, but it cannot change anything, so several migration steps stay manual:
- Change of Address (domain moves only): Settings → Change of address in the old property. Per Google’s Change of Address help, you must own both properties with the same Google account, the tool works only on domain-level properties, it doesn’t move subdomains (including www), and it runs pre-move checks before submitting.
- Submitting sitemaps in Indexing → Sitemaps (owners only).
- Live tests and Request indexing in the URL Inspection tool. The API behind our
inspect_urlreports Google’s indexed version only; it can’t test the live page. - The Crawl stats report (Settings → Crawl stats). It isn’t in the Search Console API, so check its response-code breakdown by hand.
- Testing redirects at scale with a crawler or a script that requests every old URL and checks for a single 301 or 308 to the right destination.
- Bing: adding the new site, submitting its sitemap and sending IndexNow pings.
On a domain you bought, also check the new property’s Manual actions and Removals reports for leftovers from the previous owner, and re-upload any disavow file to the new property, as Google recommends.
Before launch: save a baseline
Every later question (“is this normal?”) needs a fixed point to compare against. Search Console keeps 16 months of data, and after a domain move your history stays in the old property, so take a snapshot in the week before launch.
Before we migrate example.com, build a baseline. Use multicall to run get_search_overview with provider all and range 90; get_search_pages with provider google, range 90 and limit 1000; get_search_queries with provider google, range 90 and limit 1000; list_sitemaps with provider all; and get_bing_crawl_stats with range 90. Summarise normal daily clicks by weekday (median and range), normal daily Bing 4xx and 301 counts, and list the top 500 pages by clicks with clicks, impressions and position.
In Claude Code, Cursor or another agent with file access, ask it to save the top-pages list as a CSV in the repository next to your redirect map; in chat clients, copy the table out. Then use it to check the map itself: ask the assistant to list every baseline URL that has no redirect rule, redirects to the home page, or redirects to a URL missing from the new sitemap. Those are the pages most likely to lose traffic, and they are cheap to fix before launch.
The Claude Code SEO guide shows how to run this kind of data-plus-codebase check in one session. Also inspect one or two URLs per template with inspect_url so you know which canonical Google chose before anything changed.
Day 1: launch-day checks
In Search Console and your stack
- Turn on the redirects, then remove any staging
noindexrules and robots.txt blocks. - Run your redirect crawl against the full list of old URLs.
- For domain moves, submit the Change of Address from the old property, for every verified variant of the old domain.
- Submit the new sitemap. Google’s guide suggests submitting both the old-URL and new-URL sitemaps for monitoring: the old one’s indexed count should fall to zero as the new one’s rises, and redirect warnings on the old sitemap are expected.
- Add an annotation to the Performance chart (right-click the chart, then Add annotation) so the launch date is visible to everyone on the property.
With your assistant
Ask for list_sitemaps on both the old and new properties, with provider set to all so Bing feeds are included. You want to see that the new sitemap has been downloaded since launch, isn’t still pending, has no errors, and lists roughly as many URLs as the old one.
A word on what this can show. Google’s Sitemaps API still has a per-sitemap “indexed” field, but its reference marks it deprecated, so list_sitemaps reliably shows fetch dates, URL counts, errors and warnings but not indexing progress. For indexed counts per sitemap, open Indexing → Sitemaps, click the sitemap and choose See page indexing.
Don’t over-read day-1 inspections either. URL Inspection reports the version in Google’s index, so a new URL inspected hours after launch will usually say Google doesn’t know it yet. That is normal.
Week 1: inspect your most valuable URLs
From day 2 or 3 onwards, URL Inspection becomes the most useful tool you have. Inspect old and new URLs in pairs, starting with the pages that earned the most clicks in your baseline.
Google’s URL Inspection API quota is 2,000 inspections per property per day and 600 per minute. In a domain move the old and new properties have separate quotas; in a same-domain restructure, old and new URLs share one. A practical plan: inspect the top 50 old/new URL pairs daily in week 1, then the rest once. Keep the old property connected and verified, because inspect_url only works on URLs inside a property you have access to. Each inspection is also one tool call against your monthly plan, so daily sampling at this scale needs a paid plan rather than the Free plan’s 30 calls.
Here is the redirect map for our top 50 pages. Run inspect_url on each old URL and each new URL. For old URLs, report the coverage state and last crawl. For new URLs, report the verdict, coverage state, Google-selected canonical, user-declared canonical and robots.txt state. Flag every pair where the new URL isn’t indexed, Google’s canonical isn’t the new URL, or the old URL was crawled after launch but isn’t showing “Page with redirect”.
Work in batches of about 50 pairs so answers stay readable. Here is how to read what comes back:
| URL | What inspect_url shows | Meaning | Action |
|---|---|---|---|
| Old | Page with redirect | Google recrawled it and saw the redirect | None |
| Old | Still indexed, last crawl before launch | Not recrawled yet | Wait; make sure it’s in the old-URL sitemap |
| Old | Not found (404) or Redirect error | Missing redirect, chain or loop | Fix the rule; redirect in one hop |
| New | URL is unknown to Google | Not discovered yet | Normal at first; check sitemap and internal links |
| New | Indexed, Google canonical is itself | Moved | None |
| New | Google canonical is the old URL | Mixed signals | Check canonical tags, internal links and sitemaps |
| New | Excluded by noindex, or robots.txt disallowed | Staging block left in place | Fix today |
Google’s Page indexing report documentation explains that “Page with redirect” URLs are not indexed by design, and that inspecting one shows the tested URL, not its target. For more on running these checks from an editor, see technical SEO in Cursor and VS Code.
Weeks 2–4: sitemaps, crawl stats and the traffic hand-off
Sitemaps and indexing
Weekly, run list_sitemaps to confirm the new sitemap is still being read without errors, then open Indexing → Pages in each property. Indexed pages should fall in the old property and rise in the new one. Look for any error reason that spikes after launch, especially Not found (404), Soft 404 and Redirect error.
Crawling
Google warns that it will crawl the new site more heavily than usual for a while, because crawls of old URLs are redirected on top of normal crawling, so make sure the server can cope. In Settings → Crawl stats, expect 301 responses to rise and watch for 404 and 5xx spikes. If you changed hosting without changing URLs, Google’s hosting move guide says a temporary dip in crawl rate followed by a steady increase is normal.
Bing’s crawl data is in the API, so your assistant can read it daily:
Run get_bing_crawl_stats for example.net for the last 28 days. Show daily pages crawled, crawl errors, 301, 4xx and 5xx counts, pages blocked by robots.txt and pages in index, and compare each with the baseline I saved before launch. Flag any day where 4xx or 5xx is more than double the baseline average.
The traffic hand-off
For a same-domain restructure, track old and new URL patterns separately with query_search_analytics, a date dimension and page regex filters, for example ^https://example\.com/blog/\d{4}/ for old dated URLs and ^https://example\.com/guides/ for new ones. The Search Console regex cheat sheet has more patterns.
Since launch on 2026-10-05, run query_search_analytics with dimension date twice: once with a page includingRegex filter ^https://example\.com/blog/\d{4}/ and once with ^https://example\.com/guides/. Sum clicks by week for each, add them together and compare the combined total with the weekly baseline.
For a domain move, the two halves live in different properties. Ask for get_search_overview twice in one multicall, once with each siteUrl, and add the results. The combined line is what matters: old falling and new rising is the move working.
Months 1–3: find pages that didn’t make the move
Sitewide totals can recover while individual pages quietly don’t. Once most top URLs show as moved, compare each new URL with the old URL it replaced.
Using redirects.csv and the baseline, compare each of our top 200 old URLs’ clicks in the 28 days before launch with its new URL’s clicks in the last 28 days, using query_search_analytics with the page dimension. List new URLs below 70% of their old URL’s baseline, with inspect_url results for the 20 biggest gaps.
Then run compare_search_periods with dimension: page on the new property to see which pages are still gaining week on week and which have stalled. Two caveats:
- Year-over-year comparisons: judge them on clicks. Search Console misreported impressions from 13 May 2025 to 27 April 2026, and the September 2025 &num=100 change shifted impressions and position too; the content decay audit explains both.
- Old and new both ranking: in a same-domain restructure,
find_keyword_cannibalizationwill flag queries where the old and new URL both get impressions. That is normal in the first weeks. If it persists after a month, Google hasn’t accepted the redirect; see the keyword cannibalization guide for how to read page shares. The tool works within one property, so it won’t see cross-domain overlap.
Also compare query lists with get_search_queries. Queries that vanished entirely often point to content that was cut or merged during the migration rather than to a redirect fault.
What normal post-migration fluctuation looks like
Google is direct about this: expect temporary ranking fluctuation while it recrawls and reindexes. A medium-sized site can take a few weeks or more before Google gradually shows the new URLs instead of the old ones, larger sites take longer, and speed depends mostly on the number of URLs and your server speed. Google also says that combining a move with a redesign of content and URL structure will probably cost some traffic while it reassesses pages.
Google doesn’t publish thresholds, so here are the rules of thumb we use to separate normal from worrying:
| Signal | Normal | Investigate |
|---|---|---|
| Combined clicks, old + new | A dip in weeks 1–4, then recovering towards baseline | Still down 25% or more after four weeks, or still falling |
| Old URLs indexed | Falling week by week | Flat after two weeks |
| New URLs indexed | Rising week by week | Flat, or many “Discovered – currently not indexed” |
| Google-selected canonical | Switches to new URLs as they’re recrawled | Still the old URL after both were crawled |
| 404s in Crawl stats or Bing 4xx | Small and stable | A spike after launch |
| Redirect warnings on the old sitemap | Expected; Google says to ignore them | – |
If combined clicks fall sharply and keep falling, stop treating it as migration noise and work through the organic traffic drop checklist.
When is a site migration finished?
Google considers a move complete once Googlebot has visited every URL on the old and new site at least once. In practice: old-property clicks are close to zero, your inspected old URLs all show “Page with redirect”, and the new property’s indexed count has levelled off. Keep the redirects for at least a year (Google’s site move guide; its Change of Address help sets a 180-day minimum), and keep the old domain registered for at least a year so nobody else can use it.
Bing Webmaster Tools after a migration
Bing handles moves differently from Google in two ways that matter.
- HTTP to HTTPS is not a new property. A Bing Webmaster Tools team member confirmed in May 2026 that Bing doesn’t distinguish between http and https, so both appear as one property. Make sure the redirects work and the sitemap lists https URLs; there is nothing new to verify.
- A new domain is a new site. Add and verify it, or import it from Search Console, and submit its sitemap. Keep the old site in your account so you can watch its crawl stats wind down.
Bing supports IndexNow. Its FAQ says you can submit redirected URLs and pages returning 404 or 410, and that submitting every URL after a migration is acceptable. You can send up to 10,000 URLs per request, but the key file must be hosted on each host you submit for, so set it up on the old domain too. Google doesn’t use IndexNow, and our tools can’t send pings; use your CMS or CDN integration or a short script.
Older guides point to a Bing “Site Move” tool. Its availability in 2026 is unclear, so don’t build your plan around it. Redirects, sitemaps and IndexNow do the job. For why Bing’s index matters beyond Bing itself, see Bing Webmaster Tools and AI search visibility.
Common migration problems and how they show up
Most migration losses come from a short list of mistakes. Each one leaves a recognisable signature in the data.
| Problem | Signature | Where to look |
|---|---|---|
| Missing redirects | 404 spike; old URLs show Not found (404) | Crawl stats, Bing 4xx, inspect_url |
| Redirect chains or loops | Redirect error; slow recrawl of old URLs | inspect_url, your crawler |
| Everything redirected to the home page | Old URLs may be treated as soft 404s | Page indexing report, inspect_url |
| Staging noindex or robots.txt block | New URLs excluded or disallowed | inspect_url, Bing robots.txt blocks |
| Canonicals pointing at old or staging URLs | User-declared canonical isn’t the new URL | inspect_url |
| Sitemaps still listing old URLs | Warnings on the new sitemap; slow indexing | list_sitemaps, Sitemaps report |
| hreflang not updated | Clicks fall in some countries only | query_search_analytics by country |
| Image URLs not moved or redirected | Image search clicks fall while web clicks hold | query_search_analytics with search type image |
A single prompt can sweep for most of these once a week:
Run a migration health check for example.net. Inspect the 30 new URLs with the biggest click gap against their old URLs, list sitemaps for both properties, pull Bing crawl stats for the last 14 days, and break clicks down by country and by search type (web and image) against the baseline. Report only what looks wrong, with the likely cause and the fix.
Frequently asked questions
How long does it take Google to process a site migration?
Google says a medium-sized site can take a few weeks or more for new URLs to replace old ones in search, and larger sites take longer. The move happens URL by URL and is only complete once Googlebot has visited every old and new URL at least once. For domain moves, the Change of Address tool keeps forwarding signals for 180 days.
Should I use the Change of Address tool for an HTTPS move?
No. Google says not to use it for HTTP to HTTPS moves, switching between www and non-www, or moving paths within the same domain. Use it only when moving from one domain or subdomain to another, from the old property, for every verified variant of the old domain.
Why did traffic drop after my migration?
Some temporary fluctuation is normal while Google recrawls. Drops that persist usually trace back to missing or wrong redirects, many URLs redirected to the home page, a noindex or robots.txt block left over from staging, canonicals still pointing at old URLs, or a redesign shipped together with the move, which Google says can cost traffic while it reassesses pages.
How many URLs can I inspect per day?
The URL Inspection API allows 2,000 inspections per property per day and 600 per minute. In a domain move, the old and new properties each have their own quota. Inspect your highest-traffic URLs and a sample from each template rather than every URL.
Do I need to re-verify Bing Webmaster Tools after a domain change?
Yes for a new domain: add and verify it as its own site, or import it from Search Console, and submit its sitemap. No for an HTTP to HTTPS move on the same domain, because Bing Webmaster Tools treats http and https as the same property.