A post that held page one for two years just gave back a month of clicks, and you want to know why. Search for why your blog traffic dropped suddenly and every result opens the same way: it was a core update, here is a seven-step recovery plan, and step seven is wait for the next one. That advice covers half of what happens to a dropped post. Two clocks run on every page that ranks. The external clock is the SERP, where Google periodically re-scores your page against everything else that ranks for the same query. The internal clock is the data inside the post, where every cited statistic gets older each day the page keeps ranking. The external clock gets watched by every rank tracker you pay for. The age of the claims inside the post goes unwatched, and that's the clock you can read yourself, today, from data you already have.
Two Clocks on Every Ranking Post
Open Search Console for the post that dropped. It probably still holds position for a decent share of its queries. Ranking while losing clicks is the first clue that more than one thing moved, since a clean re-ranking would show up as lost positions across the board. A drop looks like a single event on a single graph, so the instinct is to name a single cause, blame the update, and settle in to wait.
Both clocks deserve names. The external clock belongs to the SERP: a core update re-evaluates your page against its competitors, and your position can change without a word on the page changing. The internal clock belongs to the numbers: the 2023 benchmark you cited, the "according to" figure from a vendor report, each one stamped with a date that recedes further into the past every week. That aging is content decay, and it keeps time on page one just as steadily as it does on page five.
The two clocks rarely tick together, and that mismatch is what makes diagnosis worth doing. Only the internal clock leaves anything to inspect: every claim it governs comes with a printed date.
What a Core Update Does to Your Page
A core update is Google re-asking, at scale, whether your page is still the best available answer to its query. The judgment is broad and it happens entirely outside your page. Thousands of results get reassessed in the same window, and yours can slide because a competitor improved, because searcher intent shifted, or because the whole topic got re-weighted. No single edit reverses that, since the thing that changed was the field around you while your page sat still.
Sistrix analyzed the March 2026 core update across five countries and found one pattern in the winners: authority beats interchangeability. Domains that are the natural first stop for their topic gained visibility, and the swappable middle lost it. An update keeps asking whether your page is the obvious source for the question, and it grades on a curve drawn by everyone else writing about the same thing.
That shape makes a real update identifiable. It lands near the dates Google announces and moves many of your pages inside the same window. One post sliding for six months while its neighbors hold steady fails that test. When the footprint does match, the honest conclusion is that the cause sits outside the page, and the response is slow, external work: becoming a stronger answer over time.
All of that is real, and in the short term none of it is yours to fix. What the recovery checklists skip is the other question: whether the page you're defending still says true things, or whether its numbers expired somewhere in the second year of ranking.
Sudden Traffic Drop or Gradual Decay
Your own Search Console holds enough to separate the clocks before you commit to a fix. Three signals do most of the work: when the drop started, how many pages it touched, and which queries lost the clicks.
Sudden, sitewide, and aligned with an announcement reads as the external clock. One post fading alone reads as the internal clock winding down. Real drops usually carry some of each, so the signals tell you which half to act on first rather than which story to believe. On our own posts I pull the dates before anything else, since a date is the only part of a drop that comes with a timestamp I can verify.
One caution before you settle on a verdict. A number published two years ago can still be correct. When you can't confirm a claim either way, mark it for review rather than assuming the worst; the diagnosis exists to find the claims a reader would no longer trust, and age on its own is just the lead worth chasing.
Run the Decay Check Now
A confirmed core update is the comfortable verdict. It closes the case from outside the page: nothing to reopen, nothing you missed, wait it out. Look at what the update actually did before you accept that comfort, because it weighed your page against every alternative and liked the comparison less than it used to. The comparison is Google's to run. The page inside it is yours to change.
Before you check this drop, settle a prior one from memory. Call up the last post whose traffic fell and never came back the way you expected, and name what the cause finally turned out to be.
Whichever answer you picked, aging data is the only one of the four you can verify on the page itself today. The rest leave you waiting or guessing.
The decay half is the one you can settle from inside the page, and the reason to settle it first is the address it hands back. A flagged number comes with a location you can open, a single span you can stand in front of and edit, while the algorithm read leaves you nothing to act on but patience. Start where the cause has a known place on the page, and you either find it or rule it out in one pass.
Start with the half that leaves evidence. The Content Health Scanner below, the reading end of LiquiChart's living content system, pulls every dated statistic and cited source out of a page, scores each one for freshness, checks that the sources still resolve, and hands back a claim-by-claim list. The algorithm half of the drop sits outside anything it can read.
A flagged claim or a dead source hands you a located cause: one span with an address, and the fix is scoped to that span. A clean scan is a finding too. It rules out the decay half and moves the cause to the SERP side, which means the standard update advice finally rests on something firmer than a guess.
Flagged claims turn up often enough to justify the check. Across the state of content decay, roughly one in five posts that cite data carry numbers two or more years old, and the share of aged stats grows with neglect: about 2.0% of the cited stats in a fresh post, rising to 10.3% in a post that is two to three years old. Most of those numbers were right on the day they went in. Years without maintenance is what turns them, and decay starts exactly there.
When the Source Moves Under You
The internal clock has a second mechanism, and your own writing plays no part in it. A figure you measured yourself ages on a schedule fixed at publication, so you can predict when it needs a look. A borrowed figure ages on the source's schedule: the publisher can revise the number, restructure the page, or take it down, and your post receives no signal for any of it. The "according to" lines are where the internal clock usually shows first.
The scanner tests every cited URL for liveness in the same pass that flags aged stats, so a source that died or moved surfaces right beside the expired numbers. There's a wide gap between detecting when published data goes stale on a schedule and finding out from a traffic graph, and a standing watch on the pages you cite is what closes it. That watch is also how you fix dead source citations before they cost you a reader's trust.
Next Moves for Each Verdict
Three verdicts, three jobs. Update confirmed: hold the page steady and keep strengthening it as an answer, on a timeline you don't control. Decay confirmed: repair the flagged span, then audit your older posts by data age and let the refresh ranking-lift data decide which of them earn the same treatment. Both at once: the update exposed a number that had been aging the whole time, and that number is a five-minute edit on a single span.
A drop arrives feeling like a sentence handed down from somewhere you can't see. Then you open the post, read the dates, and find the repair is smaller than the rewrite you were bracing for. If I could check one thing before blaming an update, it would be the dates inside the post. A quarterly content audit checklist keeps the next drop from arriving as a surprise at all, and you'll never again need Google's announcement schedule to learn whether a drop was even about you.