Límite de 15 MB en Googlebot: impacto en crawling y crawl budget

Cómo funciona realmente el límite de 15 MB

Googlebot no rastrea sin límites ya que existe un umbral técnico claro: solo procesa los primeros 15 MB de cada recurso que descarga. Todo lo que supere ese tamaño se omite y no se procesa ni se tiene en cuenta para la indexación.

Este comportamiento fue documentado por Google dentro de su Google Search Central Blog, en el artículo Googlebot y los 15 MB

Este límite no se aplica al total de la página, sino a cada archivo individual que la compone. Una página web no es un único documento, sino un conjunto de recursos que se descargan por separado: el HTML principal, hojas de estilo CSS, scripts, imágenes o fuentes.

En términos prácticos, el comportamiento es sencillo: si un recurso supera los 15 MB, Googlebot procesa únicamente hasta ese punto y descarta el resto del contenido de ese archivo.

¿Qué ocurre realmente cuando se superan los 15 MB?

Una de las dudas más habituales cuando se habla del límite de 15 MB es pensar que, si se supera, el crawling se detiene por completo, y en la práctica esto no funciona así.

Cuando un recurso supera ese tamaño, Googlebot procesa únicamente los primeros 15 MB y omite el resto del archivo. El rastreo no se detiene, pero el tiempo invertido en gestionar recursos demasiado grandes puede reducir la eficiencia del crawling si ocurre de forma repetida.

Es importante entender que el límite se aplica al contenido que Googlebot procesa. Una vez alcanzados los 15 MB, el resto del contenido del recurso deja de procesarse y no se tiene en cuenta para la indexación.

Esto significa que el impacto depende mucho del tipo de recurso que esté superando ese límite.

Por ejemplo, imagina una página con esta estructura:

HTML → 600 KB  
CSS → 120 KB  
JavaScript → 800 KB  
Imagen → 16 MB  

En este caso:

  • El HTML, el CSS y el JavaScript se procesan completamente
  • La imagen se procesa solo hasta los primeros 15 MB
  • El resto de la página sigue analizándose con normalidad

Cuando esto ocurre de forma puntual, el impacto suele ser limitado. La página sigue siendo rastreable y el resto del contenido se procesa correctamente.

Cuando el recurso afectado es el HTML principal

La situación cambia cuando el archivo que supera los 15 MB es el HTML principal.

El HTML no es un recurso más. Es el documento que contiene el contenido, los enlaces internos y la estructura que permite interpretar la página, por ello si el HTML crece hasta superar ese límite, Googlebot procesará solo los primeros 15 MB y omitirá el resto del documento.

Nota técnica: aunque el límite general se sitúa en 15 MB por recurso, el HTML principal suele tener umbrales prácticos mucho más bajos. En muchos escenarios reales, tamaños superiores a aproximadamente 2 MB pueden empezar a generar problemas de procesamiento.

Puedes ver un análisis detallado sobre este punto aquí → Cuándo el HTML supera el umbral práctico de 2 MB

En ese escenario, el impacto puede ser mayor, especialmente si el tamaño del HTML ha crecido sin control con el tiempo.

¿Puede afectar al crawl budget?

Sí, pero de forma indirecta, ya que cada recurso grande consume tiempo de descarga y procesamiento. Si esto ocurre muchas veces, el rastreo se vuelve menos eficiente.

No porque el crawling se detenga, sino porque se vuelve menos eficiente.

Por ejemplo:

100 páginas  
Cada página con 5 imágenes de más de 15 MB

En ese escenario, el volumen total de datos descargados crece rápidamente, lo que puede reducir la eficiencia del rastreo.

Esto puede ser especialmente relevante en sitios:

  • con muchas URLs
  • con contenido dinámico
  • que se rastrean con frecuencia

En webs pequeñas, el impacto suele ser mínimo, mientras que en webs grandes esto puede empezar a ser relevante.

