Are Google's 'Leaked' AI Ranking Signals Testable?

Verdict. The viral “7 leaked Google AI ranking signals” is not a leak. It is a documented enterprise search API, a set of console labels, and one name collision, repackaged with the hedge removed. Three of the claims are documented and testable, two of the named signals do not exist in Google’s public API, and the load-bearing “leak” claim — that consumer AI Mode runs on these signals — is unverifiable from anything Google publishes. Do not build a strategy on the names. Test the field set, keep the pipeline description, and drop the “leak” framing.

1. The operator and the leak

You run a site you want AI search to cite, or you are deciding which “AI SEO” advice to follow before you spend a sprint on it. A post with ~167K views claims Google “leaked” seven named ranking signals that power AI Mode: Base Ranking, Gecko, Jetstream, BM25, a three-tier PCTR system, Freshness, and Boost/Bury. It pairs that with a “500-token chunking” constant and three structured-data flags.

The decision is not “do I rank higher?” It is “which of these claims can I trust, and how do I test the rest?” That is a receipts question, which is what this Workflow Decision Lab is for. The claim is strong enough, and wrong enough in specific places, that the answer changes what you do.

2. How the claim travels: a hedge gets dropped

The viral post is a secondhand account. Its primary source is a researcher’s November 2025 writeup on Google’s Discovery Engine (a.k.a. Vertex AI Search, now “Agent Search”), an enterprise search product with a public API and public docs. That author is explicit about scope:

“I’m not saying AI Mode uses identical code. … Is this exactly how AI Mode works? I can’t say for certain.”

The viral post removed that hedge and replaced it with the word “leak.” That single edit is where most of the damage happens. A documented, configurable enterprise product becomes, by framing, a “secret ranking stack.” Every claim downstream inherits the error.

3. The receipts: what Google’s own API actually exposes

The load-bearing test is one lookup. Google’s Discovery Engine returns a rankSignals object on each result. The public field set, from the API reference, is:

rankSignals field	What it measures
default_rank	Base rank from the standard algorithm
semantic_similarity_score	Query/document embedding similarity
relevance_score	“Deep-relevance model” query-document interaction
keyword_similarity_score	Keyword matching, documented as BM25
pctr_rank	Predicted click-through / conversion
topicality_rank	Keyword-similarity adjustment
document_age	Age of the document in hours
boosting_factor	Combined custom boosts you applied

That is eight fields plus custom_signals. There is no gecko field and no jetstream field in the public API. Two of the seven viral signal names, in other words, are not in the product’s own schema.

What this tells you: the “seven signals” is a real, documented, and testable field set — but it is not what the viral post names it.

4. Where the “leak” breaks down

“Gecko” is a console label, not a signal

The source author flags this himself: there is a deprecated embedding model named Gecko, and the Cloud Console labels a column “Gecko score.” That is a human-readable UI name over the real semantic_similarity_score. Citing “Gecko” as a ranking signal is citing a dashboard caption, not the API.

“Jetstream” is a name collision

Google’s JetStream is a throughput-optimized TPU LLM-inference engine (an Apache-2.0 repo being archived in February 2026). It has nothing to do with relevance ranking. The viral post describes Jetstream as “a cross-attention model that handles negation better than embeddings.” The public API’s actual deep-relevance signal is relevance_score, described as a model that “handles complex query-document interactions.” Same job, different (correct) name.

“500 tokens” is a default you can change, not a secret

Agent Search’s chunkSize setting “defaults to 500” with “supported values: 100–500.” includeAncestorHeadings defaults to false. These are ingestion settings in your own data store. A “constant” you can edit in your own console is not a leaked internal value — it is documented configuration.

5. The testability ledger

The decision-useful artifact is the ledger, not the list. Each claim, checked against a primary source, and whether it can actually be tested:

