Is this drop real? Search Console anomaly check

What to upload

In Search Console, open Performance and the report you want to check (Search results by default), set the dates, then Export → Download CSV and upload the ZIP. This tool reads the Dates table (or Chart) and the Filters file inside it. Google does not publish the export's exact headers, so columns are read by what they hold — a date column, clicks, impressions — not by name, and columns it does not know are ignored.

To measure across 27 Apr 2026 the file must include 28 whole days on each side: 30 Mar to 26 Apr and 28 Apr to 25 May 2026, at one row per day, with clicks and impressions both switched on. The newest day in a file is set aside, so the file has to run to 26 May 2026 or later. It also needs enough clicks: the chance band around the click change is within ±10 points only above about 770 clicks in each 28-day window (about 27 a day), and below that a small gap between impressions and clicks is “cannot tell”. Without them the anomaly list still works and the measurement says why it was not made.

Compare exports (Compare selected in Search Console) hold two periods and nothing that lines the days up, so no per-day measurement is possible. If the Filters file has written-out dates they are used to list the anomalies; if it only says something like “Last 3 months”, which is relative to a day the file does not record, the tool explains this and stops.

A table with both a Date and a Page column, from Data Studio (formerly Looker Studio), the API or a spreadsheet add-on, is accepted too, by adding the pages up per day, and the result says so.

Methods: the rules and thresholds

Each number below is a constant in public/assets/lib/anomaly-check.js, in the table in anomalies.js, or (for the 13–17 Aug test) in ai-report.js; the read-size limit is in tool-ui.js. The project's tests compare the numbers quoted here with those constants; that is a check on the numbers, and not on every sentence. They are judgement calls, and they are the owner's to change.

Which anomalies are shown

An entry is shown when its dates overlap the dates in your file, and only for the report you are checking: Search results entries (including FAQ and job-listing appearances) for Search results, Discover entries for Discover, and so on. Google files its Performance entries under one “Search results / Discover / Google News” heading and names the report in only some of them: the impressions logging error, the FAQ change and the job-listing gap are treated as Search results because Google does not say otherwise, and the table marks them. For a Discover, Google News or bulk-export file that overlaps the logging error's dates, the result says Google does not say which of those reports the entry covers. With no Filters file the report is assumed to be Search results and the result says so.

Which report

Your choice in the selector wins. Otherwise the Filters file decides if it says Discover, Google News or names the generative AI report under a heading this tool does not fill in for you; a query or page filter that happens to say “ai mode” or “discover” is a filter, not the report. A Filters file that only says Web does not settle it, because the Generative AI report draws on the Web search type, so Search results is assumed.

The measured step

Mean daily impressions and mean daily clicks over the 28 days before the boundary day against the 28 days after it, the boundary day itself set aside. 28 days is four whole weeks, so every weekday appears four times on each side and the weekday mix cancels. The boundaries are 27 Apr 2026, where Google's fix lands and impressions are expected to read lower, and 13 May 2025, where the error began and impressions are expected to read higher (the direction there is this tool's inference from Google's note, which says only that impressions were not accurately reported); each is measured only if it is inside your dates. The 13 May 2025 step needs days from 15 Apr 2025, which Search Console may no longer show (it shows up to 16 months), and the result says so when it is given today's date. A day with no row and the file's newest day are not counted, and dates that appear more than once are not used, because their rows were added together; with fewer than 28 days on either side nothing is computed. A file has to run to the day after the last day of the after-window (26 May 2026 for the 27 Apr step), because its newest day is set aside.

The rule

The change in impressions minus the change in clicks, in percentage points. Clicks are counts, so their change carries chance: the ±1.96 standard-error band of the click change (Poisson counts, which understates real noise; its width assumes clicks did not fall, so it does not narrow when they happen to, and it widens when they rose) is worked out from the totals. Under 10 points, and with the click change measured to within ±10 points: the file does not show the logging step, which means no impressions-only step of 10 points or more. A gap inside the band, or under 10 points with a band wider than ±10 points, is “cannot tell”. A gap of 10 points or more that is also beyond the band is a verdict even when the band is wider than ±10 points; exactly 10 points counts as 10 points, in the gap and in the change in impressions alike. 10 points or more in the direction Google describes: consistent with the logging fix, provided impressions themselves also moved by at least 10 points in that direction; if impressions moved by less than that, or the other way, the result is “not called the logging step”, whether or not clicks moved, because a movement under 10 points is under the size this tool counts as a step. 10 points or more the other way: not the logging step. With a band wider than ±10 points either of those two results may be nothing but chance. The 10 points are a line this tool draws and not a cliff in the evidence: a file just under it and one just over it differ little. The measure is a proxy, and a real change that moves impressions and clicks apart would look the same. The band is within ±10 points only above about 770 clicks in each 28-day window (about 27 a day); below that a small gap is “cannot tell” and only a large one gets a verdict.

Other anomalies in the same windows

Entries that overlap the two 28-day windows, such as the FAQ change from 7 May 2026 or the job-listing gap from 16 Apr 2026, are named under the measurement, because where they apply they move impressions on their own. An entry that moves impressions and is not said to move clicks (the FAQ change) is named beside the verdict itself, because it looks the same and this check cannot separate the two.

The April 3 entry

Google's heading for it reads April 3, and its text says impressions were not accurately reported from 13 May 2025 until 27 April 2026. The text is used. If the true end were earlier, a measured “does not show the step” would be misread as an export that already carries the corrected figures.

Year on year

A warning when any date in your file falls from 13 May 2026 to 27 Apr 2027 (its year-earlier date is inside 13 May 2025 to 27 Apr 2026), or falls inside 13 May 2025 to 27 Apr 2026 itself. Whether a comparison across them is unreliable depends on whether your export still carries the old figures, which Google does not say: the warning is worded as conditional, and where your file has a measured step it says what that step shows (a step consistent with the error, which is evidence and not proof: unreliable if it is the old figures, and it names an impressions-only entry in the windows that could be the cause; no impressions-only step of 10 points or more: may be fine; one boundary stepped and the other flat: the two measurements disagree and the line says so). Impressions, CTR and average position are the metrics affected; clicks were not affected by this error, apart from the separate job-listing gap that applies only to sites with job-posting results.

Generative AI in Search, 13–17 Aug 2026

Each of the five days is compared with the same weekday in the 7 days before and the 7 days after; a day is tested only when that figure is at least 60 impressions, and at least 3 of the five days must be testable. If every tested day is under 60% of it, the file is read as the under-count Google logged for those dates, which it says in an update of 21 Aug was restored; dates that appear more than once are not used here either. The 60% line is set for counting noise only: a site with more day-to-day variation than that will see “not called either way” more often, and a real dip is sometimes not called.

What is read

A choice of files totalling more than 64 MB is not opened. A row with a negative or fractional impressions or clicks value is not used. Google says a value Search Console shows as ~ or - is written as 0 in its download, so an export carries zeros there; a table copied from the screen or from Data Studio still has the ~ or -, which is not a number, and that row is skipped and named under “What the parser could not read” and is not read as 0, so the day it was for has no row (and a measurement that needed that day says so). An empty clicks or impressions cell is read as 0 and named in the notes. A date after today (Pacific Time) is warned about. A table whose dates carry a time of day (an hourly table, which Search Console offers only in its 24-hour view, in your local time) is refused with a sentence that says to export with the Dates tab set to days.

Coverage

If your file starts earlier than 16 months before 30 Sep 2026, the result says that events before then may not be in the table.