New Site Rank (NSR) – Google’s Site-Wide Quality Engine

This is part 1 of a 3-part series. Part 2 is here. Part 3 is here. 

Understanding that NSR stands for New Site Rank rather than “Neural” or “Normalized” shifts the strategy from chasing dynamic, page-level AI optimisation to managing an offline, batch-calculated authority ceiling for your entire domain.

Recognising it as a historical, domain-wide baseline – periodically updated via Google’s RankLab – explains why local on-page tweaks won’t immediately recover a site during core updates without macro-level brand and traffic shifts.

QUOTE: “No document defines the acronym, so I asked Erfan Azimi. His answer: the correct name is New Site Rank. Somebody guessed early, the guess got repeated, and repetition did the rest. I repeated it too, which is the ordinary way a field acquires a fact nobody checked. What sits behind the name is the part that changes a decision. In his words: “It’s directly connected to the RankLab system, and RankLab collects user data using live experiments, and they will collect the data, and retune it slightly based on human raters feedbacks. After retuning, the new data and new QualityScore is pushed out via a broad core update and affects the entire site. NSR has other components too, like links, PageRank, clicks, impressions, chrome traffic, and spam factors. There is a ratio of weight, smoothing, exact curve.” Szymon Slowik 2026

In search engine optimisation literature, NSR has frequently been misidentified as Normalized Site Rank or Neural Site Rank.

After my own independent research connected 2019 Vertias leaks to the 2024 API leaks to confirm NSR, I can safely agree with Azimi and will be updating my literature to align with this interpretation.

While normalisation and neural embeddings are computational techniques used within the pipeline, historical records and internal disclosures reveal that NSR stands for New Site Rank.

Rather than calculating site quality dynamically on a page-by-page basis, NSR functions as an offline macro-classifier that dictates a domain’s baseline authority ceiling across search results.

By cross-referencing leaked internal documentation – including the 2019 Project Veritas slide cache and the 2024 Google Content Warehouse API leak we can map out how NSR operates under the hood.

1. The Evidence: Tracing the Origins of “New Site Rank”

The 2024 Google Content Warehouse API leak introduced engineering attributes like predictedDefaultNsr, hostNsr, and QualityNsrNsrData, but left the acronym undefined.

One leaked Google slide I discovered through primary investigation, not from the DOJ antitrust files or API leak, but from a third, previous 2019 leak. This slide wasn’t in text format, so I had to access the image. And nobody seemed to pick up on this “New Site Rank from Web Search” before, publicly, and just how important a ranking system NSR actually was, with most commentators at the time more focused on the political aspect of the Fringe Query Classifier.

Establishing its true identity relies on cross-referencing internal technical leaks:

• Internal Cache Evidence: A leaked internal Google slide titled “Fringe ranking/classifier: Defining channel quality” explicitly references “New Site Rank from Web Search.” Another document in the cache lists “The NSR (site rank score) and Freshdocs Article Score both show that most documents were high quality news”.
• Code Confirmation (hostNsr): The 2024 API schema includes the deprecated hostNsr field, with an explicit code description stating: “This value encodes nsr, site_pr and new_nsr.” This provides direct code-level proof from Google’s repository.
• Cross-Platform Extraction: Google extracts web-based NSR metrics to grade corresponding video channels on YouTube.
• Distribution Anchors: Internal classifiers track entities using negative anchors (e.g., -1.56 or -3.35) to flatten the visibility distribution curve of untrusted or fringe entities.

2. The RankLab Loop and Strategic Memory Limits

NSR relies on RankLab, Google’s machine-learning experimentation infrastructure:

1. Session Ingestion: Live traffic signals—including click streams, impressions, and Chrome user patterns—are ingested.
2. Quality Evaluator Alignment: Feedback from human quality raters is injected into ML models to adjust scoring curves.
3. Batch Freeze and Deployment: Updated scores are frozen and pushed globally during Broad Core Updates, altering site authority across the index.

Memory Constraints & “Step Drops”

• Optimization via float32: In modules like MustangReposWwwSnippetsSnippetsRanklabFeatures, flatfiles enforce 32-bit floating-point variables (float32) instead of float64. This memory optimisation halves storage requirements across trillions of signals.
• The “Step Drop” Phenomenon: Because RankLab evaluates model changes in an offline sandbox, active SERP scores remain fixed between updates. When a new model is deployed during a Core Update, a site’s baseline shifts instantaneously, creating abrupt “step changes” in visibility.

3. Dissecting the QualityNsrNsrData Container

Google encapsulates these macro-quality features inside the QualityNsrNsrData protocol buffer. Key attributes include:

Emergency Switch (nsrOverrideBid): Documented explicitly as an asset for emergency overrides, nsrOverrideBid provides search engineers with a manual bypass. If an algorithmic deployment inadvertently demotes critical public safety resources, healthcare portals, or major trusted brands, engineers can manually adjust this bid to restore baseline authority.

The Horizontal Quality Suite: Peer Scores Inside QualityNsrNsrData

