The 2024 Google Leak: Findings and Limits for SEO

What did the 2024 Google leak reveal?

The Content Warehouse documentation publicly described in May 2024 provided names of modules, attributes, and data structures related to search. It did not publish the complete algorithm, its scoring functions, or its weights. A field may be stored, experimental, or obsolete: its existence does not prove its current use in ranking.

This is an annotated edition of Agencia Cero’s published translation of Mike King’s analysis at iPullRank, dated May 27, 2024. We preserve its technical progression, examples, images, and references. The first person, research, book, clients, and commercial offers in the analysis belong to King and iPullRank, not Agencia Cero. The editorial clarifications distinguish the hypotheses of that time from public evidence and do not imply access to internal systems.

How to read it: field names are discussed as historical references; interpretations are not guaranteed instructions for ranking. The public ruling of August 2024, sections on interaction data and NavBoost, provides independent evidence of the use of clicks in that system during the period examined. It does not prove that every attribute discussed below is active today or that increasing CTR causes a ranking improvement.

Historical analysis: context, caveats, and systems

Google, if you are reading this, it is too late 😉 .

Okay. Crack your knuckles. Let’s get to it. Internal documentation for Google Search’s Content Warehouse API has leaked. Google’s internal microservices appear to mirror what Google Cloud Platform offers, and the internal version of the documentation for the deprecated Document AI Warehouse was accidentally published publicly in a code repository for the client library. The documentation for this code was also captured by an external automated documentation service. 

According to the history cited by Mike King in May 2024, the accidental publication was corrected on May 7 of that year. The author mentioned a copy on a documentation service and an Apache 2.0 license associated with the repository. This edition does not verify the current availability of those copies or interpret the license as general authorization to access internal information, redistribute any material, or recover private code.

I have reviewed the API reference documents and contextualized them with other previous Google leaks and the Department of Justice’s antitrust testimony. I am combining this with the extensive patent and white-paper research conducted for my forthcoming book, The Science of SEO. Although there are no details about Google’s scoring functions in the documentation I have reviewed, there is a wealth of information about the data stored for content, links, and user interactions. There are also varying degrees of descriptions, from disappointingly sparse to surprisingly revealing, of the features being manipulated and stored.

We might be tempted to call these “ranking factors,” but that would be imprecise. The presence of an attribute does not demonstrate that it is a ranking factor, that it is active, or how much weight it carries. What I will do here is contextualize some of the most interesting ranking systems and features, at least those I could find in the first hours of reviewing this massive leak, based on my extensive research and things Google has told us or lied about over the years.

In the original, King harshly criticizes Google’s public responses and their effect on the company’s credibility. Here we retain the debate about transparency, but do not present an intent to deceive as a proven fact. An apparent contradiction requires comparing the date, context, definition, and scope of each statement.

Caveats about the article

I think we all know people will work hard to discredit my conclusions and analysis of this leak. Some will ask why it matters and say, “but we already knew that.” So let’s get the caveats out of the way before moving on to the good stuff.

• Limited time and context: With the holiday weekend, I have only been able to spend about 12 hours deeply focused on all this. I am incredibly grateful to some anonymous parties who were very helpful in sharing their knowledge with me to get me up to speed quickly. Also, as with the Yandex leak I covered last year, I do not have a complete picture. Whereas with Yandex we had the source code to analyze and none of the thinking behind it, here we have some of the thinking behind thousands of functions and modules, but not the source code. You will have to forgive me for sharing this in a less structured way than I will in a few weeks after spending more time with the material.
• No scoring functions: We do not know how features are weighted in the various downstream scoring functions. We do not know whether everything available is used. We know some features are deprecated. Unless explicitly stated, we do not know how things are used. We do not know where everything happens in the process. We have a series of named ranking systems that loosely align with how Google has explained them, how SEOs have observed rankings in the wild, and how patent applications and IR literature explain them. Ultimately, thanks to this leak, we now have a clearer picture of what is being considered that can inform what we focus on versus ignore in SEO going forward.
• Probably the first of several posts : This post will be my initial stab at what I have reviewed. I may publish subsequent posts as I continue to dig into the details. I suspect this article will prompt the SEO community to rush to analyze these documents, and collectively we will be discovering and recontextualizing things for months to come.
• Time context: King interpreted the material as a snapshot from March 2024 and cited publication on March 27 and removal on May 7, 2024. Those dates do not demonstrate that every field was active then or that it describes the system in use today.

• Correlation is not causation: An observed association between a change and traffic does not prove its cause. Nor does the existence of a field demonstrate that it determines a position.

