En el ecosistema del SEO técnico, pocos cambios de documentación han generado tanto debate como la reciente aclaración de Google sobre sus límites de procesamiento.
Google ha confirmado que su motor de indexación solo procesa los primeros 2 MB de un archivo HTML o basado en texto, ignorando cualquier dato que se encuentre después de este umbral.
Esta directiva marca una frontera crítica entre el rastreo (descarga del archivo) y la indexación (procesamiento del contenido para el ranking).
Históricamente, se mencionaba un límite de 15 MB, pero esta cifra se refería a la capacidad de carga del rastreador general. La realidad actual es más estricta: si tu código fuente es una maraña de scripts inyectados y estilos pesados que empujan el contenido principal más allá del segundo megabyte, Google simplemente no lo leerá.
Puntos críticos de la actualización
- Umbral de corte: 2,048 KB exactos para archivos HTML, JS, CSS y JSON.
- Peso sin compresión: Google calcula el límite basándose en el archivo «raw», ignorando los beneficios de Gzip o Brotli.
- Impacto en SGE: Esta medida busca optimizar los recursos para las IA Overviews, que requieren datos ligeros y estructurados.
- PDFs y otros: El límite para documentos PDF se mantiene en 64 MB, una excepción lógica dada la naturaleza de los documentos corporativos.
1. Rastreo (crawl) vs. indexación (Index)
Para comprender el impacto de esta directiva, debemos diseccionar cómo funciona la infraestructura de búsqueda de Google. Cuando Googlebot visita tu sitio, realiza una solicitud GET.
El sistema de descarga puede manejar archivos de hasta 15 MB sin problemas; sin embargo, ese archivo descargado se pasa a un «indexador» que extrae el texto, los enlaces y los metadatos.
Es aquí donde entra la restricción. Como señala la documentación actualizada de Google Search Central, el indexador detiene su trabajo al llegar a los 2 MB.
Según Gary Illyes, analista de Google, esta limitación no es nueva en la práctica, sino que ahora es una directiva pública para ayudar a los desarrolladores a entender por qué sus páginas podrían no estar indexando partes críticas.
Si tu archivo HTML pesa 3 MB, el primer megabyte extra (que suele contener el pie de página, enlaces de navegación profunda y, a veces, el marcado de datos estructurados) será un «agujero negro» para el bot.
2. Anatomía de una página pesada
A primera vista, 2 MB de texto parecen una cantidad inabarcable (aproximadamente 1.2 millones de palabras). Sin embargo, en el desarrollo web moderno, el peso no viene de la literatura, sino de la arquitectura técnica deficiente.
El problema de los Page Builders
Constructores visuales como Elementor, Divi o Gutenberg (cuando no está optimizado) tienden a generar una «sopa de etiquetas».
Cada elemento visual se envuelve en múltiples capas <div>, lo que aumenta exponencialmente el peso del DOM. Una página de producto compleja en un e-commerce puede alcanzar fácilmente los 500 KB solo en estructura de etiquetas.
CSS y JS «inlined»
La técnica de inyectar CSS crítico directamente en el <head> es excelente para el Largest Contentful Paint (LCP), pero muchos desarrolladores cometen el error de inyectar todo el CSS del sitio.
Si tienes 400 KB de estilos y otros 400 KB de scripts de seguimiento o bibliotecas inyectadas, ya has consumido casi la mitad de tu presupuesto de indexación antes de que Google lea la primera palabra de tu contenido.
3. Impacto en el SEO y las IA Overviews (SGE)
La llegada de la Búsqueda Generativa (SGE) ha cambiado la prioridad de Google. Los modelos de lenguaje (LLM) que alimentan los resúmenes de IA necesitan datos limpios y rápidos de procesar. Un archivo HTML de 5 MB es ineficiente para el entrenamiento de modelos en tiempo real.
Si tu contenido clave queda truncado:
- Pérdida de señales de relevancia: Google no entenderá el contexto completo de tu artículo si las conclusiones quedan fuera.
- Ruptura del enlazado interno: Los enlaces en el footer son esenciales para el descubrimiento de páginas nuevas. Si el footer no se indexa, el crawl budget de tu sitio se desperdicia.
- Fallo en fragmentos enriquecidos: Si el marcado JSON-LD está al final del documento y este se corta, tu sitio perderá las estrellas de reseñas, precios o FAQs en las SERPs.
4. Cómo detectar el riesgo de truncamiento
Como especialista, no puedes confiar en la apariencia visual de la página. Debes auditar el flujo de datos crudos.
Herramientas de diagnóstico recomendadas
- Screaming Frog: Configura el rastreo para que resalte cualquier HTML que supere los 2,000 bytes. Esta es la forma más rápida de obtener un inventario de riesgos.
- Google Search Console: Utiliza la herramienta «Probar URL en vivo» y haz clic en «Ver página probada». Busca el final de tu código. Si ves que el código termina abruptamente en medio de una etiqueta, Google ha aplicado el recorte.
- Terminal de comandos: Puedes usar
curlpara verificar el tamaño exacto que recibe el bot:curl -so /dev/null -w '%{size_download}\n' [tu-url]
| Tipo de archivo | Límite de descarga | Límite de indexación | Recomendación SEO |
|---|---|---|---|
| HTML / Texto | 15 MB | 2 MB | Bajo 500 KB |
| 64 MB | 64 MB | Documentos largos |
5. El impacto en Frameworks
En las aplicaciones de una sola página (SPA) o sitios con renderizado en el cliente (CSR), el HTML inicial suele ser pequeño, pero el «payload» de JavaScript puede ser gigantesco.
Si el archivo .js principal supera los 2 MB, Googlebot podría tener dificultades para ejecutar el renderizado completo. La eficiencia del script es vital. Un script truncado significa una página en blanco para Google.
Consulta las guías de Web.dev para profundizar en la optimización de JS.
6. Guía de optimización: Adelgazando el código
- Externalización de recursos: Saca CSS y JS a archivos independientes.
- Limpieza de comentarios: Elimina código muerto y notas de desarrollador.
- Fragmentación de contenido: Usa paginación o carga diferida.
- Optimización de datos estructurados: Coloca el JSON-LD en el
<head>. - Evitar data URIs: No incrustes imágenes en Base64.
7. El futuro de la web ligera
El consenso es claro: la web debe ser ligera. Barry Schwartz comenta:
«Esta actualización es una señal de que Google prioriza la eficiencia energética y la velocidad de procesamiento sobre la exhaustividad de páginas mal construidas.»
Un HTML de más de 2 MB es una mala experiencia tanto para el bot como para el usuario móvil.
Preguntas frecuentes (FAQs)
1. ¿El límite afecta al JS?
El límite de 2 MB es para el archivo descargado. Si el DOM generado por JS es demasiado pesado, puede causar timeouts de renderizado.
2. ¿Qué pasa con las etiquetas meta después de los 2 MB?
Google no las verá. Podría indexar tu página con un título genérico.
3. ¿Aplica a archivos CSS?
Sí, el límite de 2 MB aplica a todos los archivos basados en texto utilizados para el procesamiento.
4. ¿Por qué los PDFs tienen más margen?
Son documentos estáticos y extensos por naturaleza. El HTML debe ser eficiente.
5. ¿Basta con minificar?
No siempre. La minificación reduce el peso, pero la solución real es la reestructuración del código.
Conclusiones
La directiva de los 2 MB es un recordatorio de que el SEO técnico requiere refinamiento constante. Mantener archivos ligeros asegura la indexación total y mejora la experiencia de usuario.