The Economic Logic Behind Google’s Algorithms

The economic constraint that dictates the engine’s architecture

Billions of queries a day, nearly a hundred thousand per second, directed at an index comprising hundreds of billions of pages, with a strict response time requirement: to display the list of blue links within a few milliseconds, whether on a computer with a strong internet connection or on a low-end mobile phone connected via 3G deep underground in the metro… .

That is the technical constraint, and it demands a huge feat, because to achieve this, time must be treated as a budget, and Google does not have the time, whether to rank every document in its index using its most precise models, or to match a query against a billion candidates using a transformer with ten billion parameters. Nor does it want to burn through money for nothing in pursuit of a marginally better result.

This is a fundamental constraint that shapes the engine’s architecture. And it explains why QBST and NavBoost are so crucial to its operation.

The problem: the physical impossibility of comprehensive scoring

To understand the issue, one must accept an idea that the general public generally struggles to grasp: building a search engine, evaluating a document, does not come free of charge. Every call to a machine learning model costs computational power, and therefore time, and therefore money.

Running a document through a lightweight algorithm, such as a TF-IDF calculation, takes a few microseconds. Running it through a classifier takes tens of microseconds. Running it through a transformer such as BERT or MUM takes milliseconds, sometimes tens of milliseconds per document.

On the scale of a single query, the difference is imperceptible, but on the scale of a hundred thousand queries per second on this index of a hundred billion pages, it is enormous. If Google wanted to apply its most precise scoring to every document in the index for every query, it would need to use the equivalent of several machine-years per query. Multiply that by a hundred thousand queries per second, and you end up with figures that make no sense.

This leads to a fairly logical conclusion: Google cannot finely score the entire index on the fly. It must filter aggressively before applying its costly signals, which is exactly what the cascade architecture offers.

The cascade architecture: coarse sorting first, fine sorting later

The principle of cascade ranking has been documented in the field of information retrieval for several years now. Wang, Lin and Metzler laid the academic foundations for it in 2011, and all major modern search engines with an index (Bing, Yandex, Baidu, Google) operate on this principle, adapted to their own infrastructures. The idea is simple: we link together several ranking stages, each more precise than the last, each operating on a more restricted subset of documents. We filter and clean the web, removing what amounts to spam or content that is uninteresting or illegitimate, in order to achieve an average standard closer to high-quality content.

In practical terms, here is the architecture as it can be reconstructed by cross-referencing the leak, DOJ testimonies, and Google research publications:

What makes this architecture viable is the combination of two properties. Firstly, the exponential reduction in the number of candidates at each stage: we go from billions to millions, then to thousands, then to hundreds, then to ten. Secondly, the reversal of marginal cost: the low-cost stages process many documents, the high-cost stages few.

It is within this logic that QBST and NavBoost must be situated. Not as peripheral factors. But as the components that enable the cascade to remain economically viable.

QBST: weighting the query even before the inverted index

QBST, which stands for Query-Based Salient Terms, injects intelligence learned from users into the query, and this is what makes it the search engine’s most discreet yet powerful tool. The public description of QBST is minimalist, but it does indicate that it operates directly on the query, rather than on the documents.

For each query (or family of queries), the system analyses which terms appear prominently in the documents that users have actually preferred over time. It derives a weighted representation of the query from this, where truly discriminating terms are given a high weight, and where incidental terms are downgraded.

The consequence is that this weighting can be applied to the inverted index itself. The inverted index is the engine’s fundamental data structure: a giant table that associates each query with the list of documents containing the important (prominent) terms that users expect to find in them. When a query arrives, this is what is consulted to retrieve the initial pool of candidates. Once the query has been processed, we retrieve all documents containing these terms, and ignore those that do not.

The initial pool of candidates is therefore smaller, cleaner and more relevant right from the first stage. The engine does not waste time loading into memory and filtering through millions of documents that had no chance: they never even enter the race.

This is the point in the pipeline where the economic impact is most significant. This optimisation saves a few hundred costly ML evaluations in stage 3. An optimisation at the recall stage saves several orders of magnitude in documents that won’t need to be processed at all. Filtering once well upstream is better than filtering ten times downstream: this is the central tenet of any cascade architecture, and it is why QBST is an essential component (and why Yourtext Guru is not a semantic optimisation tool like any other, since we identify the QBST terms for the queries you are targeting).

A small detail, but an important one: QBST is partly fed by what NavBoost measures. Salient terms are not defined in the abstract: they emerge from observing the documents that users have actually preferred. A loop is observed: clicks inform NavBoost, NavBoost determines the top documents, QBST extracts the salient terms from these documents, and these terms weight the inverted index for future queries. It is this loop that transforms the retrieval itself (and no longer just the ranking) into a hidden behavioural signal.

NavBoost: pre-aggregated click intelligence

NavBoost is mentioned several times in the leaked Content Warehouse documentation, and was confirmed under oath by Pandu Nayak, VP of Search at Google, during the DOJ trial. This double confirmation, combined with Google’s past misrepresentation regarding click measurement, gives this signal a special status

The attributes of the Craps module (which stores the signals used by NavBoost) are now widely discussed. goodClicks for clicks followed by a meaningful session. badClicks for pogo-sticking (the user returns to the SERP within a few seconds). lastLongestClicks for the last click of the session, the one that kept the user engaged the longest: according to technical analyses, this is one of the strongest signals (even if, technically, a click is the main requirement).

But what is interesting for this article is not the list of attributes, but the way NavBoost fits into the cascade. Behavioural scoring is not calculated on the fly for every query. The signals are aggregated and stored in the Craps module, indexed by query and by document, and queried during inference in the same way as a hash table. The marginal cost of a call to NavBoost is virtually zero compared to a full ML re-scoring.

