En el contexto del juicio antimonopolio de USA contra Google, se han hecho públicas las declaraciones, muy jugosas, de 2 figuras clave del equipo de Búsqueda, las de Hyung-Jin Kim (HJ Kim), uno de los principales ingenieros responsables del sistema de ranking de búsqueda de Google (y creador de Navboost) y las de Pandu Nayak, VP of Search at Google. Ambos nos ofrecieron detalles inéditos y dieron más información sobre cómo se estructura internamente el ranking de resultados en Google Search.
Sus testimonios revelan cómo se definen y calculan la Calidad (Q) y la Topicalidad (T) y también cómo se integran estas señales con sus modelos de deep learning. Así como los problemas que les supone esta arquitectura en términos de ingeniería inversa. En este artículo pretendo hacer un análisis de ambos documentos, lo que nos permitirá entender mejor cómo funciona el motor de búsqueda más importante del mundo y qué implicaciones tiene para profesionales del SEO y curiosos del IR.
A excepción de algunas señales basadas en modelos de lenguaje (RankBrain, DeepRank), la mayoría de las señales que Google utiliza para determinar el ranking de resultados están diseñadas manualmente. En la práctica, esto significa que para la mayoría de señales, los ingenieros de Google aplican funciones matemáticas (como sigmoides) sobre datos observados (contenido, enlaces, comportamiento de usuario, evaluaciones humanas) y determinan umbrales adecuados mediante regresión o ajuste manual.
La razón de este diseño manual es que permite a Google intervenir y depurar el sistema cuando detecta comportamientos no deseados o anomalías, porque pueden trazar mejor los errores. Por ello, Google considera que este enfoque les da una ventaja competitiva frente a otros buscadores como Bing, que no lo hace. Y menos mal que muchas son manuales, porque una las cosas que se quejaban los ingenieros de Google Search en el Web Creator Conversation Event, es que no saben cómo arreglar sus algoritmos. Es decir, admitieron no ser capaces de explicar por qué sitios de calidad no sólo no logran posicionar, sino que son filtrados por completo por sus clasificadores.
Las dos señales principales en el sistema de ranking son Q* (Quality) y T* (Topicality). La primera mide la calidad percibida de una página web y la segunda, su relevancia respecto a la consulta.
La calidad (Q*, pronunciada Q star) es una señal mayoritariamente estática y está asociada a dominios más que a URLs individuales. Se calcula por dominio o conjunto de páginas y está formada por múltiples sub-señales como PageRank, autoridad del dominio, confiabilidad percibida, popularidad (comentan que la sacan de Chrome), reputación histórica y estructura del contenido. Aunque es estable, puede incorporar información específica de la consulta cuando el sistema detecta que la intención requiere un nivel de especificidad mayor (por ejemplo, cuando una consulta técnica necesita redirigirse hacia sitios con expertise demostrable). Este sistema fue desarrollado como respuesta a la proliferación de content farms, y ha evolucionado desde entonces para adaptarse a nuevas amenazas, como el contenido generado automáticamente por IA.
El PageRank alimenta a Q* como una de sus entradas y Google reconoce que Q* sigue siendo una de las señales que más impacto tiene en la percepción de los usuarios y también una de las más susceptibles a ser replicada si se expusieran sus logs internos (que es lo que pide el DOJ). Es decir, dada su naturaleza estable, si un competidor conociera su lógica, podría hacer ingeniería inversa fácilmente.
La topicality (T*, T star), por su parte, es una señal dinámica compuesta por tres elementos básicos que llaman el ABC:
Esta estructura ABC les proporciona un marco para calcular la relevancia semántica del documento frente a la consulta y luego se asocian con Navboost. Recordemos que Navboost mide cómo interactúan los usuarios con ciertos documentos para determinadas queries, tomando en cuenta variables como localización, tipo de dispositivo y temporalidad (últimos 13 meses) y se combinan para formar una puntuación de relevancia. Navboost no es un algoritmo de machine learning, es una tabla que tiene la información de comportamiento de los usuarios sobre cada URL.
Buscando cómo se podría calcular esto, hace tiempo llegué a una patente China (2015) donde explican cómo funcionaría Navboost (pero aplicado para ranking de video). No os podéis imaginar lo contento que me he puesto al ver que lo que cuenta HJ Kim es muy similar a esto que tenía guardado y que comparto a continuación:
navboost = a * normalizado(long_click_count) + b * normalizado(long_click_rate)
Donde:
final_score = α * topicality + β * quality + γ * navboost
Donde:
Esta combinación no es lineal y se realiza mediante curvas que ajustan el impacto de cada señal en función de su valor, que luego veremos.
La construcción de la topicalidad ha sido uno de los proyectos más largos y complejos de Google Search. Kim comenta que durante muchos años estuvo en desarrollo activo, pero en los últimos cinco años ha habido menos cambios estructurales.
Además, volvieron a explicar que usan RankEmbed, que no es más que un nuevo enfoque basado en modelos LLM. Es un sistema dual encoder que genera embeddings tanto para consultas como para documentos, y calcula su compatibilidad mediante la similitud entre vectores. Dicen que es extremadamente eficiente para consultas comunes, pero que tien limitaciones en el long tail. Según Nayak, fue entrenado sobre solo un mes de datos, lo que vuelve a ser un problema, ya que podría ser replicable por terceros si tuvieran acceso a suficientes ejemplos reales o sintéticos.
Como decíamos, las señales no se aplican de forma directa o lineal. En su lugar, Google utiliza curvas para ajustar la respuesta de cada señal en distintos rangos. Por ejemplo, una señal como el número de veces que aparece un término en el contenido no aumenta indefinidamente la relevancia, llega un punto de saturación que las curvas permiten modelar. Es decir, estas curvas:
Este enfoque no sólo aplica a señales raw sino también a las combinaciones de topicalidad y calidad. Algunas señales estáticas se almacenan dentro del propio índice para facilitar el acceso y las señales dinámicas, como las basadas en la consulta, se calculan en tiempo real. Para eficiencia, algunas señales dinámicas se almacenan temporalmente en tablas auxiliares. Este enfoque mixto (almacenamiento directo vs computación en real time) les permite balancear latencia y personalización.
De hecho, en consultas sensibles (como temas de salud mental), Google ajusta umbrales, pesos y curvas con mucho cuidado para controlar el tipo de información que se muestra. Un ejemplo de ello es la feature conocida como «suicide box».
En cuanto a los features del SERP, Google no sólo clasifica resultados web clásicos (los 10 links azules), sino que también decide cuándo mostrar bloques como paneles de conocimiento, carruseles (como el de top stories que expliqué cómo funcionaba aquí), imágenes… Para aplicar el ranking en estos módulos, HJ Kim lideró la creación de Tangram (anteriormente llamado Tetris, que también comentamos en este blog), un sistema que aplica principios de búsqueda (ranking, activación, diversidad) a cada componente del resultado.
Cada uno de estos features tiene sus propias curvas de activación, reglas, pesos y condiciones contextuales. Como por ejemplo, las AIO.
Google organiza sus señales en «buckets» (agrupaciones lógicas). Por ejemplo, hay un bucket de calidad, uno de topicalidad y otro para señales de navegación. Las señales de nivel superior se construyen como combinaciones lineales (normalmente del logaritmo de las señales raw), con el requisito de que su impacto sea monótono. Es decir, a mayor valor de la señal, mayor relevancia o calidad percibida.
Las puntuaciones de cada documento pueden visualizarse internamente en herramientas de depuración donde incluyen:
Estos sistemas permiten identificar por qué un documento aparece antes que otro, y realizar ajustes controlados si se detecta un fallo o una oportunidad de mejora. Muy manual, como decíamos antes. Por ejemplo, Nayak menciona un ejemplo sobre el negacionismo del holocausto en la SERP, donde Google ajustó su sistema para que fuentes fiables tengan prioridad absoluta en consultas sensibles.
Otra parte también manual y poco conocida del pipeline son los Twiddlers (de los que llevo años hablando), que son componentes que reordenan resultados una vez seleccionados por el sistema principal. Se usan para aplicar políticas de diversidad, cobertura semántica o afinamiento de resultados. Por ejemplo, evitar que todos los resultados sean de una misma fuente cuando hay muchas alternativas relevantes.
Por otro lado, Google elimina señales de ranking cuando estas:
El típico ejemplo clásico es el de la señal de CTR, que descubrieron que esta estaba sesgada por la posición en la SERP (tal y como comenté hace 10 años) y se sustituyó por una versión ajustada que compensaba ese sesgo (en función del slot de impresión).
Como ya sabemos, gran parte de las señales modernas de Google se alimentan de datos de interacción, lo que Google llama User-Side Data y que han estado negando hasta la saciedad. Esta data incluye:
Estas señales tienen una alta correlación con las preferencias del usuario y se usan para alimentar sistemas como Navboost. Luego, toda esta data se almacenan en tablas QD (query-to-document), que permiten hacer lookup en ambas direcciones. Es decir, dado un documento se puede saber qué queries lo activan, y dada una query, qué documentos responden mejor.
Históricamente, Google usaba funciones tipo BM25 para ranking, y es muy probable que las sigan usando. La razón es que es muy poco costosa para cálculos rápidos de relevancia (así vi que lo hacían en Yandex cuando analicé el leak del código de su algoritmo) y soluciona los problemas de TF-IDF en textos largos. Luego integró modelos ML (RankBrain, DeepRank) que servían como predictores adicionales. DeepRank (eDeepRank, como lo llaman internamente), por ejemplo, usa BERT y puede descomponerse en señales tradicionales. La estrategia actual es combinar señales clásicas con señales derivadas de modelos ML, lo que les permite obtener lo mejor de ambos mundos, es decir, interpretabilidad y cobertura semántica.
En paralelo, Google está «repensando su stack» desde cero con un enfoque LLM-first, lo que implicaría redefinir el rol de cada componente: recuperación, ranking, presentación de la SERP y personalización. Uno de los retos es el coste computacional de los LLMs, que varía según el uso (ej: respuesta instantánea vs re-ranking). Lo que ya estamos viendo con las AI Overviews.
Estos documentos confirman que, al menos sobre el papel, buena parte del sistema de ranking de Google sigue siendo altamente artesanal. La mayoría de señales parece que son mantenidas manualmente, calibradas con funciones diseñadas por ingenieros y, en teoría, depurables. Esto les permitiría intervenir de forma quirúrgica cuando algo falla.
Pero esta narrativa creo que entra en conflicto con la realidad actual. Desde el Helpful Content Update y otros Cores, hemos visto cómo el sistema se comporta de forma errática, filtrando sitios de calidad sin que los propios ingenieros puedan explicar o revertir los efectos, sesgados por la autoridad. Ellos mismos lo han admitido públicamente y de forma reciente. Así que por más que la arquitectura esté pensada para ser trazable, en la práctica, la escala, la interdependencia de señales y la opacidad que introducen algunos modelos hace que ese control se haya vuelto parcial, si no ilusorio.
Al mismo tiempo, no podemos ignorar que están avanzando y rediseñando su arquitectura hacia un enfoque más LLM-first. No para reemplazar todo lo anterior, sino para extenderlo. ¿Significa esto que las prácticas tradicionales dejan de ser válidas? Para nada y aquí te cuento por qué.
Foursquare anunció su asociación con OpenAI hace 4 meses para alimentar las búsquedas locales en ChatGPT a través de su Places API. Desde entonces, su base de datos, que incluye más de 100 millones de puntos de interés en más de 200 países, se ha convertido en una de las principales fuentes utilizadas por el […]
Leer másLa Inteligencia Artificial ha dejado de ser una promesa futurista para convertirse en una fuerza transformadora en el presente y, el SEO, tenía que subirse también a la ola. Problema: nadar por el estado actual de herramientas, workflows y agentes de IA para SEO puede ser complicado, y el hype existente nubla la realidad práctica. […]
Leer más