Googlebot al descubierto: límites de bytes, rastreo e indexación explicados
Google

Googlebot al descubierto: límites de bytes, rastreo e indexación explicados

En resumen

Google ha publicado una guía técnica detallada sobre el funcionamiento interno de Googlebot, aclarando que no se trata de un único programa sino de una infraestructura centralizada de rastreo compartida por múltiples productos. El artículo revela los límites de bytes aplicados durante el rastreo y explica cómo estos afectan directamente a la indexación del contenido. Comprender estos mecanismos permite a los profesionales SEO optimizar sus páginas para garantizar que el contenido crítico sea siempre procesado.

Puntos clave

  • Googlebot no es un único programa: es el nombre que identifica al rastreador de Google Search dentro de una infraestructura centralizada que comparten docenas de productos como Google Shopping y AdSense, cada uno con su propio nombre de rastreador.
  • El límite de bytes para Googlebot en HTML es de 2 MB por URL (incluyendo las cabeceras HTTP), lo que significa que todo el contenido situado más allá de esa marca es completamente ignorado y no se rastrea, renderiza ni indexa.
  • Los archivos PDF tienen un límite independiente y mucho más generoso de 64 MB, mientras que los rastreadores de imágenes y vídeos tienen umbrales variables según el producto, y cualquier rastreador sin límite definido aplica por defecto 15 MB.
  • Cada recurso externo referenciado en el HTML (scripts, hojas de estilo, solicitudes XHR) es rastreado por separado con su propio contador de bytes de 2 MB, sin que su tamaño cuente hacia el límite del documento HTML padre.
  • El Web Rendering Service (WRS) procesa JavaScript y CSS de forma similar a un navegador moderno para entender el estado final de la página, pero opera de forma stateless: borra el almacenamiento local y los datos de sesión entre solicitudes.
  • El orden de los elementos en el HTML es determinante: los metaetiquetas, canonicals, el título y los datos estructurados deben colocarse lo más arriba posible para evitar que queden por debajo del umbral de 2 MB y sean ignorados.

Análisis

Durante décadas, la denominación 'Googlebot' ha generado la percepción errónea de que Google utiliza un único robot de rastreo. La realidad es que se trata de una plataforma centralizada de rastreo a la que acceden múltiples clientes internos de Google. Esta aclaración es importante porque explica por qué pueden aparecer en los registros del servidor diferentes nombres de rastreadores asociados a Google, y por qué las configuraciones de rastreo pueden variar según el producto que realiza la solicitud.

El límite de 2 MB para el rastreo de HTML puede parecer generoso a primera vista, ya que la mayoría de las páginas web están muy por debajo de ese umbral. Sin embargo, determinadas prácticas de desarrollo web pueden inflar considerablemente el tamaño del HTML: el uso de imágenes embebidas en formato base64 directamente en el código, bloques extensos de CSS o JavaScript en línea, y estructuras de menú o navegación muy voluminosas colocadas al inicio del documento son factores que pueden empujar el contenido valioso más allá del límite y hacerlo invisible para Google.

El comportamiento del sistema ante un documento que supera el límite no es rechazar la página, sino truncarla exactamente en el byte número 2 097 152 (2 MB) y pasar ese fragmento al sistema de indexación como si fuera el archivo completo. Esto significa que el desarrollador o el SEO no recibe ninguna señal de error explícita en Google Search Console que indique que parte del contenido está siendo omitida, lo que convierte este problema en especialmente difícil de detectar sin un análisis deliberado del tamaño de los recursos.

El hecho de que el WRS opere de forma stateless tiene implicaciones directas para los sitios que dependen de JavaScript para renderizar su contenido principal. Si una aplicación web utiliza almacenamiento local o datos de sesión para determinar qué mostrar al usuario, esa lógica no funcionará cuando Googlebot realice la renderización, lo que puede provocar que el contenido dinámico no sea procesado correctamente. Este comportamiento refuerza la conveniencia de optar por estrategias de renderizado en servidor o de pre-renderizado para el contenido crítico.

La infraestructura de rastreo de Google también ajusta dinámicamente la frecuencia de rastreo en función del rendimiento del servidor. Si un servidor tarda en responder o tiene dificultades para servir los bytes, los rastreadores reducen automáticamente la frecuencia de las visitas para no sobrecargar la infraestructura del sitio. Esto significa que un servidor lento no solo afecta a la experiencia del usuario, sino que puede reducir directamente la tasa de rastreo y, por tanto, la velocidad de actualización del índice de Google.

Qué hacer

  • Auditar el tamaño del HTML de las páginas más importantes del sitio utilizando las herramientas de desarrollo del navegador o analizadores de rendimiento web, prestando especial atención a aquellas que superen o se acerquen a 1,5 MB para disponer de margen de seguridad respecto al límite de 2 MB.
  • Eliminar imágenes embebidas en base64 del HTML y sustituirlas por referencias a archivos de imagen externos, reduciendo significativamente el peso del documento principal sin sacrificar la experiencia visual.
  • Mover todo el CSS y el JavaScript no crítico a archivos externos enlazados desde el HTML, ya que cada recurso externo tiene su propio contador de 2 MB independiente y no consume el presupuesto de bytes del documento HTML padre.
  • Reorganizar la estructura del HTML para que los elementos de mayor relevancia para el SEO (etiqueta title, metadescripción, canonical, datos estructurados en formato JSON-LD y contenido textual principal) aparezcan lo antes posible en el código fuente, antes de cualquier bloque de navegación, cabeceras complejas o scripts.
  • Revisar los registros del servidor de forma periódica para identificar patrones de respuesta lenta o errores que puedan estar provocando una reducción automática de la frecuencia de rastreo por parte de Googlebot, y actuar sobre la infraestructura de hosting o la configuración del servidor si fuera necesario.
  • Para los sitios que dependen de JavaScript para renderizar contenido esencial, evaluar la adopción de renderizado en servidor o de generación estática de páginas, de modo que el contenido crítico esté disponible directamente en el HTML servido antes de cualquier ejecución de scripts por parte del WRS.
Impacto

Los sitios web con páginas HTML que superen los 2 MB de tamaño corren el riesgo de que su contenido esencial, incluyendo metaetiquetas, datos estructurados y texto principal, nunca sea rastreado ni indexado por Google. Aplicar las buenas prácticas reveladas en este artículo puede mejorar directamente la cobertura de indexación y la visibilidad en los resultados de búsqueda.

Fuente oficial
No te pierdas ninguna novedad

Novedades de producto, actualizaciones de algoritmos y buenas prácticas, directamente en tu correo.

Volver al seguimiento

Mantente un paso por delante de los algoritmos

Pulsar sigue tus posiciones en Google, tu visibilidad en las IA y tus redes sociales en un único dashboard. 14 días de prueba, sin tarjeta bancaria.

Empezar una prueba gratuita