Límite 2 MB HTML Googlebot

Google ha documentado que Googlebot solo procesa los primeros 2 MB de HTML o archivos de texto.
Cuando ese tamaño se supera, el crawler deja de descargar el documento y el resto del contenido queda fuera del procesamiento.

Esto significa que si un documento HTML es demasiado grande, parte del contenido no llega a analizarse, ya que el corte se produce exactamente en el punto en el que se alcanza el límite.

En la práctica, cualquier bloque situado después de ese punto queda fuera del análisis.
Como los documentos HTML se construyen en orden, el contenido situado al final del archivo es el que más riesgo tiene de no procesarse.

Esto puede provocar situaciones como:

• enlaces internos que dejan de rastrearse si aparecen después del punto de corte
• contenido que no llega a procesarse, especialmente en listados largos
• datos estructurados que no se interpretan cuando se insertan al final del documento

Este límite no sustituye al conocido límite de 15 MB por recurso. Ambos conviven y cumplen funciones distintas.
El límite de 15 MB define el tamaño máximo general que puede descargar un crawler, mientras que el de 2 MB afecta directamente al HTML que Google Search procesa.

Existe un análisis específico sobre ese comportamiento aquí →
Límite 15 MB Googlebot

Un fichero HTML que supera los 2 MB suele indicar que algo ha crecido sin control dentro del documento.

A partir de aquí vamos a analizar tres aspectos clave:

• qué tendría que pasar para que un HTML alcance ese tamaño
• qué contiene realmente un documento inflado
• cómo detectar estos casos en un sitio real

Qué tendría que pasar para que un HTML supere los 2 MB

Un HTML puede superar los 2 MB por una acumulación de malas prácticas como estas:

• CSS inline repetido dentro del HTML

  Grandes bloques de estilos insertados directamente en el documento en lugar de cargarse desde archivos externos.

  <div style="margin:10px;padding:20px;background:#f5f5f5;
  border-radius:8px;font-size:16px;color:#333;">
  Contenido estilado inline
  </div>
  

• JavaScript embebido directamente en el HTML

  Scripts insertados dentro del documento en lugar de cargarse desde archivos externos.

  <script>
  function trackEvent(){
    console.log("evento ejecutado");
  }
  </script>
  

• SVG inline incrustado en múltiples partes del documento

  Iconos vectoriales insertados directamente en el HTML en lugar de utilizar recursos externos.

  <svg width="24" height="24">
    <path d="M10 20v-6h4v6h5v-8h3L12 3 2 12h3v8z"/>
  </svg>
  

• Salida HTML inflada por constructores visuales

  Herramientas como Elementor, Divi o Visual Composer generan estructuras HTML profundas y repetitivas.

  <div class="elementor-section">
    <div class="elementor-container">
      <div class="elementor-column">
        <div class="elementor-widget-wrap">
          <div class="elementor-widget">
            Contenido
          </div>
        </div>
      </div>
    </div>
  </div>
  

• Markup duplicado generado automáticamente

  Bloques HTML repetidos por plugins o funcionalidades que generan estructuras similares una y otra vez.

  <div class="product-card">
    <div class="product-title">Producto</div>
    <div class="product-price">29.99€</div>
  </div>
  

Normlamente no suele ser una única causa, sino la acumulación progresiva de varias de estas prácticas dentro del mismo documento.

En busca de ficheros HTML >2 MB

Para localizar qué páginas superan los 2 MB e identificar rápidamente qué URLs pueden darnos problemas podemos utilizar distintos métodos, tanto de forma masiva como individual.

1. Localizar páginas grandes con Screaming Frog (análisis masivo)

Tras realizar el crawl del sitio, basta con ordenar las URLs por tamaño.

En Screaming Frog:

• ordenar la columna Response Bytes de mayor a menor

Las primeras URLs de la lista serán las que tengan mayor tamaño HTML.

2. Comprobar una URL concreta con curl (análisis individual)

El comando curl permite medir el tamaño HTML de una URL específica.

Ejemplo:

curl -s https://tudominio.com/url-ejemplo/ | wc -c

Este comando devuelve el tamaño del HTML en bytes.

Ejemplo de salida:

2154873

1 MB equivale aproximadamente a 1.048.576 bytes.

En este ejemplo:

