Every core update, the same three questions land in my inbox and in every SEO community I follow. When is the next update coming? Did this one hit my site? And why did it hit me and not the site above me?
Google answers none of them. The Search Status Dashboard confirms updates after they start, Search Console shows you a traffic chart and wishes you luck, and the ranking systems themselves are a black box by design.
So over the past months, we built three free tools at ProofWrite that answer each question with actual measurement instead of vibes. This post explains what they do, and more honestly, what building them taught me about how search works in 2026.
None of them require a signup. Two of them never even see your data.
When is the next core update? Odds, not horoscopes
The Core Update Predictor does something that sounds impossible and is actually just statistics: it gives you the probability that Google's next confirmed core update starts within 30, 60, or 90 days.
The method is old reliability engineering. Take the gaps between every confirmed core update since 2018, fit a Weibull distribution to them, and you get a hazard curve: the chance the next update starts tomorrow, given that it has not started yet. The interesting property is that the hazard rises as the gap ages.
The longer it has been since the last update, the more likely the next one becomes. Every SEO already feels this ("we're overdue"), but the model puts a number on it. Adjust for the calendar months Google historically ships in, and you get a daily probability curve with a median date and honest uncertainty bands.
Here is the part I insisted on, because without it the whole thing is a party trick: a forecast you can only verify after the fact is worthless. So the tool freezes its displayed odds every single day. When Google later confirms an update, we publish the snapshot from the day before it started as a receipt.
What did the tool say before anyone knew? You can check. There is also a public backtest where the model is fitted only on updates that came before each prediction, scored against what actually happened, misses included. The whole method is documented in the open: how the predictor works.
Did the update hit me? Measure it, don't squint at it
The standard way to answer "did the core update hit us" is to stare at a traffic chart and argue. The Core Update Impact Checker replaces the squint with a defined measurement. You export your Search Console performance report, drop the zip on the page, and every confirmed core and spam update gets overlaid on your real traffic with a verdict: gain, loss, or flat.
Two design decisions matter here. First, privacy: the analysis runs entirely in your browser. Your Search Console data never touches our servers, which I consider the only acceptable way to build a tool that asks for GSC exports.
Second, clean windows: the tool compares the 14 clean days before a rollout started with the 14 clean days after it completed, and days inside any rollout window are excluded from both sides. Back-to-back updates like the October and November 2023 pair would otherwise contaminate each other's baselines, and most eyeball analyses do exactly that. Movements under five percent are reported as flat, because on most sites that is weekday noise, not Google.
If you did take a hit, the checker now estimates when recovery is realistic. The uncomfortable truth, which Google has said and every practitioner has observed, is that core update hits are typically reassessed at the next core update, not continuously. So the Recovery Estimator anchors your recovery checkpoint to the predictor's live forecast window. Deep hits get a second checkpoint one update cycle later, because they usually recover in stages.
There is also an anonymous benchmark: contribute your bucketed result (verdict, rounded change, niche, traffic size bucket, and nothing else, no domain, no URLs) and you see where you land among other analyzed sites.
Below a minimum sample count the tool refuses to show a benchmark at all, which felt like leaving conversion on the table until I accepted that a benchmark built on seven sites is a lie with a percentage sign.
Why did it hit me? The information gain era
This is the question the third tool grew out of, and it is the one that changed how I think about content. Since the March 2026 core update, information gain has moved from a Google patent to something you can watch moving rankings. Pages that only restate what the top 10 already says are losing visibility. Pages that add something are gaining it.
The Information Gain Analyzer makes this measurable for any keyword. It reads Google's live top 10, breaks every readable page into its information units (the distinct points a reader learns), and clusters the units that make the same point across pages.
The share of repeated points becomes a SERP Echo Score from 0 to 100. Run it with your own URL and you see your unique contribution: which of your points no top result covers, and which consensus points you are missing.
A concrete example. I ran "search engine optimization" through it. Seven of the top ten were readable, they produced 76 distinct points, and only 31 percent of the content mass repeated across pages. That is a diverse SERP, which surprised me until I looked at who ranks: Google's own documentation, Wikipedia, and government sites, each serving a different audience.
The tool now says this out loud in a "ranking leverage" verdict: on a diverse SERP, new information alone is a weak lever, and authority does the heavy lifting. On an echo chamber SERP, the opposite holds, and a genuinely new angle is your way in.
We deliberately did not dress this up as a keyword difficulty score, because difficulty depends on link data the tool does not have, and pretending otherwise would make it just another made-up metric.
What building these taught me
Three lessons from the build, because the failures were more instructive than the launches.
First, verify your inputs. An early version of the analyzer happily included Spanish-language pages in an English keyword analysis, because the search API's language parameter was a suggestion rather than a constraint. The fix was pinning the language and country explicitly in the search URL itself. If your tool measures the SERP, make sure it measures the SERP your user actually sees.
Second, never trust a language model's summary of evidence. The first clustering version let the model claim that a page "probably also makes this point", which quietly inflated echo scores by several points. I caught it because the numbers stopped adding up: the clusters claimed more point instances than the pages had points, which is arithmetically impossible.
Now the model must cite the exact page and point for every cluster membership, the server verifies every citation, and anything unverifiable is discarded. Scores dropped and became true.
Third, pre-register or shut up. The predictor's receipts exist because a prediction tool that shows its wins after the fact deserves zero trust, including from me. Freezing the forecast daily was one small cron job, and it is the single feature that makes the tool defensible in front of a skeptical audience.
Who should use what
If you run any site that lives on organic traffic: run the impact checker after every confirmed update, it takes a minute and costs nothing. If you plan content: run your target keywords through the analyzer before writing, cover the consensus points, and spend your effort on what the top 10 is missing.
If you like knowing what is coming: the predictor's alert list sends exactly two emails per update, one at the start and one at completion, and the current odds are on the page any time.
All three methodologies are published in full, formulas and limitations included, because tools that hide their math are asking you to take marketing on faith. That felt like the most useful thing we could contribute to an industry that runs on unverifiable claims.