Límite de rastreo de Googlebot: lo que Google reveló sobre cómo funciona realmente
Durante años, el límite de rastreo de Googlebot se trató como un dato fijo: 15 megabytes por documento, punto. Lo que Google acaba de revelar en el episodio más reciente de Search Off The Record, con Gary Illyes y Martin Splitt, cambia esa lectura por completo. No estamos ante una regla rígida. Estamos ante un sistema de configuración dinámica que varía según el tipo de contenido, la velocidad requerida y las decisiones internas de cada equipo dentro de Google.
Si gestionas el SEO técnico de un sitio, necesitas entender este matiz. No para entrar en pánico, sino para dejar de asumir que los límites documentados son los únicos límites que existen.
Qué es realmente el límite de rastreo de Googlebot y por qué no es lo que crees
El límite de rastreo de Googlebot opera como un parámetro de infraestructura, no como una política editorial. Illyes lo explicó con claridad: el límite de 15 MB existe por defecto en cualquier crawler dentro de Google que no haya sobreescrito ese valor. No es que Google haya decidido que 15 MB es el peso ideal de una página web. Es simplemente el umbral que protege los sistemas internos de ser desbordados por documentos excesivamente pesados.
El matiz que importa es este: ese valor se puede modificar. De hecho, se modifica con frecuencia. El equipo de Google Search lo tiene configurado en 2 MB para rastreo web estándar. Otros equipos internos lo ajustan hacia arriba o hacia abajo dependiendo de lo que necesiten indexar y con qué urgencia.
El límite de 15 megabytes no aplica igual para todos los formatos
PDFs, HTML y el peso real del contenido
Los PDFs son el caso más ilustrativo. Según Illyes, el límite para este formato se amplía considerablemente, ya que hay documentos PDF que fácilmente superan los 60 o incluso 96 megabytes. Google no los ignora, pero tampoco los ingiere completos sin condición. Si la conversión de ese PDF a HTML para procesamiento representa una carga desproporcionada para la infraestructura de rastreo de Google, el sistema simplemente limita lo que toma.
Lo que se recomienda en estos casos es en los PDF’s incluir en las partes iniciales de cada uno algo que se conoce como TL;DR, que en si es un resumen de lo que trata el PDF, hay que realizarlo de tal modo que cause engagement en el auditorio y por lo tanto interes en leerlo completo.
Con HTML sucede algo similar. Illyes mencionó directamente el estándar HTML living standard como ejemplo: un documento de 14 MB con todas las especificaciones consolidadas en una sola página no va a ser rastreado en su totalidad. Google va a preferir las versiones fragmentadas por función, que son más ligeras y procesables. Esto tiene una implicación directa para sitios que consolidan demasiado contenido en una sola URL: más no siempre es mejor cuando se habla de velocidad de rastreo de Google.
Cuándo el límite se reduce por diseño
Illyes también introdujo un escenario que raramente se menciona en documentación oficial: cuando Google necesita indexar algo con rapidez, el límite de truncamiento puede reducirse a 1 MB o menos. La lógica es directa. Menos datos que procesar significa menos tiempo hasta que el contenido entra al pipeline de indexación. Si la velocidad es prioritaria, la profundidad de rastreo se sacrifica.
La infraestructura de rastreo de Google no es monolítica
Martin Splitt fue quien cerró el debate con la frase más útil del episodio: la infraestructura de rastreo de Google no es monolítica. Es un servicio, y Google Search es uno de sus clientes, no el único ni el más privilegiado en todos los contextos.
Pensar en Googlebot como una entidad única con configuración fija es un error de modelado. Lo que existe es un sistema de rastreo como servicio, donde cada cliente interno —Google Search, Google Imágenes, otros crawlers especializados— llama a ese servicio con sus propios parámetros. Eso explica por qué Splitt señaló que probablemente el límite para imágenes sea mayor que 2 MB, dado que las imágenes modernas fácilmente superan ese peso.
La documentación pública de Google refleja los valores más comunes, no la totalidad de configuraciones posibles. Saber esto no significa que debas diseñar tu arquitectura esperando excepciones. Significa que cuando un sitio tiene documentos pesados o estructuras inusuales, el comportamiento real del rastreador puede diferir de lo que los informes de cobertura en Search Console muestran a primera vista.
Qué significa esto para tu presupuesto de rastreo
El concepto de presupuesto de rastreo cobra una dimensión adicional con esta información. No se trata solo de cuántas URLs rastrea Google por día en tu sitio. Se trata también de cuánto peso por URL está dispuesto a procesar en función del tipo de contenido y la prioridad que le asigna internamente.
Un sitio con páginas HTML pesadas, con código no utilizado acumulado, scripts embebidos y recursos sin comprimir, no solo afecta la experiencia del usuario. Está compitiendo contra el límite de 2 MB que Google Search aplica para rastreo web. Si tu página supera ese umbral, Google va a procesar solo la fracción que cabe en esa ventana. El resto, aunque esté en el DOM, puede no llegar al índice.
La buena noticia es que este problema tiene solución técnica directa: auditar el peso de tus páginas más estratégicas, eliminar código muerto, optimizar recursos embebidos y validar con herramientas como PageSpeed Insights o el reporte de experiencia de página en Search Console que el contenido visible y rastreable esté bien dentro de ese margen de 2 MB.
Recomendaciones para optimizar tu sitio web para un rastreo óptimo
Conocer cómo funciona el límite de rastreo de Googlebot sin traducirlo en acciones concretas no mueve ninguna aguja. Lo que sigue es el proceso que aplicamos con nuestros clientes cuando el rastreo eficiente es una prioridad de posicionamiento.
Paso 1 — Audita el peso real de tu HTML
Mide el tamaño del documento HTML puro de tus URLs más estratégicas, sin contar imágenes ni scripts externos. El objetivo es mantenerte por debajo de 2 MB. Usa Screaming Frog con la columna “HTML Size” o ejecuta una revisión directa con herramientas de análisis de respuesta HTTP. Las páginas que superen ese umbral son candidatas inmediatas a optimización.
Paso 2 — Elimina código muerto y peso innecesario
Revisa si tu tema o plantilla carga CSS y JavaScript que no se usan en determinadas páginas. Plugins acumulados, scripts de terceros sin condicionales y hojas de estilo globales aplicadas a toda la instalación son las fuentes más comunes de código acumulado sin propósito (código que existe en tu sitio pero no cumple ninguna función visible para el usuario ni para el rastreador). Herramientas como el reporte de cobertura de código en Chrome DevTools identifican exactamente qué porcentaje del código cargado no se ejecuta.
Paso 3 — Comprime y sirve recursos de forma eficiente
Habilita compresión Gzip o Brotli en tu servidor. Verifica que tu CDN o hosting aplique estos formatos correctamente en las respuestas HTTP. Un documento de 4 MB sin comprimir puede reducirse a menos de 1 MB con configuración básica de servidor, sin tocar una línea de código del sitio.
Paso 4 — Fragmenta contenido excesivamente consolidado
Si tienes páginas que agrupan gran cantidad de información en una sola URL porque “es más fácil de gestionar”, evalúa si esa consolidación tiene sentido desde la perspectiva del rastreo. Google mismo divide el estándar HTML en páginas individuales por función. Tu sitio puede seguir la misma lógica: URLs más ligeras, más específicas y con mayor probabilidad de ser procesadas completas por el rastreador.
Paso 5 — Revisa tus PDFs indexables
Si publicas documentos en PDF dentro de tu sitio, asegúrate de que el contenido más relevante esté en los primeros megabytes del archivo. Lo que Googlebot no alcanza antes del corte no aparece en los resultados. Considera también si esos PDFs realmente necesitan ser indexados o si el contenido serviría mejor en una página HTML dedicada, con mayor control sobre estructura y rastreo.
Paso 6 — Valida con Search Console y registros de servidor
El reporte de estadísticas de rastreo en Google Search Console muestra cuántos kilobytes descarga Googlebot por visita y con qué frecuencia regresa. Si ves caídas en la frecuencia de rastreo o páginas que llevan semanas sin ser revisitadas, ese es el indicador de que algo en el peso o en la arquitectura está frenando el proceso. Los logs de servidor, analizados con herramientas como Screaming Log Analyzer o GoAccess, dan el mapa completo de qué rastreo Google y qué ignoró.
Paso 7 — Mantén una revisión periódica, no puntual
El rastreo no es un problema que se resuelve una vez. Las actualizaciones de plugins, cambios de plantilla, nuevas integraciones de marketing y migraciones parciales pueden reintroducir peso innecesario en cualquier momento. Un proceso de revisión técnica trimestral, con las métricas correctas en el dashboard, es lo que separa los sitios que mantienen visibilidad sostenida de los que acumulan deuda técnica silenciosa.
Optimizar el rastreo de tu sitio no es una tarea de una tarde, pero tampoco es un proyecto de meses si se aborda con el orden correcto y las herramientas adecuadas. En Mark3teros acompañamos a las PYMEs en cada uno de estos pasos: desde la auditoría técnica inicial hasta la implementación y el monitoreo continuo, con una visión de consultoría que traduce los tecnicismos de Google en decisiones de negocio claras. Si tu sitio no está siendo rastreado con la frecuencia que merece, es el momento de revisarlo juntos, contáctanos y cuentanos de tu proyecto, con gusto te asesoraremos.
Carlos Enrique es especialista en SEO, Marketing Digital y Business Intelligence con más de 10 años de experiencia.
Licenciado en Administración por la UNAM, con Maestría en Marketing Digital y Comercio Electrónico por la UNIR y formación en Inteligencia de Negocios por el ITAM. Ha desarrollado su carrera en el sector bancario mexicano y como docente universitario.
Actualmente dirige Mark3teros, agencia especializada en el acompañamiento digital de PYMEs bajo el concepto "Inmersión Empresarial para el Éxito Digital".