In May 2024, thousands of pages of internal Google documentation showed up online, and the SEO world spent the following weeks treating it as the day the algorithm got cracked open. If you only caught the headlines, you probably walked away thinking the Google API leak ranking factors story settled a decades-old argument. It did confirm something real. It did not confirm nearly as much as the recap posts claimed.
Here is the short version, before the detail. Google confirmed the leaked documents were genuine internal Search API documentation. That document is a real, if very wide, map of attributes, fields and modules that Google's systems can reference. What it is not is a ranking formula, a weighted list of factors, or proof that every field in it is active, current, or used the way commentators guessed. So when someone asks what did the Google leak reveal, the honest answer is: a detailed look at the shape of the system, not the rules it runs on.
What actually leaked, and what Google actually said
The material was internal documentation connected to Google's Content Warehouse API, and it appeared to have been committed, likely by accident, to a publicly reachable Google-owned code repository. The Register's reporting on this was careful to call it documentation, not ranking-system source code, which matters more than it sounds like it should. Documentation describes what a system can record and reference. It is not the same thing as a readout of what that system actually does with those fields when it ranks a page.
Rand Fishkin of SparkToro was the person who brought the material to wider attention, and his account is where most of the specific numbers in circulation came from. He described more than 2,500 pages of API documentation covering 14,014 attributes, and said commit history pointed to an upload in late March 2024 that stayed accessible until early May. Those figures and dates belong to his account of events, not to a statement Google issued. It is worth holding that distinction, because a lot of the coverage since has repeated "14,014 ranking factors" as if Google itself had published a count. Google did not publish a count. Fishkin and other analysts counted attributes in a document and reported that number.
On May 29, 2024, The Verge reported that Google confirmed the documents were real. That confirmation is the one solid fact in this whole story, and it is narrower than it sounds. Google spokesperson Davis Thompson told the outlet that drawing conclusions from "out-of-context, outdated, or incomplete information" could lead to inaccurate assumptions, and the company said it would not comment on the specifics of how its ranking systems work or exactly what the leaked fields meant. So the confirmation covers authenticity. It says nothing about current use, weighting, or meaning. Treat "Google confirmed the leaked ranking factors" as a different and unsupported claim from "Google confirmed the documents were real."
What the documentation appears to describe
The clearest, most substantive thread running through the 2024 Google leak SEO coverage is clicks. Analysis from IPullRank pointed to a module called NavBoost, built around click and impression signals, and listed named click fields like bad clicks, good clicks, and last-longest clicks. Search Engine Land's reporting described NavBoost in similar terms: a system that re-ranks results based on click logs, with separate fields for different categories of click and for site-wide impressions.
There is a useful, separate piece of evidence that predates the leak entirely. In Google's 2023 antitrust trial, a Department of Justice exhibit cited testimony from former Google engineer Eric Lehman, given in September 2023. Lehman described NavBoost as a large table recording clicks tied to a specific search query and document, built from roughly thirteen months of user data, and he was careful to say the word "trains" was misleading because NavBoost is not a machine-learning system in the way people assume. That testimony is independent of the 2024 document leak, and it is the strongest grounding available for the idea that click data genuinely factors into how Google orders results. It does not, on its own, tell you the exact mechanism, the weight any single click category carries, or how a specific page's position changes because of it. Notably, the two sources do not even agree on the exact time window: the 2023 testimony describes roughly thirteen months of data, while IPullRank's reading of the 2024 documents describes a rolling eighteen months. Nobody has reconciled that gap, so it is worth treating either figure as source-specific rather than as a single settled number.
The documents also surfaced a field called siteAuthority, described as an integer attribute tied to compressed, document-level quality signals. It is tempting to read that straight into the familiar idea of a domain authority score, and a fair amount of the post-leak commentary did exactly that. Fishkin himself, quoted in Moz's roundup of SEO reactions, called siteAuthority the least interesting signal of the site-wide group, precisely because its actual meaning was not established by the leak. An attribute having a name that sounds like a concept you already understand is not evidence that it works the way you assume. The documentation does not include a formula, a scale, or a description of how the value gets calculated.
Chrome data is the third thread worth separating out carefully. Search Engine Land's analysis identified a field named ChromeInTotal, describing it as interactions tracked through Chrome, and treated it as a likely ranking signal. The Verge's follow-up reporting noted the same field but also pointed out that Google representatives had previously said Chrome browsing data is not used for ranking. That leaves a real tension: a field exists in the documentation with a name that implies Chrome data, and Google has separately said that kind of data isn't used to rank pages. A field being present in a schema is not the same as proof that it drives ranking outcomes. Some coverage went further and speculated the same practice might extend to Android usage data; that extension was explicitly offered as speculation in the reporting, not as something the documents or Google confirmed, and it should not be repeated as fact.
A handful of other named fields turned up in the reporting, including SiteImpressions and a score tied to title relevance against the query. These are worth knowing as examples of what analysts found inside the documentation. None of them come with a threshold, a weight, or evidence of a measured ranking effect. The honest description of this part of the story is "the documents name these things," not "the documents prove these things decide rankings."
What the leak did not prove
This is the part that gets skipped in a lot of the recap content, and it is the part that matters most if you are trying to act on any of this. Fishkin's own account was explicit that the documentation does not show the weight any individual element carries in the ranking system, and it does not prove which elements are actually used in live ranking versus simply available to be referenced. Google's statement added the same caveat from the other direction: the material might be outdated, incomplete, or missing context, and the company would not walk through what any specific field means today.
This is the real answer to what did the Google leak reveal: a documentation set, not a decoder ring. Put together, here is what stays unestablished even after the confirmation. There is no complete ranking formula and no authoritative, current list of ranking factors. The leap from "14,014 documented attributes" to "14,014 ranking factors" is not supported; an attribute is a thing a system can reference, and calling it a ranking factor is a much stronger claim that the documents themselves don't make. There is no confirmation that every named field was active in production ranking at the time of the leak, let alone now. There is no weighting, threshold, or directional evidence for any individual field. siteAuthority has not been shown to function as a conventional domain authority metric, and Chrome or Android usage data has not been shown to be a live ranking input. None of this amounts to a tactic you can apply to move a page. It was internal documentation, not a controlled experiment that measured what happens when a factor changes.
It helps to hold a clean line here: a documented attribute is not automatically a confirmed ranking factor, and a confirmed ranking factor is not automatically something whose effect size anyone outside Google actually knows. Anyone citing Google API leak ranking factors as a settled list is skipping past that distinction. The 2024 Google leak sits on the first rung of that ladder. Treating it as if it answered everything up to the third rung is where most of the exaggerated claims came from.
The verdict, and what to actually do with it
Looking back at the 2024 Google leak SEO discussion now, it mostly settled into two camps: people who still cite the raw attribute count as proof of something specific, and people who read the actual reporting closely enough to know better. Grade the evidence as mixed, leaning toward confirmed-but-limited. Google did confirm the documents were real, which rules out the theory that the whole thing was fabricated or misattributed. What it did not do is confirm a ranking algorithm, a factor list, or the relative importance of anything inside the documentation. The most defensible way to describe the 2024 Google leak is that it gave outsiders an unusually detailed look at internal documentation referencing real systems and signal categories, while leaving deployment, current relevance, and ranking impact unresolved.
If you run content or SEO for a living, the practical move is not to go rewrite a strategy around siteAuthority or NavBoost click categories you cannot measure or influence directly anyway. The leak is genuinely useful as confirmation that click behavior matters to Google's systems in some form, which lines up with testimony that predates the leak and with years of indirect evidence. Beyond that, the specific attribute names are closer to trivia than to a checklist. What would change this verdict is Google publishing an actual explanation of how a named field is used and weighted, something it has explicitly declined to do. Until that happens, the safest position is to keep working from what Google has stated publicly about how it evaluates content and pages, and to treat the leak as context rather than as a new set of instructions.
For a team trying to track whether any of this translates into actual visibility, whether in traditional search results or in how AI engines describe and cite your pages, the more productive use of time is watching your own measured outcomes rather than reverse-engineering a leaked schema. DeepSmith tracks how AI engines answer the questions your buyers ask and which pages they cite, which is a direct read on outcomes instead of a guess based on documentation nobody outside Google can fully interpret.