More than 14,000 documented attributes: not equivalent to ranking factors

There are 2,596 modules represented in the API documentation, with 14,014 attributes, or features, that look like this:

The modules relate to components of YouTube, Assistant, Books, video search, links, web documents, crawling infrastructure, an internal calendar system, and the People API. Like Yandex, Google’s systems operate in a monolithic repository, or “monorepo,” and the machines run in a shared environment. This means all the code is stored in one place and any machine on the network can be part of any of Google’s systems.

The leaked documentation describes each API module and breaks them down into summaries, types, functions, and attributes. Most of what we are seeing is property definitions for various protocol buffers, or protobufs, accessed through ranking systems to generate SERPs, Search Engine Result Pages: what Google shows searchers after they make a query.

Unfortunately, many of the summaries refer to Go links, which are URLs on Google’s corporate intranet offering additional details about different aspects of the system. Without the appropriate Google credentials to access and view these pages, which would almost certainly require being a current Googler on the Search team, we are left to our own devices to interpret them.

Documentation and public statements: what differences can be interpreted

The original analysis questions whether Google’s public explanations adequately described its systems. This is the author’s criticism, not proof of an intent to deceive. When comparing statements and documentation, it is useful to distinguish third-party commercial metrics, internal names, historical systems, and current operation.

Below, I present historical statements from Google employees alongside interpretations of the documentation with limited commentary so you can judge for yourself.

“We do not have anything like domain authority”

Google spokespeople have said on numerous occasions that they do not use “domain authority.” King interpreted these responses as incomplete; that assessment alone does not demonstrate a deliberate falsehood. 

By saying they do not use domain authority, they could specifically mean that they do not use Moz’s metric called “Domain Authority” (obviously). They could also mean that they do not measure the authority or importance of a specific topic, or domain, in relation to a website. This semantic confusion allows them never to answer directly whether they calculate or use sitewide authority metrics. 

Gary Ilyes, an analyst on Google’s Search team who publishes information to help website creators, has repeated this claim on numerous occasions.

And Gary is not alone. John Mueller, a “Search Advocate who coordinates Google Search Relations,” stated in this video, “we don’t have a website authority score.” 

In reality, as part of the Compressed Quality Signals stored per document, Google has a feature they compute called “siteAuthority.” 

We do not know specifically how siteAuthority is calculated or how it is used in scoring functions. The field name does not allow it to be equated with Moz’s Domain Authority, prove its current use in Q*, or establish a weight. It is a clue for studying possible site signals, not a metric an owner can optimize directly.

“We do not use clicks for ranking”

Let’s settle this once and for all.

The testimony of Pandu Nayak in the DOJ antitrust trial recently revealed the existence of the Glue and NavBoost ranking systems. NavBoost is a system that uses click-based measures to improve, demote, or reinforce a ranking in web search. Nayak stated that Navboost has existed since 2005 and historically used 18 consecutive months of click data. The system was recently updated to use 13 months of data and focuses on web search results, while a system called Glue is associated with other universal search results. But even before that revelation, we had several patents, including the 2007 Time Based Ranking patent, that specifically indicate how click logs can be used to change results. 

Clicks can provide information about the success of a search, but are subject to bias and require interpretation. Machine learning and patents help formulate hypotheses; by themselves, they do not confirm which function is in production. Public discussion of NavBoost should be supported by testimony and court documents as well as specialist commentary.

Gary Ilyes has addressed this issue of click measurement many times. On one occasion, he reinforced what Google Search engineer Paul Haahr shared in his 2016 SMX West talk about live experiments, saying that “using clicks directly in rankings would be a mistake.”

Later, he used his platform to disparage Rand Fishkin, founder and CEO of Moz and an SEO veteran, saying that “dwell time, CTR, whatever Fishkin’s new theory is, are generally made-up crap.”

In reality, Navboost has a dedicated module entirely devoted to click signals. 

The summary of that module defines it as “click and impression signals for Craps,” one of the ranking systems. As we see below, bad clicks, good clicks, last longest clicks, unsquashed clicks, and unsquashed last longest clicks are considered metrics. According to Google’s patent “Scoring local search results based on location prominence,” “Squashing is a function that prevents one large signal from dominating the others.” In other words, the systems normalize click data to ensure there is no uncontrolled manipulation based on the click signal. Google representatives argue that systems appearing in patents and white papers are not necessarily those in production, and that caution remains valid: NavBoost’s use has independent public evidence, but that does not validate every interpretation of the attributes or reveal their current weights.

