Trampas de rastreo: cómo detectarlas antes de que crezcan

Una trampa de rastreo es un patrón del propio sitio que genera URLs nuevas sin un límite claro: un buscador interno que crea una dirección por cada consulta, un calendario que ofrece una página para cada día del futuro, un enlace relativo que se repite sobre sí mismo. Ninguna de esas URLs falla. Todas responden 200 y muestran contenido real, aunque sea contenido duplicado o vacío de valor. Por eso una trampa de rastreo no aparece en el informe de errores: el rastreador no se queja, simplemente sigue encontrando URLs nuevas y dedicando tiempo a ellas en lugar de a las páginas que sí importan.

Este artículo cubre cinco familias de trampas que rara vez se identifican como tales porque no dan ningún error: buscadores internos, calendarios y archivos por fecha, parámetros de sesión y de seguimiento, "cargar más" con scroll infinito, y bucles de URL relativas. Queda fuera la navegación por facetas de las tiendas online -filtros de talla, color o precio-, que por su tamaño y su complejidad merece su propio tratamiento aparte. También verás cómo confirmar cada una con las herramientas que ya tienes en Search Console, sin necesidad de tocar los logs del servidor.

Qué diferencia a una trampa de rastreo de un error de rastreo

El informe de errores de rastreo —que hoy forma parte del informe de indexación de páginas de Search Console— señala URLs que Google no pudo procesar: un 404, un 500, una redirección que no llega a ningún sitio, un soft 404 disfrazado de página válida. Todo eso interrumpe al rastreador de forma visible, y por eso tiene su propio diagnóstico. Una trampa de rastreo es el problema contrario: cada URL individual funciona perfectamente. Devuelve 200, carga el HTML, muestra contenido. El problema no está en ninguna URL suelta, está en la combinación: el patrón que las genera no tiene un final natural.

Googlebot reparte un número de peticiones limitado por sitio en cada periodo. No es un límite fijo ni público, pero sí es real: cuando la mayoría de esas peticiones se va en rastrear variaciones casi idénticas de la misma página -mismo contenido, distinto parámetro o distinta fecha-, quedan menos para descubrir páginas nuevas o para volver a rastrear las que ya posicionan y necesitan una actualización. El coste no se ve en ningún informe de errores porque no hay error que reportar; se ve en la lentitud con la que Google encuentra o refresca el contenido que sí te importa.

La señal para distinguir una trampa no es un código de estado, es un volumen: cuando el número de URLs únicas que Google dice conocer crece mucho más rápido que el número de páginas que realmente publicas, casi siempre hay un patrón generándolas solo.

Buscadores internos: resultados que se indexan a sí mismos

Un buscador interno crea una URL nueva por cada consulta que alguien escribe: /buscar?q=zapatos, /buscar?q=zapatos+azules, /buscar?q=zapatos+azules+38. Si el sitio no lo impide, esas direcciones son rastreables y, en cuanto quedan enlazadas -por ejemplo, en un widget de "búsquedas relacionadas" o al paginar los propios resultados-, también son descubribles sin que nadie las haya creado a propósito. El resultado son miles de páginas casi idénticas entre sí, muchas con el mismo mensaje de "no se encontraron resultados" repetido palabra por palabra.

La forma más limpia de cerrar esta trampa es impedir que Googlebot llegue a pedir esas URLs, no solo que las indexe. Un noindex en la página de resultados obliga al rastreador a solicitar igualmente cada una para leer la etiqueta, así que el gasto de rastreo ya se produjo. Bloquear el patrón de parámetro en robots.txt evita la petición desde el principio. Si el buscador interno también genera enlaces internos hacia esas URLs -paginación de resultados, "compartir esta búsqueda"-, revisar que esos enlaces no sean rastreables es tan importante como el bloqueo mismo.

Calendarios y archivos por fecha: una URL para cada día que existirá

Los calendarios de eventos y los archivos por fecha de un blog suelen tener un botón "mes siguiente" que existe siempre, sin comprobar si hay algo que mostrar en ese mes. El rastreador lo sigue igual que seguiría cualquier otro enlace, y como cada mes siguiente enlaza al mes que le sigue a él, la cadena no tiene un final natural: técnicamente hay una URL válida para marzo de 2031 aunque el sitio lleve años sin publicar nada. Cada una de esas páginas devuelve 200 y muestra una plantilla de calendario vacía, indistinguible en la práctica de las demás.

El arreglo no es eliminar el calendario, es darle un límite. Si no hay eventos programados más allá de una fecha razonable -normalmente unos meses vista-, el enlace "siguiente" simplemente no debería renderizarse, o debería llevar el atributo que impide seguirlo. Los archivos por fecha de un blog se benefician del mismo principio: enlazar meses o años sin contenido publicado no ayuda a nadie a encontrar nada, y sí le da a Googlebot un motivo para seguir pidiendo páginas vacías en lugar de volver a las que ya tienen artículos.

Parámetros de sesión y de seguimiento: la misma página con mil disfraces

Un identificador de sesión en la URL -jsessionid, PHPSESSID- no es lo mismo que un parámetro de campaña -utm_source, gclid-, pero para un rastreador el efecto es parecido: la misma página aparece bajo una dirección distinta cada vez. La diferencia importante es que una sesión rota constantemente. Si el sitio guarda el identificador de sesión en la URL en lugar de en una cookie, y ese identificador se propaga a los enlaces internos, cada rastreo -incluido el que hace el propio Googlebot- genera automáticamente un lote nuevo de URLs "nuevas" sin que se haya publicado ni cambiado nada. Es la única familia de esta lista que se regenera sola, sin que nadie edite el sitio.

