Googlebot ve tu página hasta 10 millones de píxeles de alto, pero no ve el final de tus carruseles

En agosto conté aquí que el límite de renderizado de Googlebot no es de tiempo: los 5 segundos nunca existieron y lo que vigila Google es el Event Loop. Este fin de semana Natzir Turrado ha medido la otra mitad del problema, el espacio. Hasta dónde llega la pantalla con la que Google pinta tu página, qué imágenes con lazy load pide y cuáles se quedan sin cargar. El resultado desmonta un miedo muy extendido y destapa un punto ciego que casi nadie revisa.

Qué tamaño tiene el viewport con el que renderiza Googlebot

Empecemos por la medida, que es lo que lo cambia todo. Natzir montó páginas de prueba que escriben en su propio HTML renderizado lo que ven, y las pasó por la prueba en vivo de la inspección de URLs de Search Console. Googlebot arranca con un viewport de móvil de 412×732 píxeles. Hacia los 5 segundos lo redimensiona de golpe hasta el alto total de la página, sin hacer scroll en ningún momento.

• Richard Hearne, que discutía el test con él, recordaba haber medido un viewport de algo más de 9.000 px la última vez que lo probó. El techo ha subido tres órdenes de magnitud.
• Las 200 imágenes con loading="lazy" repartidas por la página de 200.000 px se cargaron todas.

Carga Google las imágenes con lazy load de un carrusel

A lo alto sí, como acabamos de ver, pero a lo ancho solo en parte. El viewport no se estira en horizontal: se queda en 412 px. En un carrusel horizontal, Googlebot solo pidió las imágenes con lazy load que estaban a menos de unos 1.500 px del borde, y Natzir comprobó en la lista de recursos cargados de Search Console que las que quedaban más lejos nunca llegaron a pedirse. Con tarjetas de unos 300 px de ancho, eso son las cuatro o cinco primeras. Mi lectura es que es el margen con el que Chrome adelanta la carga de las imágenes lazy, el mismo que aplica en vertical.

Qué cambia en la práctica para una web

De esas dos mediciones salen cuatro consecuencias, y ninguna es la que suele darse por hecha.

• El lazy load en vertical no esconde nada a Google. Como el viewport mide lo mismo que la página, todo lo que está debajo entra en pantalla a la vez. No hace falta poner todas las imágenes en eager "por si Google no las ve". Las de la parte de arriba, sí, pero por el LCP del usuario.
• El punto ciego son los carruseles. Si la imagen lleva su src en el HTML, Google tiene la URL aunque no la descargue al renderizar. Si el carrusel usa un script que guarda la URL en data-src y la pasa a src al deslizar, las fichas del final se quedan sin imagen para Google. Y si las diapositivas se crean al pulsar la flecha, para Google no existen, porque no hace clic.
• El scroll infinito que depende del evento de scroll no carga nada. Googlebot nunca hace scroll. Los listados de productos o artículos tienen que tener paginación con enlaces normales a cada página, no un "cargar más" que solo responde al dedo del usuario.
• La captura de la inspección de URLs engaña. Se corta hacia los 1.750 px de alto y parece que Google no ha visto el resto, cuando su viewport llega mucho más abajo. Lo que hay que mirar es el HTML renderizado, no la captura. Natzir ha sacado una extensión de Chrome, GSC Full Fetch & Render, que enseña la captura completa.

Hasta qué punto son fiables estos datos

Conviene ponerle el margen que merece. Es el test de una sola persona, hecho el 10 de octubre de 2026 en la prueba en vivo de Search Console, y Hearne avisa de que esa herramienta da resultados distintos entre una petición y otra. En agosto ya vimos que la prueba en vivo y la indexación real no se comportan igual: con peticiones en bucle infinito, una cortó a las 16-18 llamadas y la otra a las 10. Lo bueno es que las páginas de prueba son públicas y cualquiera puede repetir el experimento en su propia propiedad.

Mi opinión: el límite está a lo ancho, no a lo alto

Llevo años oyendo que Google solo ve la parte de arriba de la página y que el lazy load esconde contenido. En vertical no es así, y el techo de 10 millones de píxeles no lo va a tocar ninguna página normal. Donde sí hay un límite es a lo ancho y en todo lo que necesita un gesto del usuario. Antes de reescribir el lazy load de una web, yo revisaría los carruseles de las fichas y las categorías en móvil: qué hay a partir de la quinta tarjeta y si está en el HTML.

Esta semana un desarrollador de un cliente me dijo que estaban recortando funcionalidad de una página porque "Google deja de renderizar a los 5 segundos". Es una frase que llevo años escuchando. Y no es cierta.

El test de Dave Smart con el Web Rendering Service de Google

Dave Smart, de Tame the Bots, publicó el 23 de julio de 2026 el test que lo demuestra. Montó una página con dos llamadas API que tardan entre 3 y 6 segundos cada una en responder desde el servidor. Total: entre 6 y 12 segundos. Google renderizó e indexó el contenido completo, tanto en la inspección de URLs como en la indexación real.

¿De dónde sale el mito de que Google deja de renderizar a los 5 segundos?

El Web Rendering Service de Google no usa el reloj del hardware. Usa un reloj virtual que puede acelerar, ralentizar o congelar. Cuando el WRS espera una petición de red, congela el tiempo. Por eso, si montas un contador con setInterval dentro de tu página, se para en 5 y concluyes que hay un límite de 5 segundos. En realidad estás midiendo un reloj que no avanza mientras Google trabaja.

Los datos del test de renderizado que confirman la caída del mito

• En el test, dos llamadas que tardaron 9 segundos reales de servidor reportaron un tiempo total de 0,02 segundos.
• En indexación real, el reloj siempre arranca a medianoche UTC, así que todos los timestamps salen a las 00:00:00.

¿Pero hay algún límite para el renderizado de Google?

Sí, pero no es de tiempo. Google observa el Event Loop para decidir cuándo la página está en reposo. Smart montó una página con peticiones en bucle infinito: la herramienta en vivo cortó a las 16-18 llamadas (48-54 segundos) y la indexación real a las 10 (30 segundos).

Mi opinión sobre los límites del Web Rendering Service de Google

Mi lectura, después de ver cuántos equipos han reescrito arquitecturas persiguiendo este umbral: el problema nunca es el reloj, es el Event Loop. Si tienes polling constante, animaciones infinitas o listeners que se reactivan solos, ahí sí tienes algo que arreglar. Si no, deja de optimizar contra un número inventado y optimiza para el usuario, que tiene mucha menos paciencia que Googlebot.