The short answer
Start with two equal, complete Search Console periods: a stable pre-migration baseline and a post-migration window. Keep the property, search type, dimensions, filters, and aggregation identical. Compare pages first, then queries inside the page groups that lost visibility. Inspect a representative set of business-critical URLs. Finally, separate what Google’s indexed data confirms from what still needs a live redirect, HTML, robots, sitemap, analytics, or server-log check.
The useful question is not “Did traffic fall after the migration?” It is “At which layer did the evidence first diverge?” That turns a vague traffic drop into a prioritized repair queue.
Table of Contents
Find the first broken layer
A migration can affect discovery, indexing, ranking, snippets, tracking, or demand. Diagnose those layers in order:
Property coverage: Are you reading the correct old and new Search Console properties, including protocol and subdomain variants?
Page visibility: Which old or new URLs lost impressions and clicks?
Query demand and ranking: Did impressions disappear, positions fall, or demand change?
Click-through rate: Did visibility hold while clicks declined?
Indexed URL evidence: What does Google’s indexed version report for representative URLs?
Live technical behavior: Do redirects, canonicals, robots directives, status codes, internal links, and sitemaps work now?
Search Console is strongest at the first five layers. The last layer requires live-site and infrastructure checks. Treating those as separate evidence sources prevents an AI summary from sounding more certain than the data allows.
Read the pattern before naming the cause
Use the metric pattern to decide what to investigate next. These are hypotheses, not automatic diagnoses.
Signal | First interpretation | Next Search Console check | Live follow-up |
Clicks and impressions fall; position broadly stable | Demand, coverage, or property scope may have changed | Compare queries, pages, countries, devices, and search type | Check seasonality, analytics, property setup |
Impressions fall and new pages are absent | Discovery, indexing, canonical, or mapping issue | Inspect missing new URLs and sitemap records | Test redirects, canonicals, robots, sitemap XML |
Impressions hold; CTR falls | Snippet, search appearance, or query mix changed | Compare CTR by page, query, device, and appearance | Review live titles, snippets, SERP context |
Impressions hold; position falls | Ranking, relevance, competition, or algorithm change | Find affected page-query groups and timing | Review content changes and ranking updates |
Only one host, protocol, or directory disappears | Property scope or migration batch issue | Verify exact properties and filter by page pattern | Check host redirects, internal links, deployment rules |
A practical migration-diagnosis workflow
1. Record what changed
Write down the migration launch date, affected hosts or directories, URL-mapping rules, CMS or template changes, analytics changes, and any content consolidation. A domain move, an HTTPS move, a path rewrite, and a redesign create different failure modes. If several changes launched together, mark that uncertainty explicitly.
2. Verify property coverage before comparing performance
List the Search Console properties available to the connected Google login. For a domain move, confirm access to both the old and new domains. For a URL-prefix property, protocol, subdomain, and trailing slash matter. A clean-looking report from the wrong property is still the wrong report.
Do not interpret an empty result as zero organic demand until you have checked the property, date range, search type, filters, and permissions.
3. Build equal, complete comparison windows
Use finalized data ending yesterday or earlier. Choose equal-length periods and keep the configuration identical. A 28-day baseline and the following 28 complete days often provides enough volume for an initial pass, but adjust for site size, seasonality, holidays, and the migration date. Google notes that significant moves can produce temporary ranking fluctuations while URLs are recrawled and reindexed, so avoid treating the first few days as a stable post-migration state.
If the business is seasonal, compare against a similar period or add a year-over-year check. Keep the raw clicks, impressions, CTR, and average position next to every percentage change; large percentage swings from tiny baselines should not lead the queue.
4. Compare pages before queries
Run page-level reports for the old and new properties or URL patterns. Group URLs by template, directory, market, content type, or migration batch. Identify:
Old URLs that still receive impressions when their replacements should be taking over
New URLs that never gained impressions
Page groups with large impression losses
Pages with stable impressions but weaker CTR
Business-critical pages missing from the returned rows
The page layer shows whether the drop is site-wide, template-specific, or concentrated in a few URLs. Only then drill into queries for the affected groups.
5. Use query data to distinguish demand from visibility
For the affected pages, compare query clicks, impressions, CTR, and average position. If impressions fell across a stable set of high-value queries, investigate indexing, canonicalization, redirects, relevance, and ranking changes. If query impressions fell across the whole market, seasonality or changing demand may be involved. If impressions stayed stable but CTR dropped, inspect titles, snippets, search appearance, query mix, and SERP competition before rewriting pages.
Search Console may omit anonymized or lower-volume queries and returns top rows rather than a guaranteed complete table. “Missing from the export” is not the same as “zero searches.”
6. Inspect representative old and new URLs
Select a small, high-value sample from each affected template or migration batch. For each new URL, inspect Google’s indexed verdict, coverage state, robots state, indexing state, fetch state, last crawl time, Google-selected canonical, and user-declared canonical. Also inspect important old URLs when their index state helps explain whether signals have moved.
Classify each finding as:
Confirmed: directly reported for Google’s indexed version
Likely: supported by indexed evidence plus another source
Needs live validation: cannot be established from indexed data alone
URL Inspection API data describes the version Google knows in its index. It cannot run a live URL test. A stale canonical or fetch result can be a clue, but it is not proof of current browser behavior.
7. Check sitemap records without overclaiming
List the sitemaps submitted for each relevant property and review the paths, status, timestamps, warnings, errors, and content counts Google returns. This confirms what Search Console reports about submitted sitemap records. It does not fetch or validate the live XML, prove that every new URL appears in the file, or submit a replacement sitemap.
8. Complete the live technical validation
Hand the prioritized URL sample to the SEO or engineering owner for live checks:
Old URL returns a direct server-side 301 or 308 to the correct final URL
Redirect chains are avoided and irrelevant many-to-one redirects are not used
New URL returns the intended status and renders the expected content
Canonical, robots directives, hreflang, and internal links point to the new URL
New sitemap contains the intended URLs and is reachable
Analytics tagging and reporting survived the migration
Server logs show Googlebot reaching old and new URLs without unexpected errors
Google recommends keeping migration redirects for as long as possible, generally at least one year. For a domain or subdomain move, confirm whether Search Console’s Change of Address workflow is appropriate; it is not used for every kind of URL change.
Copyable AI prompt
Use this after confirming the exact Search Console properties and migration date:
Compare organic web-search performance before and after our site migration. Use the exact old and new Search Console properties I provide. Use equal-length, complete date ranges and identical settings. Start with page-level clicks, impressions, CTR, and average position; group affected pages by directory or template. Then analyze queries only for the page groups with material losses. Inspect a representative sample of critical URLs and label every conclusion Confirmed, Likely, or Needs live validation. Keep raw values beside percentage changes, flag small denominators and missing rows, and do not treat indexed URL data as a live-page test. Return a prioritized action queue with an owner and the next evidence needed. Do not change anything.How HireOtto helps with this workflow
HireOtto can handle the repetitive evidence-gathering inside your AI client: list the Search Console properties available to the connected Google login, pull pre- and post-migration performance by page or query, apply page and query filters, export up to 25,000 top rows, list submitted sitemap records, and inspect Google’s indexed version of individual URLs.
A practical division of labor is:
HireOtto: retrieve matched reports, preserve raw metrics, surface the biggest page and query losses, list sitemap records, and return indexed URL evidence
AI plus operator: group affected pages, formulate hypotheses, choose representative URLs, and prioritize the review queue
SEO or engineering owner: validate live redirects, response codes, rendered canonicals, robots rules, sitemap contents, internal links, analytics, deployments, and server logs
The review gates matter. HireOtto’s Search Console access is read-only: it cannot change a property, submit or remove a sitemap, request indexing, run a live URL test, edit a canonical, or modify the website. Use HireOtto’s Search Console guide for the workflow and limitations, the Search Console tools reference for exact request shapes, and Connect HireOtto to your AI client to get started.
Common mistakes to avoid
Comparing unequal date ranges or mixing finalized and preliminary data
Changing dimensions, filters, property, or aggregation between periods
Starting with site-wide totals and never locating the affected page group
Assuming every post-launch drop was caused by the migration
Treating average position as a fixed rank
Reading a missing query row as zero demand
Treating indexed URL evidence as a live redirect or HTML test
Letting AI recommend fixes without naming the evidence and the human owner
A good final deliverable
The output should be a short decision queue, not a speculative essay. For each issue, include the affected URL group, pre- and post-migration metrics, representative inspected URLs, confidence label, likely failure layer, next validation step, owner, and business priority. That makes the analysis usable by SEO, content, analytics, and engineering teams without pretending that one dataset can prove the entire cause.
About Me
I’m Suyash – badminton junkie, ex‑GroupM ad‑ops grunt, first marketer at a B2B SaaS startup, and creator of Hiretto: MCP servers for performance marketers.
My mission: less clicking, more thinking.
Let’s build leverage together.