How NavBoost Really Works: The Click-Based Ranking System Google Denied

NavBoost is the system that tracks your clicks, measures how long you stay, and feeds that data directly into the ranking algorithm — precisely the kind of system that Google publicly denied existed for over a decade. Google's 2024 API leak revealed it under the internal codename CRAPS — visible in the API schema as QualityNavboostCrapsCrapsData. In a sworn statement during the United States v. Google LLC antitrust trial, an internal email from a Google VP (Exhibit UPX0197) was entered into evidence describing NavBoost as "more positive on clicks by itself than the rest of ranking." That makes it one of the most influential known re-ranking signals in Google's infrastructure — a feedback layer that acts on results after initial retrieval and scoring by systems like PageRank and BERT. The exact production weights and pipeline ordering are not public, but the direction of the evidence is clear: user behaviour is not a side note. It is central infrastructure.

If you want a grounding read on the system being described here, start with the NavBoost patent analysis — it covers the foundational mechanism in forensic detail. This guide goes well beyond that. I synthesize six patents in the NavBoost continuation chain, Google's leaked API documentation, sworn testimony from the DOJ antitrust trial, and over ten years of SEO work — including the practitioner data from those campaigns — into a unified theory of how NavBoost actually operates in production. Where claims rest on inference rather than direct observation, I've marked that clearly.

Honest Hedge

Every analysis has a threshold where certainty ends and inference begins. This guide draws from three evidence tiers:

---

---

---

The Evidence Stack

Evidence level: Confirmed — patent text, API leak fields, sworn federal testimony.

Let me show you what we're building from. Four categories of primary evidence — no secondary sources, no blog posts, no conference slides, no "a Google employee once said at a meetup." Here's the thing: everything in this guide traces back to patent text, leaked production code, or sworn federal testimony. If I can't point to the source document, it doesn't make the cut.

The Patent Chain (2004–2023)

NavBoost lives in a six-patent continuation chain. All six share identical specification text — the same technical mechanism, described in the same words. The only differences are in the claims (legal scope). This means the core architecture has been legally maintained, without fundamental revision, for over twenty years.

Six patents. Seventeen years of maintenance fees. Same specification text. This isn't legacy code — it's active production infrastructure. Google doesn't pay to maintain things they've abandoned.

But the patent chain doesn't exist in isolation. Three companion patents — some from the same inventors — feed into the broader NavBoost architecture:

The API Leak — Production Attributes

In 2024, Google's internal API documentation leaked. It revealed the production attribute names that map directly to the patent's mechanisms:

Attribute	Container	What It Maps To
goodClicks	CrapsData	Patent "long click" — user stayed, satisfied
badClicks	CrapsData	Patent "short click" — user bounced (negative weight)
lastLongestClicks	CrapsData	Final click + longest dwell — the strongest positive signal
unicornClicks	CrapsData	Disputed — see competing theories below
mobileSignals	CrapsData	Separate mobile click signals — device-specific NavBoost
navDemotion	CompressedQualitySignals	10-bit [0–1023] navigational UX penalty from badClicks ratio
pandaDemotion	CompressedQualitySignals	Site-level quality penalty (Panda system)
clutterScore	NSR	Page clutter — ads, popups, navigation noise
onsiteProminence	Content Density	Simulated traffic from homepage + high-click internal pages

unicornClicks — Two Competing Theories

Theory A: Child Privacy Flag

unicornClicks is a COPPA/GDPR-K compliance flag that identifies click data from minor users (under 13 in the US, under 16 in the EU). This data would be excluded or down-weighted from NavBoost's LC ratio calculations to comply with children's privacy regulations.

Source: Naming convention analysis. Google's codebase uses "unicorn" as an internal label for child/minor user classification in other products. Cross-referenced with COPPA compliance requirements for click data retention.

Theory B: Elite User Cohort

unicornClicks represents clicks from "unicorn users" — a statistically rare, high-value cohort whose engagement patterns are disproportionately predictive of quality. These could be power users, domain experts, or users whose historical click patterns correlate strongly with eventual ranking stability.

Source: Industry interpretation. Several SEO practitioners and analysts interpreted the field name literally as "rare, exceptional" users. No direct documentation has confirmed or denied this reading.

Our position: Theory A has stronger circumstantial evidence (naming conventions, regulatory requirements), but Theory B cannot be ruled out. The field could serve both functions — compliance flagging AND cohort weighting are not mutually exclusive in a system this large.

