NavBoost: what Google’s click data does to your rankings

SEO articles

For years, every theory that Google ranks pages on clicks got the same treatment from Google’s spokespeople: denial, sometimes with mockery attached.

Then, in October 2023, Pandu Nayak, Google’s VP of Search at the time, took the stand in the DOJ antitrust trial and walked the court through NavBoost: a click-based re-ranking layer, running since around 2005. Half a year later the Content Warehouse leak named the click fields it runs on.

In this article I go through what the trial record and the leaked documents actually say about the NavBoost algorithm. That means what it changes about how you run SEO, what happens to a page that keeps disappointing searchers, which queries it touches, whether you can fake it, the Chrome question, and the documents and testimony behind all of it.

TL;DR

  • NavBoost is court-confirmed. Pandu Nayak described Google’s click-based re-ranking system under oath: running since around 2005, a rolling 13-month window, sliced by country and device.
  • A ranking is a hypothesis, and your visitors are the test. Clicks that end a search support a position; clicks that bounce back count against it. Positions with bad behavior under them are countdowns, not assets.
  • The famous field definitions are readings, not documentation. goodClicks and badClicks carry no description in the leaked documents; lastLongestClicks does.
  • Faking clicks is a bet against documented defenses. Squashed counts, IP priors and user floors sit in the same schema as the signals. Branded demand is the legitimate route to the same click pattern.
  • You cannot see NavBoost’s data, only its shadow. Four Search Console proxies below turn that shadow into a quarterly review; audit engagement before you spend on links.

Two kinds of evidence meet here, and they carry different weight. Sworn testimony is a court record; I treat it as confirmed and I link the transcript, so you can check my reading. The leaked documentation is a 2024 snapshot of what Google could store and compute, not a live view of production, so I treat every field as a working model that either predicts what I observe on client accounts or does not. Where a claim is only an industry reading, I say so.

Leaked Google Content Warehouse documentation: the CrapsClickSignals module with goodClicks and badClicks carrying no description
The raw evidence this article reads: the leaked click-signals schema. goodClicks and badClicks undescribed, squashed and unsquashed instances noted. Source: leaked Content Warehouse documentation, hexdocs 0.4.0 snapshot, accessed 2026-08-25.

What is NavBoost?

NavBoost is Google’s click-based re-ranking system, described under oath by Pandu Nayak, Google’s VP of Search at the time, during the DOJ antitrust trial. It aggregates good clicks, bad clicks and last longest clicks over a rolling 13-month window, sliced by country and device, and adjusts rankings that the first-pass scoring already produced.

That definition needs no leak at all, which is what makes NavBoost the cleanest case in the whole post-leak debate. The trial transcript is public. Asked whether NavBoost goes all the way back to 2005, Nayak answered: “It’s somewhere in that range. It might even be before that.” Asked about its weight, he called it “one of the important signals that we have”.

And the 13-month window comes from the same testimony, with a date attached: before 2017 the system memorized 18 months of queries, then Google cut it to 13. None of that is an SEO theory anymore. It is what Google said about itself once staying silent stopped being an option.

What does NavBoost change about how you run SEO?

This page owns the mechanism; the playbook owns the moves. Together they are the behavioural half of what I call BUXS.

The loop that compounds NavBoost is the checkpoint where coverage either converts into authority or starts expiring. Semantic coverage territory mapped, intent matched Eligibility and impressions you enter the click election Satisfied clicks NavBoost’s verdict, 13-month window Branded demand and site state siteAuthority, host click history the next page starts higher Each pass around the loop starts the next one higher. Neglect runs the same loop in reverse, on the same 13-month clock. Field names from the documents and the testimony; the loop itself is the BUXS operating model I run accounts on: brand, UX and semantics feeding each other, with NavBoost as the gate between them. szymonslowik.com · Szymon Słowik

What the mechanism itself dictates fits in four sentences.

Audit whether your ranking pages end the search or restart it, before you spend on anything else, because a position with bad behavior under it is already expiring.

Treat engagement as a time-series, not a switch: the window rolls for 13 months, so gains settle slowly and neglect decays slowly too. Write the title and pick the format at brief stage, because they act twice, once at scoring and once at the click that feeds this system. And fund branded demand, because people who searched for you by name are the one click population that almost never bounces back.

You cannot see NavBoost’s data, but you can watch its shadow, and Search Console is the only first-party window onto the neighboring events: impressions, clicks, position, per query and per page.

