Google update impact check

What to upload

The daily table of a regular Performance export. In Search Console, open Performance, then Search results, choose the longest date range you can (a longer file holds more updates and more ordinary comparisons), and use Export, then Download CSV. Upload the ZIP, or its daily CSV: the ZIP names it Dates.csv, or Chart.csv in newer exports. The file is read by what its columns hold, not by its name. Clicks and impressions must both be switched on.

The table must have one row per day. A weekly or monthly table is refused, and so is one taken with Compare, since neither is a daily series. Dates in an export are Pacific Time, which is also how the dashboard's times are given, so the two can be set side by side without converting anything. Google's help pages say that in every view except the 24-hour view the Performance report labels daily data in Pacific Time.

Two daily tables are never added together here, because overlapping days would count twice and a different filter would look like a change. To use more than one export, merge them first with the Search Console history merger, then upload its result.

The dashboard entries this tool uses

Read from the dashboard's history page for Ranking and from each entry's own page, on 21 Oct 2026. Nothing is taken from a third-party list. Times on the dashboard are Pacific Time. The end is the day the rollout was complete: the date in Google's "complete as of" post where there is one, else the day the entry ended. The table is data in public/assets/lib/google-updates.js, and node tools/build_google_updates.mjs rewrites it from the dashboard, and this table with it.

Methods: the rules and thresholds

Each number below is a constant in public/assets/lib/series-tools.js (the dashboard's entries are in google-updates.js). The project's tests compare the numbers quoted here with those constants. They are judgement calls, and they are the owner's to change.

Reading the file

A table is recognised by its columns, not its name. A daily table has a date column and both clicks and impressions. A weekly or monthly table, a table taken with Compare, and a table of pages by day are refused with a sentence that says what to export instead. A day that appears more than once is left out, not added up, because adding the rows would double the day. A row with a negative or fractional count is not used, and is named. A day with no row is not a day of zero: a window with a missing day is not compared, and the update is listed with that reason.

The windows

For an update that began on day S and was complete on day E: the 2 weeks (14 days) from S minus 14 to S minus 1, against the 2 weeks (14 days) from E plus 8 to E plus 21. The rollout, S to E, and the 7 days after it are left out. The default is 2 weeks, and the page also offers 1 and 4; a 4-week window needs a file of about two years to have enough ordinary comparisons. Each window is a whole number of weeks of seven days, so every weekday appears equally often in both; the windows are not aligned to Sunday, because they are anchored to the update's own dates. The 7 days of settling follow Google's core update guidance to wait at least a full week after completion; it is applied to every update type, which is this tool's choice and not Google's statement about spam or other updates.

The change

After divided by before, minus one, separately for clicks and for impressions. With 0 before there is no change to show. When the smaller window holds under 100 clicks (or impressions), the figure is flagged as mostly chance.

The file's ordinary changes

The same pair of windows, with the same rollout length and the same 7 days of settling, started on every other day of the file where: the pretend rollout overlaps no dashboard rollout; the update being tested is nowhere in the span, so it is never part of its own yardstick; every day in the span has a row; and no day Google marks for a documented anomaly that affects that metric is in it. Other updates may sit in a pretend window: Google posts so many that spans clear of all of them are rare, and keeping them widens the ordinary range, which errs toward "within ordinary" and not toward a finding. Comparisons that start on neighbouring days overlap, so they are also counted as independent stretches (laid end to end without overlapping); fewer than 6 stretches and no percentage is printed.

Where the change falls

The share of the file's ordinary changes that are smaller in size than this one (a tie counts half). It is printed as a whole percent rounded down, and never as 100%: a change bigger than every ordinary one is "larger than all" of them. A share of 90% or more is "at or above the 90% line", which is a label for reading the page and not a test of significance. The expected number of changes that clear the line by chance is the number placed times 11%. That rate was measured on plain noise, not assumed: ordinary changes in files with no update effect in them were called larger than ordinary 9.8% to 13.1% of the time (an independent test of several noise models, 150 files each), against the 10% the line is set at. A file with a strong seasonal swing clears it more often, so treat the expected number as a floor.

The newest days

The newest 3 days of the file are not used in any window, because the newest data can still change and the file does not say when it was exported.

Documented data anomalies

Google's data anomalies, as listed in anomalies.js, are read for a Search results export. A day Google says was lost or under-reported marks itself; a change of level (the impressions logging error, FAQ rich results going away) marks its first and last day, because comparing two windows that sit wholly inside such a period is not what Google warns against and comparing across its edge is. A mark in a comparison's windows withholds the metric it affects, unless Google's entry applies only to some sites (job listings, FAQ rich results), in which case it is a warning.

Sources

Every statement about Google on this page comes from one of these pages, each read on 21 Oct 2026.

• Google Search Status Dashboard, history for Ranking, and each entry it links to
• Using the Google Search Status Dashboard
• Google Search core updates: what to do, and when to compare
• AI features and your website: where the traffic is reported
• Performance report (Search results): overview, preliminary data and Pacific Time
• Performance report (Search results): troubleshooting data discrepancies
• Data anomalies in Search Console