Why did a post that ranked for two years lose traffic in a month? Search why your blog traffic dropped suddenly and the first answer is always a core update, with a seven-step recovery checklist that ends at "wait for the next one." That checklist is honest about half the problem. A drop has at least two clocks running on it: the external one, where a SERP gets reshuffled and your page is reassessed against everything around it, and the internal one, where the data the post stands behind ages out while the page keeps ranking. Every rank tracker reads the first clock. The second one, the age of the claims inside the post, is the one nobody told you to check, and it is the one you can read from your own Search Console today.
A Dropped Post Has More Than One Clock
The post that lost traffic this week probably still ranks for half its keywords. That gap, ranking but bleeding clicks, is the first sign that more than one thing is moving. A traffic drop feels like a single event with a single cause, and the search results treat it that way, so the instinct is to file it under "algorithm update" and wait.
Two clocks run on every ranking post. The external clock is the SERP, where a core update reassesses your page against everything around it and you lose position without changing a word. The internal clock is the data inside the post: a cited 2023 benchmark or an "according to" stat ages on its own schedule whether or not anyone reads the page. That second clock is content decay, and it keeps time even while the post sits on page one.
The two clocks rarely move together, which is the whole problem. You wait out the external one. The internal one carries a date on every number, and a date is something you can read today.
What an Algorithm Update Actually Is
A core update is the SERP looking again at whether your page is still the best answer to a query. It is broad and it is external: Google reassesses many pages at once against the competition, and a page can lose position without anything on it changing. You cannot edit your way out of a core update the way you can fix a broken link, because the thing that moved is the comparison around your page, while the page itself stayed exactly as it was.
When Sistrix analyzed the March 2026 core update across five countries, the pattern it found was authority beats interchangeability: the update rewarded the domains that are the natural first port of call for their topic, and pulled visibility away from the interchangeable middle. So a core update asks whether your page is still the obvious source for the question, and it answers against every other page chasing the same searcher.
That shape is what makes an update recognizable. A real core update moves many pages on a site at once, around the dates Google announces. It does not single out one post that has been slipping for months while everything around it holds steady. When the pattern matches, the honest read is that the cause sits outside your page, and the work is to make the page a stronger answer over time.
That is real, and it is genuinely out of your hands in the short term. The question the genre skips is whether the page you are defending is still accurate, or whether its numbers expired while it kept ranking.
How to Tell a Sudden Blog Traffic Drop From a Decay Drop
You can tell the two clocks apart from your own Search Console before you decide on a fix. The signals are timing, scope, and which queries moved. Pull the dates and the page-level data, and the shape of the drop usually points one way.
When the drop is sudden, sitewide, and lined up with an announced update, you are reading the external clock. A post that drops on its own while neighbors hold is the internal clock running down. Most real cases carry some of both, and the value of reading these signals is knowing which one to act on first. On our own posts, I start with the dates, because they are the only part of a drop that carries a timestamp I can check.
One caution before you commit to a verdict. Old data is not automatically wrong data. A number from two years ago can still be accurate, and the honest call when you cannot tell is to mark it for a look rather than assume the worst. The point of the diagnosis is to find which claims have aged past the point where a reader would still trust them, not to declare every old figure false.
Check the Decay Half Now
A confirmed core update is the comfortable verdict: the cause sits outside the page, and there is nothing in the post you have to reopen. The more useful read is that the algorithm is weighing your page against everything around it, and the data inside that page is the one part of the comparison you can still move. The algorithm responds to the page it finds. The lever you have is the data inside it.
Before you check this drop, settle one thing from memory. Think of the last post whose traffic fell and never came back the way you expected, and name what it actually turned out to be.
Whatever you picked, only one of those answers is something you can check on the page itself today. The other three you can wait out or guess at.
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.
So check that half directly, because it is the half that leaves evidence. Run the post you are worried about through the Content Health Scanner below, the reading end of a living content system that keeps published data accurate as it ages. It reads the decay half of the drop, pulling every dated stat and cited source out of the page and flagging which ones have aged past the point where the number still holds. It scores freshness, checks whether each cited source is still alive, and hands back a claim-by-claim list. It does not see the algorithm half, and it does not pretend to.
If it comes back with a flagged claim or a dead source, you have your located cause: a specific number or link with an address you can open, and the fix lands on that span rather than the whole post. If it comes back clean, that is a finding too. The decay half checks out, which moves the cause to the half this tool cannot see, a SERP that shifted under a page that is still accurate. That is the verdict that sends you to the algorithm checklist with a real reason to trust it.
This is not rare. Across the state of content decay, roughly a quarter of posts that cite data are carrying numbers two or more years old, and the share climbs the longer a post sits unmaintained: about 2.3% of the cited stats in a fresh post, rising to 13.1% in one that is two to three years old.
That climb is the part I keep coming back to. The data is rarely wrong yet. It is unmaintained, and unmaintained is where decay starts.
When the Source Moved Under You
There is a second way the internal clock runs down, and it has nothing to do with your own writing. A figure you measured yourself holds its date the moment you publish it, so it ages on a schedule you can predict. A borrowed figure runs on the source's schedule instead: that source can revise the number or let the page go dark and send your post no signal at all. The borrowed "according to" lines are where the internal clock usually shows first.
The scanner runs a liveness check on every cited URL in the post, so a source that died or moved shows up in the same pass that flags an aged stat. Catching it the next time a source changes, rather than the next time your traffic drops, is the difference between detecting when published data goes stale on a schedule and finding out from a graph. The same idea extends to a standing watch on the pages you cite, so a change at the source reaches you before it reaches your readers. That is also how you fix dead source citations before they cost you anything.
What Each Verdict Tells You to Do Next
Three readings, three different next moves. A confirmed update sends you to wait it out and make the page a stronger answer over time, which is slow work, and all of it external. A confirmed decay points you at a specific claim with an address, and from there the move is to audit by data age across the rest of your library and decide whether refreshing the post actually earns the effort. Both at once means the SERP exposed a number that was aging the whole time, and that number is a five-minute edit on a single span.
The drop that felt like a verdict handed down from the outside turns out to leave a date you can read from your own dashboard today. You check it on the post you are worried about, one claim at a time, and the fix is almost always smaller than the rewrite you were dreading. If I had to check one thing before blaming a drop on the algorithm, it would be the dates inside the post. A quarterly content audit checklist keeps the next one from being a surprise at all. You do not have to wait for the next core update to know whether this one was even about you.