Search Console Broke Seven Times in Five Weeks

The most expensive decisions in search work are made from charts, which makes it worth knowing how often the charts are wrong. Between 17 August and 20 September 2026, seven separate Search Console data incidents were reported across four different reports. Several were logged by Google itself in its data anomalies notes. A site owner reacting to any one of them without checking would have been optimising against a bug.

Five weeks, seven incidents

The list, with the dates each was reported and the data each affected:

• 17 August. Performance reports showed impressions and clicks falling. Google’s anomaly note attributed it to a logging error decreasing impressions on the generative AI performance report in Search for data from 13 August 2026.
• 17 August. A second, separately logged anomaly: the same logging error decreased clicks and impressions on the Discover performance report for data on 13 August 2026. Both were recorded as resolved on 31 August.
• 21 August. The crawl stats report was missing 15 and 16 August entirely, so data after 15 August displayed as 18 August. Patched on 23 August.
• 8 September. The links report had not refreshed in roughly a month, with the last fresh link data dating to around 8 August.
• 9 September. A short indexing reporting blip briefly showed pages as “Crawled – currently not indexed”. Google confirmed it and it cleared within about an hour.
• 11 September. The page indexing report was missing a large block of June 2026 data.
• 20 September. The crawl stats report was missing 15 September. Fixed on 22 September.

Four of the seven are in one of two reports. That is not a coincidence, and it is the most useful thing on the list.

What the anomaly notes are actually for

Google maintains a data anomalies page alongside the Performance report documentation, and it is the first place to look when a chart moves in a way the site did not. The August entries are a good example of the form: they name the report, the affected dates, whether the cause was logging or processing, and whether the issue is ongoing. A logging error means the events happened and were not recorded — your visibility did not change, only the record of it did. That distinction decides whether there is anything to fix.

The Performance report documentation also warns that the newest data can be preliminary, still being collected and liable to change within hours, and marks it with a dotted line on the graph. A drop on the right-hand edge of a chart is the least reliable signal in the product.

How to tell a reporting bug from a real drop

Four checks, in order, resolve most of these before anyone escalates. First, look for a hard edge: a genuine ranking or demand change decays over days, while a reporting fault usually starts and stops on an exact date boundary, which is what a missing 15 September looks like. Second, cross-reference an independent source — sessions from organic search in analytics, or server logs. If impressions fall and sessions do not, the impressions are wrong. Third, check whether the drop is uniform across every dimension at once; a real change concentrates in some queries, pages, countries or devices, while a logging fault tends to flatten everything together. Fourth, check the anomalies page and Google’s own channels before touching the site.

Server logs are the strongest of those, because they are yours and nobody else’s pipeline can drop them. What server logs reveal about crawling is also the only independent check available when it is the crawl stats report that has gone missing, which happened twice in these five weeks.

Which reports are fragile, and what to do about it

Crawl stats, links and page indexing carry the pattern. All three are aggregated on a slower pipeline than the performance data, all three are reconstructed rather than streamed, and all three went wrong in this window. The performance report is the most reliable of the set and is still the one that carried two logged anomalies in August. Search Console has removed reports before, so its report set is not fixed either — the history of what Search Console dropped is a reminder that building a process on one chart is a fragile habit.

The practical defence is to annotate. Keep a dated log of known incidents against your own reporting timeline, so that six months later, when a quarterly chart shows a dip in the third week of August, the answer is in the file rather than in somebody’s memory. Google’s own guidance on getting started with Search Console makes the modest point that the data does not need daily checking; it needs checking against reality before it is used to justify anything.

The decision rule that follows: if a movement has a hard date edge, is uniform across dimensions, and has no corroboration in analytics or logs, wait seventy-two hours before acting. Three of the seven incidents above were fixed inside that window.