For a few days in the middle of August, anyone watching Search Console's newer Generative AI performance report saw impressions fall off a cliff. The instinct in that situation is always the same: pull up the report, screenshot the drop, and start drafting the explanation for whoever asks about it next. This time, the honest explanation is duller than any story a team could invent, and duller is the right answer to lead with.
It is also a useful reminder that Search Console itself is software, built and maintained by people, shipped with the same kind of bugs any other analytics pipeline ships with. Teams tend to treat first-party Google data as a fixed, authoritative ground truth precisely because it comes from the source, which makes a Google-side data bug more disorienting than a third-party tool glitch would be. Nobody double-checks the thermometer, right up until the week the thermometer is the thing that's actually broken.
What broke, and when
A logging error caused a decrease in impressions on the Generative AI performance report in Search, with the drop appearing in data starting August 13, 2026 and still visible in reports through at least August 17. The same underlying issue caused a decrease in clicks and impressions on the Discover performance report for data on August 13, and for properties with access to Generative AI features inside Discover, it hit the reported impressions there as well. Two separate report surfaces, one shared logging problem, one starting date, and by the time anyone outside Google noticed, the drop had already been sitting in the data for the better part of a week.
Search Engine Land's coverage and Search Engine Roundtable both picked this up quickly once practitioners started comparing notes on the sudden drop, and the pattern lined up across enough properties, in different verticals, with different traffic profiles, that it was clearly systemic rather than a handful of unrelated site-level issues. That cross-property consistency is usually the tell that something broke in Google's own pipeline rather than in any individual site's crawlability, indexing, or actual search performance.
The Generative AI performance report is still a relatively new addition to Search Console, rolled out in stages earlier this year and still not available to every property. New reporting surfaces are exactly where logging bugs like this tend to surface first, because the underlying pipeline has had the least real-world traffic running through it and the fewest edge cases already found and patched. The Discover report, by contrast, is a mature, years-old surface, and the fact that the same underlying error touched both suggests the break happened somewhere further upstream, in shared logging infrastructure both reports draw from, rather than in either report's own code specifically.
What Google says, and doesn't say
“This is just a logging issue and not representative of visibility changes in Search.”
That line, from John Mueller, is the whole story from Google's side, confirmed directly rather than left to inference from a support thread. Google's own framing matches it: the company describes the problem as affecting data logging only, and says it is adding an annotation inside Search Console itself so anyone looking at the affected date range in the future sees a flag explaining the dip rather than a mystery drop with no context attached.
What Google has not said is whether the missing data will ever get backfilled once the underlying logging pipeline is fixed. Past logging incidents on Search Console have generally not been retroactively corrected once identified and patched going forward, which means the honest working assumption is that the affected days stay dented in the historical record permanently, annotation or not. That is a meaningfully different problem than a temporary dashboard glitch that quietly resolves itself: it means any trailing 28-day, 90-day, or year-over-year comparison that spans August 13 onward is going to carry a visible notch in it for months, unless a team accounts for it explicitly in how it reports the number.
The annotation Google is adding will help anyone looking at the raw report inside Search Console itself. It will not help anyone looking at a downstream dashboard, a monthly PDF export, or a slide in a quarterly review that already pulled the raw number before the annotation existed. Annotations live where Google puts them, not wherever a team's reporting actually gets consumed, which is exactly why the burden of flagging this falls on whoever owns the reporting pipeline internally, not on Google's UI to catch it for them after the fact.
Why this one is easy to misdiagnose
The timing made this bug unusually easy to misread. Google's August 2026 spam update also rolled out in the same general window, and a team that noticed a Generative AI or Discover dip without checking the specific report and specific date range could plausibly, and wrongly, attribute it to the spam update instead of to an unrelated logging error sitting in a completely different part of Search Console. Reading Search Console like an analyst instead of like a dashboard-watcher means checking which report moved, not just that some number went down the same week something else newsworthy happened.
| WHAT HAPPENED THIS WEEK | WHAT IT ACTUALLY AFFECTS | WHAT IT DOES NOT AFFECT |
|---|---|---|
| Generative AI / Discover logging bug (from Aug 13) | Reported impressions and clicks in two specific Search Console reports | Actual search or Discover visibility, rankings, or real traffic |
| August 2026 spam update | Rankings and visibility for sites affected by spam policy enforcement | Search Console's logging pipeline; unrelated system |
This is the same discipline this site has argued for around what the Generative AI performance report actually measures in the first place: it is a frequency count with no query, click-through, or position data attached, which already made it easy to over-read even before a logging bug got layered on top. A metric that was already thin on context is a metric where a data-quality incident does the most damage to a team's confidence in what they are looking at, because there is so little else in the report to cross-check it against.
There is a broader lesson here about how fast a plausible but wrong explanation spreads once two unrelated events share a calendar week. A spam update is exactly the kind of story people already expect to explain a metrics dip, because it has happened before and the mechanism is intuitive: Google changed something, rankings moved, numbers followed. A logging bug in one specific report is a far less intuitive explanation, even when it is the correct one, because it requires knowing that report exists, checking whether the dip is confined to it specifically, and trusting Google's own confirmation over a more dramatic-sounding theory. The less dramatic explanation is right here, and it is worth resisting the pull toward the more dramatic one just because it fits a familiar shape.
What to do about it
The bigger habit worth building out of this is treating every reporting and analytics pipeline as something that can silently misreport, not just something that can silently miss real events. Most incident response playbooks are built for the second case: rankings drop, traffic drops, go find out why. This is the first case: nothing about the underlying site or its performance changed at all, but the number reporting on it did, and the fix is a logging patch on Google's end rather than anything discoverable through a technical audit of the property itself. A GSC-to-revenue reporting setup that pipes this data straight into a board deck without a human checking for exactly this kind of incident first is one bad week away from reporting a story that never happened.
For a B2B SaaS team where a single monthly organic report often doubles as the evidence for next quarter's content or SEO budget, this is not a minor caveat. A logging-bug-shaped dip that gets reported as a real visibility drop can talk a stakeholder into cutting a budget line that was actually performing fine, and the correction, if it ever happens, rarely gets the same attention as the original bad news. The five minutes it takes to check which specific report moved, and cross-reference it against Google's own confirmed incidents, is cheap insurance against a much more expensive misreading landing in a board deck, and it costs nothing beyond the discipline of checking before forwarding.
It is also worth keeping an eye on whether this specific incident recurs. A relatively new report, still being rolled out to additional properties, is more likely to see another data-quality issue before its logging pipeline fully matures than an established surface like the main Search performance report is. Treating this as a one-off to note and move past, rather than a pattern to watch for, would be the wrong lesson to take from a first-year reporting surface's first known bug, especially for any team that is building automated reporting or alerting directly on top of it.
See where you are cited today
A free snapshot audit of your rankings and AI citations before we ever talk.
Josh leads work at the intersection of SEO and generative engines at Something Inc., helping B2B brands get ranked and cited across every major AI engine.