Before treating an abrupt Search Console change as lost rankings, check whether Google has documented a logging, processing, or aggregation incident for the same report and dates. A reporting anomaly can change the graph without changing what users actually saw in Google Search.
The reverse matters too: a real Search feature change can produce an expected reporting decline. Google's anomaly page contains both kinds of entry, so the explanation—not merely the presence of a date—is what determines the response.
Current official record
Google's anomaly page is a rolling record, normally covering only issues from roughly the previous 3 to 16 months. This snapshot was verified on July 18, 2026.
| Affected dates | Report or feature | What Google documented | Interpretation |
|---|---|---|---|
| June 24, 2026 | Discover and Generative AI in Discover | A logging error reduced reported clicks and impressions in Discover and reduced reported generative-AI impressions for properties with that report. | Reporting only; do not infer a one-day audience loss from GSC. |
| May 21, 2026 | Discover | A logging error reduced reported clicks and impressions. | Reporting only. |
| May 7, 2026 onward | FAQ search appearance and FAQ rich-result report | FAQ rich results stopped appearing in Google Search, so reported FAQ impressions decline. | Actual Search feature change, not a logging outage. |
| May 7–8, 2026 | Discover | A logging error reduced reported clicks and impressions. | Reporting only. |
| April 16–27, 2026 | Job listing and Job details search appearances | A logging error prevented impression and click reporting for those appearance types. | Reporting only; the missing rows cannot establish lost Search visibility. |
| May 13, 2025–April 27, 2026 | Search results impressions | Google corrected an error that had prevented accurate impression reporting. The correction can appear as a decrease in impressions; CTR and average position are also affected, while clicks are not. | Long-running reporting correction. Avoid comparing pre- and post-correction impression-derived metrics without a caveat. |
| February 28 and March 1, 2026 | BigQuery bulk data exports for some properties | Two export days are missing and will not be recovered. | Permanent holes in affected exported datasets; do not silently interpolate them as observed values. |
At the verification date, Google listed no recent issues for product-wide notes, Crawl Stats, Page Indexing, Video Indexing, the AMP enhancement report, or Core Web Vitals. “No recent issues” means no issue is listed on that page; it is not proof that an individual property has no data-quality or technical problem.
Check the live Search Console data anomalies page before relying on this snapshot.
A reliable triage procedure
1. Confirm the affected data surface
Identify the exact report, search type, appearance, property, date range, and metric. A Discover logging incident does not explain a Search results decline. A Job listing appearance incident does not explain unfiltered clicks unless those rows represent a meaningful share of the property.
2. Exclude ordinary data behavior
- The newest Performance points can be preliminary and change after first publication.
- The 24-hour view deliberately exposes preliminary hourly points.
- Search Console normally publishes data with a delay, and different reports refresh on different schedules.
- Pacific Time is used for normal Performance dates, while the 24-hour view displays the browser's local time.
- Privacy filtering, top-row truncation, page/property aggregation, and canonical attribution can make table sums differ from chart totals without an incident.
Read Data limits, hidden queries & missing rows before labeling a normal discrepancy an anomaly.
3. Match both date and scope
An official incident is a plausible explanation only when all of these match:
- affected report;
- affected metric or appearance;
- documented property population, if Google names one;
- date or date range;
- direction and shape of the change.
A one-day Discover dip on June 24, 2026 matches the documented incident. A sitewide Search decline beginning June 20 does not.
4. Determine whether Search or only logging changed
Look for explicit wording such as “affects data logging only.” In that case, the Search Console series is incomplete or wrong, but Google is not saying Search visibility changed. Add a reporting note, avoid incident-driven SEO changes, and use independent evidence such as analytics landing pages or server logs if a business-impact estimate is required.
When Google documents an actual Search change—such as FAQ results ending—expect the corresponding Search Console metric to change. The report is reflecting the product change rather than malfunctioning.
5. Check system and custom annotations
Search Console can place system annotations on Performance charts for data-processing or reporting issues. Custom annotations can identify launches, migrations, and site fixes. Annotations are valuable context, but they have limits: they do not appear in comparison or 24-hour views, remain visible regardless of filters, and custom notes older than 500 days are deleted.
6. Continue diagnosis when the incident is insufficient
Do not stop at the anomaly page when:
- the decline continues beyond the documented window;
- unaffected metrics or reports also changed;
- only one directory, country, or device declined;
- GA4, conversions, or server traffic corroborate a real loss;
- Page Indexing, Manual Actions, Security Issues, availability monitoring, or releases provide stronger evidence.
Use the sudden traffic-drop playbook for the remaining investigation.
How to annotate and report an incident
Use language that separates observed data from inferred impact:
Search Console documents a Discover logging error for June 24, 2026. The reported decline for that date should be treated as incomplete GSC data, not evidence of an equivalent loss in actual Discover exposure. Other data sources are required to estimate business impact.
For a permanent BigQuery gap, keep the date in the series and add an explicit quality flag such as gsc_data_complete = false. A zero would falsely state that Google measured no activity; interpolation would create activity Google did not measure. Exclude or specially handle the affected day in comparisons and alert baselines.
What Search Console cannot answer
The anomaly record does not provide corrected values for every incident, guarantee recovery, identify every affected property, or estimate lost clicks, sessions, or revenue. It also is not a comprehensive historical archive because older incidents roll off.
SearchConsole.ai can detect unusual changes in available GSC data, but the conclusion that Google had a platform incident requires current external documentation. It cannot reconstruct rows Google never logged or exported.
Prevention and validation
- Preserve a local incident log with report, dates, affected metrics, official link, discovery date, and resolution status.
- Add custom annotations for site-controlled events, without personal information.
- Make alerting aware of preliminary days and known anomaly windows.
- Keep independent analytics and availability evidence for business-impact questions.
- Re-run comparisons after Google resolves an incident, but do not assume historical rows were backfilled unless the notice says so.
Screenshot status: no screenshot is included. System annotations and anomaly notices should be captured with the date because both the UI and the rolling official record can change.