Knowing when your traffic fell is half a diagnosis. Which pages fell is the other half, and it decides the entire recovery plan. A site-wide loss means a quality judgement on the whole domain, reassessed only at the next core update. A loss confined to one template means a much smaller and faster job. Four pages carrying the whole decline usually means something else entirely. Paste a Search Console Pages export taken with a date comparison and this tool works out which of those you have.
Free tool
Page scope analyzer
Knowing when your traffic fell is half the diagnosis. The other half is which pages fell, because a site-wide loss and a one-template loss need completely different fixes. Paste a Search Console Pages export taken with a date comparison and this works out the scope. Nothing is uploaded.
- Search Console, then Performance, then Search results.
- Click the date filter, choose Compare, and set a period before the drop against a period after it.
- Open the Pages tab, then Export as CSV.
- Paste the Pages file below, or drop it onto the box.
The comparison is what makes this work. A single-period export has nothing to compare against.
Search Console exports at most 1,000 pages, so on a large site this reflects your top pages rather than the whole index. That is usually enough to establish scope.
The four scope patterns
Almost every drop falls into one of these. The pattern tells you which Google system moved, which is more useful than knowing the drop percentage.
| Pattern | Measurement (what the data shows) | What it usually means | Where the work goes |
|---|---|---|---|
| Site-wide | Most pages lost 20 percent or more, fairly evenly | A core update or helpful content judgement on the domain | Site composition: pruning, consolidation, trust signals |
| One section | One URL folder fell far harder than the rest | A system that judges that page type, or a weak template | Rebuild that template, leave the rest alone |
| A handful of pages | Under 10 percent of pages carry 80 percent of the loss | Competitors, lost snippets, or AI Overviews on those queries | Page-level competitive work, not recovery |
| Broad but uneven | Many pages fell, but some held or grew | A core update hitting some content types harder | Start with what the survivors have that the losers lack |
The third row is worth dwelling on, because it is routinely misdiagnosed as an algorithm problem. If four pages out of six hundred carry the entire decline, no site-level system did that. Something specific happened to those four queries, and spending three months on site quality will not bring them back.
Why the pages that gained matter most
The tool lists pages that held or grew while others fell, and that list is usually more useful than the losers.
In a core update, Google applied one standard across your whole site. Some pages met it and some did not. Your survivors are a controlled experiment you already ran: same domain, same authors, same technical setup, different outcome. Whatever is different about them is the thing being rewarded.
Read three survivors and three losers side by side before writing a single recommendation. In my audits that comparison identifies the cause faster than any checklist, because it removes every variable except the content itself.
Getting a comparison export
This is the step people get wrong, because Search Console defaults to a single period and the resulting export has nothing to compare against.
- Click the date filter and switch to the Compare tab. Why: This is what adds the previous-period columns the tool needs. Without it you get one set of numbers and no baseline.
- Set a clean period before the drop against an equal period after it. Why: Equal lengths, and neither should straddle the drop date. Three months against three months works well for most sites.
- Do not include the rollout window in either period. Why: Rankings move in both directions during a 12 to 24 day rollout, so data from inside it is unreliable.
- Export the Pages tab, not Queries. Why: Scope is about pages. Query data answers a different question and comes later.
If you do not know your drop date yet, get it first with the drop analyzer, which reads the daily totals and finds the break. That tool answers when. This one answers where.
What this cannot tell you
- Whether the loss was clicks or rankings. Why: A page can hold position one and lose most of its clicks to an AI Overview. Compare impressions alongside clicks, as covered in impressions stable, clicks falling.
- What is wrong with the losing pages. Why: Scope narrows the search. It does not read your content or compare it against whatever replaced you.
- Anything about pages outside the top 1,000. Why: That is the Search Console export limit. For a large site this shows your most important pages, which is normally enough to establish scope but understates a long tail problem. The index bloat ratio covers that side.
- Whether a Google update was responsible at all. Why: A site-wide pattern is consistent with a core update and also with a technical fault. Match the date against confirmed updates before concluding.
Frequently asked questions
How do I know if a Google drop was site-wide?
Compare click loss per page across a period before and after the drop. If most pages lost a similar share, it is site-wide and points at a quality judgement on the whole domain. If the loss concentrates in one folder or a few URLs, it is not.
My export has no previous period columns. What went wrong?
The date filter was set to a single period. Open the date filter, switch to the Compare tab, choose two periods, then export the Pages tab again.
What if only a few pages lost traffic?
Then no site-level system demoted you. Look at those specific queries: a competitor may have published something better, you may have lost a featured snippet, or an AI Overview may now answer the question above your result.
Why do some pages gain during a core update?
Because core updates reassess quality relative to competitors rather than penalising sites. Pages that meet the revised standard can rise on the same domain where others fall, which is why the survivors are the most useful diagnostic you have.
How long should the comparison periods be?
Three months against three months suits most sites. Use equal lengths, keep both periods clear of the rollout window, and avoid periods that straddle a seasonal peak on one side only.
You have the scope. The next question is why.
Scope narrows the search but does not read your pages or compare them against whatever now outranks them. Send your Search Console access and within 48 hours I will tell you what those pages have in common and what the fix sequence should be. Free, no obligation.
Get free recovery audit