Google tiene un límite máximo sobre cuánto de una página realmente recuperará y remitirá para indexación, y ese límite puede ser más pequeño de lo que muchos equipos suponen. Si tu HTML supera el límite, Google aún puede rastrear la URL, pero efectivamente puede “dejar de leer” a mitad del código fuente.
Esto importa para las auditorías técnicas de SEO porque el modo de fallo es sutil: puede que no veas un error obvio en Google Search Console, pero contenido importante, enlaces internos o datos estructurados pueden quedar más allá de la porción rastreable y nunca llegar a indexarse. A continuación hay un enfoque práctico de auditoría basado en la documentación oficial de Google y en pruebas recientes de febrero de 2026.
1) Entiende los dos límites: 2 MB para Googlebot (Search) vs 15 MB por defecto
La documentación de Google ahora describe más de un límite de tamaño de archivo, según qué rastreador/recuperador esté implicado. Oficialmente, Googlebot (Search) solo rastrea los primeros 2 MB de un tipo de archivo compatible, y para PDFs el límite es de 64 MB; tras el corte, Googlebot deja de recuperar y solo remite lo que ya descargó para indexación.
Por separado, Google también indica: “Por defecto, los rastreadores y recuperadores de Google solo rastrean los primeros 15 MB de un archivo”, y que los proyectos pueden establecer límites distintos por rastreador y tipo de archivo. Esto crea una aparente división en la documentación: una sección enfatiza el valor general de 15 MB por defecto, mientras que otra (más específica) destaca el comportamiento de 2 MB para Googlebot usado en la indexación de Search.
Los informes de la industria a principios de febrero de 2026 (p. ej., Search Engine Land y Search Engine Journal) enmarcan esto como una aclaración/reorganización de la documentación más que como un cambio de comportamiento confirmado. En el mismo contexto, Spotibo citó una frase atribuida a John Mueller vía SERoundtable: “Googlebot es uno de los rastreadores de Google, pero no todos ellos”, y otra: “Ninguno de estos cambió recientemente, solo queríamos documentarlos con más detalle.” Para los auditores, la conclusión es simple: debes auditar según el límite del rastreador correcto para el resultado que te interesa, la clasificación y la indexación en Google Search.
2) Qué significa en la práctica el corte de 2 MB para la indexación
La redacción oficial de Google es explícita: después del corte por tamaño de archivo, Googlebot deja de recuperar y solo remite lo que ya descargó para la indexación. Eso significa que el contenido ubicado después del corte no solo es “menos prioritario”, puede que nunca sea visto por la canalización de indexación.
En términos de SEO, cualquier texto, entidades, encabezados, enlaces internos, pistas canónicas en el HTML, o datos estructurados que aparezcan después del límite están en riesgo. La guía de Seobility de febrero de 2026 coincide con esto: si el HTML supera los 2 MB, Google puede omitir texto/enlaces internos/datos estructurados ubicados después del corte, lo que puede afectar la descubribilidad (enlazado interno) y la elegibilidad para resultados enriquecidos (datos estructurados) si ese marcado se coloca demasiado abajo.
Una matización importante para las auditorías: el límite se aplica al tamaño de archivo descomprimido. Así que una página que se transfiere como una carga gzip/brotli pequeña aún puede superar el umbral rastreable una vez descomprimida. No tomes el “tamaño de transferencia en red” en un navegador como referencia final; mide los bytes reales descomprimidos que Google procesaría.
3) Las subrecursos son recuperaciones separadas, y cada una tiene su propio límite
Google ha aclarado que cada recurso referenciado, como CSS y JavaScript, se recupera por separado, y cada recuperación está limitada por el mismo tope de tamaño de archivo (con la excepción de los PDFs). Esto se reforzó en la entrada del Search Central Blog (28 de junio de 2022) y la aclaración del 16 de marzo de 2023 dentro de esa misma entrada: cada subrecurso recuperado individualmente (notablemente CSS/JS) también está sujeto al límite de 15 MB descrito allí.
Para las auditorías, esto significa que no puedes “promediar” cosas en toda la página. Un documento HTML pequeño que referencia un bundle de JavaScript extremadamente grande aún puede sufrir truncamiento o restricciones de procesamiento a nivel de subrecurso. Del mismo modo, un archivo CSS hinchado por activos embebidos o frameworks enormes puede alcanzar el techo incluso si el HTML es moderado.
También explica por qué algunos sitios ven discrepancias confusas: el HTML podría estar dentro de los 2 MB, pero los scripts necesarios para renderizar contenido significativo (para aplicaciones del lado del cliente) pueden estar limitados por el tope por archivo. Si el código crítico para el renderizado es truncado, Google puede no ejecutar la página como pretende, y contenido o enlaces clave pueden no materializarse en el DOM renderizado que se indexa.
4) Evidencia de pruebas de febrero de 2026: truncamiento de la fuente indexada sin avisos
Las pruebas de Spotibo de febrero de 2026 proporcionan una ilustración práctica del riesgo. En una prueba, una página HTML de alrededor de 3 MB fue indexada, pero la fuente indexada fue truncada después de 2 MB, y no hubo advertencia en Search Console. Ese es exactamente el tipo de fallo silencioso que hace necesaria una auditoría proactiva.
Spotibo también observó que la prueba “en vivo” de Inspección de URL mostró la fuente completa de 3 MB, mientras que la versión indexada estaba recortada. Esto sugiere que la herramienta de Inspección puede usar una ruta de rastreador/recuperador diferente a la que usa Googlebot para la indexación, coherente con la declaración más amplia de Google de que existen múltiples rastreadores/recuperadores y que pueden tener límites distintos.
En otra prueba de Spotibo, un archivo HTML muy grande (unos 16 MB) hizo que Google fallara la solicitud de indexación con un error (“Algo salió mal…”) y mostró los datos de rastreo como N/A. Aunque este es un caso extremo, subraya que más allá del truncamiento, los archivos muy grandes pueden provocar fallos de procesamiento en herramientas o tuberías, haciendo que el control de tamaño sea una preocupación de estabilidad, no solo una buena práctica de SEO.
5) Qué priorizar en una auditoría: mantener el contenido crítico al principio
Un marco de lista de verificación ampliamente usado es priorizar “contenido crítico temprano en el HTML” para que no pueda ser empujado más allá del corte de 2 MB. “Crítico” típicamente incluye: contenido textual principal, enlaces clave, enlaces internos que impulsan el descubrimiento, directivas canonical y robots, y los datos estructurados necesarios para resultados enriquecidos.
Prácticamente, esto significa comprobar el orden de tu marcado. Si tu plantilla coloca sistemas de navegación enormes, bloques de filtros facetados, mega-menús o widgets repetidos por encima del contenido principal, corres el riesgo de desperdiciar bytes rastreables en contenido repetitivo. De igual forma, si tus datos estructurados se inyectan tarde (o se agregan después de grandes bloques de script), pueden quedar más allá del corte.
Usa un margen de seguridad en lugar de tratar los 2 MB como un objetivo exacto. Una heurística de la industria es marcar cualquier archivo HTML/JS/JSON que se aproxime a ~1,8, 2,0 MB descomprimidos, dejando espacio para pequeños cambios en la plantilla, ampliaciones por localización, fragmentos de pruebas A/B o schema adicional que pudiera empujarte por encima.
6) Patrones comunes de hinchazón que empujan las páginas por encima del límite
Los frameworks modernos pueden inflar el HTML de maneras que los equipos no notan durante el desarrollo normal. Un patrón de alto riesgo son las grandes JSON en línea o cargas serializadas de “estado” (para hidratación) incrustadas directamente en el HTML. Estos blobs pueden ser enormes y a menudo aparecen antes o alrededor del contenido principal, consumiendo rápidamente los bytes rastreables.
Otras fuentes de bloat incluyen imágenes en base64 embebidas, CSS/JS en línea y sistemas de navegación/filtros excesivamente grandes que generan miles de enlaces u opciones. Incluso cuando estos son “útiles”, pueden desplazar lo que más quieres que Google indexe: texto único, descripciones de producto, contenido editorial y un enlazado interno limpio que facilite el descubrimiento.
Los auditores también deben vigilar los patrones de duplicación: bloques JSON-LD repetidos, marcado de componentes repetido en listas renderizadas en servidor, o DOM oculto masivo (pestañas/acordeones) generado para cada variante. Estos no solo ralentizan las páginas, pueden literalmente empujar señales indexables más allá de lo que Googlebot (Search) recupera.
7) Cómo medir correctamente y evitar confusiones documentales
Puesto que la documentación de Google tiene múltiples afirmaciones en circulación, los auditores deben notar una instantánea documental contradictoria/legada: algunas versiones de la documentación “¿Qué es Googlebot?” aún mencionan un límite de 15 MB para HTML/texto. Mientras tanto, la sección más nueva “Googlebot para Search” enfatiza el tope de 2 MB para tipos de archivo compatibles (y 64 MB para PDFs). Al auditar, confirma que estás leyendo la documentación más reciente y específica relevante para la indexación en Search.
En cuanto a mediciones, valida el tamaño descomprimido. En una prueba controlada, obtén el HTML bruto, descomprímelo si es necesario y mide los bytes. Para tu flujo de trabajo de auditoría, almacena el primer segmento de 2 MB y compara lo que queda después, luego comprueba específicamente si elementos importantes (texto principal, enlaces primarios, JSON-LD) se encuentran más allá de ese límite.
Finalmente, trata las herramientas de Search Console con cuidado. Los hallazgos de Spotibo implican que la “prueba en vivo” de Inspección de URL puede mostrar contenido que no coincide con lo que finalmente se indexó cuando Googlebot (Search) aplica el corte de 2 MB. Usa Inspección para diagnóstico, pero confirma la realidad de la indexación comprobando el comportamiento de la fuente en caché/indexada cuando esté disponible, y asegurando que tus plantillas son seguras incluso bajo la restricción más estricta de 2 MB.
Auditar por el límite de 2 MB de Googlebot trata menos de perseguir un número arbitrario y más de preservar la porción de tus páginas que realmente llega a la indexación. La guía oficial de Google indica que después del corte, Googlebot deja de recuperar y solo remite lo que ya descargó, por lo que cualquier cosa más allá del límite puede ser invisible para Search.
El enfoque más resiliente es mantener el HTML ligero, colocar el contenido crítico y los datos estructurados al principio, y configurar alertas automatizadas cuando archivos clave se aproximen a ~1,8, 2,0 MB descomprimidos. Dadas las pruebas recientes que muestran truncamiento silencioso y comportamiento distinto entre herramientas “en vivo” y la realidad indexada, la auditoría proactiva de tamaños es ahora una necesidad práctica para el SEO técnico.
