How the ProofWrite Core Update Predictor Works

The full methodology behind proofwrite.io/core-update-predictor: the statistical model, the data, the pre-registered receipts, and the public backtest. Last updated August 2026.

Most update trackers are seismographs: they tell you an earthquake is happening. The Core Update Predictor is a forecast. Before it happens, the predictor tells you the probability that Google's next confirmed core update starts within 30, 60, or 90 days, with a verifiable paper trail.

This page documents exactly how those numbers are computed, so you can judge for yourself whether to trust them.

The data

The model is trained on one thing only: the start dates of every core update Google has publicly confirmed, as listed on the Google Search Status Dashboard. The list is refreshed hourly. Spam updates and other confirmed update types are tracked for the impact checker but are deliberately excluded from the prediction model because they follow a different cadence.

No volatility sensors, no SERP scraping, no private signals. The model's entire input is public and reproducible.

The model in one paragraph

The gaps between consecutive core update starts form a distribution: some updates land two months apart, some six. We fit a Weibull distribution to those gaps, the standard tool in reliability engineering for "time until the next event" questions.

Given how many days have already passed since the last core update, the fitted distribution yields a daily hazard: the chance the next update starts tomorrow, given that it hasn't started yet. We adjust each day's hazard by Google's historical seasonal launch pattern (some calendar months have seen far more core update launches than others) and accumulate the result into a day-by-day cumulative probability curve for the next 365 days.

Everything shown on the predictor page (the 30/60/90-day odds, the monthly bars, and the likely window) is read off that single curve.

Step by step

1. Interval extraction

Confirmed core updates are sorted by start date and the day-gaps between consecutive starts become the training sample. The current sample statistics (size, mean, median, shortest and longest gap) are shown on the predictor page and update automatically whenever Google confirms a new core update.

2. Weibull fit

The gaps are fitted by maximum likelihood. The shape parameter k solves

g(k) = Σ(xᵢᵏ · ln xᵢ) / Σ(xᵢᵏ) − 1/k − mean(ln xᵢ) = 0

which has a unique root, found by bisection. The scale parameter λ then follows in closed form:

λ = ( Σ xᵢᵏ / n )^(1/k)

A shape parameter above 1 — which the core update history consistently produces — means the hazard increases with time: the longer it has been since the last update, the more likely the next one becomes. This matches the intuition every SEO already has ("we're overdue"), but quantifies it.

3. Seasonality

Google has not launched core updates uniformly across the calendar. We count historical launches per calendar month, apply Laplace smoothing (+2 to every month, so a month with zero launches is dampened rather than zeroed), and clamp the resulting multipliers to the range 0.4–2.0 so no single month can dominate the forecast. These factors scale the daily hazard.

4. The daily survival walk

For each of the next 365 days:

ageₜ            = days since last update start + t
baseIncrementₜ  = (ageₜ/λ)ᵏ − ((ageₜ−1)/λ)ᵏ          # Weibull cumulative-hazard increment
pₜ              = 1 − exp(−baseIncrementₜ × seasonalₘₒₙₜₕ)
survivalₜ       = survivalₜ₋₁ × (1 − pₜ)
P(update by t)  = 1 − survivalₜ

This produces the cumulative probability curve. From it we read:

• P30 / P60 / P90: the probability the next core update starts within 30/60/90 days.
• Monthly odds: the probability mass falling inside each of the next six calendar months.
• Likely window: the dates where the curve crosses 25%, 50% (median), and 75%.
• Outer window: the 10%–90% band, for the honest "it could be this wide" view.

5. Rollout awareness

While a confirmed update is still rolling out (Google has announced a start but no completion, or the completion date is in the future), the page says so instead of pretending to forecast the next one mid-rollout.

Receipts: pre-registered predictions

A forecast you can only verify after the fact is easy to fake. So every day, a scheduled job freezes the exact numbers the page displayed, including the 30- and 60-day odds, the median date, and both windows, into a snapshot row.

When Google later confirms a core update, the tool publishes the snapshot from the day before the update started as that update's receipt: what we provably showed before anyone knew. Each receipt states whether the actual start date fell inside the 50% likely window and the 80% outer window. Updates from before snapshotting began simply have no receipt; we do not backfill.

The public backtest

The predictor page also runs a leave-future-out backtest on every render:

• For each historical core update (after the first 13, which are needed for a stable fit), the model is trained only on the updates that preceded it.
• The forecast is taken as of one week after the previous update started, and scored against what actually happened: was the real start inside the 50% window? Inside the 80% window? How many days off was the median?
• The 30-day probability is also read as of the day before the update actually began.

The backtest is deterministic: same history in, same scorecard out. It also includes the misses. Back-to-back updates that arrived before the forecast window even opened are counted and labeled as early misses, not silently dropped.

Honest limitations

• Small sample. Google has confirmed a limited number of core updates; the Weibull fit works with dozens of gaps, not thousands. The outer window is wide for a reason.
• The past is the only input. If Google structurally changes its release cadence, the model will lag until new gaps accumulate. The backtest will show this degradation publicly if it happens.
• This is a schedule model, not a mind reader. It models when updates tend to launch, not what they will do or whom they will affect.
• Probabilities, not promises. A 70% 30-day probability means roughly: in 10 parallel worlds, 7 see an update within a month. Three don't.

FAQ

Why Weibull and not a simple average? An average ("core updates come every ~N days") throws away the shape of the distribution and cannot express "overdueness". The Weibull hazard rises as the gap ages, which is what the data shows.

Do spam updates reset the clock? No. Only confirmed core updates enter the model. Spam updates are analyzed by the impact checker but follow their own cadence.

Can I embed the current odds? Yes. The odds badge at /api/public/core-update-odds-badge is an embeddable SVG that updates hourly and is free to use with a link back.