We told a site its traffic was down 36%. It wasn't.

What the tool said

A site connected its Search Console account at 19:24. Eighty minutes later, the first batch of insights landed. Near the top:

Clicks down 36% week-over-week Last 7 days: 16 clicks vs 25 the previous 7 days.

Three more alerts said versions of the same thing: daily clicks had fallen below the forecast range, non-brand clicks were down 35%, and there was an anomalous low-click day in the last fortnight.

All four were wrong. Traffic had not moved.

What the data actually showed

Here is the real daily click series for that site across both weeks the rule compared. Nothing in it is smoothed or selected — it is every day in the window:

Daily clicks never leave the range 1–7. There is no cliff, no trend, no event. It is a small site with flat, noisy traffic.

The bug

Google publishes Search Console data on a two-to-three day delay. We document this on every report page — and then our insight rules ignored it. Each rule built its comparison window like this:

end = timezone.now().date()      # today
start = end - timedelta(days=6)

Ending the window at today means the current period always contains two or three days that Google has not published yet. Those days are not missing — they read as zero. The comparison period, sitting a week further back, is complete.

So every period-over-period rule was comparing a week with a hole in it against a week without one. The bias only ever runs one way: toward "decline".

Measured today, with the backfill long since complete, the correct window shows 29 clicks against 29 — dead flat. The buggy window shows a -59.4% fall out of the same underlying data.

The alert the site actually saw that evening was worse still — 16 against 25 — because the initial backfill had not finished either. A freshly connected account is precisely where this bug hit hardest, which is the part that bothers us most: it fired on people's first impression of the product.

How we found it

Not from a bug report. We were assembling a case study and checking whether the claims our own insights made were true. Seven structural findings — homepage concentration, dormant pages, click cannibalisation — held up exactly against an independent query of the warehouse. The homepage figure we reported as 97% measured 97.9%. The dormant-page count matched to the page and the impression.

The four decline alerts did not survive the same check. That is what exposed it.

The uncomfortable detail: this bug was already known in our codebase. The client-summary report carries a comment explaining that ending a window at today "zero-fills the tail and overstates period-over-period declines in a client-facing report", and it uses the last ingested date instead. That lesson was learned once, in one file, and never made it to the rules engine. Twenty-six rules had the same defect.

The fix

Rules now derive the end of every window from the last day actually ingested for that site, falling back to today minus the publish lag when a site has no ingestion history yet. It can never return a future date, so stale ingestion state cannot push a window forward instead.

The regression test reproduces the symptom rather than asserting the implementation: perfectly flat traffic at five clicks a day, with a three-day publish lag, used to raise "Clicks down 43% week-over-week". A second, structural test fails the build if any rule reintroduces a window that ends at today.

Why this page exists

An SEO tool that invents declines is worse than no tool at all. It sends people chasing problems that do not exist, and it erodes the one thing an analytics product has to sell, which is that the numbers are right.

We would rather publish the failure with the arithmetic attached than have you take our accuracy on faith. Every figure on this page came out of the warehouse while the page was being written, and the daily series above is there so you can add it up yourself.