En la conversación diaria sobre rendimiento web, hay una frase que se repite como muletilla: “El WPO no afecta al SEO”. Esta semana, sin embargo, Google ha vuelto a poner sobre la mesa un detalle técnico que desmonta el argumento con una precisión quirúrgica. No se trata de un cambio de algoritmo ni de un “core update” misterioso: es documentación oficial, clara y reciente. Y su implicación es directa: Googlebot solo procesa los primeros 2 MB de los tipos de archivo compatibles cuando rastrea contenido para la Búsqueda, con una excepción relevante para PDF, cuyo límite sube a 64 MB.
La clave, además, es que no habla de “2 MB por URL” ni de un tope acumulado para toda la página, sino de 2 MB por cada archivo descargado, y calculado sobre el tamaño sin comprimir. Dicho de otra forma: una página puede tener decenas de recursos, pero cada CSS y cada JavaScript referenciado se obtiene por separado y queda sujeto al mismo límite de tamaño (salvo PDFs). Cuando se alcanza el umbral, Googlebot detiene la descarga y solo considera para indexación la parte ya obtenida.
No es el tamaño de la URL: es el tamaño del archivo que Googlebot llega a leer
Parte del ruido generado en redes nace de una confusión comprensible: hablar de “URLs de más de 2 MB” no tiene sentido práctico en la web convencional. Lo que Google está describiendo es el tamaño máximo de contenido que procesa por descarga. Si un HTML, un JavaScript o un CSS supera ese límite, Google no “deja de rastrear” el sitio; lo que ocurre es que el archivo se trunca: el robot no ve lo que queda más allá de esos 2 MB.
En SEO técnico, este matiz cambia el enfoque. El problema no es “si Google entrará” (entrará), sino qué parte del contenido alcanzará a interpretar. Y eso afecta a lo que realmente importa: contenido principal, enlaces internos, metadatos, datos estructurados y cualquier pieza crítica para la indexación.
De 15 MB a 2 MB: la historia real es más matizada
En los últimos años se citaba con frecuencia un umbral de 15 MB asociado a Googlebot. De hecho, Google explicó en 2022 que, al recuperar ciertos tipos de archivos, solo los primeros 15 MB se envían a indexación y lo demás se descarta. Lo nuevo ahora es que la documentación separa con más precisión dos planos que a menudo se mezclaban:
- Por un lado, la documentación de la infraestructura de rastreo de Google indica un límite por defecto de 15 MB para “crawlers y fetchers” en general, con la nota de que proyectos individuales pueden definir límites distintos y que ciertos tipos de archivo, como PDF, pueden tener umbrales diferentes.
- Por otro lado, la página específica de Googlebot para Búsqueda concreta que, cuando rastrea para Google Search, el robot solo explora los primeros 2 MB de los tipos de archivo compatibles y hasta 64 MB en PDFs.
El resultado es que, más que un “recorte” universal, lo que Google ha hecho es aclarar qué límite aplica a qué contexto y dónde.
La frase que más debería preocupar a los equipos técnicos: “sin comprimir”
El detalle que convierte este punto en un asunto de WPO es que el límite se aplica a los datos sin comprimir. Es decir: aunque el servidor entregue un JavaScript muy comprimido por gzip o Brotli, a Google le cuenta el tamaño que resulta tras descomprimirlo, que suele acercarse al tamaño “real” del archivo tal y como está en disco.
Esto coloca en el foco a los habituales sospechosos del rendimiento moderno:
- Bundles JavaScript desmesurados en frontales SPA o “dashboard” internos que acaban filtrándose a rutas indexables.
- JSON embebido o estados serializados enormes inyectados en el HTML.
- Plantillas que generan HTML inflado por exceso de atributos, nodos repetidos o contenido duplicado.
- CSS monolítico que acumula reglas no usadas por falta de purgado.
En estos casos, el impacto no es solo “tarda más en cargar”. El impacto es que Googlebot puede no llegar a leer partes del archivo, y esas partes —si contienen enlaces internos, contenido indexable o marcado estructurado— pueden quedarse fuera.
Renderizado y recursos: el límite también se aplica a CSS y JavaScript
La documentación de Googlebot remarca otro punto que suele olvidarse en debates simplificados: desde la perspectiva de renderizado, cada recurso referenciado en el HTML (CSS y JavaScript, por ejemplo) se obtiene de forma independiente, y cada obtención tiene su propio límite de tamaño.
Esto implica un escenario práctico: una página puede tener un HTML muy pequeño, pero depender de un JavaScript gigantesco para construir contenido crítico. Si ese JS supera el límite, el robot solo tendrá acceso parcial al archivo. En el mundo real, esto es especialmente delicado cuando el contenido depende de JavaScript para:
- Pintar listas de producto o fichas de servicio.
- Insertar enlaces internos dinámicos.
- Cargar datos estructurados en runtime.
- Generar el contenido principal tras la hidratación.
La recomendación clásica “haz SSR o prerenderiza lo importante” vuelve a ganar peso, no como dogma, sino como protección ante límites de rastreo y renderizado.
Qué deberían revisar los equipos de desarrollo
La mayoría de sitios no rozarán jamás estos umbrales. Pero las excepciones existen: proyectos con frontales complejos, webs con deuda técnica o stacks donde la optimización no ha sido una prioridad. Para esos casos, el “checklist” es bastante concreto:
- Auditar el peso sin comprimir del HTML y de los recursos críticos (JS/CSS) en rutas indexables.
- Reducir JavaScript con división de código (code splitting), eliminación de dependencias innecesarias y tree-shaking real.
- Evitar contenido crítico tardío: si algo debe posicionar, que no dependa de un bundle mastodóntico para existir.
- Controlar el HTML inflado: plantillas, inyecciones masivas, datos embebidos y contenido duplicado.
- Separar rutas: dashboards, entornos de app interna y páginas públicas no deberían compartir la misma carga de recursos si no es estrictamente necesario.
El mensaje final es incómodo, pero útil: el rendimiento no es solo UX. En algunos casos, es literalmente “qué parte de tu web llega a ver el buscador”.
Preguntas frecuentes
¿Google ha limitado el rastreo a 2 MB por URL o por archivo?
El límite descrito para Google Search aplica por archivo descargado (HTML, CSS, JS y otros tipos compatibles), no como un tope total acumulado por URL. Cada recurso referenciado se obtiene por separado y queda sujeto al mismo límite (salvo PDFs).
¿Qué significa que el límite sea “sin comprimir”?
Que el tamaño se calcula sobre los datos descomprimidos. Un archivo servido con Brotli o gzip puede viajar mucho más ligero, pero a efectos del límite cuenta el tamaño tras descomprimir.
¿Cómo puede afectar el límite de 2 MB al SEO de una web con mucho JavaScript?
Si un bundle JavaScript supera el umbral, Googlebot puede no procesar el archivo completo. Si el contenido importante, enlaces internos o datos estructurados dependen de ese JavaScript, parte de la información puede no llegar a considerarse en la indexación.
¿Los PDFs también tienen el límite de 2 MB?
No. Google especifica un límite mayor para PDF: hasta 64 MB cuando Googlebot rastrea para la Búsqueda.
vía: developers.google