• 2 MB ≈ 2.097.152 bytes
• la URL supera los 2 MB

3. Listar archivos HTML por tamaño desde el servidor (análisis masivo en disco)

Con acceso al terminal del servidor web, es posible listar directamente los archivos HTML que superan un tamaño determinado.

Ejemplo:

find public_html -type f -name "*.html" -size +2M

Este comando devuelve todos los archivos HTML cuyo tamaño en disco supera los 2 MB.

4. Comprobar el tamaño del HTML desde DevTools (navegador)

En DevTools aparecen muchas peticiones, por lo que es importante identificar correctamente el recurso HTML principal. Aquí es importante fijarse solo en la petición principal del documento, no en CSS, JS, imágenes o fuentes.

Pasos:

• abrir DevTools (F12)
• ir a la pestaña Network
• recargar la página
• filtrar por Doc o Document
• seleccionar la primera petición (la URL principal)
• revisar el tamaño en la columna Size

Limpiar el origen del problema antes de optimizar

Cuando un HTML supera los 2 MB, la solución no pasa por aplicar compresión, cacheo o técnicas de optimización superficial: primero hay que eliminar el origen del problema.

Reducir el tamaño del HTML consiste, en la mayoría de casos, en limpiar código innecesario y evitar que el documento siga creciendo sin control.

Además, muchas de estas acciones no solo ayudan a reducir el tamaño del HTML: son prácticas directas de performance y PageSpeed que mejoran la velocidad de carga del sitio.

No tiene sentido aplicar cacheo o compresión sobre un HTML inflado.
Es como ponerse colonia antes de ducharse.

1. Evitar CSS y JavaScript embebido dentro del HTML

Uno de los errores más frecuentes es acumular estilos o scripts directamente dentro del documento.

Siempre que sea posible, debemos:

• mover los estilos inline a archivos CSS externos
• mover scripts embebidos a archivos JS independientes
• evitar que cada bloque tenga sus propios estilos individuales

En muchos constructores visuales, cada uno de los widget con los que trabajamos la maquetación, permite añadir estilos propios de manera manual. Esta técnica va a generar grandes cantidades de código embebido CSS dentro del HTML.

La manera correcta de hacerlo sería:

2. Configurar estilos globales en lugar de repetirlos por bloque

La mayoría de builders permiten definir estilos globales.

Por ejemplo:

• tipografías
• colores
• tamaños de texto
• espaciados

Definir estos valores a nivel global evita que cada bloque genere su propio CSS embebido dentro del HTML.

Esto reduce el volumen total del documento y mejora la eficiencia del renderizado.

3. Reducir la profundidad de contenedores en constructores visuales

Constructores como Elementor, Divi o WPBakery pueden generar múltiples capas de contenedores.

Dentro de lo posible:

• evitar anidar contenedores innecesarios
• simplificar estructuras visuales
• revisar secciones que contienen múltiples niveles sin necesidad real

En muchos casos, una estructura más simple genera exactamente el mismo resultado visual con menos HTML.

4. Unificar bloques cuando sea posible

Algunos widgets generan más marcado del necesario.

Por ejemplo:

• un bloque de encabezado y otro de texto pueden unificarse en un solo bloque HTML
• ciertos contenidos simples pueden escribirse directamente en un widget HTML
• estructuras repetidas pueden simplificarse con marcado más directo

Cada bloque adicional introduce nuevas etiquetas y aumenta el tamaño total del documento.

5. Revisar plugins que generan código excesivo

Algunos plugins añaden marcado adicional de forma automática. Si se detecta que un plugin genera gran cantidad de código, debemos:

• revisar su configuración interna
• desactivar opciones que generen estilos inline
• evitar cargar recursos innecesarios
• sustituir el plugin por una alternativa más ligera si es necesario

Muchos problemas de HTML sobredimensionado se originan en plugins mal configurados o excesivamente pesados.

6. Optimizar después, no antes

Una vez limpio el HTML y eliminadas las causas que inflan el documento, entonces sí tiene sentido aplicar optimización adicional.

Por ejemplo:

• compresión gzip o brotli
• cacheo
• minificación
• optimización de recursos externos

Aplicar estas técnicas sin haber limpiado el HTML previamente solo oculta el problema, pero no lo resuelve.

Primero se limpia el HTML. Después se optimiza el rendimiento.