Google Search Console Impression Bug: What the Year-Long Data Error Means for Your SEO Reports

What Happened: The Year-Long Impression Bug

Google Search Console records an impression every time your URL appears in a search result that a user could theoretically see. That count is the foundation of almost every SEO visibility metric: total impressions, impression share by query, CTR calculations, and trend analysis. Starting May 13, 2025, a logging error in Google's backend began counting some of those impressions more than once. The result was an inflated impression count in the Performance Report for every property in Search Console, worldwide.

Google has not disclosed the technical root cause in detail. The Data Anomalies page describes it as a "logging issue" that affected impression counting, and confirms the fix is rolling out over the next few weeks. What we know from cross-referencing client data is that the magnitude of the inflation varied. Sites with heavy search feature visibility (FAQ rich results, sitelinks, image packs) appear to have been more affected than sites with simple blue-link listings. This makes sense if the bug was double-counting impressions across different search result types for the same query.

The uncomfortable truth is that this bug ran undetected, or at least unacknowledged, for nearly 11 months. SEO teams across the industry built strategies, set benchmarks, reported wins, and justified budgets using data that was systematically too high. That does not mean the strategies were wrong or the actual SEO work was wasted. Clicks were accurate the entire time. But it does mean that anyone who relied heavily on impression-based metrics during this period was working with a flawed denominator.

If you noticed impression numbers climbing faster than expected sometime after May 2025 without a corresponding increase in clicks, you were probably seeing the bug in action. Many teams attributed that divergence to increased search demand, algorithm changes, or improved visibility. Some of those explanations may have been partially true. But the bug was a confounding variable the entire time. Run your data through our meta tag analyzer to ensure your on-page signals are solid regardless of impression fluctuations.

The Timeline: May 2025 to April 2026

May 13, 2025 is the date Google identifies as the start of the logging error. At the time, the SEO community was focused on other things. Google had been rolling out AI Overviews more aggressively, and most fluctuations in Search Console data were attributed to the shifting SERP landscape. Nobody was looking for a backend counting bug because Google's data infrastructure had been generally reliable for years.

Through the summer and fall of 2025, scattered reports appeared in SEO forums and on X about impression numbers that did not match click trends. Some practitioners noticed that impressions were growing 20-40% faster than clicks for queries where rankings had not changed. Others saw sudden jumps in impressions for pages that had been stable for months. The common explanation was increased search volume or expanded SERP features. The bug hypothesis was floated by a few analysts but never gained traction because there was no official confirmation and the data looked plausibly organic.

The March 2026 core update further muddied the waters. When that update rolled out, some sites saw large impression swings that were impossible to separate from the bug's impact. Teams trying to assess whether the core update had expanded or contracted their visibility were doing so with contaminated data. The April 2026 core update compounds this problem even further, since it overlaps with the bug fix rollout.

Then, on April 3, 2026, Google updated the Data Anomalies page. The entry is characteristically terse: it identifies the date range, confirms the over-reporting, notes that the fix is in progress, and states that historical data will not be corrected. No apology, no explanation of scope, no guidance for how to adjust reporting. That last part is on us to figure out, and it is why this article exists.

What's Affected and What's Not

Impressions in the Performance Report are the sole metric affected. That sounds narrow until you realize how many downstream calculations depend on impressions. CTR, which is clicks divided by impressions, was artificially deflated for the entire bug period because the denominator was too high. Impression trend lines used for visibility tracking were inflated. Any impression-based benchmarking or competitive analysis during this period is compromised.

What was not affected: clicks, average position, coverage reports, Core Web Vitals data, indexing status, structured data reports, and everything in the URL Inspection tool. Your click data from May 2025 forward is accurate. Your position data is accurate. If you built reports centered on clicks and conversions during this period, those reports are fine. The problem is isolated to teams and dashboards that gave significant weight to impression counts.