Many of these same click-based measures also appear in another module related to indexing signals. One measure is the date of the “last good click” on a given document. This prompted a hypothesis about the relationship between interaction and traffic loss. It does not allow a drop to be diagnosed or demonstrate that an expected click quota exists for each position. 

In addition, the documentation represents users as voters, and their clicks are stored as their votes. The system counts the number of bad clicks and segments the data by country and device.

The analysis describes references to the longest click in a session. They do not allow a long click, dwell time, and time on page measured by Analytics to be automatically equated. Nor do they establish a minimum number of seconds or justify artificially prolonging navigation. The practical priority is for the person to complete their task easily.

Several sources have indicated that NavBoost is “already one of Google’s strongest ranking signals.” The leaked documentation specifies “Navboost” by name 84 times, with five modules including Navboost in the title. There is also evidence that they consider its score at the subdomain, root-domain, and URL levels, inherently indicating that they treat the different levels of a site differently. I will not get into the subdomain-versus-subdomain discussion, but later we will discuss how the system’s data has also informed the Panda algorithm.

So yes, Google does not mention “CTR” or “dwell time” in those exact words in this documentation, but the spirit of what Rand demonstrated is included: clicks on search results and measures of a successful search session. Public court evidence supports the historical use of interactions in NavBoost. It does not demonstrate that increasing a page’s CTR or its time in Analytics causes a ranking improvement, nor does it justify generalizing every hypothesis in the article.

“There is no Sandbox”

Google spokespeople have been categorical in stating that there is no sandbox into which websites are segregated based on age or a lack of trust signals. In a now-deleted tweet, John Muller answered a question about how long it takes to become eligible to rank by stating, “There is no sandbox.”

In the PerDocData module, the documentation indicates an attribute called hostAge used specifically “to sandbox fresh spam in serving time.”

The reference to hostAge and new spam does not demonstrate a universal sandbox for all recent sites. An attribute’s name and description are not enough to infer a fixed waiting period or an age-related penalty.

“We do not use anything from Chrome for ranking”

Matt Cutts had previously been quoted as saying that Google does not use Chrome data as part of organic search. More recently, John Mueller reinforced this idea. 

One of the modules related to page quality scores features a site-level measure of visits from Chrome. Another module that appears related to sitelink generation also has an attribute related to Chrome.

A leaked internal presentation from May 2016 about the RealTime Boost system also indicates that Chrome data was coming to search. It is a historical reference that does not by itself demonstrate how that data was used or how it is used today.

Google spokespeople mean well, but can we trust them?

The answer requires comparing sources. Public statements, testimony, and technical analyses have different scopes; an attribute related to Chrome does not demonstrate that any visit from that browser improves rankings.

I hold no ill will toward the people I have quoted here. I am sure they all do their best to provide support and value to the community within permitted limits. However, these documents make clear that we should continue to treat what they say as one input, and our community should keep experimenting to see what works.

An interpretation of Google’s search architecture

Editorial note: the following inventory is an interpretive map from 2024. It preserves names and functions attributed by King, not a current technical specification verified from end to end. The WordPress analogies and examples of result restrictions help explain possibilities; they are not public rules for composing every SERP.

Conceptually, you might think of “Google’s algorithm” as a single thing, a giant equation with a series of weighted ranking factors. In reality, it is a series of microservices in which many features are preprocessed and made available at runtime to compose the SERP. Based on the different systems referenced in the documentation, there may be more than a hundred different ranking systems. Assuming these are not all the systems, perhaps each individual system represents a “ranking signal,” and perhaps that is how Google arrives at the 200 ranking signals it often discusses.

In Jeff Dean’s talk “Building Software Systems at Google and Lessons Learned,” he mentioned that early iterations of Google sent each query to 1,000 machines to process and respond in under 250 milliseconds. He also diagrammed an earlier version of the system architecture abstraction. This diagram illustrates that Super Root is the brain of Google Search, sending out queries and bringing everything together at the end. 

Distinguished research engineer Marc Najork, in his recent presentation on generative information retrieval, showed an abstract model of Google Search with its RAG system, also known as Search Generative Experience/AI Overviews. This diagram illustrates a series of different data stores and servers processing the different layers of a result.

Google whistleblower Zach Vorhies leaked this slide showing the relationships of different systems within Google by their internal names. Several of them are referenced in the documentation.

Using these three high-level models, we can begin thinking about how some of these components work together. From what I can infer from the documentation, this API appears to be based on Google’s Spanner. Spanner is a distributed architecture that allows data storage and processing capacity to scale while treating a series of globally networked computers as one. 