If you want a dashboard for the engagement layer, watch four proxies: click-through at a stable position per template, position stability through updates rather than raw position, impressions rising while clicks stall on your top thirty pages, and the trend of your branded impressions. None of them shows a bad click directly; together they draw its shadow. Verify after each core update.

Where the bad clicks are most likely accumulating differs by business model. GSC never shows the click verdict itself, so what follows are the proxy signs I check first, in the four models I work with most:

Business modelWhere bad clicks accumulateHow to spot it in Search ConsoleFirst fix
SaaS (B2B)Generic top-of-funnel posts ranking near money terms with mismatched intent; the visitor wanted a tool or a number and got an essayHigh impressions with near-zero clicks at positions 5-10; rankings on queries the product does not actually answerRebuild the page around the searcher’s job, or prune it; ship the small tool or template that ends the search on your domain
EcommerceCategory pages that rank while users bounce back to compare prices and options elsewhereStable position with a sliding click share on category terms; impressions hold, clicks decayMake the category a transactional answer: price ranges visible, decision arguments above the grid, comparison handled on the page
Expert servicesGuides ranking for cost and process queries without ever giving a number, so the searcher returns for a page that willTop-5 positions on “cost”, “price”, “how long” queries while leads stay flatPublish the fees, the timeline, and what happens at each step; the searcher stops on the page that finally answers
Banking and insurance (B2C)Template pages winning branded-plus-category queries on brand trust while generic variants quietly decay update after updateClicks concentrating on branded queries; generic-term positions stepping down at each core updateCalculators and eligibility checkers that end the search with a number; fix the template, not one page

And the counterweight, what to stop funding while the audit runs: links for pages that restart the search, because the same behavior that undermines the position will undermine the new links; click-buying services, for every reason in this article; and reports that celebrate positions without behavior under them. None of this is a growth tactic. It is triage, and it reprioritizes the whole backlog.

Does UX affect SEO? Yes: a documented re-ranking layer reads what users do after the click, so the experience your page delivers is a ranking input. How to act on that, the design, measurement and experiment side, is a discipline of its own, and I keep it in one place: the UX and SEO integration playbook.

I have watched the loop run in both directions on client accounts, including a fashion ecommerce brand whose rankings followed its branded demand up through the lockdowns and back down years later with nothing on the site getting worse. That case, graded honestly with its confounders, is in the pillar. Reading your own account for the same pattern, engagement first, links second, is how I open a strategic SEO audit, and the follow-through is what consulting engagements are for.

What happens to a page that keeps disappointing searchers?

It decays, and usually not on the day you notice. Bad engagement accumulates quietly under a stable position, then the correction arrives, often visibly around a core update. Good engagement works the same way in reverse, only slower. The window rolls for 13 months, so both directions are trends rather than events.

Here is the pattern I see most often, and it explains a class of site that confuses people. A page wins its position on architecture and authority: good internal linking, a strong host, a title that matches the query. It gets the traffic. Then it fails to hold anyone.

Sessions are short, visitors return to the results, nobody comes back a second time. The position was a hypothesis and the visitors voted it down. Rankings slide, the owner blames an algorithm change, and the algorithm change was mostly the moment the accumulated verdict got applied.

That timing is worth stating carefully, because it is a reading rather than something the documents spell out. My working model is that click-derived signals, or the systems and scores that consume them, are re-weighted heavily when a core update ships. It fits what I observe on accounts. It is an operational hypothesis, not a documented mechanism, and I would drop it tomorrow if the pattern stopped repeating.

The reverse case moves at a different speed. Pages that start ending searches do not jump; they firm up. Positions stop sliding through updates first, and only later does the average improve.

Expect early signals in a quarter or two and a full settle past a year, which is the horizon the 13-month window implies. Those numbers are a rule of thumb from my own accounts, not a figure from the record.

One live case, on an international insurance group’s Polish site. We rebuilt a heavily trafficked section around what the searcher actually needed and consolidated several related URLs into it with redirects, which means the page now carries both its own history and the record of what it absorbed.

The engagement data on it is being collected now, which is exactly the point: this is a system you verify over quarters, not one you declare victory over in a monthly report. I would rather tell you what I am measuring than sell you a case study that has not finished happening.

Does NavBoost affect all queries?

Not equally. NavBoost’s influence scales with how much click data a query generates. Nayak said it plainly in the same testimony: NavBoost is a factor “but by no means the only” one, because plenty of documents have no clicks at all.

Head terms with millions of monthly searches give the system a strong signal. A query searched a handful of times a month gives it almost nothing on its own, and other factors carry the ranking there.

