- Definition
- Matched cohort analysis — Matched cohort analysis compares the performance of a specific set of URLs before and after a migration by following each old URL to its destination. If A redirects to B, then A's post-migration performance is B's performance. It isolates migration effects from seasonality and from new pages added since launch.
Two weeks after a migration, someone will send a screenshot of a traffic graph with a downward line on it, and ask whether the migration failed.
It is a reasonable question and it cannot be answered from that graph.
What the first two weeks actually contain
Google recrawls a site at its own pace, determined by size, crawl frequency and how many URLs changed. For a mid-sized site that is days to weeks. For a large one it can be longer.
During that window, your Search Console data contains a mixture: pages that have been recrawled and reprocessed against the new URLs, and pages Google has not revisited yet. The aggregate of those two populations is not a performance measurement. It is a picture of crawl scheduling.
That is why the first two weeks look alarming even on migrations that turn out fine, and occasionally look fine on migrations that turn out badly. Neither reading is reliable.
Matched cohorts
The method that works is straightforward and almost nobody uses it.
Take the specific set of URLs that existed before the migration. For each one, follow its redirect to the destination. Compare the performance of that destination now against the performance of the original URL then.
If /old-page 301s to /new-page, then /old-page’s current performance is /new-page’s performance. Not zero. The traffic did not disappear; it moved address.
Comparing site totals instead conflates three things: migration effects, seasonality, and pages added or removed since launch. The cohort holds the population constant so the only variable left is the migration.
Why losses concentrate
Run the cohort comparison and something useful happens: the losses stop looking like a vague site-wide decline and start looking like a list.
They concentrate. One template. One section. One group of pages that lost a sidebar module and with it half their internal links. A set of URLs whose canonical now points at the wrong host.
That grouping is diagnostic. A site-wide 8% decline is a problem nobody can act on. “Category pages lost 40% and everything else is flat” is a ticket with a cause attached — probably the copy that got shortened when the template was rebuilt.
Group the cohort by template and by section before looking at individual URLs. The pattern appears immediately.
Impressions move before clicks
A detail worth knowing in advance, because it prevents a bad decision at day 30.
Impressions recover before clicks. Impressions register as soon as a page is ranking again; clicks require it to rank well enough to be clicked, which takes longer as positions settle.
So at day 30 it is normal to see impressions substantially recovered and clicks still down. That is the expected shape, not evidence of a snippet problem. If impressions have not recovered by day 30, that is the signal worth acting on — it means pages are not ranking at all, which is a redirect or indexation problem rather than a positioning one.
The logs tell you what nothing else does
If you have server log access, the most informative post-migration metric is the distribution of Googlebot requests between old and new URLs.
At launch, nearly all crawler requests hit old URLs. Over the following weeks that shifts. When the large majority land on new URLs, discovery has essentially completed and the remaining performance gap is about ranking rather than about crawling.
Nothing else shows you this. Search Console reports on outcomes; logs report on the process. When traffic has not recovered and you need to know whether Google has finished looking, this is the only direct answer available.
Set the windows before you launch
The most valuable thing on this page is procedural rather than analytical.
Agree, in writing, before launch: measurement happens at day 30, day 60 and day 90, against the frozen benchmark, on a matched cohort. Everything before day 30 is operational verification — redirects, directives, crawl errors — and is not a performance read.
Without that agreement, someone opens Search Console on day four, sees a dip, and a fortnight is spent responding to crawl scheduling. With it, the same dip is expected and the team stays focused on the checks that actually matter in week one.
The pre-migration benchmark this all compares against is the first phase of the process, and the checklist sets out what to capture. If your migration already happened without a benchmark, the audit page covers reconstructing one.
| Metric | Meaningful from | What it tells you | Trap |
|---|---|---|---|
| Redirect status codes | Hour one | Whether the map actually shipped | Testing staging instead of production |
| Production directives | Hour one | Whether a noindex or Disallow escaped | Checking page source but not response headers |
| Crawler hit distribution | Week one | How fast discovery is shifting to new URLs | Needs server logs; nothing else shows it |
| Indexed URL count | Week two to three | Whether new URLs are being taken up | A rise can mean bloat rather than progress |
| Cohort clicks vs benchmark | Day 30 | Whether traffic actually transferred | Comparing site totals instead of the matched cohort |
| Cohort impressions vs benchmark | Day 30 | Whether visibility transferred, ahead of clicks | Impressions recover before clicks; do not panic at day 30 |
| Query-level position | Day 60 to 90 | Whether specific rankings settled | Query data is volatile; look at distributions, not individual terms |
When this method applies
- A pre-migration benchmark was captured at URL level.
- The migration changed URLs, so old and new can be paired.
- You need to distinguish migration effects from seasonality.
When it does not
- No benchmark exists — reconstruct from Search Console retained data first.
- URLs did not change, in which case compare the same URLs directly.
- The migration coincided with a large content change, which confounds everything.
Questions people ask before starting
How soon after a migration can I tell if it worked?
Hour one for redirects and directives — those are pass/fail. For traffic, day 30 is the earliest meaningful read on a matched cohort, and day 90 is when the picture is settled. Anything you conclude in the first fortnight is mostly recrawl timing.
Why is week-over-week comparison misleading?
Because Google recrawls a site over days to weeks. In that window your data mixes pages that have been reprocessed with pages that have not been looked at yet. The resulting line reflects crawl scheduling more than it reflects performance.
What does a normal recovery curve look like?
A dip in the first two to three weeks, impressions recovering before clicks, and a return to the previous range between weeks four and twelve. Domain changes and consolidations sit at the longer end. A flat line with no dip usually means the migration was smaller than it looked.
Migration coming up?
If this raised a question about your own move, send the specifics — the launch date and what is changing is enough to start.
- Reply
- Typically within one business day.
- Hours
- Monday to Friday, 9am–6pm US Eastern.
- First call
- Scoping, not a pitch. No deck.