Note CrapsData — the container name. CRAPS stands for Click Rate Adjusted by Position and Style. The internal codename leaked alongside the data, confirming the direct connection between the API attributes and the patent mechanism.

DOJ Sworn Testimony

During the United States v. Google LLC antitrust trial (Case No. 1:20-cv-03010, D.D.C.), Google executives testified about NavBoost under oath. Sworn testimony is the highest-confidence evidence available outside the patent text itself.

Read that last one again. Google had an internal policy — in writing — telling employees not to discuss whether clicks influence rankings. Because they knew it did, and saying so publicly would invite manipulation.

So for years, Google's stated position was that clicks don't influence rankings — a position that, by their own internal policy, they knew was "debatable." The denial didn't prevent sophisticated operators from reverse-engineering NavBoost through testing. It only prevented good-faith practitioners from understanding the system they were building for. That's the part that bothers me.

Or, as Mark Zuckerberg would have put it:

Senator, we use clicks.

---

The Core Mechanism

Evidence level: Confirmed (patent + API) for the feedback loop and anti-spam layers. Strong inference for the system interconnections.

I've covered the LC ratio, click weighting, and IRBoost formulas in the NavBoost patent analysis. Here's the thing: knowing the formula isn't enough. What matters is understanding what these mechanisms create when they run together — a feedback loop that connects to everything else in Google's ranking infrastructure.

The Feedback Loop

NavBoost operates as a closed circuit:

But this understates its scope. NavBoost doesn't exist in isolation — it connects to at least seven other production systems:

Anti-Spam Safeguards

Now, the patent describes two layers of click manipulation defence. Very straightforward:

1. Democracy rule — Each user gets one vote per time period per query-document pair. Refreshing and clicking again doesn't generate additional signal.
2. Behavioural model — Anomalous click profiles are detected and filtered. If 40 clicks arrive from the same IP range within 10 minutes, all with exactly 90-second dwell times, the system flags and discards them.

From the API leak, we know additional safeguards exist: unscaledIpPriorBadFraction stores an IP-based spam prior, and voterTokenCount tracks distinct users who contributed data (a privacy floor that doubles as a manipulation detector).

---

The 4D Satisfaction Tensor

Evidence level: Confirmed for country, language, device (API leak fields). Strong inference for metro/location granularity (API feature data examples).

NavBoost doesn't store a single number per page. It stores a multi-dimensional satisfaction profile:

This means optimization must be device-specific and location-aware. A site targeting US English on desktop has a different NavBoost profile than the same site targeting UK English on mobile.

The Statistical Distribution Layer

At the host/domain level, Google tracks the complete statistical distribution of engagement:

This is where the real damage happens. If your site has 50 pages with excellent engagement but 200 pages with terrible engagement, Google sees high variance, low percentiles dragging the distribution, and 200 bad pages mathematically overwhelming the 50 good ones. This is the mechanism behind what happened to HubSpot — topical dilution across thousands of pages shifted the statistical distribution, and group-based quality scoring (US10055467B1) ensured those bad pages dragged the good ones down.

The 13-Month Memory Window

Pandu Nayak testified that NavBoost memorises "quite literally all of the data" from the last 13 months. Why thirteen and not twelve?

But storing 13 months of data doesn't mean applying all 13 months equally. If your LC ratio was 0.1 for twelve months and you fix everything, bringing it to 0.9, the system can't weight the twelve bad months equally against the one good month — that would make the system too punitive to be useful. Fresh positive data likely receives higher weight than stale negative data.

I've never seen a case where you have to wait six, seven, or eight months for NavBoost to "forgive" a site that has genuinely fixed its engagement problems. The recovery, in isolation, is faster than the 13-month window would suggest.

---

Speed as NavBoost Gateway

Evidence level: Practitioner observation from ~2,000 verified GSC accounts, supported by patent mechanism and API attributes.

Google's own documentation states that Core Web Vitals are used by its ranking systems. But the larger SEO impact of CWV is probably not as a standalone score. Let me be precise about what I think actually happens: CWV influences whether users can load, read, and stay long enough to form honest opinions — which influences NavBoost, which influences the re-ranking algorithm, which ultimately influences rankings. You move this lever and the engine works differently. This is more nuanced than most guides acknowledge — and getting the mechanism wrong leads to the wrong fixes.

