# Ultra guía del renderizado en Google: qué ejecuta Googlebot, cuándo hace la captura y cómo comprobarlo
*Qué hace Google con tu página desde que la rastrea hasta que la indexa: cómo la renderiza, cuánto espera, qué ve y qué no, y cómo comprobarlo en tu web. Con pruebas que puedes repetir, el misterio de los 5 segundos explicado y lo que pasa fuera de Google, con Bing y la IA.*
Por Carlos Sánchez, con ayuda de IA
Publicado el 12 de octubre de 2026, 12:36 · Revisado el 14 de octubre de 2026, 15:42
Google no indexa el HTML que escribes. Indexa **el DOM que queda después de cargar tu página en su propio navegador**, ejecutar tu JavaScript y aplicar tu CSS. De esa diferencia sale casi todo lo que cuesta explicar en una auditoría: el noindex que nadie puso, el texto que está en la página y Google no ve, la captura de Search Console con un bloque enorme donde debería haber un artículo.
Llevo escribiendo sobre esto desde 2023 y haciendo mis propias pruebas: contadores, metaetiquetas inventadas, páginas con marcas de píxeles. En esta guía junto lo que he aprendido con ellas, lo que documenta Google y lo que han medido otros, ordenado para que se entienda de principio a fin: primero qué es renderizar, después qué hace Google con tu página y, al final, cómo comprobarlo en la tuya.
Es larga. Si solo quieres auditar tu web, ve directo al [checklist](#checklist).
## La versión corta
- Google indexa el HTML renderizado: el DOM tal como queda después de ejecutar tu JavaScript. Lo que el script añade cuenta igual que lo que venía del servidor, y lo que el script quita desaparece.
- Renderiza todas las páginas que responden con un 200 y no llevan noindex, tengan o no JavaScript, y casi siempre lo hace segundos o minutos después de rastrearlas.
- Según las pruebas publicadas (Google no lo documenta), captura la página cuando su reloj marca unos 5 segundos, pero ese reloj no es el tuyo: lo que retrasas con un temporizador de más de 5 segundos se queda fuera, y lo que tarda porque una API va lenta puede entrar.
- No hace clic ni scroll, y no recuerda nada entre una carga y la siguiente. Para ver lo de abajo estira la ventana, y por eso un bloque a 100vh (tan alto como la ventana) sin tope se estira con ella.
- Antes de renderizar ya ha leído el HTML del servidor, con su código de estado, su noindex y su canonical. Un noindex que venga ahí no se quita con JavaScript, y con la canonical es mejor no arriesgarse.
- Fuera de Google casi nadie ejecuta tu JavaScript. En mis pruebas, el índice de Bing no refleja lo que cambia el script, y la mayoría de los chats de IA leen solo el HTML cuando les das una URL. Un navegador con IA sí lo ejecuta, porque es un navegador.
- Todo se comprueba en el mismo sitio: inspección de URL de Search Console, «Ver página rastreada». Si tu contenido está en ese HTML, Google lo tiene.
### Seis palabras que vas a leer mucho
- **HTML inicial** (o código fuente): lo que envía tu servidor. Es lo que ves con Ctrl+U.
- **DOM**: el árbol que el navegador construye a partir de ese HTML y que JavaScript puede cambiar. Es lo que ves en el inspector de elementos.
- **HTML renderizado**: el DOM convertido otra vez en HTML en un momento dado. Es lo que Google indexa.
- **WRS** (Web Rendering Service): el servicio de Google que abre tu página en un Chromium sin pantalla, ejecuta el JavaScript y devuelve el HTML renderizado.
- **Snapshot**: el momento en que el WRS da la página por terminada y se queda con el DOM. No es una imagen.
- **CSR y SSR**: renderizar en el navegador del usuario (client-side) o en el servidor (server-side). Lo que importa para el SEO es quién monta el HTML y cuándo.
### Qué se sabe a ciencia cierta, qué está en disputa y qué conviene revisar
No todos los datos que circulan sobre el renderizado valen lo mismo. En esta tabla, «a ciencia cierta» quiere decir que lo documenta Google o que varias pruebas independientes han medido lo mismo; «en disputa», que hay fuentes serias que no coinciden o que falta una prueba publicada; y «conviene revisar», que el dato sale de una sola prueba, de una prueba antigua o de algo que cambia rápido.
| Dato | Lo que se sabe | Estado | De dónde sale |
| --- | --- | --- | --- |
| Qué indexa Google | El HTML renderizado: el DOM que queda tras ejecutar el JavaScript, no el código fuente | A ciencia cierta | Documentación de Google |
| Qué páginas renderiza | La documentación y Zoe Clifford (2024) dicen que todas las que responden 200 y no llevan noindex, tengan o no JavaScript. Martin Splitt dijo en 2023 que, si ya han detectado que una página es mala, se saltan el renderizado | En disputa | Documentación de Google y Search Off the Record (2024) frente al webinar de Duda (2023); medición de Vercel y MERJ |
| Espera entre el rastreo y el renderizado | Segundos o minutos para la gran mayoría de las páginas. Las medianas que se han dado van de 5 segundos (Google, de viva voz) a 10 (una medición externa) | A ciencia cierta | Google; Vercel y MERJ |
| El 10 % más lento de esa espera | Minutos según Google; unas 3 horas en el percentil 90 y unas 18 en el 99 según una medición externa | En disputa | Google frente a Vercel y MERJ |
| Cuándo captura la página | Cuando su reloj interno llega a unos 5 segundos. Ese reloj se para mientras espera a la red y corre deprisa cuando la página no hace nada: un temporizador de más de 5 segundos se queda fuera y una API lenta puede entrar | Conviene revisar | Mis pruebas, las de Dave Smart y las de Tony McCreath (Website Advantage). Google no lo documenta |
| Espera máxima en tiempo real | Unos 30 segundos en la indexación real y unos 50 en la prueba en vivo. Google no da la cifra | Conviene revisar | Pruebas de Dave Smart y de Tony McCreath |
| Caché de JS y CSS | Hasta 30 días, sin atender a tus cabeceras de caché | A ciencia cierta | Google (Crawling December) |
| Cuánto descarga Googlebot | 2 MB por URL y por recurso, medidos sin comprimir y con las cabeceras HTTP incluidas (64 MB en los PDF). Lo que queda detrás no existe | A ciencia cierta | Documentación de Googlebot (3 de febrero de 2026) y post de Gary Illyes (31 de marzo de 2026); avisa de que puede cambiar |
| Clics, scroll y estado | No hace clic ni scroll y no guarda cookies ni almacenamiento entre cargas | A ciencia cierta | Documentación de Google |
| Cómo ve lo que queda abajo | Agranda la ventana (viewport expansion) en lugar de hacer scroll | A ciencia cierta | Google; medido por Tony McCreath |
| Medidas de la ventana y de la captura | 981 × 1742 px al empezar en móvil y más de un millón de píxeles de alto en una prueba. La captura de Search Console corta a 1750 px | Conviene revisar | Tony McCreath; mi prueba con Mario Mangas |
| Hero a 100vh sin max-height | Se estira con la ventana y deforma la captura. Que además perjudique la indexación no está probado | En disputa | Mi experiencia en proyectos frente a Google |
| Quitar un noindex con JavaScript | No funciona. Añadirlo con JavaScript, sí | A ciencia cierta | Google; prueba de Dave Smart |
| ¿Se renderiza una página con noindex? | Google «puede» saltárselo, y se le ha visto ejecutar JavaScript en páginas noindex. Lo más habitual es que no, más si siempre estuvo en noindex | Conviene revisar | Documentación (desde diciembre de 2025); prueba de Dave Smart |
| Canonical hacia otra URL en el HTML inicial | Google solo dice que las canonical en conflicto, o cambiadas por JavaScript, pueden dar resultados inesperados. En mi experiencia, la página ni llega a renderizarse | En disputa | Documentación frente a mi experiencia, sin experimento publicado |
| Enlaces que solo existen por JavaScript | Se descubren más tarde, sobre todo en sitios nuevos. Un sitemap al día reduce mucho la diferencia | A ciencia cierta | Onely; Vercel y MERJ |
| Renderizado dinámico | Google lo desaconseja: es un parche, no una solución | A ciencia cierta | Documentación de Google |
| Web workers | Un worker sencillo se renderizó; los que pedían datos o tardaban más de un segundo, no | Conviene revisar | Prueba de Dave Smart de 2021, sin repetir |
| Bing | Dice que renderiza. En mis pruebas, su índice no refleja los cambios hechos por JavaScript | En disputa | Directrices de Bing frente a mi prueba |
| Chats de IA cuando les das una URL | La mayoría lee solo el HTML. Qwen ejecutó el JavaScript; DeepSeek, Kimi y Mistral, a veces | Conviene revisar | Mis pruebas (junio de 2026) |
| Rastreadores de IA | Descargan los ficheros JS, pero no los ejecutan. La excepción es AppleBot; Gemini va aparte | Conviene revisar | Vercel y MERJ (diciembre de 2024) |
| Navegadores y agentes con IA | Abren la página en un navegador de verdad, así que el JavaScript se ejecuta. Solo he probado uno | A ciencia cierta | Google; mi prueba con el navegador de Claude Code |
| AI Overviews y AI Mode | Recuperan las páginas del índice de Google: si tu página está indexada y la propiedad no está excluida de las funciones de IA en Search Console, pueden usarla | A ciencia cierta | Documentación de Google; ayuda de Search Console (control desplegado el 31 de agosto de 2026) |
Cada fila se explica en su capítulo:
1. [Qué es renderizar y por qué el HTML que escribes no es el que cuenta](#que-es-renderizar)
2. [Cómo renderiza Google: de la cola de rastreo al WRS](#como-renderiza-google)
3. [Qué ve Google y qué no: clics, scroll, ventana, recursos y caché](#que-ve-google)
4. [El HTML inicial manda: noindex, canonical, códigos de estado y soft 404](#html-inicial)
5. [El misterio de los 5 segundos: cuánto tarda y cuánto espera Google](#cinco-segundos)
6. [Estrategias de renderizado: CSR, SSR, estático, ISR, hidratación y renderizado dinámico](#estrategias)
7. [Cambiar lo que Google lee sin tocar el código de la web](#controlar)
8. [Cómo comprobar lo que Google ha renderizado](#herramientas)
9. [Fuera de Google: Bing, los chats de IA, sus rastreadores y los navegadores con IA](#fuera-de-google)
10. [Checklist para auditar el renderizado de tu web](#checklist)
11. [Preguntas abiertas](#abierto)
## Qué es renderizar y por qué el HTML que escribes no es el que cuenta
El HTML que se escribe no es el HTML que termina viendo el usuario. Por el camino puede haber un CDN, un CMS, un lenguaje de servidor o un JavaScript que lo cambie todo.
> El renderizado es el proceso de convertir el HTML en píxeles.
Es la definición con la que Martin Splitt abrió sus charlas en [SEO on the Beach 2023](https://sanchezdonate.net/articulo/noticia/martin-splitt-renderizacion/) y en [Andalu-SEO 2026](https://andalu-seo.es/ponente/2026/martin-splitt). A un buscador, sin embargo, los píxeles le importan poco: le interesa lo que el navegador construye por el camino, y lo vas a ver paso a paso.
### Del HTML al DOM
Ni los navegadores ni Google leen el HTML tal cual. Lo convierten en un árbol de nodos, el DOM, y trabajan con ese árbol (lo expliqué con más calma en [Renderizado en el SEO](https://sanchezdonate.net/articulo/renderizado-en-el-seo/)).
*El mismo documento como texto y como árbol DOM. El navegador trabaja con el árbol, no con el texto.*
El DOM es el modelo que el navegador se hace de la página: se construye a partir del HTML y recoge todo lo que JavaScript cambie después. Una forma de verlo es una receta. El HTML, el CSS y las imágenes son los ingredientes, el navegador cocina y el DOM es la masa de la que salen las tortitas.
Una casa sirve para entender otra cosa: por qué el mismo código no da siempre la misma página. Si la describes como si fuera HTML, con dos pisos, tres ventanas y una chimenea, queda así:
```
```
Dale esa descripción a diez personas y dibujarán diez casas distintas, todas correctas. Con una web pasa lo mismo: el mismo código produce resultados distintos según el dispositivo, el tamaño de la pantalla o la orientación. No existe «la página» como algo fijo. Existe un código y lo que cada navegador, o cada bot, construye con él.
En el DOM no queda ninguna marca de si un contenido venía en el HTML inicial o lo inyectó JavaScript, y eso ahorra muchas discusiones: si está en el árbol cuando Google lo captura, es indexable y puede posicionar.
### El recorrido dentro del navegador, en cinco pasos
El DOM es solo una parada. Desde que llega el HTML hasta que ves algo en pantalla, el navegador pasa por cinco pasos:
1. **Parseo:** lee el HTML y el CSS que le han llegado.
2. **DOM y CSSOM:** con el HTML construye el DOM y con el CSS su equivalente para los estilos, el CSSOM.
3. **Árbol de renderizado:** la combinación de DOM y CSSOM, solo con lo que se va a ver.
4. **Layout:** calcula dónde va cada cosa y qué tamaño tiene en pantalla.
5. **Pintado:** ahora sí, los píxeles.
En una web real estos pasos se ven en el panel de rendimiento de Chrome DevTools, cada uno con su color:
*El panel de rendimiento de DevTools. Azul: carga y parseo del HTML. Amarillo: ejecución de JavaScript. Lila: cálculo de estilos y layout. Verde: pintado.*
En este ejemplo el JavaScript crea más HTML, y por eso vuelve a aparecer azul después del amarillo. Detrás viene un bloque lila de unos 700 milisegundos: el navegador recalculando estilos y colocando cada cosa en su sitio. Ese bloque no tiene por qué ser culpa del JavaScript. Una página sin una sola línea de JS puede dar un gráfico parecido si el HTML y el CSS están mal planteados.
¿Con qué parte de ese recorrido se queda Google? Con el contenido y con la geometría. Para indexar, según contó Martin Splitt en [Andalu-SEO 2026](https://andalu-seo.es/ponente/2026/martin-splitt) (la organización publicó un resumen y las diapositivas), usa el DOM, que le dice qué hay, y el árbol de renderizado con su layout, que le dice qué tamaño tiene cada cosa y dónde queda. Los píxeles del último paso no los necesita.
Por eso **el snapshot que toma Google es del DOM, no una imagen**. Lo que se indexa es el HTML renderizado. La captura de pantalla que enseña Search Console está hecha para que la miremos nosotros. Cuándo se toma ese snapshot da para un capítulo entero: [el misterio de los 5 segundos](#cinco-segundos).
### Código fuente frente a DOM final: míralo en tu propia web
Los dos HTML se ven en diez segundos. El primero es el código fuente: pulsa Ctrl+U o escribe `view-source:` delante de la URL. Es lo que ha enviado el servidor, antes de que se ejecute nada.
*El código fuente (Ctrl+U) de un artículo del blog de Ahrefs: lo que envía el servidor.*
El segundo es el DOM final: clic derecho, «Inspeccionar» y pestaña Elementos. Es el árbol vivo, con todo lo que JavaScript ha añadido, quitado o cambiado desde que llegó el HTML.
*La misma página en el inspector de elementos: el DOM después de ejecutarse el JavaScript.*
En la captura hay un ejemplo pequeño. La barra de progreso de lectura lleva un `style="width: 13.3312%"`, un valor que nadie escribe a mano con cuatro decimales: lo va cambiando un script mientras hago scroll.
La prueba rápida es buscar una frase de tu contenido principal en el código fuente. Si no está ahí y sí en el inspector, la está poniendo JavaScript, y para que Google la lea dependes de que la renderice.
Ten en cuenta que el DOM de tu inspector es el de tu navegador, con tu pantalla, tus cookies y tus clics. El que ha construido Google solo se ve en la inspección de URL de Search Console; cómo leerla está en [el capítulo de las herramientas](#herramientas).
### Cliente y servidor: quién ejecuta qué (y por qué Java no es JavaScript)
*El servidor envía HTML, CSS, JS y multimedia. Lo que pase después depende del navegador.*
El servidor siempre le envía al navegador lo mismo: HTML, CSS, JS y archivos multimedia. Lo que cambia es quién ha hecho el trabajo antes de que lleguen.
Los lenguajes de servidor (PHP, Python, .NET, Ruby, Java, Liquid en Shopify) se ejecutan en el ordenador del hosting. Hacen allí su parte del renderizado y al navegador le llega el código ya procesado. Por eso en tu Ctrl+U nunca verás PHP: verás el HTML que PHP ha generado.
JavaScript actúa después y en otro sitio. Llega el HTML, el HTML le dice al navegador que ejecute los scripts y estos empiezan a modificar el propio HTML. Yo lo llamo «lenguaje parche». Y quien lo ejecuta es el visitante desde su móvil o su ordenador, o el bot que rastrea. Rastrear una web que depende de JavaScript lleva bastante más tiempo que rastrear una que no, y el tiempo son recursos y dinero.
Y aquí va la aclaración de siempre: [Java no es JavaScript](https://sanchezdonate.net/articulo/curiosidades/java-javascript-seo/). Java es un lenguaje de servidor más, de los que entregan el HTML ya hecho. JavaScript es el único lenguaje de programación que leen, procesan y ejecutan los navegadores. El nombre se parece porque en su día JS quiso aprovechar el tirón de Java, pero son tan distintos como el rumano y el romaní.
JavaScript también puede trabajar en el servidor, con Node.js o con un framework que renderice allí (SSR); lo verás en [las estrategias de renderizado](#estrategias).
### Plantilla más datos
Da igual que uses WordPress, Shopify o un desarrollo propio: una web son plantillas y datos. Piensa en una página de producto. La plantilla es igual para todos los productos y los datos viven en una base de datos. Alguien tiene que juntarlos, y puede hacerlo en tres momentos: antes de que nadie pida la página, en el servidor cuando llega la petición o en el navegador del usuario con JavaScript. Un WordPress los junta en el servidor con PHP; un framework de JavaScript que renderiza en el cliente (CSR), en el navegador.
Renderizar, para el SEO, es decidir dónde, cuándo y cómo se juntan. Cuanto más tarde y más lejos del servidor se haga, más dependes de que quien visita la página, sea una persona o un bot, ejecute bien el JavaScript, y más se separa tu Ctrl+U de tu DOM final.
## Cómo renderiza Google: de la cola de rastreo al WRS
Googlebot no es un navegador que entra en tu web, mira y se va, sino una cadena de colas y servicios en la que el navegador solo aparece en uno de los eslabones. Y es solo el cliente de la Búsqueda dentro de [una plataforma de rastreo compartida](https://developers.google.com/search/blog/2026/03/crawler-blog-post) por la que también pasan Google Shopping o AdSense, cada uno con su user-agent y sus propios límites.
Tener este mapa en la cabeza deshace muchos malentendidos: que si Google elige qué renderiza, que si manda la caché de tu servidor, que si lo que ves en tu Chrome es lo que ve él.
### El recorrido de una URL, paso a paso
1. **Descubrimiento.** La URL llega por enlaces, sitemaps o Search Console.
2. **Cola de rastreo.** Antes de pedir nada, Googlebot mira el robots.txt del host. Si la URL está bloqueada no hay petición HTTP y el recorrido termina ahí.
3. **Rastreo.** Descarga el HTML y nada más, como lo haría un `curl` muy optimizado, y guarda la respuesta con sus tiempos, sus cabeceras y la IP.
4. **Procesamiento.** Se evalúan el código de estado y la canonical, y se extraen los enlaces de los `href`, que vuelven a la cola de rastreo.
5. **Cola de renderizado.** Entran las páginas que han respondido 200 y no llevan noindex.
6. **WRS.** Cuando los recursos de Google lo permiten, un Chromium sin interfaz (headless) abre la página y ejecuta el JavaScript.
7. **Vuelta al procesamiento.** El HTML renderizado es el que se indexa, y de él se vuelven a extraer enlaces para la cola de rastreo.
*Esquema propio, basado en la [ilustración de Jan-Peter Ruhso](https://x.com/JanRuhso/status/1454026389078872065). Es orientativo, no un diagrama oficial de Google.*
El diagrama oficial, más escueto, está en [la documentación de Google sobre JavaScript](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics). En el mío hay más cajas de las que Google documenta, y el orden exacto de algunas (dónde se detecta un soft 404, por ejemplo) no está confirmado. Tómalo como un mapa, no como un plano: hay pasos que ocurren a la vez y pasos que se repiten.
Ese Chromium es [evergreen desde 2019](https://developers.google.com/search/blog/2019/05/the-new-evergreen-googlebot): se actualiza poco después de cada versión estable de Chrome. Antes, Googlebot renderizaba con un motor de hace años, y de esa época vienen muchos consejos que ya no aplican.
### El WRS dentro del sistema de indexación
La indexación de Google es un conjunto de servicios que hablan entre ellos, cada uno con su trabajo: el rastreo, el análisis del robots.txt, el de los enlaces, el del contenido, la eliminación de duplicados y el renderizado. El sistema procesa muchas webs a la vez, y una URL puede quedarse por el camino con un código de error mientras la de al lado sigue adelante.
> El Web Rendering Service (WRS) es el servicio que recibe el HTML ya rastreado y sus recursos, y devuelve el DOM renderizado.
*Diapositiva de Google, de la ponencia de Martin Splitt en SEO on the Beach 2023.*
Ese DOM es el que ves en la inspección de URL de Search Console y el que Google usa para indexar. Por dentro, el WRS tiene dos partes: el núcleo que renderiza y una caché de recursos. La caché es lo que le permite aguantar el volumen de webs que procesa cada día, y también el origen de buena parte de las diferencias con tu navegador.
Detrás hay una flota de navegadores:
*Diapositiva de Google, de la ponencia de Martin Splitt en SEO on the Beach 2023.*
Una capa de orquestación reparte el trabajo, otra instrumenta los navegadores y otra recoge métricas; un gestor (Pool Manager) mantiene un grupo de Chrome sin interfaz en marcha. Si una instancia se cae, arranca otra y vuelve a lanzar el trabajo (está explicado en [la ponencia de SEO on the Beach 2023](https://www.youtube.com/watch?v=BU8ZvTq4A6M&t=1024s)), así que un renderizado no se queda a medias por un fallo del navegador. En 2023 escribí que esto servía para detectar cloaking, y me equivoqué: relanzar un trabajo que ha fallado no tiene nada que ver con renderizar la misma URL varias veces para comparar.
¿Y si aun así el renderizado falla? Es raro, y en ese caso Google se queda con el HTML del servidor, que es mejor que nada. Cuando falla, suele ser por recursos bloqueados en el robots.txt o por casos límite, según [la medición de Vercel y MERJ](https://vercel.com/blog/how-google-handles-javascript-throughout-the-indexing-process).
### En qué se diferencia el WRS de tu Chrome
El WRS es Chromium, pero no se comporta como el Chrome que tienes abierto:
| Qué | Tu Chrome | El WRS | Fuente |
| --- | --- | --- | --- |
| Red | El navegador descarga cada recurso. | No sale a la red: le pide cada recurso a Googlebot. | [Splitt e Illyes, Crawling December](https://developers.google.com/search/blog/2024/12/crawling-december-resources) (3 de diciembre de 2024) |
| Caché | Obedece tus cabeceras HTTP de caché. | Caché propia de JavaScript y CSS de hasta 30 días, al margen de esas cabeceras. | Crawling December (2024) |
| Estado | Conserva cookies, Local Storage y Session Storage. | Sin estado: los borra entre una carga y otra. | [Guía de problemas de JavaScript](https://developers.google.com/search/docs/crawling-indexing/javascript/fix-search-javascript) (act. 18 de diciembre de 2025) e Illyes (2026) |
| Imágenes y vídeo | Los descarga. | No los pide. Tampoco las fuentes. | Illyes (31 de marzo de 2026) |
| Shadow DOM | Árboles separados. | Aplana shadow DOM y light DOM en el HTML renderizado. | Documentación de JavaScript (act. 4 de marzo de 2026) |
| Azar y reloj | Math.random() distinto en cada carga y hora real. | Math.random() devuelve siempre la misma secuencia y el reloj está manipulado. | [Experimento de Tony McCreath](https://bigcommerce.websiteadvantage.com.au/tonys-theory-of-googlebot-relativity/), de Website Advantage (pruebas de principios de 2025) |
La primera diferencia es la que más cuesta interiorizar. Como el WRS no sale a la red por su cuenta, cada JS y cada CSS lo pide Googlebot: respeta el robots.txt y gasta crawl budget del hostname que aloja el recurso. Por eso entre un paso y otro puede pasar bastante más tiempo que en un navegador.
La segunda significa que para el WRS no manda tu `Cache-Control` (qué hacer con eso está en [la caché de 30 días](#cache-30-dias)). Y «sin estado» quiere decir que para Google siempre es tu primera visita: si el contenido depende de una cookie o de algo guardado en Local Storage en una carga anterior, no lo va a ver.
La última, la del azar y el reloj, no está documentada, pero se ha medido ([esta prueba](https://bigcommerce.websiteadvantage.com.au/tonys-theory-of-googlebot-relativity/) lo detalla). La explicación más razonable es que Google quiere que dos renderizados de la misma página den el mismo resultado, y ese reloj manipulado es el que explica el [misterio de los 5 segundos](#cinco-segundos).
### El límite de 2 MB y el orden dentro del HTML
Si te suena la cifra de 15 MB, es la que figuraba antes en la documentación. Google la cambió en la [página de Googlebot](https://developers.google.com/search/docs/crawling-indexing/googlebot) el 3 de febrero de 2026, y el 31 de marzo Gary Illyes explicó [cómo se cuentan esos bytes](https://developers.google.com/search/blog/2026/03/crawler-blog-post). Los números son estos:
- Googlebot descarga como máximo **2 MB por URL**, PDF aparte. El límite se aplica sobre los datos sin comprimir (no sobre lo que viaja con gzip o Brotli) e incluye las cabeceras HTTP.
- En los PDF el límite es de 64 MB.
- Cualquier otro rastreador de Google que no declare un límite propio usa 15 MB por defecto.
- Los rastreadores de imagen y vídeo tienen umbrales que cambian según el producto.
Cuando un HTML pasa de 2 MB, Google no rechaza la página: corta la descarga ahí y entrega ese trozo a indexación y al WRS como si fuera el fichero completo. Lo que queda detrás ni se descarga, ni se renderiza, ni se indexa.
Cada recurso que pide el WRS tiene su propio contador de 2 MB, independiente del HTML. No suman, pero tampoco se libran: la documentación aplica a cada recurso el mismo límite que al HTML, y el post de Illyes avisa de que el WRS solo ejecuta el código que el rastreador haya llegado a descargar. Un bundle de JavaScript de más de 2 MB llegaría cortado.
A la inmensa mayoría de las webs esto no les afecta: 2 MB de HTML es muchísimo. Lo que sí depende de ti es el orden. Lo que empuja el contenido por debajo del corte son las imágenes en base64 incrustadas, los bloques enormes de CSS o JavaScript en línea y los megabytes de menús al principio del documento. De ahí dos reglas:
- El CSS y el JavaScript pesados, a ficheros externos, que se descargan aparte y tienen su propio límite.
- Lo crítico, arriba: title, metaetiquetas, canonical, elementos `link` y los datos estructurados esenciales. Si caen por debajo del corte, para Googlebot no existen.
Google avisa de que el límite puede cambiar.
### ¿Renderiza Google todas las páginas?
Eso dice la documentación: todas las que responden 200 y no llevan noindex, tengan JavaScript o no. Y lo dijo Zoe Clifford, del equipo de renderizado, en [Search Off the Record](https://www.youtube.com/watch?v=XBT_DUzUbOI&t=264s) el 11 de julio de 2024, cuando le preguntaron cómo deciden qué páginas renderizar: «We just render all of them as long as they're HTML». Tampoco hay sitios a los que se les «apague» el renderizado durante semanas: [todo va a la cola](https://www.youtube.com/watch?v=0iHDk7uqByI&t=1489s), según Martin Splitt en la entrevista con Olga Zarr de mayo de 2024.
Lo respalda una medición externa. Vercel y MERJ analizaron más de 100.000 peticiones de Googlebot, casi todas en nextjs.org, y todas las páginas HTML indexables con código 200 acabaron renderizadas, incluida una sin JavaScript. Su alcance es limitado (un mes, prácticamente un solo sitio, y firma quien vende alojamiento para frameworks de JavaScript), pero apunta en la misma dirección que Google.
Google, sin embargo, ha dicho las dos cosas. Un año antes que Clifford, en el [webinar de Duda del 23 de agosto de 2023](https://www.youtube.com/watch?v=-newLrArh6c&t=2166s), Martin Splitt contó que hacen control de calidad en varias fases y que, si ya han detectado antes que una página es mala, se saltan el renderizado: «what's the point?». La documentación va con Clifford. Yo trabajo con esa versión, pero no doy la de Splitt por desmentida, y por eso la tabla del principio marca este dato como en disputa.
Las excepciones documentadas son dos, y Google las redacta en condicional:
- Con un código distinto de 200, por ejemplo un 404, el renderizado podría saltarse.
- Con un noindex en la metaetiqueta o en la cabecera, Google puede saltarse el renderizado y la ejecución de JavaScript. «Puede» no es «siempre»: lo cuento en [el noindex en origen](#noindex-origen).
Un recurso bloqueado por robots.txt no es una tercera excepción: la página se renderiza sin él, con lo que eso suponga.
Lo que sí está claro es que del interés que Google tenga por tu página depende **cuándo** la renderiza y **con qué frecuencia** vuelve. Si además existe el filtro de calidad del que habló Splitt en 2023, afecta a páginas que ya tenían un problema mayor que el renderizado. Según Martin Splitt en [la entrevista de 2024](https://www.youtube.com/watch?v=0iHDk7uqByI&t=1239s), si una página tarda mucho más de lo normal en procesarse, suele ser señal de que le interesa poco ese contenido (lo verás en [la cola de renderizado](#cola)).
## Qué ve Google y qué no: clics, scroll, ventana, recursos y caché
Google captura el DOM que queda después de cargar la página **sin tocar nada**. No hace clic, no pasa el ratón por encima, no hace scroll y no recuerda nada de una visita para la siguiente.
Eso no significa que solo vea lo que aparece en pantalla. Lo que está en el HTML aunque esté oculto, y lo que el JavaScript trae por su cuenta durante la carga, sí entra. Con cada pieza de contenido hay que hacerse la misma pregunta: ¿está en el DOM sin que nadie haga nada?
### Sin clics ni interacción: pestañas, acordeones y muros de pago
Googlebot no hace clic ni interactúa con nada: ni pestañas, ni botones de «ver más», ni avisos de cookies. La prueba más práctica que conozco sobre esto son los [12 experimentos con contenido en pestañas](https://merj.com/blog/12-experiments-for-tabbed-content-seo) de MERJ: una página que Google no había visto nunca, con pestañas de Bootstrap y una frase única por cada forma de meter el contenido, comprobada en 2018 y otra vez en 2021.
| Cómo llega el contenido | 2018 | 2021 |
| --- | --- | --- |
| HTML estático en la pestaña visible (exp. 1) | Indexado | Indexado |
| HTML estático en una pestaña oculta (exp. 2) | Indexado | Indexado |
| Texto traído por AJAX de una API externa durante la carga (exp. 6) | Indexado | Indexado |
| HTML inicial al que ese AJAX sustituye (exp. 5) | No | No |
| Texto de un diccionario JS de la propia página, insertado en la carga (exp. 4) | No | No |
| HTML inicial al que ese diccionario debía sustituir (exp. 3) | Indexado | Indexado |
| Texto que solo llega con un onClick, desde JSON interno o desde una API (exp. 8 y 10) | No | No |
| HTML estático que ese clic habría sustituido (exp. 7 y 9) | Indexado | Indexado |
| iframe con `index,follow` (exp. 11) | Indexado | No |
| iframe con `noindex,nofollow` (exp. 12) | No | No |
Se resume en tres reglas:
- El HTML estático se indexa aunque la pestaña esté oculta.
- El contenido que llega por AJAX durante la carga también, y Google se queda con el resultado final.
- **Lo que depende de un clic no existe para Google**: se queda con lo que había antes del clic.
La tabla tiene dos resultados raros que no tomaría como regla: el texto que salía de un diccionario JavaScript de la propia página no se indexó, y el iframe con `index,follow` dejó de indexarse en 2021. Es una sola página de prueba, comprobada con `site:` y no con la inspección de URL. Lo que sí deja claro es que, si algo te importa, mejor que esté en el HTML.
Lo que Google sí simula es la inactividad. El navegador de Googlebot finge estar ocioso para que salten los eventos que esperan ese momento, como `requestIdleCallback` (lo contó Zoe Clifford en [Search Off the Record](https://www.youtube.com/watch?v=XBT_DUzUbOI&t=1008s) el 11 de julio de 2024: «we fake being idle every once in a while»; yo lo conté en [Googlebot finge inactividad para renderizar](https://sanchezdonate.net/articulo/noticia/googlebot-iteratorect-rendering/)). Lo que cuelgues de un evento de inactividad puede ejecutarse; lo que cuelgues de un clic, no.
Para el contenido plegable hay una alternativa nativa que no depende de JavaScript: `details` y `summary`. El texto está en el HTML desde el principio, el navegador se encarga de abrirlo y cerrarlo, y funciona en todos los navegadores:
```
Pregunta que ve el usuario
Respuesta que ya está en el HTML aunque esté plegada.
```
De esta misma regla sale lo de los muros de pago. Si envías el artículo completo desde el servidor y lo ocultas con JavaScript hasta que el usuario demuestra que está suscrito, el contenido está en el DOM y Google lo ve, igual que cualquiera que desactive JavaScript. [La documentación de Google](https://developers.google.com/search/docs/crawling-indexing/javascript/fix-search-javascript) lo advierte: no es una forma fiable de limitar el acceso. El contenido completo solo debería salir del servidor cuando la suscripción esté confirmada.
### Googlebot no hace scroll: agranda la ventana
**Googlebot no hace scroll ni dispara eventos de scroll.** Lo dice Google y se ha comprobado desde dentro de la página escuchando ese evento: nunca llega.
¿Cómo ve entonces lo de abajo? Agrandando la ventana. Google lo llama viewport expansion (lo explicaron en [el episodio 96 de Search Off the Record](https://www.youtube.com/watch?v=l2E3gBDP_qY&t=1442s)): el renderizador va estirando la ventana, sobre todo en alto, para que se dispare lo que solo ocurre cuando un elemento entra en pantalla. Por eso Google lee lo que queda por debajo del primer pantallazo sin haber bajado nunca.
¿Cuánto de alta es esa ventana? Hay tres cifras que se suelen mezclar, y el primero en mezclarlas fui yo, cuando escribí que Google renderiza «con exactamente 1750px de alto»:
| Medida | Cifra | Quién y cómo | Qué significa |
| --- | --- | --- | --- |
| Ventana inicial del Googlebot móvil | 981 × 1742 px (`innerWidth` × `innerHeight`) | Tony McCreath, leyéndolo con JavaScript desde la propia página (Chrome 131) | El alto con el que se calcula el primer layout en su página de prueba |
| Corte de la captura de las herramientas | 1750 px en el visor de Search Console; 10.000 px en la prueba de resultados enriquecidos como ordenador | Yo, a propuesta de Mario Mangas (junio de 2025) | Hasta dónde llega la imagen que te enseñan, no lo que Google procesa |
| Alto tras el redimensionado | 1.251.074 px | Tony McCreath: dos eventos `resize`, hacia los 5 s y los 5,3 s del reloj interno | Hasta dónde se estiró la ventana en una página que él hacía crecer sin parar |
La ventana inicial depende de la escala que declara el navegador, así que con otra configuración de viewport el número podría ser otro. El alto final sale de una página que su autor hacía crecer sin parar, y Google no ha publicado ninguna cifra. La captura es un límite de la herramienta, y está explicada en [el capítulo de las herramientas](#corte-1750). Lo que comparten las tres es la idea: ventana muy alta y nada de scroll.
### Carga diferida y scroll infinito: por visibilidad sí, por scroll no
De lo anterior sale una regla para la carga diferida. Funciona la que se dispara cuando un elemento se vuelve visible, porque al estirar la ventana todo acaba siendo visible. No funciona la que escucha el evento `scroll`, porque ese evento no llega nunca.
Esto, por ejemplo, Google no lo va a ejecutar:
```
// Carga más productos al bajar: depende del evento scroll
window.addEventListener('scroll', () => {
if (window.scrollY + window.innerHeight > document.body.offsetHeight - 300) {
cargarMasProductos();
}
});
```
Esto sí, porque se basa en visibilidad:
```
```
Es lo que pide [la documentación de Google sobre carga diferida](https://developers.google.com/search/docs/crawling-indexing/javascript/lazy-loading): cargar el contenido cuando es visible en el viewport y no depender de acciones del usuario.
Aun así, en un listado con scroll infinito no cuentes con que Google cargue más de unas pocas tandas: en una prueba publicada hubo dos redimensionados de la ventana y el DOM acabó con tres «páginas». Lo seguro es que cada tanda tenga su URL propia y persistente (`?page=2`), que esas URL estén enlazadas entre sí con enlaces normales y que la URL se actualice con la History API al avanzar.
Con las imágenes, lo que se comprueba es que la URL acaba en el atributo `src` del `` en el HTML renderizado. Durante el render, el WRS ni siquiera descarga imágenes ni vídeos: le basta con saber dónde están.
### La pesadilla del 100vh: un hero sin max-height
Un problema de renderizado no siempre viene de JavaScript. A veces viene de una sola línea de CSS. `vh` es viewport height: un elemento con `100vh` mide el 100 % del alto de la ventana. Es muy habitual dárselo al primer bloque de la página para que el hero ocupe la pantalla entera:
```
.fullheight {
height: 100vh;
}
```
En tu navegador queda bien. En Googlebot la ventana ya arranca muy alta y después crece, y el hero crece con ella hasta que el renderizador se rinde y deja de estirar. Puedes tener todo el contenido en el HTML, sin depender de JS para nada, y aun así enseñarle a Google una página que parece vacía. Este es el aspecto que tiene en «Ver página probada» de Search Console:
*Un hero con 100vh en la captura de Search Console.*
No hay texto a la vista: solo el fondo del hero, estirado de forma desproporcionada. Le pasaba también a la página de Pandora cuando la pasé por la prueba de resultados enriquecidos:
*La página de Pandora en la prueba de resultados enriquecidos.*
Con `dvh` (la unidad de alto «dinámica», que se ajusta cuando aparecen y desaparecen las barras del navegador móvil) ocurre lo mismo si no hay un `max-height`.
#### ¿Afecta a la indexación o solo a la vista previa?
Que la captura sale deformada no lo discute nadie. Lo que se discute es si además perjudica la indexación o el posicionamiento:
- **Mi experiencia.** He visto bastantes webs con este problema mejorar de forma casi instantánea al corregirlo, y sostengo que puede acabar en thin content e incluso en [soft 404](https://sanchezdonate.net/articulo/soft-not-found-google/) (lo conté en [El VH de CSS afecta a la renderización](https://sanchezdonate.net/articulo/vh-css-rendering/)), en «Rastreada: actualmente sin indexar» y en productos o listados que dejan de ser relevantes. Es experiencia de consultoría, sin un caso publicado, y sobre el papel no debería afectar.
- **Lo que dice Google.** Preguntado por esto mismo en [Search Off the Record](https://www.youtube.com/watch?v=l2E3gBDP_qY&t=1506s), la respuesta fue que tendría que mirarlo, porque ha habido algún cambio, pero que no cree que sea necesariamente un problema, ya que el texto sigue en el DOM. Aun así, recomiendan poner un alto máximo.
Hay un argumento a favor de que sí pese: Google no indexa solo el DOM, también la geometría del árbol de renderizado, el tamaño y la posición de cada cosa. Si el layout coloca tu texto a miles de píxeles por debajo de un bloque vacío, es plausible que eso cuente aunque el texto esté en el DOM. En marcas consolidadas la autoridad lo compensa; en un proyecto normal yo no contaría con ello. Me falta publicar un caso con datos de antes y después, y lo añadiré aquí si consigo permiso para enseñarlo.
#### La solución: max-height
En el remedio coincide todo el mundo, y es una línea de CSS:
```
.fullheight {
height: 100vh;
max-height: 800px;
}
```
Los 800 px son un ejemplo; pon un máximo razonable para tu diseño. Si lo prefieres, puedes aplicarlo solo en pantallas estrechas:
```
.fullheight {
height: 100vh;
}
@media only screen and (max-width: 800px) {
.fullheight {
max-height: 800px;
}
}
```
El hero queda con un límite de altura sin perjudicar el diseño, y no necesitas resolver el debate para actuar.
*La misma web después de añadir el max-height. La captura está censurada por privacidad, pero se aprecia que el texto ya es visible.*
Para comprobarlo, pasa la URL por la prueba en vivo de Search Console, o por la prueba de resultados enriquecidos si la web no es tuya, y mira la captura. Para este problema la captura sí sirve, porque es justo donde se ve el hero estirado. Pero es solo el síntoma: lo que cuenta es que el contenido esté en el HTML renderizado.
### Pseudoelementos: texto que se ve y no cuenta
El [CSS](https://sanchezdonate.net/articulo/css-posicionamiento-web/) también se puede usar al revés: para enseñar un texto al usuario sin que cuente como texto. Lo que insertas con `::before` o `::after` se ve en pantalla, pero no está en el DOM, así que el renderizado no lo recoge. Tampoco sale en los fragmentos de los resultados, sin necesidad de un [data-nosnippet](https://sanchezdonate.net/articulo/data-nosnippet/).
```
.etiqueta::before {
content: "#";
}
```
Lo comprobaron en directo en [Search Off the Record](https://www.youtube.com/watch?v=l2E3gBDP_qY&t=1322s), y contaron el caso de una web que pintaba así la almohadilla de sus hashtags: para Google eran palabras sin más. Para lo decorativo (un icono, una coletilla que no quieres que Google lea) es perfecto. Para contenido que quieres posicionar, no lo uses.
### Qué no soporta el WRS
El WRS es un Chromium al día, pero le faltan cosas que tiene el navegador de cualquier usuario. [Google documenta](https://developers.google.com/search/docs/crawling-indexing/javascript/fix-search-javascript) lo que no hace:
- Rechaza las solicitudes de permisos (cámara, ubicación, notificaciones). Si el contenido solo aparece después de aceptar, Google no lo ve.
- Solo habla HTTP. No soporta WebSockets ni WebRTC, así que lo que llegue por ahí necesita una alternativa por HTTP.
- No soporta WebGL. Lo que pintes con WebGL, o se omite para Googlebot o se prerrenderiza en servidor.
- No guarda nada entre cargas: Local Storage, Session Storage y cookies se borran de una página a la siguiente.
- No resuelve de forma fiable los fragmentos usados como rutas (`#/productos`). Para cambiar de vista, History API.
- Aplana el shadow DOM y el light DOM. Un web component que no use `slot` puede no mostrar en el HTML renderizado lo que esperas.
A esa lista yo añado los [web workers](#web-workers): en la única prueba publicada, lo que dependía de ellos casi nunca llegó al HTML renderizado.
### Recursos bloqueados: el error más simple y más repetido
El error más común con JavaScript sigue siendo pasarse con el robots.txt y bloquear ficheros que hacen falta para renderizar. Google no renderiza JavaScript de ficheros bloqueados, y si el WRS no puede obtener un recurso crítico, puede tener problemas para extraer el contenido y para que la página posicione.
La API de la que tira tu JavaScript cuenta igual que el JS y el CSS: si el endpoint está bloqueado, el script se ejecuta pero el contenido no llega. Este robots.txt, que parece prudente, deja una tienda en CSR sin productos para Google:
```
User-agent: *
Disallow: /api/
Disallow: /assets/js/
```
No todo lo que Google deja de pedir es un problema. Su navegador cancela por su cuenta lo que no le sirve: fuentes, medios, URL que dan 404 y los eventos de analítica. Ver recursos sin cargar en la inspección de URL no es grave por sí mismo. Lo grave es que entre ellos esté algo de lo que depende tu contenido.
### Caché de hasta 30 días, ficheros con huella y CDN
El WRS intenta cachear todos los JS y CSS de las páginas que renderiza y los guarda **hasta 30 días**, sin hacer caso a tus cabeceras de caché (lo explicaron en [Crawling December](https://developers.google.com/search/blog/2024/12/crawling-december-resources)). Para el crawl budget es una buena noticia: no hay que preocuparse en exceso por lo que cuesta renderizar. Pero tiene su cara B: si cambias el contenido de un fichero sin cambiarle el nombre, Google puede seguir renderizando con la versión antigua durante semanas.
La solución es meter una huella del contenido en el nombre del fichero, como hacen casi todos los empaquetadores:
```
```
Cuando cambia el fichero, cambia la URL y la caché de Google se invalida sola. Cuidado con el extremo contrario: un parámetro que cambia en cada deploy o en cada petición (`main.js?v=1717171717`) obliga a Google a volver a pedirlo todo aunque nada haya cambiado, y eso es crawl budget tirado. La huella tiene que salir del contenido del fichero.
Sobre el CDN: Google llegó a recomendar alojar los recursos en otro hostname para trasladar allí el consumo de crawl budget, y lo matizó a los pocos días. La conexión extra a otro dominio puede ralentizar la página, así que no lo recomienda para el JS y el CSS críticos y sí para ficheros grandes no críticos, como vídeos o descargas.
### Enlaces, botones y redirecciones por JavaScript
Un enlace, para Google, es un `` con `href`. Inyectarlo con JavaScript no es problema, siempre que sea un enlace de verdad:
```
RunningRunningRunning
```
Lo que sí puede pasar es que Google encuentre algo con aspecto de URL en el código, aunque no esté en un enlace, y lo mande a rastrear: [Vercel y MERJ](https://vercel.com/blog/how-google-handles-javascript-throughout-the-indexing-process) vieron URL descubiertas dentro de un JSON y, en su prueba, que la URL estuviera en un enlace o en un JSON no cambió la prioridad con la que Google la rastreó. Así que no fíes tu enlazado interno a que Google encuentre cadenas sueltas, y no des por hecho que una URL escrita dentro de un script no se va a rastrear.
Las redirecciones por JavaScript funcionan: el WRS las sigue como un navegador normal, y la propia Google las usó al migrar su blog desde Blogger. Pero tardan más, porque una redirección HTTP se resuelve en el rastreo y la de JavaScript tiene que esperar al renderizado. Si puedes elegir, redirección de servidor.
Qué pasa cuando el JavaScript toca el noindex, la canonical o los códigos de estado es el tema del siguiente capítulo.
## El HTML inicial manda: noindex, canonical, códigos de estado y soft 404
Antes de renderizar nada, Google ya ha decidido cosas con el HTML que sale de tu servidor. El DOM final sigue contando, pero hay señales que se leen en el rastreo, como el código de estado, el meta robots y la canonical, y si ahí dicen «no», lo que haga después tu JavaScript llega tarde o no llega.
La regla de todo este capítulo es una: **el HTML inicial tiene que ser ya indexable**. Lo demás son matices, y alguno ha cambiado en el último año.
### Qué mira Google antes de mandar la página a renderizar
Googlebot guarda la respuesta HTTP con sus cabeceras y se la pasa al sistema de indexación. Lo primero que se mira es el código de estado: los 3xx se resuelven en el propio rastreo, los 4xx abortan la indexación (salvo el 429, que Google [trata como un error de servidor](https://developers.google.com/search/docs/crawling-indexing/http-network-errors)) y los 5xx se tratan como un fallo temporal hasta el siguiente rastreo. Con un 200 todavía se comprueba si la página es un error encubierto, el soft 404 de toda la vida. También se evalúan el noindex y la canonical. El renderizado viene después.
### Noindex en origen: de «no se renderiza» a «puede no renderizarse»
Durante años la regla fue categórica: Google no renderiza páginas noindex. Era lo documentado y lo que se medía: con noindex en el HTML inicial, la página no se renderizaba y el JavaScript que debía quitarlo ni llegaba a ejecutarse. Tiene lógica, porque renderizar es caro y una página que no se va a indexar no lo necesita.
En 2025 cambió la foto. Dave Smart publicó [Noindex No Longer Means Not Rendered](https://tamethebots.com/blog-n-bits/noindex-does-not-mean-not-rendered) con cuatro páginas de prueba, cada una con un `fetch` a un endpoint que registra quién lo pide:
| Página de prueba | ¿Googlebot ejecutó el fetch? | Estado en Search Console | Último rastreo |
| --- | --- | --- | --- |
| Meta robots noindex que el propio JavaScript elimina | Sí, por POST | Excluida por noindex | 20 de mayo de 2025 |
| Cabecera X-Robots-Tag: noindex | Sí, por POST | Excluida por noindex | 22 de junio de 2025 |
| Código de estado 404 | No | No encontrada (404) | 22 de junio de 2025 |
| Meta robots noindex con redirección por JavaScript | Sí, por POST | Excluida por noindex (el destino quedó como URL desconocida para Google) | 22 de junio de 2025 |
En las tres páginas con noindex Googlebot ejecutó el JavaScript, y las tres siguieron excluidas. La petición llegó por POST, lo que apunta a que venía del renderizado y no de que Google viera algo con pinta de URL en el HTML y lo pidiera por si acaso. Es un sitio de pruebas, no se sabe si es un fallo o algo intencionado y puede revertirse.
Un año antes, Vercel y MERJ habían medido lo contrario. En [su estudio de 2024](https://vercel.com/blog/how-google-handles-javascript-throughout-the-indexing-process), las páginas con noindex en el HTML inicial no se renderizaron, tuvieran el JavaScript que tuvieran, y el script que quitaba el noindex ni llegó a ejecutarse. Las dos observaciones pueden ser ciertas a la vez: algo cambió entre abril de 2024 y mayo de 2025, o depende del sitio. Lo que no vale es quedarse con una y callar la otra.
En diciembre de 2025 Google cambió su documentación, y hoy dice que al encontrar un noindex «puede» saltarse el renderizado y la ejecución de JavaScript. En la misma página sigue habiendo otra frase que dice que las páginas con noindex no se encolan para renderizar, así que la propia documentación no es del todo coherente. Con noindex en el HTML inicial, Google **puede** no renderizar la página. No des por hecho ni una cosa ni la contraria.
### Quitar un noindex con JavaScript no funciona; ponerlo, sí
Lo que no ha cambiado: un noindex en origen no se quita con JavaScript. En la prueba anterior el script que eliminaba el noindex llegó a ejecutarse, y la página siguió excluida. Y si el noindex viene en la cabecera `X-Robots-Tag`, ni siquiera hay debate: JavaScript no puede reescribir una cabecera HTTP.
Al revés sí funciona. Si el HTML inicial es indexable y el JavaScript añade un noindex, la página acaba fuera del índice. Por eso un noindex se puede implementar desde Google Tag Manager.
Eso sí, no siempre es inmediato: una página con mucho contenido de calidad puede indexarse primero con el HTML del servidor, sin el noindex, y no salir del índice hasta que se procesa la versión renderizada. Esa transición puede durar de unas horas a unos días. Cuanto más claras sean las señales desde el servidor, menos dependes de ese baile.
### El flashazo de noindex: cuando el noindex se cuela a mitad de la carga
Hay un caso raro que encaja aquí y al que en su día puse nombre. El síntoma: en Search Console la página sale como excluida por un meta noindex, le das a «Probar URL publicada» y está en index. Compruebas el código fuente y el DOM, y está en index. ¿Qué ha podido pasar?
> Un flashazo de noindex es un noindex que aparece un instante en el DOM mientras la página se renderiza y luego desaparece.
Puede pasar sobre todo en webs hechas con frameworks de JavaScript: el servidor no manda ningún meta robots, el framework acaba poniéndolo en index y, por el camino, se cuela un noindex. Que Google se quede justo con ese noindex momentáneo es **una hipótesis mía**: no lo dice ninguna documentación, no tengo cifras y no he publicado un caso real. Me parece plausible porque lo que cuenta es el DOM en el momento del snapshot y un noindex puesto por JavaScript sí funciona; lo que nadie ha probado es que Google llegue a capturar ese estado intermedio.
Lo que sí es seguro es el remedio: si el meta robots correcto sale ya desde el servidor, el riesgo desaparece de raíz.
Antes de culpar al flashazo, descarta otras dos explicaciones del mismo síntoma:
- Que la versión indexada sea de un rastreo anterior a un cambio tuyo. Mira la fecha del último rastreo en la inspección de URL: la inspección enseña lo que Google vio, y la prueba en vivo lo que vería ahora.
- Que el Googlebot real haya renderizado con un JavaScript antiguo de [su caché](#cache-30-dias), que la prueba en vivo no usa.
Descartado eso, el método que publiqué en [Revisar flashazos de noindex](https://sanchezdonate.net/articulo/curiosidades/revisar-flashazos-noindex/). [Abre DevTools](https://sanchezdonate.net/articulo/devtools-para-seo/), ve a Fuentes > Fragmentos y guarda este script como fragmento nuevo:
*DevTools en Fuentes > Fragmentos, con el script guardado como fragmento.*
```
(() => {
console.clear();
const log = (etiqueta, msg, color = 'inherit') =>
console.log(`%c${etiqueta} ${msg}`, `color:${color}; font-weight:bold;`);
let metaObserver = null;
let canonicalObserver = null;
let headObserver = null;
// Observer para meta robots
const startMetaObserver = (meta) => {
log('[VISTO]', `Detectado con contenido inicial: ${meta.getAttribute('content')}`, '#aaf');
if (metaObserver) metaObserver.disconnect();
metaObserver = new MutationObserver((mutations) => {
for (const mutation of mutations) {
if (mutation.type === 'attributes' && mutation.attributeName === 'content') {
const oldValue = mutation.oldValue;
const newValue = meta.getAttribute('content');
const time = new Date().toLocaleTimeString();
log('[CAMBIO]', `[${time}] META robots cambiado`, '#ffcc00');
console.log(' ▸ Anterior:', oldValue);
console.log(' ▸ Nuevo:', newValue);
console.trace(' Origen del cambio');
}
}
});
metaObserver.observe(meta, {
attributes: true,
attributeFilter: ['content'],
attributeOldValue: true
});
log('[OK]', 'Observando cambios en el contenido del meta robots', '#0f0');
};
// Observer para canonical
const startCanonicalObserver = (canonical) => {
log('[VISTO]', `Detectado con href inicial: ${canonical.getAttribute('href')}`, '#aaf');
if (canonicalObserver) canonicalObserver.disconnect();
canonicalObserver = new MutationObserver((mutations) => {
for (const mutation of mutations) {
if (mutation.type === 'attributes' && mutation.attributeName === 'href') {
const oldValue = mutation.oldValue;
const newValue = canonical.getAttribute('href');
const time = new Date().toLocaleTimeString();
log('[CAMBIO]', `[${time}] CANONICAL cambiado`, '#ff69b4');
console.log(' ▸ Anterior:', oldValue);
console.log(' ▸ Nuevo:', newValue);
console.trace(' Origen del cambio');
}
}
});
canonicalObserver.observe(canonical, {
attributes: true,
attributeFilter: ['href'],
attributeOldValue: true
});
log('[OK]', 'Observando cambios en el href del canonical', '#0f0');
};
// Esperar a que aparezcan ambos elementos
const waitForElements = () => {
const existingMeta = document.querySelector('meta[name="robots"]');
const existingCanonical = document.querySelector('link[rel="canonical"]');
if (existingMeta) {
startMetaObserver(existingMeta);
}
if (existingCanonical) {
startCanonicalObserver(existingCanonical);
}
if (existingMeta && existingCanonical) {
return;
}
if (!existingMeta) {
log('[ESPERA]', 'Esperando a que aparezca ...', '#999');
}
if (!existingCanonical) {
log('[ESPERA]', 'Esperando a que aparezca ...', '#999');
}
headObserver = new MutationObserver((mutations) => {
for (const mutation of mutations) {
for (const node of mutation.addedNodes) {
if (node.tagName === 'META' && node.getAttribute('name') === 'robots' && !metaObserver) {
log('[OK]', `Detectado nuevo añadido al DOM: ${node.getAttribute('content')}`, '#0f0');
startMetaObserver(node);
}
if (node.tagName === 'LINK' && node.getAttribute('rel') === 'canonical' && !canonicalObserver) {
log('[OK]', `Detectado nuevo añadido al DOM: ${node.getAttribute('href')}`, '#0f0');
startCanonicalObserver(node);
}
}
}
// Si ambos observadores están activos, desconectar el headObserver
if (metaObserver && canonicalObserver) {
headObserver.disconnect();
}
});
headObserver.observe(document.head, { childList: true, subtree: true });
};
waitForElements();
})();
```
Es una función que se ejecuta sola, limpia la consola y crea tres `MutationObserver`: uno vigila el `content` del meta robots, otro el `href` de la canonical y el tercero espera a que esos dos elementos aparezcan en el `head` si aún no existen. Por cada cambio escribe la hora, el valor anterior, el nuevo y un `console.trace` con el script que lo ha provocado.
Una vez guardado, ve a la pestaña Red y limita la velocidad a 3G, para que te dé tiempo a lanzar el fragmento antes de que el JavaScript de la página toque el head.
*Pestaña Red con la velocidad limitada a 3G. En la captura también está marcada «Inhabilitar caché».*
Vuelve a Fuentes > Fragmentos, recarga la página y dale a «Ejecutar» cuanto antes:
*Botón derecho sobre el fragmento y «Ejecutar», cuanto antes.*
Después devuelve la red a su velocidad normal y lee la consola:
*Salida del detector en un caso limpio: el meta robots se añade al DOM ya como INDEX, FOLLOW.*
La captura es de un caso limpio, con una versión anterior del script que solo vigilaba el meta robots: el meta no existía al inicio, se añade directamente como INDEX, FOLLOW y no cambia después. Un flashazo se vería con una línea «META robots cambiado», el valor anterior, el nuevo y la traza con el script culpable.
El script tiene límites:
- Solo vigila el primer meta robots y la primera canonical que encuentra.
- Si el framework elimina la etiqueta y la vuelve a insertar, añade un segundo meta robots, usa `meta name="googlebot"` o la mete fuera del head, no lo registra.
- Todo cambio anterior a la ejecución del fragmento se pierde. De ahí el 3G y la prisa.
Si sabes programarlo mejor y cubrir esos casos, adelante.
### Páginas noindex en CSR: enlaces, facetas y cuándo compensa robots.txt
Si una paginación lleva noindex en una web en CSR, ¿existen para Google los enlaces que genera su JavaScript? Antes habría dicho que no. Hoy diría «no cuentes con ellos». Que Googlebot ejecute JavaScript en una página noindex no significa que descubra ni siga los enlaces que ese JavaScript genera: en la prueba de antes, la redirección por JavaScript de la página noindex no se siguió, aunque quizá Google simplemente no quiso probarla. Y sigue valiendo lo que ya sabíamos: una página noindex, a largo plazo, [acaba tratándose como nofollow](https://www.youtube.com/watch?v=9GNg8R-X8LQ&t=3291s). Lo dijo John Mueller en un hangout del 15 de diciembre de 2017 y no está en la documentación.
*La documentación de Google sobre paginación habla de reconocer e indexar las páginas de una secuencia.*
La documentación tampoco ayuda a decidir: por un lado explica cómo reconoce e indexa las paginaciones; por otro [recomienda no indexar las variaciones de ordenación](https://developers.google.com/search/docs/specialty/ecommerce/pagination-and-incremental-page-loading?hl=es#avoid-indexing-variations). Ese debate sigue abierto.
Y una consecuencia práctica: **el noindex no te garantiza ahorrar renderizado ni llamadas a API**. En un sitio grande, los buscadores internos y la navegación facetada con noindex pueden seguir disparando peticiones pesadas a tus endpoints. Ahí puede compensar el robots.txt, porque si bloquea la URL, Googlebot ni la pide y no renderiza nada.
Pero no son intercambiables. Si Googlebot no pide la URL, tampoco lee el noindex que lleve dentro, y bloquear no es desindexar: cuando lo comprobé, amstel.es posicionaba primera por su marca estando bloqueada por robots.txt. Noindex cuando quieres la página fuera del índice; robots.txt cuando lo que quieres es que Google no gaste recursos en ella.
### La canonical, en el HTML inicial
En lo importante Google y yo coincidimos: la canonical tiene que ser correcta ya en el HTML inicial, y correcta quiere decir propia (self-canonical) o ausente. La documentación dice que la mejor forma de fijarla es en el HTML; si no puedes, admite que la pongas con JavaScript dejándola fuera del HTML inicial. Lo que pide es no usar JavaScript para cambiarla por otra distinta de la que venía y, si la inyectas, que sea la única de la página.
Donde no coincidimos es en la consecuencia. Mi experiencia es que, si el HTML inicial trae una canonical hacia otra URL, Google considera la página no indexable y no la lleva a renderizar, aunque luego el JavaScript la corrija. El fallo típico es una canonical hacia la home en la parte estática que después el framework cambia en el DOM: de inicio solo sería indexable la home.
Google no lo documenta así. Como motivos para saltarse el renderizado solo menciona el noindex y los códigos distintos de 200, y de las canonical en conflicto solo dice que pueden dar resultados inesperados. Lo mío es experiencia de consultoría, sin un experimento publicado; lo de Google, que el resultado no está garantizado. El consejo es el mismo con las dos versiones: no confíes en arreglar la canonical con JavaScript. Para cazar un framework que la cambia, el fragmento del flashazo también vigila la canonical y te dice qué script la toca.
### Códigos de estado y soft 404
Lo que no devuelve un 200 puede quedarse sin renderizar. Google lo dice en condicional y las mediciones van en la misma línea: los 304 se renderizaban con el contenido del 200 original, pero el resto de 3xx, los 4xx y los 5xx no, y en la prueba del noindex la página con 404 ni ejecutó el `fetch`. Un contenido que solo aparece por JavaScript en una URL que responde 404 no existe para Google.
En una SPA (aplicación de una sola página) con enrutado en cliente pasa lo contrario: el servidor responde 200 a todo y el error lo pinta JavaScript. Eso es un soft 404 de manual. [Google da dos salidas](https://developers.google.com/search/docs/crawling-indexing/javascript/fix-search-javascript), y puedes usar una o las dos:
```
// Opción 1: mandar al usuario a una URL que el servidor responde con un 404 real
if (!producto) {
window.location.href = '/no-encontrado/';
}
// Opción 2: marcar la página de error con un noindex
if (!producto) {
const meta = document.createElement('meta');
meta.name = 'robots';
meta.content = 'noindex';
document.head.appendChild(meta);
}
```
La segunda es la regla de antes aplicada a propósito: poner un noindex con JavaScript funciona.
Un consejo que es mío, no de Google: evita la palabra «404» en el title y en el h1, aunque hables de los 404. Es posible que la página se detecte automáticamente como soft 404, y esa comprobación puede hacerse ya con el HTML inicial, antes de renderizar. Google no documenta ese disparador.
### Un head limpio
En el `` solo caben etiquetas válidas para el head. Si metes una que no lo es, cualquier navegador, incluido el Chromium de Google, cierra el head en ese punto, y lo que venga detrás queda ya en el body:
```
Zapatillas de running
```
Si detrás venían el meta robots, la canonical o los hreflang, has dejado tus señales más importantes donde no toca. El sospechoso habitual es un script de terceros que inyecta un `div` o un `iframe` en el head.
### Cómo auditarlo en un minuto
Todo lo de este capítulo se comprueba pidiendo la URL sin ejecutar JavaScript. Con `curl`, desde la terminal:
```
# Código de estado
curl -s -o /dev/null -w "%{http_code}\n" https://ejemplo.com/pagina/
# Cabecera X-Robots-Tag (con GET: un HEAD puede responder con otras cabeceras)
curl -s -D - -o /dev/null https://ejemplo.com/pagina/ | grep -i x-robots-tag
# Meta robots y canonical del HTML inicial (solo las etiquetas, aunque el HTML venga en una sola línea)
curl -s https://ejemplo.com/pagina/ | grep -ioE '<(meta|link)[^>]*(robots|googlebot|canonical)[^>]*>'
```
Después compara lo que sale con el HTML de la página rastreada en la inspección de URL de Search Console. Si el servidor dice una cosa y el HTML rastreado otra, ya sabes dónde mirar.
## El misterio de los 5 segundos: cuánto tarda y cuánto espera Google
«Google renderiza en 5 segundos.» Lo habrás leído mil veces, y yo mismo lo escribí: en la [guía avanzada sobre el renderizado](https://sanchezdonate.net/articulo/guia-avanzada-sobre-el-renderizado/) llegué a poner, con mayúsculas, que todo lo que tardase más de 5 segundos en aparecer por JavaScript era invisible para Google. El experimento que había detrás sigue dando el mismo resultado. Lo que he tenido que revisar es qué significa ese 5.
El lío viene de que la frase mezcla dos preguntas distintas:
1. **¿Cuánto tarda Google en renderizar tu página desde que la rastrea?** Es la espera en la cola de renderizado. De aquí sale el primer «5 segundos»: una mediana.
2. **¿Cuánto deja correr tu página antes de capturarla?** Es lo que pasa dentro del navegador de Google. De aquí sale el segundo «5 segundos», el de los contadores, y es el misterio de verdad.
Y hay un tercer reloj que se cuela en las dos: el tiempo hasta indexar, desde que publicas hasta que la página sale en los resultados. Ahí entran el descubrimiento de la URL, la cola de rastreo, la canonicalización y la calidad del contenido, además del render. Desde fuera solo vemos dos momentos, la petición en tus logs y la aparición en Google, y lo de en medio lo deducimos.
### Primera pregunta: cuánto tarda Google en renderizar
Entre que Google rastrea una página y la renderiza pasan, en la inmensa mayoría de los casos, segundos o minutos. Estas son las cifras publicadas:
| Fuente | Qué mide | Cifra |
| --- | --- | --- |
| Google, [Chrome Dev Summit 2018](https://www.youtube.com/watch?v=YP2tMBhyU0I&t=299s) (Tom Greenaway y Martin Splitt) | Del rastreo al render | «Minutos, una hora, días o hasta una semana». Lo retiraron un año después |
| Google, [Chrome Dev Summit 2019](https://www.youtube.com/watch?v=4pOH8Smd0Xs&t=463s) | Del rastreo a tener la página renderizada | Mediana de 5 segundos. Percentil 90, «en minutos» |
| Google, [SEO on the Beach 2023](https://www.youtube.com/watch?v=BU8ZvTq4A6M&t=1110s) | Hasta tener la página renderizada | Mediana de 5 segundos; el 10 % más lento, unos pocos minutos |
| Google, [entrevista de 2024](https://www.youtube.com/watch?v=0iHDk7uqByI&t=1221s) | Del rastreo al render | Minutos para la mayoría de las páginas, a veces horas y muy rara vez más |
| Google, [Andalu-SEO 2026](https://andalu-seo.es/ponente/2026/martin-splitt) | Cola de renderizado frente a cola de rastreo, con sus logs | El 90 % de las URL pasa solo unos minutos en la cola de renderizado. Las horas o días se pierden en la de rastreo |
| [Documentación de Google](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics) | Espera en la cola de renderizado | Unos segundos, aunque puede tardar más. No da máximo |
| [Vercel y MERJ](https://vercel.com/blog/how-google-handles-javascript-throughout-the-indexing-process) (2024) | De la petición del HTML al fin del render, en nextjs.org | Percentil 25: 4 s. Mediana: 10 s. Percentil 75: 26 s. Percentil 90: unas 3 h. Percentil 99: unas 18 h |
| [Tony McCreath](https://bigcommerce.websiteadvantage.com.au/tonys-theory-of-googlebot-relativity/) (2025) | De servir el HTML a la primera petición de un recurso del render | Unos 23,6 segundos en un caso, no una media |
Desde 2019 las fuentes coinciden en lo esencial: **casi todas las páginas se renderizan en segundos o minutos**, y las medianas publicadas están entre 5 y 10 segundos. Ese primer «5 segundos» es una espera en cola, y además una mediana: la mitad de las páginas tarda más.
Donde las fuentes dejan de coincidir es en el 10 % más lento: minutos según Google, horas según la única medición externa amplia. Esa medición tiene pistas de por qué. En las URL con parámetros el percentil 75 pasaba de 22 segundos a 31 minutos, y las secciones que cambian poco se renderizaban más tarde que las que se actualizan a menudo. Google, por su parte, dice que esos retrasos largos existen pero no son del render: la página está rastreada y otro sistema le ha dado poca prioridad. Desde fuera es imposible separar «estaba en la cola de renderizado» de «Google decidió que esa URL podía esperar», y una URL con un `?ref=` que no cambia el contenido es la candidata perfecta a esperar. No hay una cifra cerrada para ese 10 %.
Los estudios que más se citan contra la versión de Google, los de [Onely en 2019](https://www.searchenginejournal.com/javascript-indexing-delays-google/335703/) (investigación propia de Tomek Rudzki, publicada en Search Engine Journal) y [en 2022](https://www.onely.com/blog/google-needs-9x-more-time-to-crawl-js-than-html/), miden otra cosa. El de 2019 mira cuánto contenido dependiente de JavaScript estaba indexado al cabo de un día o de un mes: es el tercer reloj, y no distingue entre «no lo renderizó» y «lo renderizó y decidió no indexarlo». El de 2022, el del titular «Google necesita nueve veces más tiempo para rastrear JavaScript», mide cuánto tarda Googlebot en seguir un enlace que solo existe después de renderizar. Ninguno de los dos mide el tiempo de render, pero el segundo deja una lección práctica que sigue en pie.
### De las «dos olas» al coste real del CSR: descubrir los enlaces
La idea de que el JavaScript se indexa «en una segunda ola» viene de 2018, cuando Google explicó que primero indexaba el HTML y el render llegaba después. En 2020 [reconocieron](https://www.youtube.com/watch?v=DK1rJhvTAdM&t=996s) que las dos olas eran una simplificación excesiva (Martin Splitt, en las office hours de JavaScript SEO del 25 de marzo de 2020: «the second wave is an oversimplification»), y hoy la documentación dice que todas las páginas con código 200 van a la cola de renderizado, tengan o no JavaScript. Aun así, el modelo sigue vivo en muchos sitios, incluido [el tutorial de Screaming Frog](https://www.screamingfrog.co.uk/seo-spider/tutorials/crawl-javascript-seo/).
Yo también escribí en 2023, en [mi artículo sobre los tipos de renderizado](https://sanchezdonate.net/articulo/renderizacion-de-javascript-en-el-seo/), que el CSR era «un proceso que necesita 3 rastreos». Lo que hay no son tres peticiones sino tres fases (rastrear el HTML, renderizarlo y volver a analizar el resultado para sacar los enlaces), y por ellas pasan todas las páginas, no solo las de CSR.
El coste real del CSR está en **el descubrimiento de enlaces**. Si los enlaces solo existen después de ejecutar JavaScript, cada nivel de profundidad exige rastrear, renderizar, volver a analizar y mandar la URL nueva a la cola de rastreo. En un nivel no se nota. En siete niveles de un sitio recién creado, el experimento de Onely tardó 313 horas en llegar al final de la cadena JavaScript, frente a 36 en la de HTML. Mediciones más cuidadosas dan una ventaja ligera para las páginas renderizadas en servidor, y un sitemap actualizado reduce mucho esa diferencia o la elimina.
La conclusión práctica: los enlaces importantes, en el HTML inicial como `` o, como mínimo, en el sitemap. Sobre todo en proyectos nuevos o poco rastreados, que es donde más pesa la cola de rastreo.
### «Rastreada: actualmente sin indexar» casi nunca es culpa del renderizado
Si le echas la culpa al renderizado de un retraso que en realidad es de rastreo o de calidad, vas a gastar semanas de desarrollo en arreglar lo que no está roto. Los sospechosos habituales de una página sin indexar son otros. Martin Splitt lo explicó en [la entrevista con Olga Zarr de mayo de 2024](https://www.youtube.com/watch?v=0iHDk7uqByI&t=595s): indexar o no depende de si el contenido es útil y de calidad, y de si Google ya tiene otro igual.
- El rastreo: la URL tarda en descubrirse o en volver a rastrearse, que es donde se pierden las horas y los días.
- Las API bloqueadas a los bots en aplicaciones que pintan en el cliente: Google renderiza, pero el contenido no llega.
- La calidad: la mayoría de las páginas sin indexar lo están porque son flojas o porque ya hay muchas que responden lo mismo.
Se comprueba en un momento. En la inspección de URL de Search Console, mira el HTML de la página rastreada (la versión indexada, no la prueba en vivo). Si tu contenido está ahí, no tienes un problema de JavaScript y toca revisar rastreo, enlazado y contenido. Si falta, entonces sí.
### Segunda pregunta: cuánto espera Google dentro de tu página
Aquí está el misterio. Para medirlo puse en el `` una metaetiqueta inventada, `snapshot-counter`, que un `setInterval` incrementa cada segundo (el código está más abajo, en [el método de las tres metaetiquetas](#metodo-metaetiquetas)). Cuando Google rastrea la página, inspecciono la URL en Search Console sin darle a «Probar URL publicada» y miro qué valor tiene la metaetiqueta en el HTML de la página rastreada:
*Página rastreada (la versión indexada, no la prueba en vivo): `snapshot-counter` vale 5. Fíjate también en la hora que ha escrito el JavaScript, que acaba en :05. De eso hablo en [cómo medirlo](#como-medirlo).*
Marca 5. Lo he repetido en varios proyectos y siempre sale 5, en la versión indexada y en la prueba en vivo. Y con temporizadores pasa lo mismo: un texto que el JavaScript pinta a los 4 segundos aparece en el HTML de la página rastreada; uno que pinta pasados los 5, no. El contador lo publiqué en [Calcular tiempo de renderizado de Google](https://sanchezdonate.net/articulo/calcular-tiempo-de-renderizado-de-google/).
No es cosa de mi montaje. Otras dos pruebas dan lo mismo: un título que cambia cada segundo [se paró en 5](https://tamethebots.com/blog-n-bits/the-5-second-google-render-limit-myth), y en [una página que apuntaba `performance.now()` cada 10 milisegundos](https://bigcommerce.websiteadvantage.com.au/tonys-theory-of-googlebot-relativity/) el último valor fue de unos 5250, mientras un `setTimeout` de 6 segundos nunca llegó a ejecutarse.
Hasta aquí, todo encaja con «Google corta a los 5 segundos». El problema es lo que pasa con la red. La primera de esas páginas, además del contador, hacía dos peticiones encadenadas a un PHP que tardaba entre 3 y 6 segundos en responder cada vez: entre 6 y 12 segundos en total. Con un corte a los 5 segundos ese texto no podría aparecer, y apareció, en la prueba en vivo y en la indexación real. La propia página calculaba cuánto habían tardado esas llamadas, y dentro de Googlebot el resultado fue de 0,02 segundos.
La explicación es que **el navegador de Google no usa el reloj de verdad, sino uno propio** que puede acelerar, frenar o parar. Por lo que se ha medido desde dentro de la página:
- Mientras hay peticiones de red pendientes, el reloj se para. Quince recursos con medio segundo de retardo cada uno costaron casi 10 segundos reales y solo 162 milisegundos del reloj de Google.
- Con la CPU ocupada, el reloj apenas avanza.
- Cuando la página no tiene nada que hacer, el reloj se acelera: un temporizador de 5 segundos se cumplió en unos 455 milisegundos reales.
- Cuando ese reloj pasa de unos 5 segundos, Google para todo y se queda con el DOM. Por eso el temporizador de 6 segundos no llega nunca.
Google no lo ha documentado, pero lo poco que ha contado encaja. De viva voz, en un directo y en una entrevista, ha contado que [los temporizadores corren más deprisa](https://www.youtube.com/watch?v=-newLrArh6c&t=1744s) cuando la página está ociosa, que el final del renderizado no lo marca un tiempo fijo sino que [esperan a que la cola de eventos del navegador quede vacía](https://www.youtube.com/watch?v=-newLrArh6c&t=1532s), y que lo de los 5 segundos [no es cierto](https://www.youtube.com/watch?v=0iHDk7uqByI&t=1371s): «esperamos más si hace falta», siempre que confíen en que la espera va a traer contenido.
El misterio se resuelve así: **los 5 segundos existen, pero son segundos del reloj de Google, no del tuyo**. Mi contador no cronometra nada. Cuenta los ticks de un reloj que Google acelera cuando la página está quieta y congela cuando está trabajando, y llega a 5 antes del corte.
### Qué entra en la captura y qué no
Juntando todo, la regla práctica es esta (Google no la ha publicado; sale de las pruebas):
- **Un temporizador de más de unos 5 segundos no entra.** Un `setTimeout`, un `setInterval` o una animación que espera antes de pintar: el reloj de Google llega a su tope antes de que se disparen.
- **Un temporizador más corto sí entra**, y Google ni siquiera lo espera de verdad: lo adelanta.
- **Lo que tarda porque una API o un servidor son lentos puede entrar**, aunque en tu reloj pasen 9 o 10 segundos. Mientras hay una petición pendiente, el reloj de Google no corre.
- **Lo que tarda porque el JavaScript es pesado tampoco gasta ese reloj**, porque con la CPU ocupada apenas avanza.
- **Lo que depende de un clic o de un scroll no entra nunca**, tarde lo que tarde.
> Lo que dependa de un temporizador de más de unos 5 segundos, Google no lo verá. Lo que tarde por culpa de la red, sí puede verlo.
Sigo esperando que no seas malo y no aproveches lo primero para hacer una suerte de [cloaking](https://sanchezdonate.net/articulo/cloaking/). Y lo segundo tampoco invita a apurar: que Google haya esperado a una API lenta en una página de pruebas no garantiza que lo haga con la tuya.
### Pruébalo en tu web
La forma de entenderlo de verdad es verlo. Esta página de prueba junta los cuatro casos: un temporizador de 4 segundos, uno de 6, una API que tarda 8 segundos reales y un texto que solo aparece al hacer clic.
```
```
Es lo que pide [la documentación de Google sobre carga diferida](https://developers.google.com/search/docs/crawling-indexing/javascript/lazy-loading): cargar el contenido cuando es visible en el viewport y no depender de acciones del usuario.
Aun así, en un listado con scroll infinito no cuentes con que Google cargue más de unas pocas tandas: en una prueba publicada hubo dos redimensionados de la ventana y el DOM acabó con tres «páginas». Lo seguro es que cada tanda tenga su URL propia y persistente (`?page=2`), que esas URL estén enlazadas entre sí con enlaces normales y que la URL se actualice con la History API al avanzar.
Con las imágenes, lo que se comprueba es que la URL acaba en el atributo `src` del `