EEAT Mechanics

SegIndexer: How Google Tiers Its Index

Google does not index all pages equally. The SegIndexer decides which tier (level) of the index a page lands in, from lightning-fast to slow storage.

By Thomas Wawra· Published · Version 1.0· Systems referenced: SegIndexer / Tiers

01What is SegIndexer?

Google does not index all pages equally quickly or cheaply. The SegIndexer decides which 'tier' (level) of the index a page lands in. The range runs from expensive, lightning-fast servers (for important pages) to slower, cheaper storage (for rarely needed pages).

The Google API leak confirmed a scaledSelectionTierRank field with values 0-32767. This 16-bit integer determines the tier. Pages with high values (close to 32767) are stored on fast servers and served quickly. Pages with low values are stored on slower, cheaper infrastructure.

Q* (System 6), the site-level quality score, feeds the SegIndexer. This creates a direct link: high Q* → high tier rank → fast serving. Low Q* → low tier rank → slow serving. The quality of the site determines not just ranking position, but also the speed at which the page can be served.

Source per claim (3)
B
SegIndexer tiers the index: fast servers (important) to slow storage (rare).[1]
B
scaledSelectionTierRank: 0-32767 (16-bit integer).[2]
Source: Google API leak — field type and range · SegIndexer / Tiers · scaledSelectionTierRank
B
SegIndexer is fed by Q* (S6) — quality determines tier.[3]
Source: Google API leak — fedBy: [6] · SegIndexer / Tiers

02How tiering affects serving

The tier determines how quickly Google can serve a page in search results. Google can retrieve a page in tier 32767 (highest) and include it in search results in milliseconds. A page in tier 0 (lowest) might take hundreds of milliseconds. That is long enough that it might be excluded from results that need to be assembled quickly.

This has a practical consequence: pages in low tiers may not appear in search results for time-sensitive queries. The reason is not that they are irrelevant, but that they cannot be retrieved fast enough. The SegIndexer is a serving optimization — it trades completeness for speed.

For large publishers, this means that not all pages are equal in Google's index. A high-quality page on a high-quality site will be served faster and more consistently than a low-quality page on the same site. The site-level Q* affects all pages on the site, and the SegIndexer translates that into serving speed.

Source per claim (3)
C
High-tier pages are served in milliseconds; low-tier pages may take hundreds.[4]
C
Low-tier pages may be excluded from time-sensitive queries — not relevance, but speed.[5]
C
Site-level Q* affects serving speed for all pages on the site.[6]

03SegIndexer in the ranking architecture

SegIndexer has no downstream dependencies (feedsInto is empty). It is a terminal system: the tier assignment is the final step in the indexing pipeline. Once a page is assigned a tier, it stays there until the Q* changes or the page is re-evaluated.

The E-E-A-T dimension mapping shows SegIndexer as indirect for Authority (A: indirect). This is an unusual mapping: SegIndexer does not measure authority, but it responds to it. A page from an authoritative site (high Q*) gets a higher tier. That means faster serving, which means more visibility in search results — an indirect authority effect.

The architectural significance: SegIndexer creates a feedback loop between quality and visibility. High quality → high tier → more visibility → more traffic → more behavioral data → higher NavBoost → higher Q* → even higher tier. The loop reinforces itself for high-quality sites and weakens itself for low-quality sites.

Source per claim (3)
B
SegIndexer is terminal — no downstream dependencies.[7]
Source: Google API leak — feedsInto empty · SegIndexer / Tiers
B
SegIndexer is indirect Authority (A: indirect) — responds to authority, doesn't measure it.[8]
Source: Google API leak — dims: {A: indirekt} · SegIndexer / Tiers
C
Feedback loop: high quality → high tier → more visibility → more traffic → higher Q*.[9]

04References

API Leak (5)

  1. [1]BGoogle API leak — system description ↗
  2. [2]BGoogle API leak — field type and range ↗
  3. [3]BGoogle API leak — fedBy: [6]
  4. [7]BGoogle API leak — feedsInto empty
  5. [8]BGoogle API leak — dims: {A: indirekt}

This Deep Dive is Layer 2 content. It interprets the material and always points back to Layer 1, the reference layer. Every claim is mapped to a source, labeled by type: [A] Sworn testimony · [B] Verbatim from the leak · [O] Documented by Google · [W] Peer-reviewed study · [S] Checked on the page · [C] Our assessment · [P] Patent.

© Thomas Wawra · Senior SEO Manager · wetter.com — a Funke Digital company