How do you measure what a Google update did to your site, and why is it timing evidence rather than proof?

To measure what a Google update did to your site, compare whole weeks of daily Search Console clicks before the update began with whole weeks after its rollout finished, leaving out the rollout and a settling week, and judge the change against your site's ordinary swings. The result is timing evidence, not proof.

• Google recommends waiting at least a full week after a core update completes, then comparing with the week before it started (Google, Search Central, read 30 October 2026).
• Rollouts of the eight latest entries in the Search Status Dashboard's Ranking section lasted from 19 hours 30 minutes to 21 days 17 hours (Google, Search Status Dashboard, read 30 October 2026).
• Search Console retains the most recent 16 months of data, so an export reaches no further back (Google, Analytics Help, read 30 October 2026).
• In tests on simulated files with no update effect in them, between 9.8% and 13.1% of ordinary changes cleared Penlid's 90% line, against the 10% it is set at (Penlid, Google update impact check, read 30 October 2026).

Where do you find the dates of a Google update?

Google lists the latest ranking updates that are relevant to website owners on the Search Status Dashboard, with a start and an end for each. The dashboard's times are US/Pacific. Google says Search Console labels daily data in Pacific Time in every view except the 24-hour one, and Penlid's tool treats an export's dates the same way, so the two sets of dates can sit side by side. The table shows how much rollouts vary; each entry's own page gives the date its rollout was complete.

What does Google recommend after a core update?

Google's core updates page lists four steps for checking a traffic drop in Search Console: confirm the rollout has finished, compare the right dates, review top pages and queries, and look at each search type separately.

1. Confirm the rollout has finished, using the start and end dates on the dashboard.
2. Compare the right dates. Google recommends waiting at least a full week after a core update completes, then comparing with the week before it started.
3. Review top pages and queries. After a small drop in position Google advises against drastic action and against changing content that already performs well; after a large drop in position it advises a deeper assessment.
4. Look at each search type separately.

In our reading, that is a timing comparison of one week against one week: it says where to look, not how large a change is normal for your site. For edits you make yourself, see how long to wait after a content update.

How do you measure an update's effect, step by step?

Measure an update in five steps: take its dates from the dashboard, fix the windows, work out the change, place that change among your site's ordinary changes, and check what else happened on those dates. Penlid's free Google update impact check runs the arithmetic in your browser.

1. Take the dates from the dashboard. Note the day S the update began and the day E its rollout was complete, using the date in Google's "complete as of" post where there is one.
2. Fix the windows. Penlid's default is to compare the 14 days from S−14 to S−1 with the 14 days from E+8 to E+21. The rollout (S to E) and the 7 days after it are left out, and so are the newest 3 days of your file: Google says recent data can be preliminary and collected data is usually available in 2–3 days, and a file does not record when it was exported. Whole weeks count every weekday equally often.
3. Work out the change. Divide after by before and subtract one, for clicks and for impressions separately. The figure is flagged as mostly chance when the smaller window holds under 100 clicks (or impressions).
4. Place the change among your ordinary changes. Slide the same pair of windows along the rest of your file, away from every dashboard rollout, and count how many of those ordinary changes are smaller in size than this one. A share of 90% or more is "at or above the 90% line", which the tool calls a label for reading the page and not a test of significance.
5. Check what else happened. Look for another update in the same weeks, edits you made, the season and any documented Search Console data error. Anything that lands in those weeks moves the comparison along with the update, and the numbers cannot separate them.

The line is set so that one in ten ordinary changes clears it. In tests on plain noise about one in nine did, so the tool puts the expected number of chance clears at the number of changes placed times 11%; a strongly seasonal file clears it more often, so treat that number as a floor. A 4-week window needs about two years of data, more than the 16 months Search Console keeps, so merge older exports first with the Search Console history merger; the 16-month limit guide explains how.

Why is the answer timing evidence rather than proof?

A change that lines up with an update date shows when something happened, not why. Google calls its results dynamic and says the constant change can bring both gains and drops in organic traffic. Your own edits, the season, a competitor, a news cycle and a tracking change all land on dates too.

Our reasoning, not a Google statement: an update gives you no pages you can be sure were left alone, because Google describes core updates as broad changes to its ranking systems, not changes aimed at particular pages. A change you make to one page is easier to read: difference-in-differences sets the changed page against pages you left alone over the same dates, so an update moves both together (see how to tell if a content update worked). For an update, the only yardstick inside your file is your own history.

Three checks make a timing result stronger without making it proof (again our reasoning):

• Read your change log for edits, launches and migrations that fall inside either window or the rollout.
• Repeat the comparison on the same dates a year earlier if your export reaches that far, because seasonality repeats on a calendar; Google's debugging page suggests a 16-month view to see whether a drop recurs yearly.
• Split the result by search type, top pages and top queries, as Google's own steps ask, to see where the change sits.