Índice
- 1 Cómo funciona realmente el límite de 15 MB
- 2 ¿Qué ocurre realmente cuando se superan los 15 MB?
- 3 Por qué cada vez es más fácil que esto ocurra sin ser detectado
- 4 Cómo comprobar si tienes recursos que superan los 15 MB
- 4.1 Comprobar el tamaño real de una URL con curl
- 4.2 Buscar archivos mayores de 15 MB directamente en el servidor (SSH)
- 4.3 Buscar solo PDFs grandes (uno de los casos más habituales)
- 4.4 Buscar imágenes grandes que puedan estar causando problemas
- 4.5 Comprobar el tamaño real desde el navegador (sin usar consola)
- 4.6 Qué hacer si encuentras archivos que superan los 15 MB
- 4.7 Un detalle importante: no todo está dentro de tu servidor
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
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:
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


