The morning the graph stopped making sense.
There is a moment every serious data professional has experienced at least once: you look at a graph you know as well as your own handwriting, and something does not add up. Not a dramatic collapse, not a red alarm — just a slight disproportion, a number that seems too round, a curve that flows too smoothly. An instinct before it becomes a conclusion.
In September 2025, thousands of SEO specialists across the world experienced this sensation simultaneously. Impressions in Google Search Console had dropped sharply — by 20, 30, sometimes 50 per cent — with no change to content, no algorithmic penalty, no official announcement. Clicks remained stable. Revenue from organic traffic had not shifted. Real positions in search results were identical to the day before.
What had disappeared was not the actual visibility of those websites. What had disappeared were impressions fabricated by bots and scrapers which had, for years, been systematically inflating one of the central indicators of SEO reporting — without Google ever flagging the problem.
And that was only the second act.
The first act had ended in silence, in January 2024, when Google withdrew a tool that had existed in Search Console for fifteen years — the Crawl Rate Limiter — with a two-paragraph note and no public discussion worth mentioning. The third act, the most serious of the three, would only be uncovered on 30 March 2026, by an Australian consultant who had noticed something strange in desktop impression spikes. Four days later, Google confirmed it: a logging error had caused Search Console to misreport impressions for fifty consecutive weeks.
A year. Nearly a full calendar year of compromised data. Discovered not by Google, but by the community.
This is not an article about a bug. It is an article about a pattern. A pattern Google repeats with a consistency that should, at some point, serve as a genuine warning to anyone who builds business decisions on data furnished by its platforms.
The tool that sat in a drawer for fifteen years without being used
Let us begin at the beginning — which is also the most innocent of the three signals.
On 8 January 2024, Google announced the removal of the Crawl Rate Limiter Tool from Search Console. The tool had been introduced in 2008 — eighteen years before this article was written — with a precise and legitimate purpose: it allowed site owners to ask Googlebot to reduce its crawl frequency when their servers were struggling under the load. A sound idea, logical implementation, genuine utility at the time of launch.
Gary Illyes, Google's representative to the webmaster community, explained the removal with disarming honesty: crawling algorithms had improved sufficiently that Googlebot now responds automatically to server signals. If it encounters HTTP 500 errors or rising response times, it reduces its own crawl rate — almost immediately. The manual tool, by contrast, could take over a day to apply new settings. And those who used it, in the vast majority of cases, set the speed to the absolute minimum — out of excessive caution or a straightforward misunderstanding of how it worked.
So: a tool that functioned poorly, was rarely used, and had long since been overtaken by its own internal logic. Nothing dramatic, taken in isolation.
But pause for a moment with this image: a tool that sits for fifteen years in an interface used by millions of webmasters, one which Google knew was rarely used and slow, and which remained there through institutional inertia — not through utility. How many other things remain in Search Console in precisely this condition? How many instruments persist there because nobody has decided to remove them yet, not because they still offer any genuine value?
This is the first fracture in what I call the illusion of officiality: the tacit conviction that if a tool appears on a Google platform, it is there because it works, because it is accurate, because it deserves trust. The Crawl Rate Limiter demonstrated that tools can outlive their usefulness by a considerable margin — surviving not through value but through neglect.
The data that never existed: the story of the &num=100 parameter
Now we arrive at the core of the problem. And the core is not pretty.
For at least several years prior to September 2025, Google Search Console had been reporting impressions for pages that no real user had ever seen. Those impressions originated from bots, scrapers and rank-tracking tools that exploited a technical parameter — &num=100 — which enabled the display of 100 search results on a single page, rather than the standard 10.
The mechanism was straightforward: instead of paginating through ten pages to collect positions 1–100, a monitoring tool could retrieve everything in a single query. Efficient for machines. Invisible to any actual human user, who had never seen those 100 results on one page and never would.
On 12–14 September 2025, Google silently disabled the parameter. No prior announcement. No transition period. It simply ceased to function.
The effect was immediate and, for many, alarming: impressions collapsed, graphs showed a vertical drop, and SEO professionals worldwide entered something close to panic. The phrase that circulated in the community was the alligator effect — on graphs from the preceding months, impressions had been climbing steadily whilst clicks remained flat, creating an expanding gap like the open jaws of an alligator. An anomaly visible in the platform's own data months before Google intervened — and one that nobody from the official teams had ever flagged.
This is where we must stop and ask the uncomfortable question.
If data from an official instrument had incorporated years of non-human activity as though it were genuine — what was the value of the reports we delivered to clients during all those years? What was the value of year-on-year comparisons built on these impressions? What was the value of content strategies justified by visibility growth that, in part, had never existed?
The honest answer is: less than we believed. Perhaps considerably less.
I am not suggesting that everything was false. Clicks were real. Rankings were real. Traffic in GA4 was real. But impressions — the metric used most frequently to demonstrate that a site's visibility was growing — contained a level of noise we could never have measured, because we did not know it was there.
And did Google know? Or did it not know? Either answer is troubling in its own way.
Fifty weeks of silence
If the first two signals can be absorbed, with goodwill and interpretive effort, into a narrative of normal technical platform evolution, the third no longer permits that generosity.
A logging error within Google's internal systems caused Search Console to over-count impressions for fifty consecutive weeks — from 13 May 2025 to 27 April 2026. Every search type was affected: web search, mobile, image search, merchant listings, job listings.
The consequences did not stop at impressions. CTR — click-through rate, the indicator used to assess the relevance of titles and meta descriptions against user intent — is calculated as the ratio of clicks to impressions. If the denominator is wrong, the ratio is wrong. The same applies to average position. Every SEO audit delivered during those fifty weeks that relied on these metrics was built on a faulty foundation — without the author of the audit having any means of knowing this at the time of delivery.
But the detail that stopped me cold, when I read the first serious analysis of this situation, was not the scale of the error. It was who discovered it.
Not Google. Not an internal quality assurance team. Not an automated anomaly-detection system.
The bug was identified by Brodie Clark, an independent SEO consultant in Australia, who on 30 March 2026 published on LinkedIn a detailed analysis of anomalies in desktop impression spikes — particularly for the merchant listings section. Four days later, Google confirmed the problem via a minimal note on its data anomalies page.
Two sentences. For nearly a year of compromised data.
My father — a mechanic, not an engineer — used to say that the loudest silence in any workshop is the one that follows a mistake you should have caught yourself. Silence after a customer's complaint is one thing. Silence after your own system has been misbehaving for a year, undetected, is quite another.
The Google Graveyard: a pattern, not an exception
Let us step back and consider the broader picture. Because what happened with Search Console is not an isolated incident. It is part of a pattern that Google repeats with a regularity that the technical community has taken to calling, with dry affection, the Google Graveyard.
Universal Analytics was retired in July 2024, after twelve years of active use. Millions of websites worldwide held years of historical data within the platform. Warning was given approximately a year in advance — which appears sufficient until you note that the deadlines were shifted twice — and any data not manually exported before the cut-off date was deleted permanently and irrecoverably. No backup, no exception, no appeal.
How many agencies delivered a proper warning to their clients? How many clients lost years of analytical data because nobody acted in time? There are no reliable statistics. There are, I suspect, many regrets.
Google Optimize — the A/B testing tool that thousands of marketing teams had woven into their workflows — was switched off on 30 September 2023, with a vague promise that Google would "invest in A/B testing in Google Analytics 4." The promise remained vague for two years. In 2025, internal Google documentation surfaced suggesting something resembling a new experimentation tool is under development — no public screenshots, no announced launch date, no guarantee that it will ever reach the ordinary user.
Google Cache — one of the oldest features of the search engine, active since 2001 — was phased out over the course of 2024, without a genuine transition period. Danny Sullivan, Google's Search Liaison, acknowledged publicly that he was sorry to see it go: "It's one of our oldest features." But regret does not restore the diagnostic instrument that SEOs had used to see how Google had indexed a page, to identify content discrepancies, to detect penalties. The only official alternative now remaining for this type of diagnosis is the URL Inspection tool in Search Console — the same Search Console that had just concluded fifty weeks of inaccurate reporting.
The Disavow Tool — also within Search Console — was informally flagged by John Mueller as a probable future removal: "At some point, I'm sure we'll remove it." No date. No timeline. Indefinite institutional suspension.
And the Google Search Console API connected to Looker Studio stopped delivering data in June 2025, April 2025, February 2025 and December 2023 — four times in fewer than two years. Each time, the problem was identified by users, reported in community forums, and resolved with delay. Each time, reporting dashboards displayed incomplete data or none at all, with no automatic alert to warn the user that what they were seeing no longer reflected reality.
The full picture: what was removed and when
| Tool | Active since | Removed / degraded | Real warning given |
|---|---|---|---|
| Universal Analytics | 2005 | July 2024 | 1 year (with deadline changes) |
| Google Optimize | 2017 | Sept. 2023 | 8 months, no clear replacement |
| Google Cache | 2001 | Sept. 2024 | A few weeks |
| GSC Crawl Rate Limiter | 2008 | Jan. 2024 | 2 months |
| GSC Disavow Tool | 2012 | announced, undated | — |
| GSC 50-week bug | — | May 2025 – Apr. 2026 | none |
| GSC API / Looker Studio | — | repeated outages 2023–2025 | none |
Looking at this table, the question that poses itself is simple: why do we continue to treat Google's data as an absolute point of reference?
The illusion of officiality and its cost
There is a belief deeply embedded in the digital industry — and amongst clients who commission digital services — that if it comes from Google, it must be correct. This belief has a logic: Google built the world's most widely used search engine, processes billions of queries daily, employs some of the finest software engineers on the planet. How could such a company supply inaccurate data?
Easily. By the same mechanism through which any complex large-scale system supplies inaccurate data: through undetected logging errors, through technical parameters exploited by external actors, through tools left to rust, through product decisions communicated insufficiently or not at all.
A badge does not make data accurate. A number on an official dashboard does not become true by virtue of appearing beneath Google's logo. It becomes reliable if it survives triangulation, if it correlates with independent sources, if it reflects a reality observable in other instruments as well.
The problem is that the SEO industry and the majority of web agencies have built reporting systems that treat GSC as the single source of truth. The monthly report travels directly from a Search Console CSV export to the client's slide deck. Nobody checks whether GSC clicks correlate with organic sessions in GA4. Nobody compares trends with Bing Webmaster Tools. Nobody cross-references impressions against independent rank-tracking data.
Why? Not for want of technical knowledge. For comfort. For apparent efficiency. For what I would call laziness dressed as confidence.
And that, in light of fifty weeks of false data, is no longer an acceptable oversight.
The responsibility that cannot be delegated
I want to be precise here, because the subject carries the temptation of sliding into easy criticism of Google whilst absolving everyone else of responsibility.
Google made errors. But Google's errors do not cover our own — those of agencies, consultants, and everyone who delivered reports based on a single data source without ever asking the question: what happens if this source is wrong?
Nobody knew in 2022 that GSC would accumulate a year-long bug in 2025. But we did know — or should have known — that any technical system can fail. We knew that digital data is, by its nature, a set of estimates and proxies, not absolute truths. We knew that triangulation is a foundational practice in any serious research methodology.
If a client reduced their content budget because "impressions fell" — impressions that later turned out to have been inflated by fifty weeks of logging errors — somebody delivered a flawed recommendation. That somebody was not necessarily acting in bad faith. But they were, with certainty, operating with insufficient rigour.
This is the hard kernel of the problem: delivering reports based on a single data source, without triangulation, without critical verification, is not a technical error — it is a choice of convenience. And choices of convenience have real consequences for the real people who pay real invoices on the basis of the conclusions in those reports.
What triangulation means in practice — and why it does not happen
Triangulation is not an exotic concept. It is what any serious journalist does before publishing a story: confirms the information from at least two independent sources. It is what any careful physician does before reaching a diagnosis: correlates the symptoms with test results rather than relying on a single reading.
In SEO, triangulation means several concrete and accessible things.
Bing Webmaster Tools provides twenty-four months of search performance data, entirely independent of Google's infrastructure. It is unaffected by GSC bugs, uninfluenced by the &num=100 parameter, and had no fifty-week logging error. If the trend from Bing correlates with the trend from GSC, you are on more solid ground. If it does not, you have something worth investigating.
Google Analytics 4 — organic sessions — remains a clean source for real traffic. Sessions cannot be fabricated by bots in the same way impressions can. A rise in impressions that does not translate into any increase in organic sessions is a warning signal, not a success to be celebrated.
Independent rank-tracking tools — Sistrix for the European market, Ahrefs, Semrush — maintain their own search databases, built independently of Google's APIs. Visibility trends from these tools should not diverge dramatically from GSC trends over extended periods. If they do, something is wrong somewhere.
Server logs, where they exist and are retained, offer the most granular level of truth about what actually occurred on a site: which URLs Googlebot accessed, at what frequency, with what results. Logs do not lie. They offer no attractive interface, produce no automatic graphs, but they are also free of fifty-week bugs.
All of these are available. Most are free, or included in tools that any serious agency already uses. What is absent is not access to data. It is the discipline to use that data systematically, rather than only when an anomaly becomes impossible to ignore.
On the speed with which digital memory disappears
There is a dimension to this story I have not seen discussed with sufficient seriousness: the psychological effect of the disappearance of Google tools on the institutional memory of the industry.
When Universal Analytics disappeared in July 2024, it took with it years of historical data for thousands of sites that had not exported in time. Not abstract data — the real behaviour of real users over five, seven, ten years. Data that cannot be recovered at any price.
When Google Cache disappeared in September 2024, it took with it the ability to see how Google had indexed a web page at a specific point in the past. For researchers, journalists, content analysts, for anyone wishing to document change over time — a window closed permanently.
When Google Optimize disappeared in September 2023, the results of thousands of A/B experiments conducted by marketing teams who had not exported their data vanished with it. Years of learnings about user behaviour, evaporated.
There is a saying about not knowing what you have until you lose it. In the context of Google platforms, the more accurate version is: you do not know you might lose it until it is already too late to export. Google's repeated model is the announcement with minimal warning, the short deadline, the deletion without appeal.
And we, as an industry, have normalised this behaviour. We have accepted it as a natural condition of working with large technology platforms. We have forgotten that normal does not mean acceptable.
What should change — and why it probably will not
Let us be honest to the end.
Google will not change this pattern in response to an article, or ten articles, or a thousand complaints in SEO forums. The pattern exists because it serves the company's interests: legacy tools are costly to maintain, historical data is costly to store, detailed communication about internal failures would generate legal and reputational vulnerability. "Why announce that your data was wrong for a year when you can add a two-sentence note to a page nobody reads?"
This is the logic of a large institutional actor. Not admirable, but predictable.
What can change is our own behaviour. That of agencies. Of consultants. Of those who deliver reports and strategies based on digital data.
The first change is epistemic: we must stop treating any data source — Google included — as an infallible oracle. Data are estimates. Platforms are systems that can fail. Official does not mean correct.
The second change is methodological: the systematic introduction of triangulation into every reporting process. Not as an optional enhancement for premium clients, but as a baseline practice — the minimum professional standard of the trade.
The third change is contractual: clear documentation, in every client relationship, of the limitations of the instruments being used. "This report is based on Google Search Console data, which carries the known limitations documented at [link]. We recommend triangulation with sources X, Y, Z." One sentence. A few seconds. A significant difference in the event of error.
The fourth change is archival: regular export of data from any Google platform, not as a reaction to a shutdown announcement, but as a permanent preventive practice. If a client's Universal Analytics data mattered, it should have been exported and stored every quarter — not in the panic of the month before the shutdown.
Returning to first principles
My father — a mechanic, not a software engineer — had a rule he applied before any intervention on an engine: "Don't trust what the instrument tells you. Put your hand on it and feel." Not because diagnostic equipment was unreliable. But because he knew that no instrument is infallible, and that his hand, corroborated with the instrument, was more trustworthy than the instrument alone.
It is a principle as old as mechanics itself: tools are aids, not substitutes for judgement.
We forgot this. We let the graphs in Google Search Console think on our behalf. We delivered reports as though the numbers in the platform were direct reality, rather than a mediated — and partially distorted — representation of reality. We confused convenience with rigour.
The fifty-week bug is not a catastrophe from which the industry will not recover. It is a lesson the industry deserves, if it has the wisdom to hear it.
The lesson is not that Google is malicious or that Search Console is useless. The lesson is that any tool, however official, however large the company behind it, can be wrong — and its error becomes your error the moment you distribute it to clients without having verified it.
Those who verify do not make the same mistake twice. Those who do not may never know how many times they have been wrong.
Epilogue: the data that never existed
Somewhere in Google's servers there is a database in which false impressions are recorded — those generated by bots through &num=100, those inflated by the logging error of 2025. We will never see them. We will never know precisely by how much they deviated from reality.
And that, perhaps, is the most unsettling part of the story: not that the data were wrong, but that we will never be able to quantify exactly how wrong they were. The reports delivered during those years remain in folders. The decisions made on the basis of those reports remain made. Their effects are in the world — in budgets allocated or withdrawn, in content strategies adopted or abandoned, in performance evaluations that determined hirings or dismissals.
False data do not disappear when the bug is fixed. They persist in their consequences.
This is why methodological rigour is not an academic indulgence. It is the respect owed to the people who make real decisions on the basis of our work.
Sources and references
Google tool deprecations
- Gary Illyes / Google Search Central — statements on Crawl Rate Limiter Tool deprecation (Nov. 2023 – Jan. 2024)
- Search Engine Land — Googlebot crawl rate tool in Search Console is going away (Nov. 2023)
- Search Engine Journal — Google Removing Crawl Rate Limiter Tool From Search Console (Nov. 2023)
The &num=100 parameter collapse — September 2025
- Smith Digital — Why Google Search Console Impressions Dropped in Sept 2025 (Dec. 2025)
- Rankfuse — Why Google Search Console Impressions Dropped in September 2025 (Dec. 2025)
- Wenstein Beyond Digital — Your Google Search Console Data Just Changed Forever (Oct. 2025)
- Search Engine Land — Why Google Search Console impressions fell (and why that's good) (Oct. 2025)
- Garrett Digital — Why Google Search Console Impressions Dropped: September 2025 (Sept. 2025)
The fifty-week bug
- Claudio Novaglio — Google Search Console bug 50 weeks (May 2026)
- Brodie Clark — LinkedIn analysis (30 March 2026)
- Google Data Anomalies Page — official confirmation (3 April 2026)
Broader Google ecosystem deprecations
- Bounteous — So Long, Universal Analytics: GA4 Replaces Universal Analytics (July 2023)
- MarTech — Google is turning off all Universal Analytics services and APIs (April 2024)
- Search Engine Land — Google Optimize will sunset this year (Jan. 2023)
- Optimizely — Google Optimize has sunset, what should you do now? (2023)
- Convert.com — Google Is Back? Google Making Personalisation Moves (Dec. 2025)
- TechHelp.ca — Google Removed Cache: What SEOs Need to Know (2024–2026)
- Search Engine Journal — Google Removes Cache Search Operator Documentation (Oct. 2024)
- SEO TL;DR Substack — Google Removing the Disavow Tool (May 2024)
- SE Roundtable — Google Search Console API Data Stuck Since June 3rd (June 2025)
The Questions
Twenty Questions on Google's Pattern of Deprecation — With Answers
1. Is Google Search Console actually unreliable, or is this article overstating the case?
Neither entirely. The article is not arguing that Search Console is worthless — it is arguing that it has been treated as infallible when the evidence does not support that treatment. Clicks, index coverage, URL inspection and crawl stats remain reliable. What has been demonstrably compromised are impressions and their derivatives — CTR and average position — across specific, documented periods. The case being made is for calibrated scepticism, not wholesale rejection. The distinction matters enormously in practice.
2. Why did Google not detect the fifty-week logging bug itself?
That question has not been answered publicly, and Google has not volunteered an explanation beyond the minimal confirmation note. The most plausible technical explanations involve the bug affecting a logging layer that was not subject to automated consistency checks — meaning the processed output (what users see in the interface) diverged silently from the underlying raw data without triggering any internal alert. Whether this reflects a gap in monitoring infrastructure, a staffing reduction in the relevant team, or something more systemic is not known. The silence around the cause is itself informative.
3. Does the &num=100 deprecation mean all historical impression data is useless?
Not all of it, and not equally. The contamination was heaviest in desktop impressions, particularly for sites that ranked between positions 11 and 100 — the range most frequently harvested by rank-tracking bots using the parameter. Sites with strong rankings in positions 1–10 were less affected, since those positions appear on the standard ten-result page and would have been counted regardless. However, any year-on-year comparison that crosses the September 2025 threshold without accounting for the discontinuity is structurally compromised. The data before that date and after it are not directly comparable.
4. What exactly is Bing Webmaster Tools, and is it genuinely independent enough to serve as a triangulation source?
Bing Webmaster Tools is Microsoft's equivalent of Google Search Console — a free platform providing search performance data (impressions, clicks, average position, crawl information) for sites appearing in Bing search results. It is independent of Google's infrastructure in every meaningful sense: different crawlers, different logging systems, different data pipelines. Its primary limitation as a triangulation source is market share — Bing accounts for approximately 3–5% of global search traffic, which means the absolute numbers are smaller and the statistical significance of individual keyword trends is lower. However, for directional triangulation — confirming whether a broad trend is real or an artefact of a GSC anomaly — it is perfectly serviceable, and its twenty-four months of data history makes it particularly valuable for longer-term comparisons.
5. Could the &num=100 parameter have been deprecated for legitimate reasons unrelated to data quality?
Absolutely, and probably was. The most credible explanations are: infrastructure cost (serving 100 results per query consumes roughly ten times the server resources of serving 10, at billions of queries per day); protection of search data from AI training scrapers (companies building large language models were harvesting SERP data at scale via this route); and improved data hygiene as a by-product of removing non-human traffic from the measurement pipeline. The fact that the deprecation had beneficial effects on data quality does not mean it was motivated by data quality. These explanations are not mutually exclusive, and Google has not disclosed its primary rationale.
6. How should an agency communicate the fifty-week data anomaly to existing clients?
Directly and proactively, without waiting to be asked. A brief written note explaining that Google confirmed a logging error affecting impression data between 13 May 2025 and 27 April 2026, clarifying which reports are affected (those relying on impressions, CTR or average position from this period), and proposing a revised baseline built from clicks and organic sessions in GA4 is the minimum responsible action. Attempting to quietly reframe reports without disclosure is, at best, misleading. At worst, it constitutes a breach of professional duty to clients who made decisions on the basis of those figures. The discomfort of the conversation is not a valid reason to avoid it.
7. Is the "Google Graveyard" problem unique to Google, or do other major platforms behave similarly?
Other large platforms exhibit similar patterns, but Google's case is distinctive for two reasons. First, the tools being deprecated are often the only official channel through which publishers can understand their relationship with the platform — there is no independent equivalent of Search Console for Google Search. When Google removes or degrades that channel, there is no substitute with equivalent authority. Second, Google's market dominance means that its data is embedded in a vast number of business processes globally. The deprecation of a Facebook analytics feature is disruptive; the deprecation of the only window into the world's largest search engine is structurally different in kind.
8. What is the "alligator effect" precisely, and is it a recognised technical term?
It is a descriptive term that emerged from community analysis in late 2025 rather than a formally recognised technical concept. It refers to the visual pattern on GSC performance graphs — visible from approximately February 2025 onwards — in which impressions climbed steadily whilst clicks remained flat, creating a diverging gap that resembled the open jaws of an alligator when viewed in chart form. The pattern was retrospectively identified as a signal of the impression inflation caused by bot activity via &num=100. It is not a Google-defined term, carries no official status, and should be understood as useful community shorthand rather than technical taxonomy.
9. If Google fixes the bug going forward, are reports from May 2026 onwards reliable again?
Provisionally, yes — for impressions. Google confirmed the bug was resolved as of 27 April 2026, and data collected after that date should reflect accurate logging. However, "reliable" requires a caveat: the removal of &num=100 inflation was a separate event (September 2025), already incorporated into the data stream by the time the logging bug was confirmed. So post-April 2026 impressions are both free from the logging error and already adjusted to the post-&num=100 baseline. Comparing them to any pre-September 2025 figures without explicit adjustment remains problematic.
10. Why did it take an independent consultant in Australia to find a year-long data error in one of the world's most used web platforms?
This is perhaps the most important question the article raises, and the honest answer is that we do not know. The possibilities range from the benign (the anomaly was subtle enough to be invisible without careful segment-level analysis of the kind Brodie Clark conducted) to the concerning (internal monitoring existed but was not acted upon promptly). What can be said with confidence is that the community-before-company discovery sequence is not unprecedented in Google's history — the &num=100 anomaly was similarly identified externally before any official acknowledgement. Whether this reflects structural under-investment in data quality monitoring, a culture of delayed disclosure, or simply the reality that a vast user base provides better coverage than any internal team is a question worth asking more loudly than it currently is.
11. Does this analysis apply equally to Google Analytics 4, or is GSC a special case?
GA4 has its own documented limitations and controversies — its data model differs substantially from Universal Analytics, session definitions changed, and the migration destroyed historical comparability for many businesses. However, GA4's core event and session data has not been subject to the same type of systematic inflation as GSC impressions. The fundamental measurement of whether a user visited your site and what they did there is more robust than the measurement of whether a search result was displayed. GSC sits at a more fragile point in the data chain: it depends on Google's internal logging of its own search result displays, which are less directly observable than website visits and therefore harder to verify through independent means.
12. What does "triangulation" look like in a practical monthly SEO report?
In a well-structured monthly report, triangulation might take the following form: GSC clicks (primary source for search-driven traffic volume) are cross-referenced with GA4 organic sessions (confirming that click-level trends are reflected in actual site visits); GSC average position trends are cross-referenced with a rank-tracking tool for the site's core keywords (confirming that position movements are real rather than artefacts of impression weighting changes); and any significant impression movement is checked against Bing Webmaster Tools for directional confirmation. If all three sources point in the same direction, confidence in the reported trend is high. If they diverge, the divergence itself becomes the story — something worth investigating rather than ignoring.
13. Is the deprecation of older tools always negative, or are there cases where removal improves the ecosystem?
Removal can genuinely improve the ecosystem when the tool being retired is misleading users, consuming resources that could improve other products, or masking better alternatives. The Crawl Rate Limiter is arguably a case where removal was the right decision — the manual tool's latency made it worse than useless in many scenarios, and users who relied on it may have been operating under a false sense of control. The problem is not deprecation per se but the combination of: insufficient notice, inadequate documentation of what replaces the functionality, and (in the case of data platforms) no provision for historical data portability. Deprecation without transition planning is where the pattern becomes genuinely harmful.
14. How does this situation relate to the broader question of AI Overviews reducing organic click-through rates?
They compound each other in an unhelpful way. AI Overviews — Google's generative search summaries — reduce clicks by answering queries directly within the search results page, meaning users receive information without visiting the source site. This produces a genuine, structural reduction in organic CTR. However, if you are trying to measure this reduction using GSC CTR data from the affected period (May 2025 – April 2026), your denominator (impressions) was artificially inflated, which means your calculated CTR was artificially deflated — making the AI Overview effect appear larger than it actually was. Analysts attempting to quantify the impact of AI Overviews using GSC data from this period may have significantly overestimated it.
15. What happened to sites that used the Disavow Tool extensively and now face its potential removal?
If the Disavow Tool is eventually retired, the practical impact will likely be modest for most sites. John Mueller's rationale — that Google's algorithms have become sufficiently capable of ignoring manipulative links without manual instruction — is broadly credible. For sites under active manual actions related to link spam, the tool remains the appropriate instrument until it is formally withdrawn. The more immediate concern for heavy users of the tool is whether a historical disavow file will continue to be honoured after the tool's removal — something Google has not yet addressed publicly. This ambiguity is itself a product of the pattern described in the main article: announcing removal without a complete transition framework.
16. Is there a case that Google's data problems are getting worse over time, or have there always been anomalies we simply did not notice?
Both are probably true simultaneously. There have always been anomalies in GSC data — the platform has never claimed to offer exact rather than sampled data, and the 16-month data retention limit has always constrained longitudinal analysis. What may be changing is the scale of the anomalies relative to the trust placed in the data. As more business decisions — including AI-driven content strategies, budget allocations and performance evaluations — are made on the basis of GSC figures, the cost of silent errors rises. The platform's credibility problem is partly intrinsic and partly a function of how much weight the industry has chosen to place on it.
17. Could this article itself be wrong — for instance, if the fifty-week bug turns out to have been less significant than described?
Yes, and that possibility should be acknowledged openly. The analysis of the bug's significance relies on third-party reporting (primarily Claudio Novaglio's analysis and the community response to Brodie Clark's LinkedIn post) rather than on direct access to Google's internal data. Google's own two-sentence confirmation is unhelpfully sparse. If the over-counting was, for example, concentrated in a small number of search types or geographies and not distributed across the platform as broadly as reported, the practical impact would be narrower than described here. The article proceeds on the basis of the most thorough independent analysis available as of May 2026. It does not claim certainty it does not possess.
18. What would responsible platform governance look like from Google's side?
Several things, none technically difficult. Automatic user notifications when a data anomaly is detected, comparable to how Google notifies site owners of indexing issues. A minimum notice period of six months for any tool deprecation, with a clearly documented migration path before the deprecation is announced. Guaranteed data portability windows — at least twelve months during which historical data can be exported in machine-readable formats. Transparent public documentation of known data quality limitations, maintained in real time rather than retrospectively. And, specifically for data anomalies: a commitment to retroactive correction or, where correction is not feasible, a clear statement of which metrics are affected and by what approximate magnitude. None of this is radical. It is what any regulated data provider would be required to offer.
19. Should SEO professionals be more publicly critical of Google's data quality, or does doing so damage client confidence unnecessarily?
Professional candour and client confidence are not as opposed as they might appear. Clients who receive honest assessments of data limitations are better equipped to make sound decisions; clients who receive artificially confident reports based on unreliable data are exposed to the risk of decisions grounded in fiction. The short-term discomfort of saying "this data has known limitations and here is how we account for them" is outweighed by the long-term trust built through transparent methodology. The industry's reluctance to criticise Google's data quality publicly is understandable — Google controls the traffic many agencies depend upon — but it is, in the end, a form of institutional cowardice dressed as client service.
20. What is the single most important practical change a solo SEO consultant or small agency could implement tomorrow?
Export your clients' GA4 organic session data and GSC click data monthly and store it in your own system — a spreadsheet, a database, anywhere you control. Do this regardless of how reliable the platforms currently appear. The lesson of Universal Analytics is not that Google will always warn you in time. The lesson is that it may not, and that the data you do not hold yourself is data you can lose without recourse. This takes perhaps thirty minutes per client per month. It is the minimum viable act of professional responsibility in an ecosystem where the rules of data retention are written by a single actor and subject to change without meaningful negotiation.
Author's Note: Limits, Tensions and Tools
What this piece can and cannot claim — and why that matters
On the sources
Every factual claim in the main article and in these questions rests on published reporting from identifiable sources — Search Engine Land, Search Engine Journal, Claudio Novaglio's independent analysis, Brodie Clark's LinkedIn documentation, Google's own data anomalies page, and community reporting via SE Roundtable and comparable forums. These sources are named and linked in the references section.
What the piece does not have access to is Google's internal data. The fifty-week bug is described and its implications are analysed, but the precise magnitude of the over-counting — how many impressions, for which sites, distributed how across geographies and search types — is unknown. Google's public confirmation ran to two sentences. The analysis therefore relies on the best available external reconstruction, not on verified internal figures. Where the magnitude is uncertain, I have tried to say so explicitly.
On the framing
The article is written from a critical standpoint. It argues that a pattern exists and that the pattern has costs. This framing involves a choice: I could have written an equally accurate piece emphasising that Google provides Search Console free of charge, that the platform delivers genuine value, and that the industry has no entitlement to error-free data from a third-party tool it does not pay for. That framing would also be defensible.
I chose the critical framing because I believe the industry's default posture — treating Google's data as authoritative without systematic verification — is more dangerous than any criticism of the platform, and that the available evidence supports a challenge to that posture. Readers who find the framing too adversarial are, I think, reflecting a reasonable alternative view rather than an incorrect one.
On the tools used in writing
Both the main article and these questions were developed in collaboration with Claude Sonnet 4.6 (Anthropic), working from a research brief and bibliographic foundation I compiled independently. The research — identification of sources, verification of dates, confirmation of factual claims — was conducted by me using web search across the sources cited. The writing process involved iteration between my editorial direction and the model's drafting, with final decisions on framing, tone and inclusion resting with me.
I document this not as a disclaimer but as a matter of transparency I consider professionally obligatory given that this site has written extensively about AI's epistemic limits. Using a tool whilst concealing its use would be a form of inconsistency I am not willing to practise.
The model was useful for: maintaining structural coherence across a long piece, ensuring British English consistency throughout, and drafting the Q&A pairs from a set of themes I identified. It was not useful for: original research, source verification, or the editorial judgements about what to include, emphasise or qualify. Those remained mine.
On the tensions
There is a tension in this article that I want to name rather than smooth over.
The piece criticises Google for communicating data failures with minimal transparency. It then argues that professionals should communicate data limitations clearly to their clients. This is not contradictory — different actors have different responsibilities — but the tension exists because the professionals who should be delivering these honest conversations often depend, commercially, on the goodwill of Google-directed traffic. Criticising the platform that controls your clients' visibility is not cost-free. I have tried to argue for what is correct rather than for what is comfortable, but I recognise that the argument is easier to make from a position of relative editorial independence than from within an agency whose largest clients rank on Google.
A second tension: the article calls for data triangulation as a standard practice whilst acknowledging that the alternative sources — Bing Webmaster Tools, GA4, server logs, independent rank trackers — each carry their own limitations. Triangulation does not produce certainty; it produces better-calibrated uncertainty. The improvement is real and worth pursuing, but I do not want to imply that the answer to one imperfect source is a collection of perfectly reliable ones. It is not. The answer is a more honest relationship with the fundamental imprecision of digital measurement.
On what is missing
This piece does not address: the legal and regulatory dimensions of a major platform supplying inaccurate data to businesses that rely on it commercially — a question that may eventually attract the attention of competition regulators, particularly in Europe. It does not examine in detail how AI-generated search summaries are likely to change the relevance of impression-based measurement over the next two to three years, beyond the brief mention in question 14. And it does not offer a comprehensive evaluation of GA4 as a data platform, which has its own significant documented problems that deserve separate treatment.
These are not omissions born of ignorance. They are scope decisions. A 4,000-word essay cannot do everything.
A final word on certainty
The strongest claim in this article is also the most verifiable: Google confirmed a logging error affecting Search Console impression data for fifty consecutive weeks, and that confirmation came four days after an independent consultant identified the anomaly publicly. Everything else — the interpretation of what this means, the argument about professional responsibility, the call for methodological change — is analysis built on that foundation.
Analysis can be challenged. The foundation, as of May 2026, cannot.
Google is not alone
Big Tech and the Pattern of Unilateral Tool Deprecation
1. Meta / Facebook — cascading deprecations, 2024–2025
The closest structural parallel to Google's behaviour, operating at comparable scale and with comparable opacity.
API deprecations — rolling programme
Meta implemented a continuous programme of API deprecations throughout 2024 and 2025. In August 2025, it deprecated additional Page Insights API metrics including the 'impressions' and 'page fans' measurements, with a 90-day notice window. In October 2024, it removed over 100 unique metrics from the Ads Insights API, affecting thousands of marketing technology platforms that depended on unique_actions and cost_per_unique_action_type fields. The October 2024 release of Graph API v21.0 simultaneously announced the deprecation of the Messaging Events API, scheduled for September 2025.
Sources:
- PPC Land — Meta deprecates additional Page Insights API metrics from November 15 (Aug. 2025)
- Sprout Social Support — Facebook Metric Deprecation — November 2025 (Nov. 2025)
- PPC Land — Meta discontinues Facebook Like and Comment buttons for external websites (Nov. 2025)
Facebook Groups API — 90-day notice, no replacement
In January 2024, Meta announced the deprecation of the Facebook Groups API — used by developers and businesses to schedule posts to Facebook Groups — with 90 days' notice. The removal included all associated permissions and reviewable features. Third-party social media management tools including Zoho Social were forced to discontinue Facebook Groups support entirely, affecting users who had scheduled content set to publish after the deprecation date.
Sources:
- TechCrunch — Meta cuts off third-party access to Facebook Groups, leaving developers and customers in disarray (Feb. 2024)
- Zoho Help Community — Discontinuing Facebook Groups due to API deprecation (Apr. 2024)
Facebook Like and Comment social plugins — discontinued November 2025
On 10 November 2025, Meta announced the discontinuation of two Facebook Social Plugins — the Like button and the Comment button — for external websites, as part of a broader platform simplification strategy. The announcement directed developers to a support FAQ, though technical support for deprecated features typically diminishes as discontinuation dates approach. Community analysis concluded that Meta's deprecations should be treated as a continuous pattern rather than isolated incidents.
Source: PPC Land — Meta discontinues Facebook Like and Comment buttons for external websites (Nov. 2025)
2. Twitter / X — destruction of a developer ecosystem in 48 hours
The most extreme documented case of unilateral deprecation without meaningful warning — and the most instructive comparison for the Google pattern.
Free API access removed — February 2023
On 2 February 2023, Twitter announced that free access to its API would end on 9 February — seven days' notice. The move broke or severely limited dozens of third-party tools including analytics platforms, tweet schedulers, archive managers, and academic research tools. Developers willing to pay for the enterprise tier reported receiving no response from Twitter's enterprise sales team in the days following the announcement, whilst their API access was simultaneously cut without notice. The new pricing structure set the Pro tier at $5,000 per month — prohibitive for independent developers and academic researchers.
Sources:
- Engadget — Twitter shut off its free API and it's breaking a lot of apps (Apr. 2023)
- The Register — No more free API access, says Twitter (Feb. 2023)
- TechCrunch — Twitter to end free access to its API (Feb. 2023)
- Social Media Today — Twitter's Cancelling Free Access to its API, Which Will Shut Down Hundreds of Apps (Feb. 2023)
Third-party clients killed — January 2023
Two weeks before the API announcement, Twitter killed a number of third-party clients with no official word as to why. Apps including Tweetbot, which had operated for over a decade, simply stopped working. No notice, no explanation, no timeline. The Iconfactory co-founder described it as the destruction of "thousands of outside developers who have built useful tools, games, and analytics on the platform."
Source: The Register — No more free API access, says Twitter (Feb. 2023)
Ongoing restrictions — 2024–2025
X continued to tighten API restrictions through 2024 and 2025. In August 2025, it removed the ability to like posts and follow accounts via the free API tier. X's API changes impacted the developer ecosystem so severely that tools such as Tracy Chou's Block Party pivoted away from the platform entirely. EU regulators partially reversed the access restrictions for researchers, citing obligations under the Digital Services Act — a rare instance of external regulation overriding platform unilateralism.
Sources:
- TechCrunch — X pulls the ability to like and follow from its developer API's free tier (Aug. 2025)
- TechCrunch — X launches top-up packs for its developer API (Mar. 2024)
- DeleteOldPosts — Twitter/X API Changes 2024–2026: What They Mean for Tweet Deletion Tools (2026)
3. Microsoft — 16 features deprecated in a single year
A different variant of the same pattern: large-scale deprecation driven by strategic repositioning rather than monetisation, but with equivalent consequences for dependent users.
2023 — the year of mass deprecation
In 2023 alone, Microsoft deprecated 16 different features in Windows 11. The most significant included:
- Cortana — Microsoft's virtual assistant, active since 2014 and present across Windows, Xbox, Teams, and Outlook mobile, was retired as a standalone app in spring 2023 and from all Microsoft 365 mobile integrations by autumn 2023. Replaced by Microsoft Copilot, which required users to re-learn and re-integrate a different assistant architecture.
- WordPad — present in Windows since 1995, deprecated in 2023 with no direct replacement inside the OS.
- Windows Mixed Reality — phased out in 2023 after Microsoft stepped back from building native VR/AR into Windows. Developers who had built applications on the platform received limited transition guidance.
- Azure Kinect DK — a developer kit born from Xbox Kinect technology, sunset in 2023 due to low adoption. Healthcare and robotics projects built on its motion-tracking capabilities were left without a successor path.
- Mail and Calendar apps — placed in maintenance mode in 2023 and retired in 2024, replaced by a new Outlook client built on web technologies. Users who had configured Mail and Calendar over years were required to migrate to a substantially different application.
Sources:
- Windows Central — Microsoft killed 16 different Windows 11 features in 2023 (Dec. 2023)
- Windows Central — Here are all the Microsoft deprecated products as listed by Microsoft Graveyard (Jan. 2024)
- KilledBy.tech — Microsoft 2022–2025: Another Batch of Goodbyes (Nov. 2025)
- Microsoft Support — End of support for Cortana (2023)
- Neowin — Every Windows feature Microsoft removed or deprecated in 2025 (Jan. 2026)
The Microsoft Graveyard — community documentation
The volume of Microsoft deprecations prompted a developer to build "Microsoft Graveyard" — an open-source website cataloguing all deprecated Microsoft products and their end-of-support dates. The project was explicitly inspired by the "Killed by Google" project, itself a community response to Google's pattern of product abandonment. The existence of parallel community-built graveyards for both Google and Microsoft is itself a signal: when users must build their own tools to track a platform's own deprecation history, the official communication is structurally inadequate.
Source: Windows Central — Here are all the Microsoft deprecated products as listed by Microsoft Graveyard (Jan. 2024)
4. Apple — the quieter pattern
Apple's deprecation pattern is structurally different — it tends to operate through hardware cycles and OS upgrade pressure rather than API withdrawals — but the effect on dependent users is comparable.
iCloud backups — deleted without recovery option
In December 2024, Apple ended support for iCloud backups on devices running iOS 8 or earlier. Existing pre-iOS 8 backups stored in iCloud were deleted at the same time, with no mechanism for recovery. Apple confirmed the change via email to affected customers — a somewhat more communicative approach than Google's two-sentence anomaly notes, though the outcome for users who missed the notification was identical: permanent data loss.
Source: How-To Geek via Yahoo — iCloud Backups Will Stop Working On Old iPhone Models (2024)
Advanced Data Protection — withdrawn under government pressure, UK 2025
In February 2025, Apple withdrew its Advanced Data Protection feature — end-to-end encryption for iCloud data — in the United Kingdom, following a legal demand from the UK government for backdoor access. The removal was made without prior notice to UK users, who had enabled the feature specifically for its privacy guarantees. The incident illustrated a variant of the deprecation pattern: features can disappear not through internal product decisions but through regulatory compliance, with users bearing the consequence either way.
Sources:
- Captain Compliance — Apple's Shocking Reversal: Advanced Data Protection Pulled Amid Privacy and Security Controversy (Feb. 2025)
The iOS hardware upgrade cycle as soft deprecation
Apple routinely ends software support for devices over seven years old, removing OS updates and security patches. Whilst this is publicly documented and broadly understood, the effect is functionally equivalent to deprecation: hardware purchased and relied upon becomes a liability, and app developers cease supporting older OS versions on their own timelines, often faster than Apple's official end-of-support dates. The mechanism is more transparent than Google's or Meta's API withdrawals, but the structural pressure on users is comparable.
Source: MacObserver — Apple Devices Losing Support in 2025: What You Need to Know (Jan. 2025)
5. The theoretical framework — enshittification
The academic and intellectual context that unifies these cases under a single explanatory model.
Cory Doctorow — the canonical formulation
Canadian writer and activist Cory Doctorow coined the term "enshittification" in November 2022 to describe the predictable pattern of decay in digital platforms. The mechanism he identified has three stages: platforms are first good to users, to attract them; then they degrade the user experience to serve business customers; then they degrade the experience for both users and business customers to extract maximum short-term profit for shareholders.
The American Dialect Society selected "enshittification" as its 2023 Word of the Year. Australia's Macquarie Dictionary followed for 2024. In October 2025, Doctorow published a book-length treatment: Enshittification: Why Everything Suddenly Got Worse and What To Do About It (Farrar Straus & Giroux).
Sources:
- Wikipedia — Enshittification (ongoing)
- The New Stack — Cory Doctorow Reveals How He'd Fix Big Tech's Domination (Jul. 2025)
- Washington Monthly — The Cory Doctorow Doctrine (Oct. 2025)
- Remio.ai — Enshittification: Cory Doctorow on Why the Internet Is Getting Worse (Oct. 2025)
The structural argument — why deprecation without notice is not accidental
Doctorow's framework explains why minimal warning is not an oversight but a structural feature. Platforms have no competitive incentive to communicate their degradations clearly — users who are already locked in have limited alternatives, and detailed communication about failures generates legal and reputational vulnerability. The pattern is not negligence; it is rational behaviour under conditions of monopolistic market power. This framing matters for the main article's argument: expecting Google to behave more transparently without structural change in its market position is expecting a rational actor to act against its own interests.
Sources:
- Medium — Enshittification: Cory Doctorow on the Collapse of Digital Platforms (Dec. 2025)
- Critical EdTech — The 'enshittification' of the digital (Cory Doctorow) (2024)
- Muhlenberg Magazine — As Platforms Decay, So Do We (Jan. 2026)
Comparative summary for editorial use
| Company | Most significant deprecation | Notice given | Data lost? |
|---|---|---|---|
| GSC 50-week logging bug | None | No (data corrupted, not deleted) | |
| Universal Analytics | ~1 year (shifted twice) | Yes — permanent deletion | |
| Google Cache | Weeks | No (Wayback Machine added) | |
| Meta | Facebook Groups API | 90 days | No (functionality lost) |
| Meta | 100+ Ads Insights metrics | 90 days | No (metrics removed) |
| Twitter/X | Free API access | 7 days | No (access revoked) |
| Twitter/X | Third-party clients | None | No (ecosystem destroyed) |
| Microsoft | Cortana (9 years old) | Months | No (assistant replaced) |
| Microsoft | 16 Windows 11 features | Variable | No |
| Apple | iCloud pre-iOS 8 backups | Email notice | Yes — permanent deletion |
| Apple | Advanced Data Protection (UK) | None | No (encryption removed) |
Editorial observation: The cases divide into three categories. The first involves tool or feature removal — disruptive, but recoverable through alternatives. The second, smaller category involves data deletion: Universal Analytics (Google), iCloud pre-iOS 8 backups (Apple). These are qualitatively more serious and represent the clearest breach of the implicit contract between a platform and its users. Google's fifty-week logging bug sits in a third category — neither deletion nor removal, but silent corruption. In some respects it is the most insidious of the three, because it is the only one in which users had no opportunity to act even if they had known.
Viewed through the theoretical framework of Yanis Varoufakis in Technofeudalism: What Killed Capitalism (2023; Melville House, 2024), this pattern is not an anomaly — it is the constitutive mechanism of a new economic system. Varoufakis argues that the digital platforms of Big Tech no longer function as market actors in the classical capitalist sense but as digital feudal lords: they control the infrastructure through which commerce, communication and information flow, and extract cloud rents — not profits — from all those who must operate within these ecosystems. The developers, independent consultants and web agencies that build services on Google, Meta or Apple data are not, in this reading, customers in a free market. They are digital vassals — dependent on the lord's goodwill for access to the very tools and data that constitute their working environment.
Unilateral tool deprecation, minimal notice and data deletion without recourse are not, from this vantage point, errors of corporate governance that could be remedied through better regulation or institutional goodwill. They are natural expressions of a power relation in which the lord bears no contractual obligation to the vassal beyond what it voluntarily assumes. The feudal lord did not give the peasant a year's notice before changing the terms of tenure. The platform does not give the developer more than the legal minimum before withdrawing the API on which a business was built.
This reading adds a dimension that neither Doctorow's enshittification framework nor purely technical analyses of deprecation fully cover: the problem is not that platforms behave badly by accident — the problem is that the structural power relation in which they operate permits them to do so systematically, without consequence. Asking Google for greater transparency without altering the underlying power structure is, in Varoufakis's terms, the equivalent of asking a feudal lord to be kinder to his serfs — an appeal to morality where the problem is one of economic architecture.
Primary source:
- Yanis Varoufakis — Technofeudalism: What Killed Capitalism (Melville House, Feb. 2024)
Secondary sources:
- Jacobin — We're Still Living Under Capitalism, Not "Techno-Feudalism" (Oct. 2023) — useful counter-argument
- The Skeptic — The tyranny of the cloud: how we became serfs to big tech (Oct. 2024)
- NPI Cascadia Advocate — Book Review: Yanis Varoufakis' Technofeudalism (Mar. 2026)
- Geert Lovink / Network Cultures — Cloud Capital and Platform Regression (Mar. 2024)
- Doing Sociology — review of Technofeudalism (Nov. 2025)
Key secondary sources for the category article
- Cory Doctorow — Enshittification: Why Everything Suddenly Got Worse and What To Do About It (Farrar Straus & Giroux, Oct. 2025) — foundational theoretical text
- KilledBy.tech — ongoing catalogue of deprecated products across Google, Meta, Microsoft and Apple
- The Register — consistent long-form coverage of API deprecations across platforms
- TechCrunch — primary source for Twitter/X API changes and developer ecosystem impact
- SE Roundtable (Barry Schwartz) — primary source for Google-specific tool deprecations