Admittedly, it is somewhat difficult to understand how everything relates from the documentation, but Paul Haahr’s résumé offers valuable insight into what some of the ranking systems mentioned do. I will highlight those I know by name and segment them according to their function.

Crawling

• Trawler: The web crawling system. It has a crawl queue, maintains crawl rates, and understands how frequently pages change.

Indexing

• Alexandria: The core of the indexing system.
• SegIndexer : A system that places documents into tiers within the index.
• TeraGoogle: A secondary indexing system for documents that live on disk long term.

Rendering

• HtmlrenderWebkitHeadless: A rendering system for JavaScript pages. Interestingly, its name comes from Webkit rather than Chromium. Chromium is mentioned in the documentation, so Google likely used WebKit initially and switched to Headless Chrome as soon as it arrived.

Processing

• LinkExtractor: Extracts links from pages.
• WebMirror: A system for managing canonicalization and duplication.

Ranking

• Mustang: The primary scoring, ranking, and serving system.
  • Ascorer : The primary ranking algorithm that ranks pages before any reranking adjustments.
• NavBoost: A reranking system based on click logs of user behavior.
• FreshnessTwiddler: A document reranking system based on freshness.
• WebChooserScorer : Defines the names of features used in snippet scoring.

Serving

• Google Web Server: GWS is the server with which Google’s frontend interacts. It receives data payloads to display to the user.
• SuperRoot: The brain of Google Search that sends messages to Google’s servers and manages the postprocessing system for reranking and presenting results.
• SnippetBrain: The system that generates snippets for results.
• Glue: The system for assembling universal results using user behavior.
• Cookbook: A signal generation system. There are indications that values are created at runtime.

As I said, many more systems are described in these documents, but what they do is not entirely clear. For example, SAFT and Drishti from the earlier diagram are also represented in these documents, but their functions are unclear.

What are Twiddlers, or reranking adjustments?

There is little information online about Twiddlers in general, so I think it is worth explaining them here so we can better contextualize the various Boost systems we find in the documents. 

Twiddlers are reranking functions that run after the primary search algorithm, Ascorer. They work similarly to filters and actions in WordPress, where what is displayed is adjusted just before being presented to the user. Twiddlers can adjust a document’s information retrieval score or change its ranking. Many of the live experiments and named systems we know are implemented this way. As this Xoogler demonstrates, they are quite important in various Google systems:

Twiddlers can provide category constraints, meaning diversity can be promoted by specifically limiting the type of results. For example, the author may decide to allow only 3 blog posts in a given SERP. This can clarify when ranking is a lost cause based on your page’s format.

When Google says something like Panda was not part of the core algorithm, it probably means it launched as a Twiddler, as a reranking boost or demotion calculation, and was later moved into the core scoring function. Think of it as similar to the difference between server-side and client-side rendering. 

Presumably, any features with the Boost suffix operate using the Twiddler framework. Here are some of the Boosts identified in the documentation:

• NavBoost
• QualityBoost
• RealTimeBoost
• WebImageBoost

The names guide hypotheses, but do not by themselves explain each system’s function, implementation, or current use. 

There is also an internal document about Twiddlers that I have reviewed which discusses this in more detail, but this post sounds as though its author saw the same document I did.

Findings and hypotheses for reviewing an SEO strategy

Let’s get to what you really came for. What is Google doing that we did not know or were not sure about, and how might it affect my SEO efforts? 

A quick note before continuing. My goal is always to expose the SEO industry to new concepts. My goal is not to give you a recipe for how to use them in your specific use case. If that is what you want, you should hire iPullRank for your SEO. Otherwise, there is always more than enough for you to extrapolate and develop your own use cases.

Hypotheses about Panda based on patents

Editorial note: a patent describes an invention; it does not certify its deployment. The formula and quotations below are preserved as examples of the author’s reasoning. According to Google’s public guide to ranking systems, Panda was integrated into the core systems in 2015; the helpful content system became part of the core systems in March 2024.

When Panda launched, there was a lot of confusion. Is it machine learning? Does it use user signals? Why do we need an update to recover? Is it sitewide? Why did I lose traffic in a particular subdirectory?

Panda launched under Amit Singhal’s direction. Singhal was firmly opposed to machine learning because of its limited observability. In fact, there is a series of patents focused on site quality for Panda, but the one I want to focus on is the nondescript “Ranking search results.” The patent clarifies that Panda is much simpler than we thought. It is largely about building a score modifier based on distributed signals related to user behavior and external links. That modifier can be applied at domain, subdomain, or subdirectory level. 