The leak sharpens that picture with a concept worth knowing by name: the documents score a “Similarity score between this navboost_query and the incoming query”. Tom Capper’s reading at Moz, which I find convincing, is that Google keeps a finite list of high-volume queries with click histories, and folds the long tail into the nearest one by similarity. Your obscure query does not get its own click election; it inherits the results of the closest election that had enough voters.

Two practical consequences follow. For a newer or smaller site, narrow queries are where you can win on content merit before any click history exists, because there the incumbents’ behavioral moat is thinnest; that is the mechanism behind the old advice to win the long tail first.

And for head terms, the top of the SERP behaves differently than everything below it, because up there the click record is thick and incumbency compounds. Ever wondered why the top three results on big head terms seem frozen in place? This is the candidate explanation, and it comes with a paper trail.

New pages are not entirely naked either. The documents store click data at pattern level, with a documented field describing levels that climb from the exact URL up to host-wide patterns, plus stats aggregated from the URLs contributing to a pattern. On that reading, a new page starts from the behavioral record of the patterns it belongs to, your host prominently among them. Your site’s accumulated click history is the prior your next page inherits.

The inheritance mechanics are a reading; the pattern-level fields are documented. It is also one more way site-level authority and page-level behavior feed each other.

Can you manipulate NavBoost with fake clicks?

The controlled experiments say mostly no, and the documents explain why. This question has a longer history than most people asking it. CTR manipulation was tested publicly, years ago, by people who ran the experiments properly. Bartosz Góralewicz sent tens of thousands of clicks at his own test domain, pushed CTR to absurd levels, and watched positions stay flat.

Dan Petrovic ran his own series of click experiments around the same era, and they too mostly failed to move rankings. The summary I can defend: the controlled experiments mostly failed to move rankings, and the clearest effect anyone documented looked like a negative-SEO clickbot dragging targets down, not a durable boost up.

The leak explains why, and this is the part the manipulation vendors never quote. The defenses are documented in the same schema as the signals:

  • Squashed and unsquashed counts are stored side by side. The documents keep two instances of the click signals, squashed and unsquashed. What squashing does is not described; the standard reading, which I share, is a compression that limits how much any burst of clicks can count. Storing both versions is what you build when you expect the raw number to lie.
  • Clicks arrive with an IP-based prior. A documented field assigns “a prior based on IP address”, with its own penalty transformation. Your clickbot’s IP profile is priced into its clicks.
  • Thin data gets filtered on distinct users. The voter-token fields put a lower bound on how many distinct users stand behind an entry, “used for privacy-related filtering” in the documentation’s own words. That it also starves small-scale fakery is my reading; a floor built for billions is not what a handful of looping accounts clears.
  • The slices multiply the cost of faking. Signals are kept per country, language, device, and down to metro and city. A convincing fake has to be convincing in every slice where real users would appear, all at once, for 13 months.

Price the advice you read on this topic accordingly. One of the top-ranking explainers for this exact query is published by a company that sells crowd-sourced clicks, which does not make its mechanics wrong, but does make its optimism about click campaigns worth a second look.

Buying clicks is a bet against defenses Google wrote into its own schema. The stronger, legitimate version of the same idea is getting real people to search for you by name, and then keeping them from bouncing back to the results. Branded demand produces exactly the click pattern this system is built to reward, from real IPs, in the right slices, at scale, and it feeds the site-level authority state at the same time. That is one loop, not two tactics.

Does Google use Chrome data in ranking?

The record supports it, but the wording matters.

Google spent years downplaying or denying that Chrome data plays any role in ranking. DOJ testimony established that Chrome data reaches Google’s systems. And the leaked site-quality data, the same record that carries the authority signals, contains a field whose entire documented description is: “Site-level Chrome views.” The field is chromeInTotal, and it sits in the store Google keeps about your whole site.

Leaked documentation: chromeInTotal field described as Site-level Chrome views
The entire documented description of chromeInTotal in the site-quality store: “Site-level Chrome views.” Source: hexdocs 0.4.0 snapshot, accessed 2026-08-25.

My verdict, and I hold it as a working conclusion rather than a documented fact: used, and downplayed. You do not build a pipeline from your own browser into your quality store to leave the data idle. It also tells the same story NavBoost tells, that Google watches what real people do with your site, just through a different window: the browser sees the visits that never started at a search box.

One disambiguation, because it costs people real money. CrUX, the public Chrome User Experience Report, is a page-experience dataset and is not a documented NavBoost input; chromeInTotal is not CrUX, and optimizing Core Web Vitals is a different project than earning satisfied clicks. Do not let anyone sell you one as the other.