Time to First Byte: The Real Lever

From approximately 2,000 verified Search Console accounts: the number of sites that hit 200 milliseconds or lower on Time to First Byte, I can count on both hands how many were already there when I first opened their Search Console.

The mechanism is very straightforward: Informational Gain divided by Cost of Retrieval.

Informational gain is the quality of your content — how much genuine, structured, parsable information the page provides. Cost of retrieval is dominated by one factor: how long the page takes to respond. Speed is money. If your site takes 1.5 seconds to deliver the page with all the information Google needs to answer a query, that's the equivalent of taking a month and a half to answer a phone call.

When you reduce TTFB from 700ms to 70ms, something immediate happens at the crawler level: "Oh, I can fetch all these pages now for a lot cheaper." Your crawl budget increases. And since making a site genuinely fast requires changing the HTML output — prefetching fonts, lazy-loading images, compressing CSS — you're also changing your SEO, because the moment you change your HTML output, you are changing your search engine optimisation.

The Reverse Evidence

Sites that migrate to slower hosting see traffic drops of greater than 75% — the same day. I've watched it happen. The new hosting is a "much better" package deal: hosting and SEO and PPC and everything for one monthly fee. Of course, the hosting is shared infrastructure with hundreds of other sites running poorly-developed plugins that consume bandwidth. Every site on that server is slow, and the rankings reflect it immediately.

Two NavBoost Connections

