A November 12 report drew attention to a specific Search Console anomaly. Google’s issue log identifies reduced reported impressions in the Generative AI performance report in Search for November 9–11, 2026, caused by a logging error. The documented scope is data recording. That creates a practical reporting question: what can a team conclude from an incomplete observation?
Start with the exact report, metric and dates
Write down the affected report name, property, metric, period and filters before interpreting the graph. “Search visibility fell” is a much wider statement than “this impression series has a documented recording issue.” Do not silently extend an issue in one report to every search metric or every source of visits.
Check the primary anomaly page and any notice in the relevant report. Save the original export and the time of retrieval. Google’s general performance-report documentation is useful for checking that you are reading the intended report. The diagnostic process below is our editorial recommendation, not a recovery procedure promised by Google.
Also separate the incident window from the rest of the trend. If a decline began earlier or continues outside the affected dates, the logging notice does not settle that wider question. Investigating the remainder is reasonable; treating the notice as a universal explanation is not.
Build a three-column evidence ledger
Use three columns: observation, limitation and decision supported. The first row might record the reported impression decrease. Its limitation is the known logging issue in that specific period. The supported decision is to flag the comparison as incomplete, rather than calculate a business loss from it.
A second row can record independently observed website visits or qualified enquiries, where available. Its limitation is that these measure different events: a visit is not an impression, and an enquiry is further along the journey. They can inform a separate operational assessment but cannot reconstruct the missing impression count.
A third row can record a reproducible symptom outside the reporting system, such as a broken landing page confirmed by a direct check. That observation may justify a website repair on its own evidence. Keeping the rows separate prevents one known measurement defect from hiding another problem or manufacturing one.
Annotate uncertainty without filling the gap with estimates
Retain the reported values and label the affected interval in stakeholder reporting. If a comparison includes those dates, explain that its denominator or coverage may be incomplete. Show the period definition alongside the result so that a later reader can understand the limitation without searching through a message thread.
Do not multiply the affected days by an assumed correction factor, borrow a previous week’s average and present it as observed data, or infer missing impressions from analytics sessions. A scenario estimate may be useful for planning if clearly labelled, but it belongs outside the measured series.
For a recurring report, add a short evidence note: source of the notice, affected metric, dates, responsible analyst and next review. This gives the uncertainty an owner. It also reduces the chance that an automated weekly summary turns a qualified observation into an unqualified claim.
Define what would justify action or closing the incident
Investigate actual customer or website problems when independently supported. Revisit performance conclusions when you have comparable observations outside the affected interval or a relevant update from the primary source. Do not set a universal waiting period or assume that missing data will be restored.
When the source is updated, retain a record of what changed and regenerate only the comparisons affected by it. If no restoration is confirmed, preserve the limitation in historical reporting. The useful outcome is a defensible decision trail: what was observed, what could not be inferred and which action followed from which evidence.
This framework answers a durable question beyond this incident. A reporting fault and a real performance change can coexist. Diagnose their scopes separately, keep measured and estimated values apart, and avoid using a graph anomaly alone as authorization for content rewrites or budget changes.
Sources
- Google Search Console performance report data bug Nov 9–11
- Data anomalies in Search Console
- Performance report: overview and basic setup