How does NavBoost work? The click family in the documents

Click signals do not rank a page on their own. They confirm or contradict a ranking the scoring systems already produced. Aggregated clicks that end a search support the position; clicks that bounce back to the results count against it. Over a 13-month window that verdict accumulates, and the re-ranking layer adjusts positions accordingly.

Everything from here is the evidence behind what you just read: the fields, the testimony, the sibling systems, and the argument about where this sits in the pipeline. If you came for the decisions, you already have them. If you want to check my reading, this is the part that lets you.

The leak documents the plumbing from the other side. The click data lives in a module family literally named QualityNavboostCraps, and the slicing Nayak described is written into the fields: a country slice (“US”, “FR”, “BR”), a language slice, a device slice, and a location id “for metro and city”. Google does not read your clicks as one global number. It reads them as a local election, market by market, device by device.

There is a third leg, older than both: a patent on modifying search result ranking based on implicit user feedback, filed years before anyone said NavBoost out loud, with a second candidate ancestor in Amit Singhal’s 2004 topicality-and-popularity patent, a connection Roger Montti drew first.

Leak, patents and testimony were produced years apart, by different people, none of them coordinating, and they land in the same place. That is the triangulation standard I use across the whole Google leak evidence base, and NavBoost passes it more cleanly than any other system in the file.

Google patent US8661029B1: Modifying search result ranking based on implicit user feedback, filed 2006, granted 2014, active
The older leg of the triangle: the implicit-user-feedback ranking patent, filed 2006, granted 2014, still active. Source: Google Patents, accessed 2026-08-25.

Google’s own framing of why this exists is in the trial record twice. An internal presentation by engineer Eric Lehman, entered as exhibit UPX0203, put it in one line: “Today, our ability to understand documents directly is minimal. So we watch how people react to documents and memorize their responses.”

A second Lehman deck, Life of a Click, exhibit UPX0004, draws the architecture: three pillars of ranking, where Body is what the document says about itself, Anchors are what the web says about it, and User-interactions are what users say about it. The same slide widens the vocabulary: interactions include clicks, attention on a result, swipes on carousels and typing a new query. The industry says “clicks” for all of it; so does Google, and so will I.

The field names under that third pillar are documented. Most of their plain-English meanings are not, and that distinction is where most NavBoost coverage goes wrong. Here is the click family as the documents actually give it, with the evidence grade attached. Quoted lines are verbatim from the leaked documentation; everything else is a reading:

Leaked documentation: lastLongestClicks described as the number of clicks that were last and longest in related user queries; goodClicks and badClicks with no description
QualityNavboostCrapsCrapsData: the one click field WITH a documented description (highlighted), the famous two without, and the country, language and device slices. Source: hexdocs 0.4.0 snapshot, accessed 2026-08-25.
FieldWhat the documents sayHow the industry reads it
goodClicksNo description in the documentsClicks that end the search. A reading, widely shared, not a definition Google published
badClicksNo description in the documentsClicks that bounce straight back to the results, the pattern known as pogo-sticking. Same status: reading, not definition
lastLongestClicks“The number of clicks that were last and longest in related user queries”The result that finally satisfied the searcher. Here the reading and the documented description actually agree
unicornClicks“The subset of clicks that are associated with an event from a Unicorn user”Some analyses sell this as a premium engagement signal. The description says it is about a class of user, not a class of click, and the documents never say what a Unicorn user is
impressionsStored beside the clicks; a host-level unsquashed impressions field exists, and compressed values are represented as click-ratiosThe denominator. NavBoost sees how often you were shown, not only how often you were chosen
voterTokenCount“A lower bound on the number of distinct users that contributed to the entry, used for privacy-related filtering”A floor on how few real people can stand behind a data point before Google uses it
unscaledIpPriorBadFraction“Used to assign a prior based on IP address”, pointing at craps-ip-prior.h and a penalty transformation in craps-penalty.ccClicks arrive pre-judged by where they come from. The anti-manipulation half of the system, named in the schema itself

Two things in that table moved my own understanding while verifying the fields against the raw documentation, because practitioner articles quote each other and the originals get lost. First, lastLongestClicks is not folklore; it has a documented description, and “last and longest” is Google’s own phrasing; satisfaction is the reading it invites.

Second, goodClicks and badClicks, the two fields every NavBoost article defines with total confidence, carry no description at all. The confident definitions are inherited readings. I share them, and I label them.