Claim (as it went viral)	Primary source says	Testable?
“7 named ranking signals”	Public rankSignals: 8 fields + custom	Yes — read the API
“Gecko = embedding signal”	No gecko field; deprecated model, console label	Yes — grep the docs
“Jetstream = relevance model”	JetStream = TPU inference engine, unrelated	Yes — look it up
“500-token chunk constant”	chunkSize default 500, range 100–500	Yes — configure it
“BM25 still ranks”	keyword_similarity_score = BM25	Yes — documented
“PCTR 3-tier, 100K unlock”	Only pctr_rank is public; tiers are a console note	No — no public API
“AI Mode runs this pipeline”	Enterprise product docs, not consumer	No — not observable
“Serve stage uses Gemini 2.5 Flash”	No public model disclosure	No — unverified

The takeaway: the testable half (rows 1–5) is boring and documented, and you can verify it in an afternoon against the public API. The untestable half (rows 6–8) is where the “leak” earns its clicks — and where it is not backed by a receipt. The three structured-data flags (“searchable / indexable / retrievable”) sit in between: the concept of field-level control is real in enterprise search schemas, but the specific three-flag consumer mapping is unverified until checked against the schema reference.

6. The test protocol (the part that’s reusable)

This is the asset worth keeping. For any “leaked ranking signal” claim — yours, a client’s, or a viral post’s — run the same five steps:

1. Find the primary source. Who published it, what is their credential, and do they carry a hedge? A hedge that a secondhand post drops is a red flag, not a detail.
2. Map each named signal to a public API field. If the name does not exist in the schema, it is a console label, a name collision, or a fabrication.
3. Check product scope. An enterprise product’s docs do not prove consumer behavior. You cannot infer AI Mode from Agent Search.
4. Write a one-line test and a falsifier for each claim. “Testable” means you can name the query and the result that would be wrong.
5. Publish the ledger, not the leak. The ledger survives contact with the primary source; the “leak” evaporates.

You do not need Google’s internal system to do this. You need the public API, the primary source, and a table. That is the same discipline as shipping a local LLM inference field guide from one machine’s measured numbers instead of a vendor’s claim.

7. Failure modes

• Confusing a console label with an API field. The Gecko/Jetstream trap. A dashboard caption is not a signal; verify the name in the schema before you build on it.
• Inferring consumer behavior from an enterprise product. The epistemic core of the “leak.” Documented does not equal “AI Mode does this.”
• Treating a configurable default as a fixed constant. The chunking trap. If you can set it in your own console, it is documented configuration.
• Following a dropped hedge. The viral repackaging. When the secondhand post is louder than the source, the source’s caveats are the signal.
• Mistaking “documented” for “proven.” A public field that exists is not the same as a field that drives a consumer ranking you can see.

If you are already running agents that spend money against assumptions, this is the same class of error as a limit that does not actually stop spending: the control looks present, but it is not the control you thought.

8. When not to use this

The protocol is for secondhand, named-signal claims. It does not apply when:

• The claim cites a primary source you can access and the product scope matches — a real consumer experiment, an official Google engineering post, or a dated API response. There, “leak” can be legitimate evidence.
• The author publishes raw artifacts (API responses, screenshots, dated logs) and bounds the claim to exactly that scope.

The test is always the same: does the claim have a receipt, and does the receipt’s scope match the claim’s scope?

9. The 30-day test

Baseline: count the ranking-signal claims in your current content or AEO playbook that cite the viral post or a similar “leak.”

Run: for the next 30 days, when any “leaked ranking signal” claim surfaces, apply the five-step protocol above. Log each row in a ledger: claim, primary source, API field, test, verdict.

Measure: how many claims survive with a public receipt, and how many you drop or mark unverified.

Keep/drop rule: keep a claim only if it carries a public API/doc receipt or a bounded primary-source artifact. Drop or mark unverified anything resting on a console label, a name collision, or a dropped hedge. Review on day 30 and target 100% of ranking-signal claims in your playbook carrying a named receipt.

10. Bottom line

The “leak” is a documented enterprise API, a console label, and a name collision, sold with the hedge removed. What is real and testable — the rankSignals field set, BM25 still ranking, configurable 500-token chunking — is boring, public, and checkable in an afternoon. What is not testable — the three-tier PCTR unlock, the specific answer model, and “therefore AI Mode does this” — is where the framing does its work and the receipts run out. Test the field set, keep the pipeline, and stop calling a product’s docs a leak.