Las preguntas clave que suelen aparecer (y que conviene tener claras)

  • ¿Se detiene el crawling si un archivo supera los 15 MB?
    No. Solo se trunca ese recurso, el resto del rastreo continúa.
  • ¿El límite aplica a toda la página?
    No. Se aplica a cada recurso individual.
  • ¿Una imagen grande es un problema grave?
    Normalmente no si es puntual.
  • ¿Cuándo empieza a ser relevante?
    Cuando ocurre de forma repetida o afecta a recursos clave.
  • ¿Puede afectar al crawl budget?
    Sí, especialmente en sitios grandes donde el consumo acumulado de recursos aumenta.

Por qué cada vez es más fácil que esto ocurra sin ser detectado

Es fácil pensar que superar los 15 MB solo ocurre cuando alguien sube archivos enormes de forma intencionada, pero en la práctica, muchas veces ocurre sin que el responsable técnico lo detecte.

No porque tú subas imágenes gigantes, sino porque otros pueden hacerlo sin darse cuenta o porque se integran herramientas externas que introducen esos recursos pesados.

Por ejemplo:

  • PDFs con imágenes sin optimizar
    Este es uno de los casos más habituales. Un catálogo, ficha técnica o manual puede contener varias imágenes sin comprimir. Aunque el documento parezca normal a simple vista, puede superar fácilmente los 15 MB. Basta con que un usuario suba un único PDF sin optimizar para introducir un recurso que supere ese límite.
  • Usuarios o terceros con acceso a la biblioteca de medios
    Un editor, cliente o colaborador puede crear una ficha de producto, añadir documentación descargable o subir material técnico sin revisar el tamaño final. En muchos proyectos, este tipo de cambios se realizan sin intervención directa del desarrollador.
  • Plugins o integraciones de terceros que cargan recursos pesados
    Al instalar plugins o herramientas externas, se añaden scripts y recursos que no siempre están optimizados. En muchos casos, la funcionalidad se valida visualmente, pero no se revisa el peso real de los archivos que se están cargando.
  • Recursos externos cargados desde servicios externos
    Algunas integraciones cargan librerías desde servidores externos (CDN, herramientas de analítica, widgets, etc.). Cada uno de esos recursos se descarga de forma independiente y puede superar el límite si no está optimizado.
  • HTML que crece con contenido generado dinámicamente
    Algunas herramientas insertan contenido directamente dentro del HTML o generan estructuras complejas que aumentan el tamaño del documento principal sin que resulte evidente.

En muchos proyectos, el problema no aparece porque alguien haga algo incorrecto de forma consciente, sino porque se añaden recursos o funcionalidades sin revisar su impacto técnico.

Por eso, cuando aparece un recurso que supera ese límite, normalmente no es una acción aislada ni intencionada, sino el resultado de múltiples decisiones tomadas a lo largo del tiempo.

Cómo comprobar si tienes recursos que superan los 15 MB

Después de entender que el límite se aplica al tamaño real descomprimido, la siguiente pregunta lógica es: ¿cómo puedo comprobar si esto está ocurriendo en mi sitio?

Existen varias formas prácticas de hacerlo. Algunas permiten comprobar URLs concretas y otras permiten revisar directamente los archivos almacenados en el servidor.

Comprobar el tamaño real de una URL con curl

Una forma sencilla de comprobar el tamaño real de un recurso es utilizar curl desde la línea de comandos.

Este comando descarga el contenido real del recurso y muestra su tamaño en bytes:

curl -s --compressed https://tusitio.com/una-url/ | wc -c

El parámetro --compressed permite que curl descargue el contenido tal como lo recibiría un navegador moderno, incluyendo compresión gzip o brotli, y medir correctamente el tamaño real del contenido procesado.

Por ejemplo:

curl -s https://tusitio.com/una-url/ | wc -c

El resultado será un número en bytes. Para interpretarlo:

1 MB ≈ 1.048.576 bytes  
15 MB ≈ 15.728.640 bytes

Si el resultado supera aproximadamente los 15.700.000 bytes, ese recurso podría estar superando el límite de procesamiento de Googlebot.

Este método es especialmente útil para comprobar:

  • HTML principal de páginas largas
  • URLs con mucho contenido dinámico
  • Páginas que generan contenido automáticamente

También puedes probar recursos concretos como PDFs o archivos descargables:

curl -s https://tusitio.com/documento.pdf | wc -c

