¿Qué es el index bloat?

Se llama index bloat a la situación en la que Google tiene indexadas muchas más URLs de un sitio de las que ese sitio necesita. No es un error concreto que se pueda señalar en una página, sino un desequilibrio: el índice se llena de direcciones que no aportan nada y el contenido que sí importa queda diluido entre ellas.

La cifra por sí sola no dice nada. Un periódico con doscientas mil URLs indexadas está bien; una tienda de trescientos productos con veinte mil, no. Lo que cuenta no es cuántas hay, sino qué proporción de ellas alguien busca alguna vez.

Y conviene desmontar de entrada la idea contraria, que sigue circulando: tener más páginas indexadas no mejora nada por sí mismo. Google no reparte visibilidad por volumen, y una URL indexada que nadie visita no es un activo, es un gasto de rastreo.

El nombre viene del inglés y describe bien lo que ocurre: algo que se hincha sin ganar sustancia. No hay un umbral a partir del cual empieza, ni un aviso en ninguna herramienta; se reconoce comparando dos cifras que casi nadie mira juntas, la de páginas que uno cree tener y la de URLs que Google dice tener.

Conviene además separarlo de un problema vecino con el que se confunde. Que una página esté indexada y no reciba visitas puede ser normal: hay contenido estacional, páginas legales, fichas de productos raros. El index bloat no es eso, es el caso en el que esas URLs se cuentan por miles y ninguna estaba prevista.

Casi nunca las ha creado nadie a propósito. Aparecen solas, generadas por el sistema que monta el sitio, y por eso crecen sin que nadie lo note hasta que el informe de cobertura enseña una cifra que no cuadra.

La fuente más abundante son las variantes: cada filtro, cada orden y cada parámetro GET producen una dirección nueva con el mismo contenido detrás. Después vienen las páginas de contenido pobre vacías por diseño, y por último los restos de migraciones y de páginas de campaña que nadie retiró.

Merece la pena mirarlo como reparto y no como total, porque la proporción entre esas partes es lo que decide si hay un problema. Dos sitios con la misma cifra pueden estar en situaciones opuestas según de qué esté hecha.

Hay un quinto origen que merece nombre propio porque se genera a una velocidad que sorprende: la navegación por facetas. Cuando marca, talla, color y precio se pueden combinar libremente y cada combinación tiene URL, el número de direcciones posibles crece de forma multiplicativa. Un catálogo modesto produce así cientos de miles de URLs sin un solo producto nuevo.

Y una fuente silenciosa que casi nadie revisa: las páginas de resultados de la búsqueda interna. Basta con que alguien enlace una búsqueda para que el rastreador la descubra, y a partir de ahí cada consulta distinta es una URL más, casi siempre con un soft 404 detrás cuando no hay resultados.

El coste más directo es de rastreo. Cada URL indexada se vuelve a pedir cada cierto tiempo, así que miles de variantes consumen presupuesto de rastreo que no llega a las páginas que se actualizan y deberían revisarse a menudo.

El segundo es de señales. Cuando cinco direcciones muestran lo mismo, los enlaces y la atención se reparten entre ellas en vez de sumarse en una, que es exactamente el problema que resuelve un canonical bien puesto. El resultado se parece al del contenido duplicado, porque en el fondo es el mismo.

Y el tercero es de diagnóstico, el más subestimado: un informe de cobertura lleno de URLs irrelevantes deja de servir para detectar problemas reales. Cuando aparece un fallo de verdad, queda enterrado entre miles de líneas que nadie mira.

Hay un cuarto coste que se paga fuera del SEO: el de la sala de máquinas. Cada petición del rastreador a una de esas URLs es una consulta a la base de datos y una página generada, y en un catálogo con facetas eso puede ser una parte notable de la carga del servidor. El TTFB que miden los visitantes empeora por peticiones que no son de visitantes.

Y uno más, difícil de medir pero real: el ruido en los informes de analítica web. Cuando miles de URLs sin valor reciben algo de tráfico residual, las medias de todo el sitio se desplazan, y decisiones tomadas sobre esas medias apuntan al sitio equivocado.

La medida de partida es sencilla: compara el número de URLs indexadas que informa Search Console con el número de páginas que de verdad quieres que existan. Si la primera cifra dobla a la segunda, hay algo que revisar; si la multiplica por diez, el problema está a la vista.

Después hay que agrupar por patrón antes de decidir nada. Veinte mil URLs sobrantes casi nunca son veinte mil casos: suelen ser tres o cuatro reglas mal puestas, y corregirlas resuelve el listado completo mientras revisar página por página no termina nunca.

Para reducirlo hay tres herramientas y conviene no confundirlas. El canonical agrupa variantes del mismo contenido; el noindex saca del índice lo que debe seguir existiendo para el usuario; y el robots.txt impide el rastreo, que no es lo mismo que desindexar. Elegir la equivocada deja el problema donde estaba.

Una precisión sobre la cifra de partida: el informe de cobertura separa lo indexado de lo excluido, y ambas listas dicen cosas distintas. Un montón de URLs excluidas no es un problema en sí mismo —muchas veces es el sistema funcionando—, pero conviene mirar por qué motivo se excluyen. «Rastreada, actualmente sin indexar» aplicada a miles de direcciones es una señal clara de que se está generando algo que no debería existir.

Y una recomendación sobre el orden: antes de tocar reglas, comprueba en el enlazado interno si esas URLs están enlazadas desde el propio sitio. Si lo están, el arreglo empieza ahí, porque una regla que desindexa algo a lo que se sigue enlazando desde cientos de páginas es un parche sobre una estructura que sigue produciendo el problema.

El primero es el clásico de esta familia: bloquear en el robots.txt lo que se quiere sacar del índice. El bloqueo impide leer la instrucción, así que la URL puede seguir apareciendo. Para desindexar hay que dejar rastrear.

El segundo es borrar por lote. Muchas de esas URLs sobrantes son útiles para el visitante aunque no deban estar en el índice: un filtro por talla, una ordenación por precio. Se sacan del índice, no del sitio; eliminarlas rompe la navegación y genera errores 404 a cambio de nada.

Y el tercero es esperar resultados inmediatos. La desindexación ocurre cuando el buscador vuelve a pasar por cada URL, y en direcciones poco visitadas eso lleva semanas. Una cifra que no baja el jueves siguiente no significa que la corrección haya fallado.

Un cuarto error es tratar la cifra como el objetivo. Bajar de veinte mil URLs indexadas a dos mil no sirve de nada si en el recorte se fueron fichas que vendían. Antes de aplicar una regla por lote conviene comprobar en Search Console si ese patrón recibe clics; unas pocas comprobaciones a mano evitan retirar del índice justo lo que funcionaba.

Y el último, el más caro a largo plazo: limpiar sin cerrar el grifo. Si el sistema sigue generando una URL por combinación de filtros, el índice se vuelve a llenar en unos meses y el trabajo hay que repetirlo. La corrección duradera está en decidir qué URLs deben existir, no en desindexar las que ya existen.