Esto se cierra en el origen, no después: el estado de sesión debería vivir en una cookie, nunca en la URL. Para los parámetros de campaña que sí necesitas -llegan desde anuncios o desde otros sitios y no puedes controlarlos en origen-, una etiqueta canonical hacia la versión limpia de la URL le dice a Google qué dirección consolidar, aunque siga habiendo que gastar una petición en descubrirla. Es el mismo mecanismo que trata en detalle la guía de parámetros de URL en SEO; la diferencia aquí es que el síntoma no es "contenido duplicado", es un conteo de URLs que no deja de crecer.

"Cargar más" y scroll infinito: la paginación que nunca cierra

"Cargar más" suele funcionar pidiendo la siguiente tanda de resultados a una URL con un número de página o un offset que aumenta: /productos?pagina=2, /productos?pagina=3. Si esa URL responde 200 con una plantilla vacía en vez de devolver un estado claro de "no hay más" cuando se pasa del final real del catálogo, no hay nada que le diga al rastreador dónde parar. Un catálogo de 40 productos con 20 por página tiene 2 páginas reales; si /productos?pagina=500 también devuelve 200, Googlebot no tiene forma de saber, solo desde la respuesta, que esa página no debería existir.

Esta familia se diferencia de la paginación bien implementada -con un límite real, enlazada de forma que el rastreador pueda descubrir cada página y llegar a la última- en que aquí el sistema no comprueba el final. La solución no es eliminar el "cargar más", es que el endpoint que sirve cada tanda se comporte como lo que es: si se pide una página que no existe, debe devolver un estado vacío claro o un código que lo indique, no una plantilla en blanco con código 200. Si ese endpoint es solo para uso interno de la interfaz y no está pensado para que nadie lo visite como página, bloquearlo directamente en robots.txt evita el problema de raíz.

Bucles de URL relativas: profundidad que no debería existir

Un bucle de URL relativas aparece cuando un enlace interno usa una ruta relativa -"carrito/", sin barra inicial- en una página cuya propia dirección ya termina en una carpeta. El navegador y el rastreador resuelven esa ruta relativa sobre la URL actual, así que si la página /tienda/zapatos/ enlaza a "carrito/" de forma relativa, el destino no es /carrito/, es /tienda/zapatos/carrito/. Si esa página nueva contiene el mismo enlace relativo, el siguiente destino es /tienda/zapatos/carrito/carrito/, y así sucesivamente sin límite. No es un error de configuración exótico: basta con un componente de menú o de migas de pan que no use rutas absolutas.

Se detecta por la forma de la URL, no por su respuesta: todas devuelven 200, así que hay que mirar la propia dirección. Una muestra de URLs descubiertas por Google con segmentos repetidos -"/carrito/carrito/carrito/"- o con una longitud fuera de lo normal para el sitio es la señal. El arreglo está en el código, no en el rastreo: cualquier enlace generado por un componente compartido -menú, migas de pan, filtros- debería usar rutas absolutas o rutas relativas a la raíz, empezando por "/", nunca relativas a la carpeta actual. Mientras se corrige, bloquear en robots.txt cualquier ruta que contenga el mismo segmento repetido dos veces contiene el problema sin esperar al despliegue.

Cómo confirmarlo en Search Console sin tocar los logs del servidor

No hace falta abrir los logs del servidor para confirmar una trampa de rastreo; Search Console ya tiene las tres señales necesarias, aunque estén repartidas en dos informes distintos.

El informe de estadísticas de rastreo, dentro de Configuración, desglosa las peticiones por código de respuesta, por finalidad y por tipo de archivo. Una trampa se ve ahí como una concentración anormal de respuestas 200 combinada con una finalidad mayoritariamente de "descubrimiento" en lugar de "actualización": significa que Google sigue encontrando URLs que no conocía, semana tras semana, en vez de revisar las que ya tiene. Si el desglose por tipo de archivo muestra que casi todo lo rastreado es HTML y el volumen no deja de subir mientras el sitio no publica nada nuevo, el patrón encaja.

El informe de indexación de páginas aporta un segundo indicador: el grupo "Descubierta: actualmente sin indexar". Son URLs que Google conoce -las encontró enlazadas o en un sitemap- pero que ha decidido no rastrear todavía, normalmente porque el patrón le resulta de bajo valor. Un crecimiento sostenido de este grupo, sin que corresponda a contenido real que estés publicando, es casi siempre una trampa generando direcciones más rápido de lo que Google está dispuesto a procesarlas.

El tercer contraste es más simple: cuántas URLs declaras en tu sitemap frente a cuántas aparecen como rastreadas o descubiertas fuera de él. Si el sitemap declara, por ejemplo, 800 URLs -tu catálogo real- y el informe de indexación muestra varios miles de URLs adicionales fuera del sitemap, esa diferencia no ha salido de ningún sitio: alguna combinación de enlaces internos la está generando sola. Cruzar estos tres datos -respuestas, finalidad de rastreo y el hueco entre sitemap y URLs descubiertas- suele bastar para saber qué familia de trampa tienes antes de mirar una sola URL individual.