Ten en cuenta que este método mide el contenido HTML generado por el servidor, entonces si tu página depende de JavaScript para generar contenido adicional, el tamaño final renderizado puede ser mayor que el resultado obtenido con curl.

Buscar archivos mayores de 15 MB directamente en el servidor (SSH)

Si tienes acceso SSH al servidor, puedes buscar rápidamente todos los archivos que superan los 15 MB dentro de la carpeta public_html.

Este comando es muy útil para detectar PDFs, imágenes o archivos multimedia pesados.

find public_html -type f -size +15M

Este comando mostrará una lista con todos los archivos que superan ese tamaño.

Es especialmente útil en sitios donde:

  • Se suben fichas técnicas o catálogos en PDF
  • Existen imágenes grandes sin optimizar
  • Hay contenido descargable para usuarios
find public_html -type f -size +15M -exec ls -lh {} \; | sort -k5 -rh

Esta variante muestra el tamaño de cada archivo encontrado y los ordena de mayor a menor, facilitando identificar rápidamente los recursos más pesados.

Buscar solo PDFs grandes (uno de los casos más habituales)

Uno de los escenarios más frecuentes es encontrar PDFs con imágenes sin optimizar.

Un catálogo técnico o manual puede contener múltiples imágenes sin compresión, haciendo que el archivo supere fácilmente los 15 MB sin que nadie lo detecte.

Puedes localizar rápidamente estos archivos con:

find public_html -type f -name "*.pdf" -size +15M

Este comando es muy práctico para:

  • Tiendas online con documentación técnica
  • Webs industriales con fichas descargables
  • Proyectos donde varios usuarios suben contenido

Buscar imágenes grandes que puedan estar causando problemas

Aunque una imagen grande aislada no suele ser crítica, sí conviene identificarlas si aparecen con frecuencia.

Puedes localizar imágenes pesadas con:

find public_html -type f \( -name "*.jpg" -o -name "*.png" -o -name "*.webp" \) -size +15M

Esto permite detectar rápidamente:

  • Imágenes subidas directamente desde cámaras
  • Material gráfico sin optimizar
  • Archivos que deberían comprimirse antes de publicarse

Comprobar el tamaño real desde el navegador (sin usar consola)

Si no tienes acceso SSH ni utilizas línea de comandos, también puedes comprobar el tamaño real desde las herramientas de desarrollo del navegador.

  • Abrir la página en Chrome
  • Pulsar F12
  • Ir a la pestaña Network
  • Recargar la página
  • Seleccionar el documento principal (HTML)
  • Revisar el tamaño indicado en la columna Size

Ten en cuenta que el valor más relevante no siempre es el tamaño transferido, sino el tamaño real del recurso una vez descomprimido. En algunos navegadores es posible visualzar ambos valores, tanto transferido como descomprimido.

Qué hacer si encuentras archivos que superan los 15 MB

Encontrar archivos grandes no significa automáticamente que exista un problema, pero sí indica que conviene revisarlos.

En la mayoría de casos, basta con aplicar algunas acciones básicas:

  • Revisar si el archivo realmente es necesario
  • Optimizar imágenes antes de generar PDFs
  • Reducir resolución innecesaria en archivos gráficos
  • Aplicar compresión adecuada en documentos descargables

En otros casos, en cambio, el archivo puede ser necesario por motivos funcionales. por ello en esas situaciones, lo importante es entender que ese recurso existe y valorar su impacto dentro del conjunto del proyecto.

Un detalle importante: no todo está dentro de tu servidor

No todos los recursos que carga una página se encuentran dentro de public_html. Muchos plugins o integraciones cargan archivos desde servidores externos, como:

  • Herramientas de analítica
  • Gestores de etiquetas como Google Tag Manager
  • Librerías externas desde CDN
  • Widgets o scripts de terceros

Cada uno de estos recursos también se descarga de forma independiente y está sujeto a su propio límite de procesamiento.

Por eso, además de revisar los archivos locales, conviene analizar qué recursos externos se están cargando y si realmente son necesarios.

Escrito por:

Óscar Carrillo

Más de 15 años de carrera me han enseñado que el SEO es un ecosistema vivo. Paso cada jornada trabajando para que las empresas alcancen su máximo potencial en Google