Independent links are basically what we consider linking root domains, but reference queries are a little more complicated. Here is how they are defined in the patent:

King connected the patent’s reference queries with NavBoost. This is the author’s interpretation; neither a patent nor a field name proves that this equivalence describes Panda’s implementation.

This suggests that Panda updates were simply updates to the rolling query window, similar to how Core Web Vitals calculations work. It could also mean that link graph updates were not processed in real time for Panda.

Not to be argumentative, but another Panda patent, site quality score, also considers a score that is a ratio between reference queries and user selections or clicks.

The practical recommendation is to attract a relevant audience, develop helpful content, and facilitate a good experience. The patent formula is preserved as an example of a proposed mechanism, not as Panda’s operational formula. There is no basis here to promise recovery from an update through more clicks, more links, or a particular ratio between them.

Authors are an explicit feature

Much has been written about E-E-A-T. Many SEOs are skeptical because scoring expertise and authority is so nebulous. I have also previously highlighted how little author markup there actually is on the web. Before learning about vector embeddings, I did not believe authorship was a sufficiently viable signal at web scale.

Nevertheless, Google explicitly stores the authors associated with a document as text:

They also seek to determine whether an entity on the page is also its author.

This, combined with the comprehensive mapping of entities and embeddings shown in these documents, suggests that systems can represent authors and entities. It does not demonstrate a universal authorship score or an automatic bonus for adding a byline.

Possible algorithmic demotions

Editorial note: these labels and their possible functions belong to the original analysis. In particular, Nav Demotion, location demotions, and the association with reviews are interpretations, not diagnoses that can be applied to a website based on a field name.

There are a number of algorithmic demotions discussed in the documentation. The descriptions are limited, but they are worth mentioning. We have already discussed Panda, but the other demotions I found are:

• Anchor Mismatch: When a link does not match the destination site it links to, the link is demoted in calculations. As I said earlier, Google looks for relevance on both sides of a link.
• SERP Demotion: A signal indicating a demotion based on factors observed in the SERP, suggesting possible user dissatisfaction with the page, probably measured through clicks.
• Nav Demotion: Presumably, this is a demotion applied to pages displaying poor navigation practices or user experience problems.
• Exact-Match Domain Demotion: In late 2012, Matt Cutts announced that exact-match domains would not receive as much value as they historically had. There is a specific feature for their demotion.
• Product Review Demotion: There is no specific information about this, but it is listed as a demotion and probably related to the recent 2023 product reviews update.
• Location Demotion: It is indicated that “global” and “superglobal” pages can be demoted. This suggests Google tries to associate pages with a location and rank them accordingly.
• Porn Demotions: This one is fairly obvious.
• Other Link Demotions: We will cover these in the next section.

All these potential demotions can inform a strategy, but it comes down to creating stellar content with a strong user experience and building a brand, if we are honest.

Links still matter

I have not seen any evidence refuting recent claims that links are considered less important. Again, this is likely due to the scoring functions themselves rather than how the information is stored. That said, a great deal of care has gone into extracting and engineering features to understand the link graph in depth. 

Hypotheses about indexing tier and link value

A metric called sourceType shows an unclear relationship between where a page is indexed and its value. To give you an idea, Google’s index is stratified into tiers where the most important content, regularly updated and accessed, is stored in flash memory. Less important content is stored on solid-state drives, and irregularly updated content is stored on standard hard drives.

King interpreted these tiers as a possible relationship between storage and link valuation. The sourceType attribute is not enough to prove that relationship or the rule that a fresh page provides a more valuable link. A reference’s currency, relevance, and usefulness should be assessed in context, not by a supposed physical location in the index.

Link spam velocity signals

There is a whole series of metrics for identifying spikes in spam anchor text. Taking note of the phraseAnchorSpamDays feature, Google effectively has the ability to measure spam link velocity.

This could easily be used to identify when a site is spamming and to nullify a negative SEO attack. For those skeptical about the latter, Google can use this data to compare a baseline of link discovery against a current trend and simply not count those links in either direction.

The reference to 20 versions does not demonstrate a general Google limit

I have previously discussed how Google’s file system can store versions of pages over time, similar to the Wayback Machine. The analysis suggests Google may retain historical versions, but does not prove that it indefinitely stores everything it has indexed. This is one reason you cannot simply redirect a page to an irrelevant target and expect link equity to flow.

The docs reinforce this idea by implying that they retain every change they have seen for the page.