You Can Cheat Core Web Vitals (But You Shouldn't)

Here's the thing: Lighthouse tests can pass with flying colours while the site is still slow. There are ways to make the test look good while the real user experience remains poor. If your site passes Core Web Vitals but the time to first byte is anything higher than 600 milliseconds, ask your developer why. The score on the test means nothing by itself — what matters is whether the real problems have been fixed.

Core Web Vitals only matter as a measurement of the real things being done to make the site work for actual humans. The score is not the point. The experience is the point.

---

Content Architecture as NavBoost Optimization

Evidence level: Strong inference — API attributes (clutterScore, onsiteProminence) confirmed; their NavBoost connection is inferred from functional overlap.

Every structural decision on your website — the number of items in your navigation, the topical scope of each page, how your content is organised — is a NavBoost decision. Not because Google reads your sitemap and assigns points, but because these decisions determine what users do when they arrive.

MECE Content Architecture

The McKinsey MECE principle — Mutually Exclusive, Collectively Exhaustive — applied to content architecture is a NavBoost optimisation strategy:

MECE architecture structures your site so that users are far more likely to land on the right page and stay. That's a goodClick. Non-MECE content means users land on a partial answer, bounce to another page on the same site, or worse — return to the SERP and click a competitor. That's a badClick, and the competitor gets the lastLongestClicks signal.

Combined with a Bottom Line Up Front (BLUF) structure, MECE pages can produce short-but-satisfied dwell times. This works because of category-relative dwell scoring (US9514194B1) — Google compares your dwell time within content category, not globally. A 45-second visit to an emergency locksmith page is excellent. A 45-second visit to a comprehensive research guide is terrible.

Navigation Architecture: The 30→15 Play

Every navigation click within a site is potentially observable via Chrome user data. If a user clicks from the SERP to your site, then clicks three navigation items before finding what they want — that's a different signal profile than landing on the right page immediately.

The API leak reveals two attributes that connect navigation to NavBoost:

• onsiteProminence — simulated traffic from homepage and high-click pages. This metric tracks internal navigation patterns. Fewer items in the main nav means each remaining item gets MORE navigational signal.
• clutterScore — excessive navigation elements increase clutter, which correlates with badClicks. A mega-menu with 30 items is clutter. A focused navigation with 15 items is clarity.

Case Study: GetMeLinks.com Navigation Rebuild

The math: 30 items means decision paralysis. The user doesn't click, dwells briefly on the homepage in confusion, and either bounces or fumbles through irrelevant pages. That's noise in the statistical distribution. 15 items means clear choices. The user navigates, finds content, stays. Each remaining page gets stronger onsiteProminence signal because it's not competing with 15 other pages for navigation attention.

The Brand Signal Amplifier

From the Panda patent, site quality incorporates branded search volume:

Brand searches generate navigational queries where NavBoost operates differently. When someone searches "GetMeLinks" and clicks the homepage, that's a navigational query with expected short dwell — the user found what they wanted quickly. NavBoost uses the Viewing Length Differentiator for navigational queries, meaning shorter dwell is acceptable and even positive.

High brand search volume creates a positive feedback loop: more navigational queries → more navigational satisfaction → better NavBoost profile → higher rankings → more brand awareness → more brand searches. This connects Brand SEO directly to NavBoost mechanics.

---

The Most Dangerous Thing About NavBoost

Evidence level: Practitioner synthesis — editorial interpretation grounded in confirmed evidence from prior sections.

The most dangerous thing about NavBoost isn't getting the mechanism wrong. It's ignoring it entirely.

An internal Google email described NavBoost as "more positive on clicks by itself than the rest of ranking." Google had an internal policy telling employees not to discuss it publicly. And yet: the majority of the SEO industry's attention is currently focused on how to manipulate AI Overviews.

A lot of the attention in the industry goes to whatever is hot in the minds of prospects so that services can be sold to them, and not to whatever actually influences rankings. You can very clearly tell who belongs to the "I must know how this works and I must rank this website" camp versus the "I must be relevant in the conversation that's being had right now so that I can sell my services" camp.

NavBoost is in the first camp. It's not new. It's not trendy. It doesn't have a SaaS dashboard. But it's one of the most important signals in the ranking infrastructure, and most competent SEOs with a decade of experience either don't know it exists or have never read the patent.

NavBoost Is Machine Learning

A common critique is that patents describe how a system could work, not how a modern ML-driven system currently works. But here's the thing: NavBoost is machine learning. What does the machine learn? It learns that this result gets clicked more, gets dwelled on longer, produces more engagement signals — and it uses those patterns to determine that a higher-satisfaction page should be placed above a lower-satisfaction page.

That's the exact same fundamental principle behind Google's content quality classifier. 16,000 human raters evaluate pages against the 176-page Quality Rater Guidelines. Those ratings don't directly affect rankings — they train a machine learning model that can replicate those judgments at scale. One ML system evaluates the page at discovery, based on its content. The other — NavBoost — evaluates the page after it meets real users, based on what those users actually do. Pre-ranking quality is learned from raters. Post-ranking quality is learned from clicks. Both are machine learning. NavBoost isn't some legacy system running alongside modern ML. It is modern ML — the version that learns from the real world instead of from a training set.

The Economics of Manipulation

People ask me whether click manipulation works. The answer is nuanced, and it's niche-dependent.

Sophisticated manipulation can work. Server rooms with thousands of physical devices, aged Google accounts, rotated residential IPs, VPNs for geo-targeting, all running 24/7 — those operations exist. I've seen videos of them. I've known people who run them. They are real, and they are primarily deployed in industries where the unit economics justify the infrastructure: online casino, pharma, adult content. When the difference between position 3 and position 2 is five million dollars a month, the calculus changes entirely.

But you're not going to find that being done for a dentist in Tallahassee. A thousand physical devices, a thousand aged accounts with real activity history, a thousand residential proxies, and the infrastructure to orchestrate all of it — that costs serious money. The industries where click manipulation is economically rational are, by nature, industries where everything goes — and they are not the industries this guide is written for. If you're reading this site, you're most likely operating in what I'd call kosher niches: legitimate businesses where the competition is won on substance, not on who has the most sophisticated manipulation operation. In those niches — which is the vast majority of the SEO market — the cost of building and maintaining a manipulation operation genuinely exceeds the cost of doing the work properly.

The patent's anti-spam safeguards don't need to be perfect. They just need to make manipulation expensive enough that the honest path is cheaper — and for the niches where honest practitioners operate, they do.

The One Test That Matters

If you read this entire guide and walk away ready to make one change, here it is.

Now think about it this way. Imagine a business owner who just got an email from their partner on a Sunday afternoon: our organic traffic is down. They're panicking about Monday because if organic is down, sales follow — and they're about to make a big business move that depends on that revenue. So they pull out their phone and start looking for an SEO agency. Right now. On their phone. On a Sunday.

Can that person use your site? Can they find what you do? Can they tell within seconds that you're competent? Can they book a call for Monday morning — without a popup blocking their view, without a chatbot opening in the corner, without a background video that takes seven seconds to load while the button they were about to click shifts to a different position on the page? All they need is one thing: a simple site that works, where they can quickly confirm yes, these people look like they know what they're doing, and book a call. Please — please — don't give them a difficult website.

Now picture the other end. A marketing manager has had three months of internal discussions about whether to pursue organic traffic for a new market expansion. The CMO has finally approved the budget. It's a Tuesday afternoon. They've opened their project management tool, ticked a box that says "Research link building providers," and they're methodically working through the task — YouTube reviews, Reddit threads, agency websites, ChatGPT for a shortlist. Controlled office environment. Full attention. Zero stress. They're building a dossier: this is who I want to work with, this is what they do, this is how much they charge.

Those two people will have fundamentally different experiences on your website — and they're looking for fundamentally different information. The Sunday-night business owner needs confidence and a booking button. The Tuesday-afternoon researcher needs depth, proof, and pricing. They both exist in your analytics. If your site is designed to work only under ideal conditions — the Tuesday afternoon researcher, the high-attention desktop session — you are failing every single person who doesn't fit that profile. And NavBoost is recording every one of those failures.

I find it funny — and a little sad — that one of the most important re-ranking signals in Google's entire infrastructure comes down to something this simple. Not a formula. Not a framework. Just: can a real person use your website when they need it most? Twenty years of patent engineering, thirteen months of memorised click data, seven connected production systems — and the answer to all of it is whether your site works for someone who's stressed, distracted, and holding a phone.

You cannot circumvent the work. But if the work is good, and the people building it actually care about the humans on the other side? That's when things compound.

---

The NavBoost Checklist

Binary items. Either done or not. Work through these from top to bottom — they're ordered by impact.

Speed (The Gateway)

• [ ] Time to First Byte is ≤200ms (check GSC → Settings → Crawl Stats → orange chart)
• [ ] Core Web Vitals pass on mobile (CrUX data, not just Lighthouse lab test)
• [ ] All above-the-fold fonts and critical CSS are preloaded/prefetched
• [ ] Images use proper sizing, lazy loading, and modern formats (WebP/AVIF)
• [ ] No layout shifts after initial paint (CLS ≤ 0.1)

Content Architecture (The Signal)

• [ ] Each page covers exactly ONE topic scope (Mutually Exclusive)
• [ ] Full topic space is covered across all pages (Collectively Exhaustive)
• [ ] Each page opens with Bottom Line Up Front — the answer before the explanation
• [ ] No two pages on your site compete for the same query

Navigation (The Distribution)

• [ ] Main navigation has ≤15 total items across all dropdowns
• [ ] No mega-menus with 20+ links
• [ ] Zero popups on page load (especially discount/newsletter popups)
• [ ] Primary CTA is reachable within one click from any page
• [ ] Contact information is findable by a drunk user at 3AM on a phone

Signal Hygiene (The Defence)

• [ ] Title tags accurately represent page content (no bait-and-switch → reduces badClicks)
• [ ] Meta descriptions set correct expectations for what the user will find
• [ ] No interstitials or aggressive ad placements that delay content visibility
• [ ] Pages that consistently underperform are either improved or consolidated (reduce variance in host-level distribution)

---

Frequently Asked Questions

---

Citation Network

This deep dive synthesizes multiple primary sources into a production-level theory. The following resources on this site provide the forensic detail behind each evidence layer:

Related Research on This Site

• US8661029B1 — NavBoost Patent Analysis — The foundational patent mechanism: LC ratio, click weighting, three-level aggregation, IRBoost, and anti-spam safeguards. Start here for the mathematical detail.
• US10055467B1 — Group-Based Quality Modification — The host-level quality drag mechanism. Explains why poor pages mathematically pull down good pages through statistical distribution scoring.
• US9767157B2 — Panda Patent Analysis — Site quality scoring, branded search ratio, and the quality gates that determine NavBoost effectiveness at the domain level.

Primary Source References

• DOJ Antitrust Trial — United States v. Google LLC, Case No. 1:20-cv-03010 (D.D.C.). Testimony of Pandu Nayak, VP of Search. Proposed Findings of Fact at ¶¶207, 214.
• API Leak (2024) — Google's internal Content API documentation. Containers: CrapsData, CompressedQualitySignals, NSR.
• Patent Chain — US8661029B1 (anchor), US9235627B1, US9811566B1, US10229166B1, US11188544B1, US11816114B1. Companion: US8938463B1 (position bias), US9229989B1 (speed), US10055467B1 (group quality).