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

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 research on the leaked docs to confirm NSR, I 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, not from the DOJ antitrust files or API leak, but from a previous 2019 leak.

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.”
• 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:

Parameter	Type	Function
siteAuthority	Float	The primary site-level trust metric assigned across the sitechunk.
lowQuality	Float	An automated score (via Site2Vec) measuring the density of thin or low-value pages.
siteFocusScore	Float	Evaluates topical coherence across the domain.
siteRadius	Float	Measures how far individual pages drift from the site’s primary topic.
nsrConfidence / nsr_variance	Float	Data-stability indicators; lower traffic reduces confidence, dampening how aggressively NSR modifies page ranks.
nsrOverrideBid	Float	An internal override field inside the Q* (Quality Score) infrastructure used for manual or emergency interventions.

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.
• Top-Of-Funnel Unoriginal Content (tofu): A dedicated machine-learning classifier whose purpose is unknown. Potentially designed to penalise sites that aggregate, scrape, or rewrite top-of-funnel informational content without offering unique value, although this needs further investigation.
• 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

User Experience & Traffic	ML Quality Models	Strategic Overrides
• chromeInTotal • directFrac • pnav / pnavClicks • clutterScore	• Site2Vec • Project Racter • Tofu & Chard • SpamBrain (LAVC)	• nsrOverrideBid • isElectionAuthority • smallPersonalSite • isCovidLocalAuthority

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: This is not official advice from Google. It is SEO theory based on patents and code leaks. The metrics equations are borrowed from known IR (information retrieval) models rather than being extracted from 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 from the leaks or patents 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. Feedback and corrections welcome.