Why Most GSC Analysis Is Wrong — And the Tool I Built to Fix It

An SEO opens Search Console, sees clicks have dropped 40%, and writes: “Clicks dropped 40%. Impressions fell. CTR collapsed.”

That is a screenshot with a caption. The client still has the same question: what should we investigate or change?

I built the GSC Anomaly Detector to make that investigation more disciplined. It is a reusable Claude Code skill that turns exports into diagnostic briefs, with competing hypotheses, evidence for and against, confidence levels and explicit next checks.

Three ways analysis loses its usefulness

Description takes the place of diagnosis

Metric movements establish the problem. They do not explain its mechanism.

If impressions grow while CTR falls, the useful question is whether existing pages became less attractive in search, or whether new pages added impressions at positions where few people click. The blended metric cannot distinguish those situations.

The first plausible explanation becomes the answer

“Algorithm update” is an easy hypothesis to reach for. An update overlaps the reporting window, several pages declined, and the explanation feels complete.

But calendar alignment does not establish causation. A URL restructure, lost internal links or inconsistent canonical signals might explain the affected pages more directly.

Confidence ignores the limits of the export

A named-query table is not a complete account of every search interaction. Google documents several reasons for differences between chart and table totals, including anonymised queries, row limits and aggregation differences. Google’s explanation of Performance report discrepancies.

That matters when an analyst calculates a precise percentage from visible rows and presents it as a sitewide finding. It also matters when a report claims a decline without identifying a comparison period.

I wanted those limitations to appear before the conclusions, where they can change the analysis rather than become a footnote nobody reads.

The framework makes alternative explanations explicit

The skill accepts CSV, XLSX and ZIP exports, as well as pasted data. Queries, Pages, Countries and Devices together give it more ways to test an explanation; a single dimension can still produce a brief, but with larger evidence gaps.

The v2.2 framework has six steps. Scope comes first: identify which pages, queries, markets, devices and metrics are involved, including URL variants that might otherwise disappear into a summary.

Timeline comes next. The skill checks relevant external events and asks about internal changes: releases, redirects, URL restructures, new content and hreflang changes. “No known change” stays distinct from “confirmed that nothing changed.”

Then it evaluates the hypothesis library. Every entry needs a disposition: supported, ruled out with reasons, or unresolved because evidence is missing. An export cannot settle every hypothesis, and the framework should not pretend otherwise.

The table below reproduces the installed v2.2 library. Some labels reflect older Search Console terminology: “Coverage” refers to indexing evidence, and the retired Mobile Usability report should be replaced with current device testing and relevant performance evidence. These are investigation prompts, not proof that a mechanism occurred.

For surviving hypotheses, the evidence cross-reference records the mechanism, evidence for, evidence against, confidence and the missing information that could change the verdict. High confidence requires at least two independent evidence points and a confirmed baseline, subject to the data-quality limits.

Two metrics calculated from the same rows are not automatically independent evidence. A crawl showing a broken redirect adds something that another summary of the same GSC export cannot.

Self-critique is the fifth step. Only then does the sixth step produce the brief: Data Quality Flags, Summary, Scope, Timeline, Ranked Hypotheses, recommended actions and Confidence Upgrade Opportunities.

Three checks that changed how I trust the output

These checks were added after testing exposed weaknesses in the earlier framework. They are operating rules I chose for the tool, not thresholds prescribed by Google.

Reconcile report totals with chart totals

In one development audit, the Queries report contained 56 clicks while the chart showed 106. The named rows represented about 53% of the total.

A query-level explanation could therefore leave nearly half the recorded clicks unexplained. That does not make the visible rows useless; it limits what they can establish about the whole site.

Version 2.2 flags a discrepancy above 10% and instructs the analysis to downgrade query-level and page-level confidence by one level. Before interpreting the gap, the analyst must check matching dates, filters, export limits and aggregation: a mismatch is not automatically evidence of anonymisation.

Measure how much activity is attributable to named queries

The second check calculates the share of clicks and impressions visible in named-query rows. Below 70% attribution, query-dependent hypotheses receive a confidence cap.

This is deliberately conservative. The missing portion might contain a different pattern from the visible rows, so a neat explanation of the named queries cannot automatically become a confident explanation of all activity.

Establish a comparison before calling something an anomaly

A three-month export can show what happened within those months. Without a suitable baseline or another defensible reference, it may not show whether that behaviour is unusual.

The skill asks for a prior-period export at intake. If none is available, v2.2 caps hypothesis confidence at Medium and labels the brief as current-state observations.

That is a constraint on claims about change, not a claim that every technical defect requires historical data to verify. A live test can confirm a broken redirect today; a performance decline still needs a comparison.