When they surface data for comparison by retrieving DocInfo, they consider only the last 20 versions of the page. 

The reference to 20 versions corresponds to the interpretation of that component. It does not demonstrate that 20 changes or indexing requests erase a URL’s history. Correcting content and redirects should respond to relevance and usefulness, not a supposed “clean slate” formula.

Homepage PageRank: possible relationships between documents

Every document has its associated homepage PageRank, the Nearest Seed version. It is likely used as a proxy for new pages until they acquire their own PageRank.

This and siteAuthority are likely used as proxies for new pages until their own PageRank is calculated.

Homepage Trust

The documentation led King to propose that trust associated with the homepage could play a part in link valuation. Its use, weight, or current application is not demonstrated here.

As always, you should focus on the quality and relevance of your links rather than volume.

Font size: a documented feature, not a proven tactic

Editorial note: recording presentation features does not prove that enlarging text or links improves rankings. Use visual hierarchy for readability and accessibility. Similarly, droppedLocalAnchorCount does not by itself demonstrate that Penguin removes internal links.

When I started doing SEO in 2006, one of the things we did was bold and underline text or enlarge certain passages to make them look more important. Over the last 5 years, I have seen people say it is still worth doing. I was skeptical, but now I see that Google tracks the weighted average font size of terms in documents.

They do the same with link anchor text.

Internal links: interpreting droppedLocalAnchorCount

In many anchor-related modules, the idea of “local” means the same site. This droppedLocalAnchorCount suggests that some internal links are not counted. 

I have not seen a single mention of Disavow

Although disavow data could be stored elsewhere, it is not specifically found in this API. I point this out specifically because quality rater data is directly accessible here. The absence of a reference does not demonstrate where disavow data is processed or whether it is disconnected from ranking.

My long-standing assumption has been that disavow was a crowdsourced feature-engineering effort to train Google’s spam classifiers. That conjecture is not demonstrated by the field’s absence from this documentation.

I could go on about links and features such as IndyRank, PageRankNS, and so on, but suffice it to say Google has link analysis highly developed, and much of what it is doing is not approximated by our link indexes. It is a good time to reconsider your link-building programs based on everything you have just read.

Token limits described in some components

Google counts the number of tokens and the ratio of total body words to unique tokens. The documents indicate a maximum number of tokens that can be considered for a given document in the Mustang system, reinforcing the idea that authors should continue to put their most important content first.

OriginalContentScore and the originality of short content

Editorial note: the attribute name does not reveal an originality formula or an ideal length. The Google helpful content guide calls for original, complete, and reliable information and rejects a preferred word count. Keep the length the answer needs.

OriginalContentScore suggests that short content is scored for originality. This is probably why thin content is not always a function of length.

Conversely, there is also a keyword-stuffing score. 

titlematchScore and the relationship between title and query

The documentation indicates a titlematchScore exists. The description suggests Google still values the match between a page title and the query. 

The title should clearly identify the topic and address search intent. Always putting a keyword first is not a rule demonstrated by titlematchScore; avoid repeating terms and prioritize a descriptive title.

There are no character-count measures

To his credit, Gary Ilyes has said SEOs invented the whole idea of optimal character counts for metadata. There is no metric in this dataset that counts the length of page titles or snippets. The only character-count measure I found in the documentation is snippetPrefixCharCount, which appears to be configured to determine what can be used as part of the snippet.

The absence of a counter in this dataset does not demonstrate that long titles improve rankings. Google recommends descriptive, concise titles and may truncate them according to available width or generate a different title for the result.

Dates are very important

Google is highly focused on fresh results, and the documents illustrate its many attempts to associate dates with pages.

• bylineDate: The date explicitly set on the page.

• syntacticDate : A date extracted from the URL or title.

• semanticDate : The date derived from the page’s content.

It is best to specify a date and be consistent with it in structured data, page titles, and XML sitemaps. Conflicting dates can confuse people and the systems interpreting them. An automatic penalty cannot be inferred from this; use real, consistent dates, and do not change the publication date to appear new.

Domain registration information is stored about pages

It has long been a conspiracy theory that Google’s status as a registrar feeds the algorithm. Storing information does not prove that hypothesis. They store the most recent registration information at the composite-document level.

As discussed earlier, this is likely used to inform the isolation of new content. It may also be used to block a previously registered domain that has changed owners. I suspect its weight has recently increased with the introduction of the expired domain abuse spam policy

A classification of video-focused sites

