Crawlers de Google y límite de 2 MB en HTML: guía para SEO técnico

Durante años hablar de Googlebot bastaba para imaginar un único robot que rastrea la web. Hoy la realidad es más parecida a una plataforma central de crawling desde la que salen distintos clientes: búsqueda, imágenes, productos, anuncios, herramientas disparadas por humanos… Entender quién pisa tu servidor, con qué reglas y hasta qué punto descarga el HTML ya no es un detalle friki: si tu plantilla “empuja” meta tags, canonical o datos estructurados más allá de lo que el bot procesa, para efectos prácticos no existen.

En esta guía resumo lo esencial sobre tipos de crawlers, el límite de HTML que más debate ha generado en el SEO técnico reciente y el papel del Web Rendering Service (WRS). Al final, un checklist aplicable en auditorías. La base de rastreo e indexación sigue siendo la misma; aquí profundizamos en bytes, agentes y render.

Objetivo: que sepas enlazar la documentación oficial con decisiones concretas en plantillas, logs y priorización de qué debe ir “arriba” en el HTML.

Por qué ya no basta con decir solo “Googlebot”

Cuando ves en tus logs un user agent con el nombre de Googlebot, estás viendo una pieza del sistema, no toda la orquesta. Otros agentes comparten infraestructura pero con objetivos distintos: descubrimiento e indexación, recursos gráficos, tareas ligadas a un producto, o peticiones disparadas porque alguien pulsó una herramienta.

En la práctica:

• Un pico de crawlers de búsqueda habla de descubrimiento, frescura y cobertura (lo que asociamos con SEO “clásico”).
• Un pico de fetchers activados por usuario habla de operativa interna: inspección de URL, verificaciones, pruebas. No debe interpretarse igual que el crawl “orgánico”.

Separar ambos mundos evita malas decisiones al leer gráficos de crawl o al plantear “problemas de presupuesto de rastreo” que en realidad son tú mismo probando en Search Console.

Tipos de crawlers y fetchers (visión práctica)

La documentación de Google agrupa sus agentes en categorías que merece la pena conocer de memoria:

Crawlers de uso general (common crawlers)

Incluyen el Googlebot asociado a la búsqueda web y variantes como Googlebot-Image. Su función habitual es descubrir y actualizar contenido que puede acabar en el índice de búsqueda o en tratamientos relacionados. Lo normal es que respeten robots.txt de forma coherente con las reglas que publicas.

Crawlers de casos especiales (special-case crawlers)

Sirven funciones o productos concretos dentro del ecosistema Google. Su relación con robots.txt y la frecuencia de visita puede ser distinta a la de un crawler de búsqueda genérico. En logs, no asumas que cada visita con marca “Google” es “SEO puro”.

Fetchers disparados por el usuario (user-triggered fetchers)

Se activan cuando tú o tu equipo usáis una herramienta: por ejemplo inspección de URL en Search Console o procesos de verificación. Google indica que estos fetchers pueden ignorar robots.txt, porque la petición se entiende explícitamente solicitada. No es “Google rompiendo reglas”: es una acción humana detrás.

Si entrenas a un equipo nuevo en SEO técnico, esta distinción ahorra sustos: no todo lo que parece Googlebot en el log impacta el crawl budget de la misma forma.

El límite de HTML y por qué importa al SEO

Google ha detallado con más claridad cómo aplican límites de bytes por URL y tipo de cliente. El dato que más ha calado en la comunidad SEO es el referido al HTML de búsqueda: el procesamiento asociado a Googlebot para la web trabaja con una cantidad limitada de datos por respuesta (incluyendo cabeceras HTTP + cuerpo, típicamente tu HTML).

No es un “rechazo” de la página. Si el documento es gigantesco, el sistema trunca la descarga en el umbral y trata solo ese prefijo como base para lo que sigue (incluido el pipeline que lleva al renderizado relevante para ese contexto).

Traducción a riesgos reales

En la mayoría de sitios el HTML no se acerca a ese orden de magnitud. Pero en e-commerce complejos, megamenús generados en servidor, CSS y JavaScript masivos en línea, SVG o assets en base64 empotrados al inicio del documento o plantillas mal optimizadas, es posible inflar el HTML hasta situaciones incómodas.

Si el umbral se supera:

• Puede quedar fuera texto importante.
• Pueden quedar fuera meta robots, canonical o bloques JSON-LD.
• El buscador, para esa descarga, no “ve” lo que quedó después del corte.

Eso no sustituye otras buenas prácticas de SEO técnico e indexación: sigue haciendo falta rastreable, código de estado correcto y coherencia de directivas. El límite de bytes es una capa adicional de “¿realmente llega a Google lo que creo que estoy enviando?”.

Otros límites (PDF y clientes por defecto)

En la misma línea documental, PDF y otros formatos pueden tener límites distintos (en conversaciones públicas se ha citado un orden de magnitud mayor para PDF frente al HTML de búsqueda). Clientes que no fijan un límite específico pueden heredar un valor por defecto distinto. No mezcles reglas: lo que aplica al HTML de la SER no es automáticamente lo que aplica a un PDF o a otro producto.

Para auditorías serias, ancla siempre en la documentación oficial vigente (enlaces al final del artículo).

Web Rendering Service (WRS): qué puede y qué no

Tras la descarga acotada, entra en juego el Web Rendering Service: un entorno tipo navegador que ejecuta JavaScript y consume CSS para aproximarse al DOM que vería un usuario.

Puntos clave:

• El WRS trabaja sobre lo ya descargado. No inventa bytes que el crawler no trajo.
• Recursos adicionales (JS, CSS) suelen tener sus propios líneas y límites en el sistema de crawling: el HTML principal no es el único sitio donde mirar peso y orden.
• El servicio opera de forma stateless entre peticiones en el sentido relevante para SEO: no debes depender de que “Google recuerde” un estado de cliente como un usuario logueado en tu SPA sin una estrategia de render o HTML inicial sólido.

Si tu arquitectura es muy dependiente de JS para pintar título, metas o contenido, y además tu HTML inicial es enorme pero “vacío” de señal, encadenas dos riesgos: poco texto útil en el primer chunk y posible truncado si la plantilla es obesa.

Checklist para SEO técnico (audituable)

1. Mide el tamaño de la respuesta HTML de URLs críticas (home, categorías top, plantilla de producto o post). Si te acercas a cientos de KB solo en HTML, revisa qué aporta cada bloque en el <head> y al inicio del <body>.

2. Ordena lo imprescindible arriba: título, meta description, directivas relevantes, canonical, hints de internacionalización si aplican, y JSON-LD esencial. Evita megablocks de navegación o estilos inline antes de la señal.

3. Externaliza CSS y JS. Minimiza inline salvo lo necesario para above-the-fold o políticas estrictas; el exceso de inline en cabecera es una de las formas más comunes de hinchar el documento.

4. Cuidado con base64 en HTML (imágenes, fuentes, iconos). Cada KB en el documento cuenta para el prefijo que el bot procesa.

5. Separa en logs crawl “de producto” de herramientas disparadas por tu equipo. No diagnostiques caídas de indexación con gráficos mezclados.

6. Verifica identidad de bots: usa la documentación de verificación de IPs / reverse DNS para no confundir Google legítimo con scrapers.

7. Servidor estable y rápido: la plataforma de crawling adapta la frecuencia a cómo se porta tu host. Errores 5xx y latencia alta reducen la tranquilidad con la que Google vuelve a rastrear.

Conclusión

Entender quién rastrea, con qué reglas y hasta dónde lee el HTML forma parte del SEO técnico moderno junto al rastreo y la indexación que ya controlas. Un sitio puede ser “rastreable” en robots.txt y, al mismo tiempo, enviar demasiado ruido al principio del documento como para que las señales importantes queden donde el sistema garantiza que las procesa.

Si trabajas plantillas grandes o proyectos muy cargados de JS, incorpora el tamaño del HTML y el orden del <head> a tus revisiones periódicas; es barato de medir y caro de ignorar cuando algo falla en SERP sin un error HTTP evidente.

Documentación oficial (fuente)

• Visión general de crawlers y fetchers de Google
• Blog y anuncios recientes en Google Search Central Blog (busca entradas sobre crawling y límites cuando actualicen el detalle).

Versión ampliada y actualizada sobre el artículo publicado en LinkedIn sobre crawlers de Google y límite de 2 MB; el contenido del blog sigue la línea editorial del sitio y enlaza a fuentes oficiales para auditorías.