The loop NavBoost runs A position produces behavior; the behavior prices the position. There is no finish line. 1 · The impression result shown impressions stored 2 · The click goodClicks lastLongestClicks badClicks bounce back to results 3 · The store 13-month window sliced: country · language · device · metro squashed + unsquashed counts IP prior · user floor 4 · The re-rank the next searcher sees the adjusted order Then the adjusted order collects its own impressions and clicks, and the loop enters step 1 again. Field names from the leaked documentation; the window and slicing from Nayak’s testimony. A position with bad behavior under it is not an asset, it is a countdown the store is already timing. szymonslowik.com · Szymon Słowik

One more line from the trial record places NavBoost’s tuning. The exhibits describe its engineered functions as having parameters “learned by trying to maximize the IS ratings” of the rankings they produce, where IS is Google’s information-satisfaction score from human raters. So the click system is not self-referential: it is calibrated against what trained humans call a satisfying result.

A fair objection says Lehman’s “our ability to understand documents is minimal” predates BERT, MUM and the current transformer stack, and text understanding has improved enormously since. Right about the reading, wrong about the conclusion: better reading changes who enters the candidate set, and the behavioral check on whether the page satisfied the searcher stayed the ground truth. Clicks are the arbiter Google leans on hardest, not the only one; the named demotions and freshness decay act on rankings too.

The same shape repeats outside web results, which tells you it is architecture, not an experiment. The documents carry a dedicated click-signals module for image search, and NavBoost references appear in the video and science search modules as well. When a company rebuilds the same mechanism for every surface it runs, it is not an optional add-on. It is how the company decides what is good.

Does Google use clicks as a ranking signal? The Illyes and Nayak problem

Yes, and the honest version of that answer has to explain why Google said no for a decade. The record now brackets the denials from both sides, so the simplest way to show it is a timeline.

The record vs the public line What the court record and the documents show, against what Google said out loud. 2005 NavBoost live, “might even be before that” (testimony) 2012 FTC record: Manber confirms clicks feed rankings 2017 click window cut from 18 to 13 months 2019 “generally made up crap” (Illyes, public AMA) 2023 Nayak describes NavBoost under oath 2024 the leak names the click fields record: testimony, filings, documents public statements Every public denial sits between two entries of the record. szymonslowik.com · Szymon Słowik

A note on the 2012 entry, because the industry mostly remembers the 2023 one. When the FTC examined Google a decade earlier, its staff report, later obtained by the Wall Street Journal, already had Google’s Udi Manber confirming that click data feeds rankings. Then, in 2019, Google’s Gary Illyes answered the click question in a Reddit AMA with a line the industry still quotes: “Dwell time, CTR, whatever Fishkin’s new theory is, those are generally made up crap.”

Four years later Nayak, his senior, described the click-based re-ranking system under oath. All of it is on the record. At most one version can be the whole truth.

My read is that the contradiction is real and the resolution is narrow. Illyes was attacking a specific folk model: that Google watches your page’s live CTR or a dwell-time metric the way your analytics does, and nudges rankings in response. On the evidence, that folk model is indeed wrong, and the controlled manipulation experiments back him up.

What the testimony and the documents describe instead is aggregation: months of clicks, squashed, sliced by market and device, filtered for fake and thin data, applied as a re-ranking layer. The denials covered the narrow mechanism. They never covered the direction.

One more corroboration comes from outside Google entirely. When Yandex’s source code leaked in 2023, with actual weights and dozens of factors referencing Google by name, click-through, time-on-site and the last satisfied click sat among the highest-weighted factor families. A different engine, built separately, for a different market.

It corroborates the direction; it confirms nothing about Google’s weights. That is exactly how much I let it count.

What are Glue and CRAPS?

Glue is the whole-page version of NavBoost, and CRAPS is the storage and processing name in the documents. Two names orbit every NavBoost discussion, and neither deserves its own mythology; both are parts of the same watching apparatus.

Glue first. Nayak defined it under oath in one sentence: “Glue is just another name for navboost that includes all of the other features on the page.” The trial exhibits go further than the soundbite, and you’ll rarely see this detail quoted with a source.

Prof. Douglas Oard’s presentation quotes Google’s own materials: user interaction data from Glue is “one of the critical signals in Tetris”, the system that assembles the result page, and there is an Instant Glue, a realtime pipeline running on the last 24 hours of logs with a latency of about 10 minutes, used among other things to suppress a feature that users are ignoring. Interactions counted include clicks, hovers, scrolls and swipes.

