The Google algorithm leak 2024 is the largest look inside Google Search that outsiders have had. It is also the most over-interpreted. Within weeks, attribute names from the documents were being turned into ranking factor checklists, most of which went far beyond what the material supports. This guide sets out what was exposed, who verified it, and where the evidence stops and the guessing begins.
What was leaked
The story broke through Rand Fishkin at SparkToro, who published his account of the leaked Google Search API documents on 28 May 2024 and updated it on 3 July 2024. The material was API documentation from Google’s internal “Content API Warehouse”, accidentally exposed on GitHub.
| Item | Detail, as reported by SparkToro |
|---|---|
| Volume | More than 2,500 pages of API documentation |
| Attributes | 14,014 attributes |
| Source | Google’s internal Content API Warehouse |
| Exposure window | On GitHub between 27 March and 7 May 2024 |
| Verification | Ex-Google employees, and Mike King of iPullRank, who judged it to be from inside the Search division |
API documentation describes the shape of data: which fields exist, what they are called, and what type of value they hold. It is not source code. It does not contain the logic that combines those fields into a ranking, and it does not say which fields a live ranking system reads.
That distinction sounds pedantic, but it decides how far any conclusion can go. A field list is closer to a database schema than to a set of instructions. It tells you what Google has chosen to record, which is genuinely revealing, while leaving open what Google does with each record once it has it.
The Google algorithm leak 2024: the notable items
Of the thousands of attributes, a handful drew most of the attention because they appeared to contradict things Google had said in public.
NavBoost and click signals
The documents reference NavBoost and click-related attributes, including “goodClicks”, “badClicks”, and a distinction between long and short clicks. This was the item with the most weight behind it, because NavBoost had already come up in sworn testimony during the US antitrust trial earlier in 2024. Our guide to NavBoost covers what that testimony said.
Chrome data
Attributes such as “chrome_trans_clicks” reference data from Chrome. That matters because whether Google uses Chrome browsing data in search has long been a point of argument. The name shows Chrome-derived data exists in the system. It does not show where it is used, or whether in ranking at all.
Link quality tiers
The documents describe mechanisms for sorting links into quality tiers. That fits what most link builders already assume: not all links count equally, and a link from a page Google rarely crawls or values is unlikely to do much.
Whitelist-style attributes
Attributes such as “isCovidLocalAuthority” and “isElectionAuthority” suggest Google can flag specific sites as authorities on sensitive topics. Again, the name shows the flag exists. How and when it is applied is not in the documents.
What the leak does not prove
Fishkin’s own caveat is the most important sentence in the whole story: “It’s not quite proof. It’s a strong indication … but still no guarantee.” The documents do not show which attributes are used in ranking, or how they are weighted.
That gap is where most of the bad advice came from. An attribute existing is a long way from it being a ranking factor. Large systems store fields for testing, logging, deprecated features and internal tools. Some of the 14,014 attributes may never touch a live result. Without weights, you cannot tell a field that decides rankings from one that is read once a year by a debugging dashboard.
It helps to sort claims into two columns before acting on any of them:
- What the documents show: named attributes exist for clicks, NavBoost, Chrome-derived data, link quality tiers and authority flags.
- What is speculation: that any given attribute affects rankings, how strongly, in which systems, and whether it was still in use when the documents leaked.
Anyone selling a precise list of “leaked ranking factors” with weights attached is presenting the second column as if it were the first.
A quick test for any leak-based claim: ask whether it names an attribute or describes an effect. “There is a field for long clicks” is supported by the documents. “Pages with longer clicks rank higher by a measurable amount” is not, because nothing in the documentation describes outcomes. The first sentence is reporting. The second is a hypothesis that needs its own evidence, and a field name cannot supply it.
Timing is a second gap. Documentation describes a system at the moment it was written, and internal systems change constantly. A field present in the leaked material may have been added for an experiment, superseded by something newer, or left in place long after the code that read it was retired. The documents cannot tell you which.
What is worth changing
The honest answer is: less than the headlines suggested. The leak is most useful as confirmation of things that careful SEOs already believed, and as a reason to stop trusting a few public denials at face value.
Take user behaviour seriously. If click signals feed ranking in any form, a result that earns the click and then fails the visitor is in a weak position. That points to titles that set accurate expectations and pages that answer the query. Our analysis of CTR by position covers how much clicks vary by rank in the first place.
Treat links as tiered, not counted. A link from a page that real people visit and Google values is a different asset from a link on a page nobody reads. That was sound practice before the leak and remains so.
Do not rebuild your strategy around one attribute name. The leak revived several old arguments, including whether new sites are held back for a period. Our piece on the Google sandbox covers why the evidence there is still mixed, and why a field name alone cannot settle it.
The limitation runs through everything above. The documents are a snapshot of what Google’s systems could describe at one point, seen through field names rather than code. They cannot be tested against rankings directly, and Google has not confirmed how any of it is used. Treat the leak as a strong hint about which kinds of signal exist, and keep measuring what actually moves your own pages.
For a running view of how algorithm changes have played out, the algorithm category collects our coverage of updates and the systems behind them.
Frequently asked questions
What was the Google search algorithm leak?
More than 2,500 pages of internal API documentation, with 14,014 attributes from Google’s Content API Warehouse, exposed on GitHub between 27 March and 7 May 2024.
Was the leak genuine?
Ex-Google employees and Mike King of iPullRank reviewed it and judged the documents to be from inside Google’s Search division.
Does the leak prove clicks are a ranking factor?
No. It shows click-related attributes and NavBoost exist in the documentation. It does not show how they are weighted or used, as Rand Fishkin’s own caveat makes clear.
Should I change my SEO because of the leak?
Mostly not. It supports existing good practice: satisfy the click, earn links from pages people use, and test changes rather than chase attribute names.
The takeaway The leak shows what Google can store, not what it rewards. Use it to confirm sound practice, not to build a checklist of attribute names.