The original analysis mentions a threshold of more than 50% of pages with video to identify a site focused on that format. It is preserved as a historical interpretation of the field, not as a current requirement, SEO advantage, or reason to add videos without usefulness.

References to YMYL classifiers

The documentation indicates that Google has classifiers that generate scores for YMYL Health and YMYL News.

They also make a prediction for “edge queries,” or queries not seen before, to determine whether they are YMYL.

Finally, YMYL works at chunk level, which led the author to propose a relationship with embeddings. This does not allow the entire system to be described or its weights to be inferred.

There are reference documents

There is no indication of what this means, but the description mentions “human-labeled documents” versus “automatically labeled annotations.” I wonder whether this is a function of quality ratings, but Google says quality ratings do not affect rankings. So we may never know. 

Site embeddings: topical affinity, not page freshness

Editorial note: “topicality” refers to a thematic relationship, not temporal freshness. The following examples describe the author’s reading of vector representations; they do not demonstrate a rule requiring all sites to cover only one topic.

I will discuss embeddings in more detail in a later post, but it is worth noting that Google is specifically vectorizing pages and sites and comparing page embeddings with site embeddings to see how off-topic the page is.

The siteFocusScore reflects the degree to which the site sticks to a single topic. The site radius measures how far the page strays from the central topic based on the site2vec vectors generated for the site.

A small-site label does not demonstrate a penalty

Google has a specific flag indicating whether a site is a “small personal site.” There is no definition of this type of site, but based on everything we know, it would not be difficult for them to add a Twiddler that boosts these sites or one that demotes them.

An update’s effects on small sites deserve investigation, but that label does not demonstrate an intention to harm them or explain a specific decline. Pages, queries, competition, and technical changes must be examined before assigning a cause.

Open questions from the original analysis

Editorial note: Baby Panda and the proposed expansion of NSR are historical hypotheses. They are not presented as official names for the helpful content system or as confirmed technical definitions.

I could go on, and I will, but it is time for an intermission. Meanwhile, I suspect it is inevitable that others will dig into this leak and reach their own conclusions. For now, I have a few open questions I would love us all to consider.

Is the helpful content update known as Baby Panda?

There are two references to something called “baby panda” in the Compressed Quality Signals. Baby Panda is a Twiddler consisting of an adjustment after the initial ranking.

It is mentioned as operating on top of Panda, but there is no further information in the documentation.

I think we generally agree that the Helpful Content Update exhibits many of the same behaviors as Panda. The apparent similarity does not prove they are the same system or allow a recovery based on clicks and links to be prescribed.

What does NSR mean? A question still open in this analysis

There are many references to modules and attributes with NSR as part of the naming convention. Many relate to site chunks and embeddings. Google has previously discussed “Neural Matching” as a major focus for improvement. My guess is that NSR stands for Neural Semantic Retrieval and that all these features relate to semantic search. However, in some cases they mention it alongside a “site rank.”

The meaning of NSR remains open in this analysis. No access to intranets, credentials, or anonymous confirmations of restricted information is requested: any clarification should come from authorized public sources.

Recommendations and opinions of the original author

As I said, I do not have recipes for you. However, I do have some strategic advice.

1. Send an apology to Rand Fishkin: Since my “Everything Google Lied to Us About” keynote at PubCon, I have been campaigning to clear Rand’s name regarding NavBoost. Rand did thankless work trying to help our industry rise for years. He received a lot of criticism from Google and the SEO world. He did not always get things right, but his heart was always in the right place, and he worked to make what we do respected and simply better. King defended his experiments on clicks, sandbox, subdomains, and site authority. This assessment does not turn all those conclusions into proven facts: they must be evaluated separately, with their methods and limits. He also deserves thanks for this analysis, since he was the one who shared the documentation with me. Now is a good time for many of you to show him some love on Threads.
2. Create great content and promote it well: I am joking, but I am also serious. Google has kept giving that advice, and we dismiss it as not actionable. For some SEOs, it is outside their control. After reviewing these features that give Google its advantages, it is fairly obvious that creating better content and promoting it to audiences it resonates with will have the greatest impact on those measures. Link and content feature measures will certainly take you quite far, but if you really want to win on Google long term, you will have to do things that continue to deserve to rank.
3. Bring back correlation studies: We now have a much better understanding of many of the features Google uses to build rankings. Through a combination of clickstream data and feature extraction, we can replicate more than we could before. I think the time has come to bring back vertical-specific correlation studies.
4. Test and learn: You should have seen enough visibility and traffic charts with Y axes to know that you cannot trust everything you read or hear in SEO. This leak is another indication that you should take inputs and experiment with them to see what will work for your website. Looking at anecdotal accounts of things and assuming that is how Google works is not enough. If your organization does not have an SEO experimentation plan, now is a good time to start one.

