Your GSC Data Was Wrong for 11 Months. Here's How We Rebuilt YoY Reporting from Clicks Only.

What Google actually disclosed

The announcement was buried in the Search Console help center known issues page. The exact wording: "A logging error prevented Search Console from accurately reporting impressions from May 13, 2025 until April 27, 2026. This issue has been resolved. As a result, you may notice a decrease in impressions in the Search Console Performance report. Only impressions and related metrics — CTR and average position — were affected; clicks were not affected by the error."

Three things to extract from that:

• Direction. "You may notice a decrease in impressions" after the fix means pre-fix impressions were inflated. The bug over-counted, the fix corrected downward.
• Derived metrics broken too. CTR is clicks ÷ impressions, so if impressions were inflated, your reported CTR was deflated. True CTR was always higher than what you saw.
• Position was wrong. Average position is impression-weighted. If impressions were miscounted, position averages drifted.

Why this broke nearly every SaaS marketing report

The 11-month window covers most of fiscal year 2025 plus Q1 2026. For any company doing YoY board reporting, growth reviews, or investor updates that referenced GSC impressions or CTR, the comparisons are mathematically invalid. Three specific patterns we've seen across the agency side:

• "Impressions are down" panic. Many sites are showing -15% to -40% impressions in late April-May 2026 vs prior year. Most of that is the bug correction, not a real decline.
• CTR "improving" reads. Pages where snippets weren't changed but reported CTR went up post-April 27 — that's the inflated denominator going away, not a real CTR lift.
• Position drift attribution. Sites that "improved" position post-fix may not have — the impression weighting shifted.

The data isn't recoverable. Google has confirmed they will not be reconstructing the historical data. So we work around it.

The clicks-only methodology we now use

Until enough post-April 27 data accumulates to enable a clean YoY (which won't be until April 28, 2027), the only honest framework is clicks-based. Here's the exact rebuild we run for our own properties and for agency clients:

Step 1: Build a clicks-only baseline

For each property, pull GSC clicks at the page level for two windows: April 28, 2025 — May 12, 2025 (pre-bug, only ~14 days but valid) and April 28, 2026 — current. Compare those windows. Any growth signal is real.

Step 2: Treat the bug period as a single block

For the May 13, 2025 — April 27, 2026 window, only use clicks. Don't quote impressions, CTR, or position from within that window — treat them as missing data, not as zero or "approximately right."

Step 3: Estimate true CTR post-fix only

CTR on any individual page is now reliable from April 28, 2026 onward. Use a 14-day rolling average — daily CTR is noisy at low impression volumes.

Step 4: Position trends start fresh

Treat post-April 27 average position as a new baseline. Anything compared to pre-fix position values is comparing apples to a different fruit category.

Step 5: Annotate every dashboard

If you have Looker Studio, GA4 dashboards, or anything that surfaces GSC data, add a vertical annotation line at April 27, 2026 with a note: "GSC reporting bug fix — pre/post not comparable on impressions, CTR, position." This saves you from explaining it on every stakeholder call.

What we actually rebuilt for 1ClickReport

Our own property (1clickreport.com) was hit by this. Pre-April 27, we were reporting around 27,000 weekly impressions across the blog. Post-fix, that number landed at about 24,000-26,000. So our true impression base never matched what we'd been quoting.

Rebuilt picture:

The clicks number being valid is what saved our entire diagnosis of the April 2026 Google Core Update. If clicks had also been bugged, we'd be flying blind. As it stands, our Core Update analysis from March-April still holds.

How we use Claude + MCP to pull the new baseline

Manual GSC pulls for the rebuild are tedious — you need to pull per-page, per-window, multiple times, then assemble the comparison. We use the 1ClickReport MCP server to skip the spreadsheet step entirely.

Sample workflow in Claude:

1. "Pull GSC clicks for sc-domain:1clickreport.com, May 1-14, 2026."
2. "Same query for May 15-28, 2026. Compute week-over-week delta per page."
3. "List pages with greater than 30% click decline week-over-week."
4. "For each declining page, pull post-April 27 CTR and position. Flag if CTR is below 0.5%."

Four prompts, three minutes, a clean clicks-based audit. The bug is the headline reason to wire this up — but the same workflow is useful for any time you need to slice GSC data without staring at the GSC UI.

For the agency side, we run the same workflow against each client property in a single Claude session. MCP servers for marketing 2026 walks through the setup.

What not to do in the meantime

• Don't try to "fix" historical CTR. There's no defensible adjustment factor. The bug magnitude varied by query and date — no formula will give you trustworthy reconstruction.
• Don't quote pre-fix CTR in board decks. Caveat or skip. Stakeholders remember the numbers you quoted; if those numbers were wrong, that's your credibility on the line.
• Don't blame the bug for real declines. If clicks dropped, that's real. The bug doesn't excuse weak content or Core Update casualties.
• Don't wait 12 months for clean YoY. Build a clicks-only framework now and start running comparisons on the post-April 27 baseline. By June 2026 you'll have 5-6 weeks of clean data — enough for week-over-week and rolling trend reads.

Frequently Asked Questions