Client A: growth concealed two separate problems

For a B2B packaging and procurement platform, impressions increased 106% over the comparison window while clicks grew 21%. Sitewide CTR moved from 14.1% to 8.3%.

The headline could easily have been positive: more visibility, more clicks, continued growth. Separating newly appearing pages from established pages produced a more useful explanation.

Twenty new content pages were appearing at average positions around 65–80 or worse. Their impressions expanded the denominator without contributing many clicks, making H12 the leading explanation for the blended CTR decline.

One long-form commercial guide accounted for approximately 35% of the reported impression increase. It had an average position of 71 and two clicks.

Insufficient content depth was a working hypothesis to test through page review, alongside intent alignment, internal links and competing results. Position 71 alone cannot prove a depth problem, and adding length would not be a diagnosis-led fix.

The same investigation surfaced a separate concern after a URL restructure. A section hub had moved from average position 4 to 74, making redirect continuity and internal-link changes immediate checks.

The export supported prioritising that investigation. Confirming lost signals would require evidence about the old and new URLs, redirects and canonical handling. Stopping at “impressions doubled” would have missed the reason to look.

Client B: URL variants changed the investigation

The Australian AI consultancy supplied a three-month export without a prior-period baseline. The correct opening was therefore a statement about the available period, not a claim that performance had deteriorated.

The Pages data contained 19 pairs of URLs with and without trailing slashes. Impressions appeared against both variants, and the dominant variant was inconsistent across pairs.

That was a concrete reason to investigate canonicalisation. It was not, by itself, proof that both versions remained indexed simultaneously: historical Performance data and current indexing status answer different questions.

The next checks were specific: request both variants, inspect redirects and canonical tags, and compare Google-selected canonicals where needed. If those tests confirm inconsistent handling, the fix may be a sitewide redirect rule aligned with the intended URL convention.

I would not prescribe nginx configuration from the export alone. The implementation depends on the hosting stack, and internal links and sitemaps should also reinforce the chosen version.

The diagnostic pass took roughly eight minutes in this development run. My estimate for a comparable manual review was two to three hours; that is a practitioner comparison, not a controlled benchmark or a promise about every dataset.

Branded clicks also fell 14% in the second half of the export window versus the first: days 47–92 compared with days 1–46. Branded impressions were broadly flat, and the click decline remained after separating branded from non-branded activity.

That within-period finding survived the dilution caused by growing non-branded impressions. It justified a closer look at branded results, but did not establish a year-over-year decline or prove the movement was unusual against a longer historical baseline.

The tool also had to critique itself

After v2.0, I tested the framework on client data with an explicit instruction to challenge its confidence, expose material data gaps and identify claims unsupported by the input.

Three omissions surfaced. It could produce High-confidence findings without a baseline, overlook report-to-chart mismatches and fail to adjust confidence when named queries represented only part of the activity.

Those became the v2.2 checks. Testing changed the diagnostic procedure rather than merely polishing the wording of its output.

The mandatory self-critique pass now asks five questions of every Medium- or High-confidence hypothesis: is it directly supported or inferred; is there an equally plausible ordinary explanation; do the confidence limits apply; are percentages being overstated; and were alternatives actually evaluated?

This does not make an LLM infallible. A skill is an instruction framework, and the analyst still needs to verify that the resulting brief followed those instructions and used the supplied evidence correctly.

Try it on a problem you already understand

The GSC Anomaly Detector is available as a free, open-source skill. Running it requires a compatible Claude Code setup; the skill itself being free does not imply free model usage.

The repository contains installation guidance. Once installed, the entry point is the problem: “Impressions went up but clicks didn’t follow,” “CTR collapsed,” or an export accompanied by “diagnose this.”

Start with a case whose outcome you already know. Check whether the brief reaches a defensible explanation, acknowledges the right gaps and names a next action that would genuinely reduce uncertainty.

This is the SEO automation I want to build: a process that keeps the analyst accountable to the evidence. The useful output is what that evidence supports, how much confidence it warrants and what is needed before a stronger claim can be made to a client.

The planned v2.3 addition is a bundled algorithm-update reference for H1 timeline checks. Dates will still need checking for freshness, and overlap will still be a reason to investigate rather than a causal verdict.

Get the GSC Anomaly Detector on GitHub. Try it on a real client investigation and share an anonymised account of what it found, what it missed and which evidence changed the conclusion. Those findings are how the framework improves.

Client examples are anonymised accounts of development runs. The timing comparison is a practitioner estimate, not a controlled benchmark.

Need help with a wider search challenge? Explore SEO consulting.