Crawl traps y espacios infinitos: cómo detectarlos y solucionarlos

Un crawl trap (trampa de rastreo) es un patrón de enlazado que genera, técnicamente, un número ilimitado o casi ilimitado de URLs distintas a partir de un espacio de contenido finito. La diferencia con el desperdicio de crawl budget genérico (parámetros sueltos, filtros combinados) es de escala y de forma: un crawl trap no solo desperdicia presupuesto, sino que puede atrapar a un rastreador en un bucle que, en la práctica, no tiene fin, generando decenas de miles de URLs nuevas por cada URL real que existía. Esta guía detalla los patrones más habituales, cómo detectarlos antes de que un rastreador se quede atascado horas en uno, y cómo cerrarlos de forma definitiva según el patrón concreto.

Calendarios y selectores de fecha sin límite

El patrón más clásico: un widget de calendario o un selector de fecha que genera un enlace "mes siguiente" con una URL propia (/eventos/2032/03/, /eventos/2032/04/...) sin ningún límite superior de fecha. Un rastreador que sigue esos enlaces de forma sistemática puede avanzar mes a mes indefinidamente, porque cada página de calendario, aunque no tenga ningún evento real, sigue generando un enlace "siguiente" válido hacia la que toca. Sin darse cuenta, el sitio ha creado un espacio de URLs que crece sin límite práctico, y cada una de esas URLs vacías compite por el mismo crawl budget que las páginas con contenido real.

Navegación facetada: la explosión combinatoria

En un catálogo con filtros (color, talla, precio, marca), cada combinación de filtros activados genera técnicamente una URL distinta si los filtros se reflejan en la URL mediante parámetros o segmentos de ruta. El problema no es lineal sino combinatorio: con solo 5 filtros de 4 valores cada uno, el número de combinaciones posibles ronda las 1.024, y con 8 filtros de 5 valores supera las 390.000 combinaciones, casi todas sin usuarios reales detrás y con el mismo contenido (o casi) que otra combinación distinta. Un rastreador sin límites descubre esas combinaciones siguiendo enlaces de filtro sobre filtro sobre filtro, generando un espacio de URLs que en la práctica es infinito aunque el catálogo real tenga solo unos cientos de productos.

/zapatillas?color=azul
/zapatillas?color=azul&talla=42
/zapatillas?color=azul&talla=42&marca=x
/zapatillas?color=azul&talla=42&marca=x&precio=50-100
/zapatillas?color=azul&talla=42&marca=x&precio=50-100&ordenar=precio
... cada filtro adicional multiplica, no suma, las URLs posibles

Parámetros de sesión incrustados en la URL

Algunos sistemas (sobre todo aplicaciones antiguas sin cookies bien configuradas) incrustan un identificador de sesión único directamente en la URL en vez de en una cookie: /producto/silla?PHPSESSID=a3f9c8e1b2. Cada visita, incluida cada visita de un rastreador, genera un identificador de sesión distinto, así que técnicamente cada URL con sessionid es única aunque el contenido sea exactamente el mismo. Si el rastreador sigue enlaces internos que arrastran ese parámetro (algo habitual si el propio motor de plantillas del sitio propaga el parámetro de sesión en todos los enlaces generados), cada nueva página visitada genera enlaces con un sessionid todavía distinto, multiplicando URLs sin límite real.

Paginación infinita mal implementada

Una paginación de resultados sin un límite superior claro, combinada con parámetros de orden u ordenación (?pagina=847&orden=precio_desc), puede generar páginas de resultados vacías indefinidamente si el sistema no devuelve un 404 o un estado equivalente al superar el número real de resultados, sino que sigue sirviendo un 200 con una página en blanco y, peor aún, sigue enlazando a una página "siguiente" todavía más alta. La combinación de paginación sin techo real y ordenaciones múltiples multiplica el problema: cada criterio de orden genera su propia secuencia infinita de páginas.

El bug de enlaces relativos que anida rutas sin fin

Un patrón menos conocido pero devastador cuando aparece: un enlace mal construido con una ruta relativa en vez de absoluta, en una plantilla que se repite en todas las páginas. Si una página en /catalogo/sillas/ tiene un enlace mal escrito como href="sillas/" (relativo) en vez de href="/catalogo/sillas/" (absoluto), el navegador y el rastreador lo resuelven concatenando con la ruta actual, generando /catalogo/sillas/sillas/. Si esa página resultante contiene la misma plantilla con el mismo enlace mal construido, el patrón se repite indefinidamente: /catalogo/sillas/sillas/sillas/sillas/.... Cada nivel adicional es una URL técnicamente nueva y, si el servidor no devuelve un error ante rutas anómalamente profundas, el rastreador puede seguir generándolas durante miles de niveles antes de que algo lo detenga.

Cómo detectar estos patrones con un rastreador

La señal más fiable no es una sola herramienta sino un patrón en los datos del rastreo: un volumen de URLs descubiertas que crece muy por encima de lo que el contenido real del sitio podría justificar, o una profundidad de ruta (número de segmentos separados por /) que sigue aumentando sin estabilizarse a medida que avanza el rastreo. En Screaming Frog y herramientas equivalentes, ordenar el informe por profundidad de URL (URL depth) y observar si las URLs más profundas siguen el patrón de una carpeta repetida es el diagnóstico más rápido. Una extracción personalizada (custom extraction, vía XPath o expresión regular) centrada en localizar enlaces que apunten al mismo segmento de ruta que la página actual permite detectar el bug de enlaces relativos incluso antes de que el rastreo se dispare a miles de URLs, deteniendo el rastreo de prueba manualmente si el volumen empieza a crecer sin control.

Señal de alarma típica en un rastreo:
Nivel 1: 40 URLs
Nivel 2: 180 URLs
Nivel 3: 1.200 URLs
Nivel 4: 9.800 URLs
Nivel 5: 78.000 URLs (y subiendo)

Un sitio con un catálogo real de unos cientos de productos
no debería generar este crecimiento exponencial por nivel.

Soluciones concretas por patrón

Cada patrón necesita un arreglo distinto y aplicar el genérico equivocado no lo resuelve. Para calendarios infinitos: limitar de raíz el rango de fechas navegable (por ejemplo, no generar enlaces "mes siguiente" más allá de 12-18 meses vista) y añadir noindex a los meses sin eventos reales. Para navegación facetada: definir en Search Console qué parámetros no deben rastrearse, aplicar rel="canonical" desde cada combinación de filtros hacia la vista sin filtrar (o hacia la combinación más relevante), y bloquear en robots.txt los patrones de parámetro que generan más ruido. Para sessionid en la URL: la única solución robusta es dejar de propagar la sesión por URL y usar cookies, corrigiendo el problema en origen en vez de intentar canonicalizar cada variante. Para paginación sin techo: devolver un 404 real más allá del último resultado existente y dejar de enlazar una página "siguiente" cuando no existe contenido posterior. Para el bug de enlaces relativos: es un fallo de código, no de configuración de SEO, así que la corrección va en la plantilla (usar siempre rutas absolutas en los enlaces internos), y mientras se corrige, bloquear en robots.txt cualquier ruta que contenga una carpeta repetida consecutiva mediante un patrón de expresión regular soportado por el servidor.

Preguntas frecuentes