The schema definitions inside QualityNsrNsrData reveal that nsr operates alongside dedicated format-specific quality classifiers:

• nsr (General Web Authority): The core baseline metric determining search visibility across standard organic results.
• localityScore (Geographic Trust): Feeds into the LocalAuthority signal (go/pq-localauthority) to measure local relevance and regional trust.
• shoppingScore (Commercial Reliability): Evaluates e-commerce trustworthiness, merchant quality, and product intent handling.
• videoScore (Video Engagement): Grades domain-level video hosting quality and media topicality.

The Pipeline Engine: How nsrDataProto Solves the Serving Bottleneck

A critical entry inside PerDocData reveals how Google balances massive site-quality datasets with sub-millisecond serving requirements:

nsrDataProto (type: QualityNsrNsrData): “Stripped site-level signals, not present in the explicit nsr_* fields, nor compressed_quality_signals.”

Engineering Implications:

• Memory Striping at Scale: Calculating site-level quality requires parsing trillions of link, click, and query features. Google cannot pass these massive datasets through live search shards. Instead, upstream annotators (in Goldmine) “strip” non-essential metadata, leaving only lightweight mathematical vectors stored in nsrDataProto.
• Three-Tier Storage Model: This field proves Google categorises NSR data into three distinct architectural layers:
  1. Explicit nsr_* fields: Uncompressed, core attributes accessed instantly during primary scoring.
  2. nsrDataProto: Stripped, structured site-level features (holding variables like siteAuthority, siteRadius, and siteFocusScore).
  3. compressed_quality_signals: Bit-packed versioned data used for experimental overrides (experimental_nsr_team_wsj_data).
• The Schema Consolidation Hub: Legacy boolean flags—such as nsrIsElectionAuthority or nsrIsVideoFocusedSite—were deprecated as standalone attributes and merged directly into nsrDataProto to optimise index serialisation.

4. Link Neutralisation & SpamBrain Overrides

A strong NSR baseline can be neutralised if Google’s safety engine, SpamBrain, triggers a penalty:

• Low-Authority Verification Content (spambrainLavcScore): Measures the proportion of artificial content or low-trust links associated with the domain.
• Link Neutralisation: Rather than applying visible manual actions, modern SpamBrain models execute link neutralisation. The system zeroes out the PageRank passing through artificial link graphs or private blog networks (PBNs), causing the authority supporting the NSR baseline to vanish without direct notification.

5. Algorithmic Momentum (predictedDefaultNsr)

A key finding in the API schema is the predictedDefaultNsr attribute. Stored as a VersionedFloatSignal, this score represents the initial default trust level granted to a page or site in the Goldmine processing pipeline.

Because it is versioned, Google maintains a historical time-series of these scores. This creates algorithmic momentum: a domain that consistently demonstrates high quality over extended periods builds a positive trajectory that buffers it against minor fluctuations.

6. Architectural Synthesis: How sitechunks and nsrDataProto Execute at Scale

Analysing fields like hostNsr and nsrDataProto across the leak reveals the exact pipeline Google uses to serve site-wide quality metrics without slowing down search results:

1. Granular Host Chunking (sitechunks)

NSR does not treat every domain as a monolithic entity. The hostNsr definition confirms scores are evaluated across sitechunks—allowing Google to isolate specific subdomains, directories, or user-generated hubs. A domain can host low-quality content in one sitechunk without automatically pulling down the NSR baseline of its core authoritative sections.

2. Multi-Vector Score Packing

Google unifies distinct authority models through utility functions like quality_nsr::util::ConvertNsrDataToHostNsr. This function packs three core inputs into a single composite integer:

• Base content quality (nsr)
• Aggregate host PageRank (site_pr)
• Machine-learned iteration models (new_nsr)

3. Serving Shard Optimisation (nsrDataProto)

To satisfy sub-millisecond query constraints on live Mustang search shards, Google strips non-essential metadata from offline calculations. The resulting nsrDataProto container stores only the streamlined, essential mathematical vectors—providing live ranking shards with instant access to siteAuthority, siteRadius, and lowQuality without memory overhead.

7. Core Engineering Principles of QualityNsrNsrData

Analyzing the QualityNsrNsrData schema alongside previously uncovered modules (QualityFringe and RankLab) reveals additional engineering principles that define how Google measures, stores, and executes site-wide quality:

1. The Machine-Learning Core: ML-Driven Quality Models

Google does not rely on static heuristic checks; it deploys specialised machine-learning sub-models inside the NSR container:

• Site2Vec (site2vecEmbedding / site2vecEmbeddingEncoded): Similar to Word2Vec or Doc2Vec, Site2Vec maps an entire domain into a high-dimensional vector space. It evaluates topical consistency, calculating how far a site’s content strays from its core topic (siteRadius).
• Project Racter (racterScores): Named after the early artificial intelligence program, this model explicitly evaluates site-level Automated Generated Content (AGC). It acts as an automated filter for low-quality or scaled AI-generated content.
•  (tofu): “tofu is a hardcoded numerical quality classifier nested within Google’s offline scoring data. While the SEO industry frequently attempts to force-fit technical acronyms to the name (such as ‘Trust on First Use’), forensic analysis of the code alongside variables like ‘chard’ and ‘keto’ indicates it is a food-themed internal project codename. Its exact mathematical weight remains an internal proprietary secret, but it functions broadly as a baseline quality predictive signal for site chunks.”
• Keto Framework (ketoVersionedData): An internal experimental framework used within Goldmine/RankLab to test versioned quality iterations on live user cohorts before deploying them broadly during Core Updates. Further information needed to confirm.

2. Strategic Memory Management: How Google Scales to Trillions of Pages

Running site-wide ML evaluations on every search query would destroy SERP latency. Google solves this with specific optimisation techniques embedded in the schema:

• Vector Encoding (site2vecEmbeddingEncoded): Full vector embeddings are too memory-intensive to pass to live search shards (Superroot). Google compresses these embeddings into lightweight encoded formats to minimise memory footprints during live query processing.
• Variance & Confidence Dampening (nsrVariance / chardVariance): For smaller or low-traffic websites, user interaction signals are sparse. Google calculates variance metrics (nsrVariance) to lower its confidence score. When confidence is low, the system dampens how aggressively NSR modifies a page’s base rank, preventing lower-traffic sites from suffering drastic, erroneous algorithmic penalties.
• Fallback Aggregation (nsrdataFromFallbackPatternKey): When a specific sitechunk lacks sufficient traffic or crawl data, the system falls back to a structural average of related host chunks, ensuring every URL receives a baseline score without needing individual processing.

3. Dynamic Whitelisting and Emergency Interventions

The schema proves that while quality scoring is largely automated, Google maintains hardcoded programmatic and manual override switches:

• Hardcoded Vertical Whitelists (isElectionAuthority, isCovidLocalAuthority): These boolean flags act as priority overrides. When active, they elevate a domain’s visibility ceiling for specific civic, health, or crisis queries, bypassing standard algorithmic competition.
• Personal Site Preservation (smallPersonalSite): Driven by internal initiatives (go/promoting-personal-blogs-v1), this signal adds an algorithmic boost to small, non-commercial personal blogs to prevent them from being completely buried by high-NSR corporate publishing hubs.
• The Manual Override Switch (nsrOverrideBid): Documented via go/nsr-override-bid, this field functions as a manual safety switch. Search engineers can set a value greater than 0.001 to unconditionally override a domain’s calculated NSR baseline in the Q* (Quality Score) engine, instantly restoring visibility if an automated update accidentally penalises a major news brand or public safety resource.

Summary Matrix: How the NSR Schema Fits Together

Strategic Summary for Site Optimisation

Because NSR is an offline calculation trained within RankLab, local on-page adjustments will not immediately alter the metric. Shifting a domain’s NSR baseline requires macro-level brand adjustments:

1. Drive Navigational Brand Queries: Run campaigns that generate explicit branded searches (e.g., “Brand X running shoes” instead of generic terms) to reinforce NavBoost user preference vectors.
2. Consolidate Topical Radius: Prune off-topic, thin, or low-performing content to lower your siteRadius score and pass Site2Vec consistency checks.
3. Stabilise Chrome Footprints: Encourage direct traffic, newsletter visits, and user bookmarks (ChromeInTotal) to increase data stability and maximise the nsrConfidence signal.

Disclosure: I use generative AI when specifically writing about my own experiences, ideas, stories, concepts, tools, tool documentation or research. My tool of choice for this process is Google Gemini. All content was verified as correct. See Hobo Web AI policy.

Disclaimer: Note that this is not official advice from Google. It is an opinion. It is SEO theory based on my own primary analysis of Google patents and code leaks. Any article (like this) dealing with the Google Content Data Warehouse leak requires a lot of logical inference when putting together the framework for SEOs, as I have done with this article. I urge you to double-check my work and use critical thinking when applying anything about the leaks to your site. My aim with these articles is essentially to confirm that Google does, as it claims, try to identify trusted sites to rank in its index. The aim is to irrefutably confirm white hat SEO has purpose in 2026 – and that purpose is to build high-quality websites. The Google API leak exposes data structures and protocol buffers, not the live executing C++/Elixir code or algorithmic weights. Take for example siteQualityStddev ; While the attribute exists, no one outside Google knows its exact mathematical multiplier in real-time query retrieval. Treat most leaked parameters similarly. Some parameters listed may be inactive or superseded in production. Modern search models (like RankEmbedBERT) don’t use fixed C++ formulas at all. They rely on neural network weights trained on millions of interactions. You can’t “decode” a neural network’s decision-making just by looking at its input schema. Also note I only discuss sales, editorial and marketing-related attributes. I do not explore attributes tied to Abuse, Sensitive or Inappropriate classifiers in documents in any of my writings (and will not). I view the leaks as an architectural map of possibilities, not a cheat code. I suggest you do the same.