Google fija en 2 MB el límite de rastreo “útil” por archivo en Search y reaviva el debate sobre rendimiento

Google ha introducido una aclaración técnica que, sin ser un cambio de algoritmo, tiene implicaciones directas para el SEO y para el rendimiento web. La compañía explica en su documentación que, cuando Googlebot rastrea contenido para la Búsqueda de Google, solo procesa los primeros 2 MB de los tipos de archivo compatibles y los primeros 64 MB en el caso de los PDF. Además, remarca un matiz clave: el límite se calcula sobre el tamaño sin comprimir.

El anuncio ha provocado confusión en redes por una interpretación simplificada: “Google reduce el tamaño máximo de URL rastreables de 15 MB a 2 MB”. La realidad es más precisa —y más útil— para cualquiera que gestione un sitio web: no se trata de un tope “por URL”, sino de un límite por cada archivo descargado (HTML, CSS, JavaScript y otros formatos compatibles). En términos prácticos, Google no afirma que deje de rastrear una URL “grande”, sino que corta la descarga cuando alcanza el umbral y solo tiene en cuenta lo que ha podido obtener hasta ese punto.

Dos números, dos contextos: 15 MB para la infraestructura, 2 MB para Search

La explicación de Google convive con otra cifra que lleva años circulando en el sector: los 15 MB. En la documentación general sobre su infraestructura de rastreo, Google indica que, por defecto, sus rastreadores y “fetchers” solo rastrean los primeros 15 MB de un archivo y el resto se ignora. Ese límite, sin embargo, funciona como una regla general de la infraestructura, no necesariamente como el umbral que aplica a todas las situaciones o productos.

En paralelo, la página específica de Googlebot para Search detalla el comportamiento cuando el objetivo es indexar contenido para el buscador: 2 MB para archivos compatibles y 64 MB para PDF. El resultado no es solo un cambio de números, sino una separación explícita de reglas: una para la infraestructura de rastreo en general y otra, más concreta, para el rastreo orientado a Búsqueda.

Este matiz es importante porque la diferencia entre “rastrear”, “obtener” y “enviar a indexación” suele perderse en titulares rápidos. En la práctica, lo que Google deja claro es qué parte del contenido llega realmente a ser considerada para indexación cuando se alcanza el umbral.

El detalle que cambia el enfoque: no es “2 MB por página”, es “2 MB por recurso”

El punto que más afecta al trabajo de desarrollo y SEO técnico aparece en una frase que Google recalca: desde la perspectiva de la renderización, cada recurso referenciado en el HTML (CSS y JavaScript, por ejemplo) se obtiene por separado, y cada obtención está sujeta al mismo límite (con la excepción de los PDF).

Esto cambia por completo la lectura simplista de “URLs de más de 2 MB”. Una página puede tener un HTML relativamente ligero, pero depender de un JavaScript enorme para generar el contenido principal o para construir navegación interna. Si ese JavaScript supera los 2 MB sin comprimir, Googlebot no necesariamente verá el archivo completo, lo que abre un riesgo evidente: partes críticas de la experiencia —y del contenido indexable— pueden quedarse fuera del alcance del rastreador.

En el extremo contrario, un HTML puede inflarse por decisiones de plantilla, estados serializados, contenido repetido o datos embebidos. En esos casos, el recorte también puede afectar a enlaces internos, texto principal o datos estructurados si están “más allá” del umbral.

“Sin comprimir”: el rendimiento vuelve a ser SEO, por definición

El otro matiz técnico tiene consecuencias muy prácticas: el límite se aplica al tamaño sin comprimir. Es decir, aunque un sitio use Brotli o gzip y entregue archivos más pequeños “en tránsito”, el umbral que considera Google se basa en la versión descomprimida. Esto pone el foco en un problema común de los frontales modernos: bundles JavaScript que crecen sin control.

La gran mayoría de webs no se acercan ni remotamente a esos tamaños en HTML, pero sí existen casos reales:

  • Aplicaciones híbridas (marketing + app) que reutilizan el mismo bundle para todo el sitio.
  • E-commerce con filtros complejos y plantillas que generan demasiado HTML, especialmente en listados.
  • Páginas que inyectan grandes volúmenes de datos en JSON dentro del HTML para “hidratar” el cliente.
  • CSS monolítico sin purga efectiva, acumulando reglas no usadas.

Cuando estos excesos aparecen, el problema ya no es solo “carga lenta”. El problema es que Google puede no alcanzar a procesar toda la información que el sitio necesita para posicionar.

Qué significa esto para un medio generalista: menos drama, más checklist

En un contexto de noticias generalistas, la conclusión no debería ser alarmista. Google no está diciendo que vaya a dejar de rastrear la web por encima de 2 MB, ni que millones de sitios estén en riesgo inmediato. Lo que sí está diciendo, de forma explícita, es que existen límites concretos en lo que procesa y que, si se superan, el contenido se recorta.

Para equipos de producto, desarrollo y marketing, esta aclaración convierte el rendimiento en un tema menos opinable. No es solo experiencia de usuario o “nota” en herramientas de auditoría: es visibilidad real en buscadores, porque el rastreador tiene un tope operativo.

De ahí que el mensaje para la mayoría de organizaciones sea bastante tangible:

  • Mantener el HTML limpio y evitar inflarlo con datos innecesarios.
  • Dividir JavaScript (code splitting) y servir solo lo imprescindible en rutas indexables.
  • Asegurar que el contenido crítico no dependa de un bundle gigante para existir.
  • Revisar recursos clave (CSS/JS) en su tamaño descomprimido, no solo “transferido”.
  • Separar claramente rutas públicas y entornos de aplicación interna si comparten infraestructura.

En resumen: la optimización web no “ayuda” al SEO de forma indirecta; en ciertos escenarios, condiciona directamente qué ve Google.


Preguntas frecuentes

¿Google limita el rastreo a 2 MB por URL o por archivo (HTML, JS, CSS)?
El límite descrito para Google Search aplica por archivo descargado. Es decir, Googlebot procesa hasta 2 MB por cada recurso compatible (HTML, CSS, JavaScript, etc.), y trata cada obtención por separado.

¿Qué pasa si un JavaScript o un HTML supera los 2 MB sin comprimir?
Googlebot puede detener la descarga al alcanzar el límite y solo considerar la parte obtenida para indexación. Si el contenido importante depende de ese archivo, existe riesgo de que no se procese completo.

¿Cómo afecta esto al SEO en webs modernas con mucho JavaScript?
Puede impactar en páginas donde el contenido, los enlaces internos o el marcado estructurado se generan principalmente con JavaScript. Si el bundle es demasiado grande, Google puede no llegar a procesar todo.

¿Por qué los PDF tienen un límite distinto en Googlebot?
Google indica explícitamente un umbral mayor para PDF en el rastreo orientado a Search: hasta 64 MB, frente a los 2 MB de otros tipos compatibles.

vía: SEOcretos

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Lo último

×