That is Google’s economic advantage: by shifting the computational load upstream, into a pre-aggregation phase that runs continuously on its databases, to make on-the-fly queries trivial. At inference, NavBoost is almost free, but during training (in the broad sense: the continuous feeding of the databases), it is costly, though this cost is spread across billions of queries.

This property explains why NavBoost is structurally irreplaceable. The day Google decides to abandon behavioural re-ranking to return to purely semantic scoring, it would have to either accept a massive decline in relevance or run its transformers on more documents than it does today, which is economically absurd.

Moreover, as NavBoost is fuelled by user data collection, it is easy to see which tool is essential to its results: Google Chrome.

This undoubtedly explains Google’s reluctance to part with this tool when the DOJ and the European Union would like to force it to sell it or sell the data.

An uncomfortable strategic consequence

The perspective developed so far has direct implications for anyone serious about SEO:

We often talk about the three pillars of SEO; it’s a three-legged stool metaphor as old as the profession itself, but we need to view these points slightly differently today:

We often talk about the three pillars of SEO; it’s a three-legged stool metaphor as old as the profession itself, but we need to look at these points slightly differently today:

  • Technical aspects: your site must be readable by a bot. Poorly encoded information, incorrectly closed tags – your site accumulates errors, and eventually you end up with parsing errors that cause your page to be simply ignored. The bot is a crawl engine, which is effectively a queue, traversed by the fetcher, which sends the information to the parser, which identifies, from a reading perspective, what it can keep. What the fetcher wants is to retrieve your pages. What the parser wants is to read the page’s content. If you receive links from outside the page, the fetcher can reach it because the parser, at some point, on another page, will have seen a link to your page and will (perhaps) have added it to the queue. If the content of your page is readable by the parser, it will decide to send it for processing, but may carry out some pre-processing so that when it sends a URL to the queue, it avoids sending a useless URL, if it can detect this in advance.
  • Semantics: once the parser has read your pages, they are broken down into chunks, and the information contained within these chunks is evaluated based on numerous factors. In terms of semantics, it is a matter of using the right keywords (QBST) to ensure your pages are included in the pool of candidates for the targeted queries. There are other signals and filters, but from a semantic perspective, this is what it comes down to: semantic proximity to an expected vector for the query by using expected keywords, and the way the content is addressed (EEAT).
  • Authority: today, the real authority of a page or a site is primarily determined by Navboost (and therefore user clicks). Previously, we could rely exclusively on PageRank calculations, but today this is less the case. Normalised PageRank can really only be used in one place: in the crawler’s queue to prioritise the fetcher’s visit. (And even then, it is possible that PageRank is not the only signal on this side and that Navboost will eventually take its place, if it hasn’t already done so).

One should not suggest that, from Google’s perspective, we are in a world where factors are independent and where one could, if necessary, neglect one by compensating with the others.

The cascade architecture suggests the opposite:

Different signals can be used at different stages, depending on their processing cost during a response to a query. But if you only process the first few stages, you’ll be filtered out if the search goes further; if you only process the final stages, you won’t even appear in the list. The page may be flawless from Mustang’s perspective and pass the pre-scoring stage without a hitch, but if it does not generate the expected goodClicks and lastLongestClicks, it will not climb the rankings.

Worse still: it will drop down the rankings, because NavBoost is bidirectional. A poor behavioural signal results in active demotion (or simply means that other pages with the signal will end up ahead).

What this means in practice

If we take the cascade architecture seriously, the concept of essential elements in SEO is reshaped somewhat:

Optimisation for lastLongestClicks becomes the core of the job, meaning you must structure the page so that the user finds their complete answer without having to go elsewhere: the user must leave with their problem solved, without having to return to the SERP.

You must also ensure consistency between the promise of the title and the delivery of the content: titlesMatchScore has an impact and you don’t want to miss out on it (we’ll discuss this in more detail in another article).

Aligning with salient terms (the QBST approach) is also changing the way things are done. Working on lexical variants simply for the sake of covering the semantic field loses its meaning if these variants are not prominent in the sense that Google measures them: it is better to have content that thoroughly covers the terms that QBST has deemed prominent for the target query than content that is scattered across fifteen synonyms that offer little distinction.

This is also why Yourtext Guru closely monitors those appearing on the results page: analysing their salient terms has become a standard step prior to writing. (We cannot guess what QBST values; it is an observable factor).

Finally, the famous distinction between ‘on-page SEO’ and ‘off-page SEO’ is losing much of its relevance. The useful distinction, in the era of the cascade, is between eligibility signals (which move the page through the upstream stages: content, links, technical quality) and satisfaction signals (which drive progression through the downstream stages: user behaviour, alignment with the observed salient terms).

One final step, one first step

Computational cost constraints dictate the order of the stages and ultimately determine where the outcome is decided. The result is a sort of ‘vise-like’ architecture: QBST upstream, for the inverted index, and Navboost downstream, to provide a significant boost during re-ranking. In between, the computationally expensive stages of semantic scoring and machine learning scoring do their job to produce an initial response proposal via Mustang.

Sources used:
Hobo Web (https://www.hobo-web.co.uk/compressedqualitysignals/) Analysis of CompressedQualitySignals and https://www.hobo-web.co.uk/evidence-based-mapping-of-google-updates-to-leaked-internal-ranking-signals/

Yourtext Guru QBST: In 2025, Writing for Google means using the right words more than ever: post by Guillaume on QBST

A cascade ranking model for efficient ranked retrieval: Lidan Wang, Jimmy J. Lin, Donald Metzler (SIGIR (2011), pp. 105–114)