The Search Console API delivered the same inflated impression data as the web interface, which means any third-party tools pulling data from the API (Looker Studio dashboards, Data Studio reports, custom analytics pipelines, SEO platforms like Ahrefs or Semrush that sync GSC data) also contain the inflated numbers. If you export GSC data into client dashboards or automated reporting tools, every impression figure from May 2025 onward in those systems is wrong. There is no automated fix for downstream systems. You will need to annotate them manually. For broader context on how Search Console fits into your technical SEO workflow, see our Google Search Console new features guide.

Why Your CTR Is About to "Improve" (It's Not Real)

Here is the math. If a page received 100 clicks and 10,000 impressions during the bug period, its reported CTR was 1.0%. If the true impression count should have been 7,500, the real CTR was 1.33%. Once the fix rolls out and impressions drop to accurate levels, that same page's CTR will jump from 1.0% to 1.33% without anything changing about the page, the query, or user behavior. Multiply that across every page and query on your site and you get a portfolio-wide CTR increase that looks fantastic on a dashboard but represents zero actual improvement.

This matters because CTR is one of the most commonly reported SEO metrics. Agencies include it in monthly reports. In-house teams track it in executive dashboards. Automated alerts fire when CTR crosses thresholds. Every one of those systems is going to register an apparent improvement over the next few weeks as the fix propagates. If you do not get ahead of this narrative, someone will ask why CTR suddenly improved, and the honest answer — "Google was miscounting impressions for a year" — is not the story anyone wants to tell.

The inverse is also true: during the bug period, CTR appeared to decline or stagnate for many sites even as clicks grew. If you were explaining to a client why their CTR dropped from 3.2% to 2.8% between Q1 2025 and Q3 2025, the bug was likely a contributing factor. Clicks may have been growing, but inflated impressions were dragging the ratio down. Revisiting those conversations with the corrected context may be uncomfortable but necessary.

The practical takeaway: do not celebrate CTR improvements in the weeks following the fix rollout. Note them, annotate them, and wait 4-6 weeks for the data to stabilize before drawing any conclusions about actual performance trends. Use our SEO score calculator to assess page-level quality independent of impression noise.

How to Explain This to Clients and Stakeholders

Proactive communication is non-negotiable. If you manage SEO for clients or report to executives, they need to hear about this from you before they see the data shift in their dashboards. Discovering a year-long data error from a Looker Studio alert instead of from their SEO team is a credibility problem you do not want. Send the communication this week, before the fix fully propagates to all properties.

Keep the explanation simple and factual. Google had a logging bug that inflated impression counts in Search Console from May 2025 through early April 2026. The bug is now being fixed. Impressions will decrease as the correction takes effect, but this reflects more accurate data, not a decline in performance. Clicks were never affected. Actual traffic, leads, and revenue metrics are accurate and unchanged. Link to Google's Data Anomalies page as the authoritative source. Resist the temptation to over-explain the technical details. Stakeholders care about one question: "Is my SEO actually declining?" The answer is no.

If you previously reported impression growth as evidence of improved visibility during the bug period, address it head-on. Explain that the growth was partially real and partially inflated by the bug, and that you are recalibrating baselines using corrected data. This is not a failure of your work. The underlying click and conversion performance demonstrates the actual value delivered. But pretending the inflated numbers were accurate when you now know they were not is a much worse look than transparent correction.

For agencies, consider adding a standing note in reports for the next 2-3 months referencing the anomaly period. Something like: "Impression data for May 2025 through April 2026 was affected by a confirmed Google logging error. Comparisons to this period use click-based metrics for accuracy." This protects you in future conversations and demonstrates professionalism. If you need help auditing client-facing reports, our SEO audit service includes reporting framework review.

Recalibrating Your SEO Baselines

You need two new baselines. The first is a pre-bug baseline using data from before May 13, 2025. This gives you accurate historical impression levels before the inflation started. The second is a post-fix baseline, which you should start collecting 4-6 weeks after the fix fully rolls out. The gap between these two baselines, adjusted for seasonal factors and any algorithm changes during the period, is your true trajectory.

For the pre-bug baseline, pull your Performance Report data for the three months before May 2025 (February through April 2025). Export it at the page and query level. This is your last clean dataset. Compare it against the post-fix data once the correction stabilizes. If post-fix impressions are higher than the February-April 2025 baseline, you have genuine impression growth during the period that was masked by the bug inflation. If they are lower, you may have lost ground, which could be related to algorithm changes, increased competition, or other factors unrelated to the bug.

Click-based metrics are your bridge during the transition. Clicks were accurate throughout the bug period, so click trends, click-based CTR benchmarks, and click-to-conversion ratios provide an unbroken analytical thread. For the next 2-3 months, weight your reporting toward clicks, conversions, and revenue rather than impressions. Once the post-fix baseline is established, you can reintroduce impression metrics with confidence.

Any automated reporting systems that use impression thresholds for alerts or KPIs need to be updated. If you have an alert that fires when impressions drop below a certain level, that threshold was set using inflated data and will trigger false alarms as the fix takes effect. Reset those thresholds after collecting 4-6 weeks of corrected data. The same applies to impression-based goals in quarterly planning documents or annual strategies. Check your pages against our AIO readiness checker to evaluate performance using metrics the bug did not touch.

What This Means for Historical Reporting

Google will not retroactively correct the data. The inflated impression counts from May 13, 2025 through whenever the fix completes on your property are permanent in the Performance Report. If you exported and archived that data, it is inflated. If you built year-over-year comparison dashboards, the 2025-2026 period is contaminated. There is no undo button.

This creates a specific problem for year-over-year reporting in late 2026 and into 2027. When you compare October 2026 (clean data) against October 2025 (inflated data), impressions will show a decline even if actual visibility improved. The reverse is also problematic: comparing May 2026 (corrected) against May 2025 (pre-bug, clean) might show genuine trends, but the months in between are unreliable. Any trend analysis that includes data from the May 2025 to April 2026 window needs a caveat.

The practical solution is segmented reporting. For any analysis that spans the bug period, create separate segments: pre-bug (before May 13, 2025), bug period (May 13, 2025 to fix completion), and post-fix (after stabilization). Only compare data within the same segment. Pre-bug to post-fix comparisons are valid for trend analysis. Anything involving the bug period should be flagged as unreliable for impression metrics, and click-based alternatives should be used instead. This is the same approach we used during previous data quality issues in Search Console history.

For teams that produce annual SEO performance reviews, the 2025-2026 fiscal year is going to require a detailed methodology note explaining why impression metrics are excluded or caveated. Build that note now while the details are fresh. By December, nobody will remember the exact dates or mechanics, and you will be grateful for the documentation.

How to Audit Your Own Data for the Bug's Impact

Start with a simple divergence analysis. Pull monthly impressions and clicks for your top 50 pages from January 2025 through March 2026. Plot both metrics on the same timeline. Look for the point where impressions begin growing significantly faster than clicks. For most sites, this divergence appears sometime in May or June 2025 and accelerates through the fall. The gap between the impression curve and the click curve represents the approximate magnitude of the bug's inflation on your property.

Next, check your CTR trends. Export monthly CTR for your top queries. If CTR declined steadily from May 2025 onward despite stable or improving rankings, the bug was artificially suppressing your ratio. Calculate what your CTR would have been if impressions had tracked proportionally with clicks (using the pre-May 2025 clicks-to-impressions ratio as your anchor). The difference gives you a rough estimate of the CTR suppression caused by the bug.

Cross-reference with third-party tools. If you track estimated search volume through Ahrefs, Semrush, or similar platforms, compare their impression estimates against your GSC data for the bug period. Third-party tools derive their estimates from clickstream data and their own models, not from GSC directly. If their estimates are significantly lower than what GSC reported for the same queries, that delta is likely the bug. This is not a precise method, but it provides directional validation. For a broader look at how to integrate multiple data sources into your content decay framework, see our guide on refresh-based analysis.

Finally, document your findings. Create an internal memo or report that records the estimated impact on your specific properties, the methodology you used to assess it, and the adjusted baselines going forward. This document will be invaluable when questions arise in future reporting cycles. If you need a comprehensive audit of how the bug affected your SEO data and what adjustments to make, our technical SEO service includes data integrity analysis as part of the engagement.

Frequently Asked Questions