Watched a SERP swap a features block for a video carousel and wondered who voted for that? Everyone who interacted with it, some of them within the last half hour. The page layout is downstream of the same behavioral data as the rankings, which is also what makes zero-click results a composition problem before they are a traffic problem.

CRAPS next. The modules holding the click and impression data are named QualityNavboostCraps, and the schema references craps-ip-prior.h and craps-penalty.cc as the code paths that judge and transform the counts (yes, the internal file names are right there in the docs). You’ll meet an expansion of the acronym in industry articles, most often “Click and Results Prediction System”.

I could not verify that expansion in the documents or the trial record, so I treat it as a community reading and nothing more. The name matters less than what the module documentably does: it is where the counts live, sliced and filtered, before the re-ranking layer reads them.

Where does NavBoost sit in Google’s ranking pipeline?

The exact wiring is disputed, and I want to show you the dispute rather than paper over it, because it is a good calibration exercise for how much the leak can and cannot tell you.

The common reconstruction runs: Mustang produces the first-pass scoring, then a serving layer of re-ranking functions, the Twiddlers, adjusts the ordering, and NavBoost is read as one of them. That placement is inference from module names and behavior, not a documented org chart.

The testimony complicates it usefully: in the transcript NavBoost “is reaching in” after the candidate set has been culled and helps pull documents forward, “a lot of the documents, not all of them”, which sounds less like a final polish and more like a hand in shaping the shortlist.

And in the DOJ exhibits, Google’s own framing is coarser and in some ways stronger: Hyung-Jin Kim’s notes describe the final IR score as composed from high-level buckets, with topicality built from anchors, body and clicks, NavBoost as its own component, and Quality alongside. In that picture NavBoost is not a bolt-on tweak; it is one of the load-bearing walls. Olaf Kopp’s DOJ-and-leak synthesis and Shaun Anderson’s NavBoost analysis reconstruct the placement differently in detail, and I recommend both precisely because they disagree in places.

Here is why I stopped caring about winning that debate: every placement anyone argues for leads to the same instruction. Whether NavBoost adjusts Mustang’s output at serving time, shapes the shortlist, or feeds the IR score as a bucket, the input is what people do after the click, and the window is 13 months.

The wiring changes nothing about what you do on Monday.

When a mechanism’s disputed details all collapse into one action, take the action and let the diagram argument run without you.

One boundary worth carrying from the pillar’s 2026 re-test: there is no verified evidence that NavBoost’s click data feeds AI Overview citation selection, which runs through a separate, faster retrieval system. Ranking and being cited are related goals, not one goal.

FAQ

Is NavBoost the same as RankBrain?

No. RankBrain is a machine-learning system on the query side: it helps Google interpret what an ambiguous or novel search means. NavBoost works on the result side, adjusting the ordering of results based on aggregated click behavior. They meet only in the sense that both were tuned against Google’s human-rater satisfaction scores, per the trial exhibits.

Does dwell time affect rankings?

No documented field measures “dwell time” as your analytics defines it. What the record supports is coarser and more important: lastLongestClicks documentably counts the result that was “last and longest” in related queries, and the split into search-ending and bouncing clicks is the industry reading of the rest. Satisfy the search; do not chase a minutes-on-page number.

Do Core Web Vitals feed NavBoost?

There is no documented connection. Core Web Vitals belong to Google’s page experience systems and are reported publicly through CrUX; NavBoost’s documented inputs are clicks and impressions. Speed can obviously shape whether a visitor stays, so the two meet in your user’s behavior, but treating CWV work as NavBoost optimization confuses the instrument with the verdict.

Is NavBoost how Google detects low-quality or unhelpful content?

Not directly, on the record. The helpful content system is described as a site-level classifier, and no document wires NavBoost into it. What the leak does show is click behavior stored in the same quality store as the site-level signals, so behavior and quality read as neighboring inputs. Treat “NavBoost demotes unhelpful content” as a reading, not documentation.

Is NavBoost still running today?

Nobody outside Google can certify what runs in production this quarter. The testimony shows a system in active, central use; the 2024 documents carried its modules; and the behavior it predicts, positions decaying under bad engagement and firming under good, is still what I observe on accounts. A model that keeps predicting observations is a model I keep using.

Direction and strategy: Szymon Slowik. Research and drafting support: LLM. Reviewed, corrected and finalized: Szymon Slowik.

Created by Szymon, edited with an LLM… see any difference? 🙂

Pozdrawiam serdecznie!

Share this post:

    Let's talk about SEO!

    This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.