What the SEO community can learn

One important thing we can all take from this is: SEOs know what they are doing. After years of being told we are wrong, it is useful to have new clues to review our hypotheses, without concluding that all of them were correct. And although there are interesting nuances about how Google works in these documents, there is nothing that will make me drastically change the direction of my SEO strategy. 

For those who dig deeper, these documents will mainly validate what experienced SEOs have long advocated. Understand your audience, identify what they want, make the best possible thing that aligns with that, make it technically accessible, and promote it until it ranks.

To all SEOs unsure about what they are doing: keep testing, keep learning, and keep growing your businesses. Google cannot do what it does without us.

The resource mentioned in the original publication

Well, someone is going to download and organize all the features in a spreadsheet for you. It might as well be me. We only have one month left in the quarter, and I want to hit our MQLs anyway. 

The original iPullRank publication announced an organized list of features. This page does not offer its own download or verify that the resource remains available. The editorial reference is preserved to make sense of the article’s closing.

An analysis open to new evidence

What I have always loved about SEO is that it is a constantly evolving puzzle. And although helping brands earn billions of dollars through our efforts is fun, there is something deeply satisfying about feeding my curiosity with all the detective work involved in figuring out how Google works. It has been a great joy finally to see behind the curtain.

That is all I have for now, but let me know what you find! Anyone who wants to share something with me can do so. I am very easy to find.

A word from Agencia Cero

This article began as a translation by Agencia Cero Group of Mike King’s analysis at iPullRank. This edition preserves its development and incorporates editorial clarifications; it is not a literal translation. The original publication can be consulted here.

If you find an error, let us know so we can correct it.

We thank Mike King, the founder and CEO of iPullRank. Deeply technical and highly creative, the author’s introduction in the original text credits him with more than 2,000 million dollars in revenue for his clients; this is not an Agencia Cero result or a figure independently verified in this review. A rapper and recovering agency man.  A tremendous article that we bring into Spanish so SEOs across LATAM take more risks to improve their battle against the Big G.

How to apply this reading to SEO, AEO, and GEO

For a company in Chile or Latin America, the practical value lies in formulating testable questions, not chasing internal names. AEO seeks to answer specific questions clearly; GEO addresses presence in generative answers. Neither turns this historical documentation into a ranking recipe.

1. Define the question and audience of each page. Review whether the content answers with examples, scope, and limits, without repeating keywords to fill space.
2. Check access, indexing, internal links, canonical version, and mobile experience. Distinguish observable technical problems from hypotheses about the algorithm.
3. Write a specific title and a faithful description. Identify authorship and sources; update dates only when they correspond to real changes.
4. Record a baseline by page and query. Note changes and dates, compare equivalent periods, and consider seasonality, demand, and competition. Separate clicks, business inquiries, and verified sales.
5. Evaluate one hypothesis at a time when possible, document results, and avoid attributing causality to a simple coincidence. Do not buy clicks or links to manipulate signals.

Google explains in its AI Overviews and AI Mode documentation that SEO best practices remain relevant and that no special mandatory markup is required to appear. Eligibility does not guarantee indexing, inclusion, or citations. A clear answer, identifiable sources, and visible content help people evaluate information; they do not guarantee selection by a generative system.

Frequently asked questions about the Google leak

Was the complete algorithm’s code leaked? That is not what this material demonstrates. The article discusses API documentation and references to attributes, not the complete scoring functions or their weights.

Are the 14,014 attributes ranking factors? That cannot be claimed. The count cited by King refers to documented attributes, with potentially different uses and no general confirmation that they remain current.

Is siteAuthority equivalent to Domain Authority? No. Sharing an idea of authority does not demonstrate equivalence between an internal name and a third-party commercial metric.

Should you increase clicks or lengthen titles? Not as a ranking formula. Improve content relevance and follow the public recommendations on titles. Neither click manipulation nor greater length constitutes an improvement demonstrated by this documentation.

What changes for a strategy in Chile or Latin America? The analysis does not establish a different regional algorithm. It is useful to work on the audience’s actual language, questions, offer, and context, with evidence from the queries each site receives.

From hypotheses to decisions you can review

If you need to organize what to change and how to evaluate the result, explore our strategic web design and digital analytics services. Scope is agreed according to the site, available sources, and project objectives, without promising rankings or attributing results that have not been measured.