Parámetros de URL en SEO: impacto en rastreo e indexación

Un parámetro de URL es todo lo que aparece después del signo de interrogación: en tienda.com/zapatos?color=rojo, el parámetro es color=rojo. Para un rastreador, la pregunta que importa no es si la URL «se ve distinta», sino si esa URL sirve contenido distinto. Esa distinción — y no la cantidad de parámetros que tenga tu sitio — es lo que decide si Google los trata como páginas nuevas que hay que rastrear e indexar, o como variantes de una misma página que puede ignorar con seguridad.

El problema aparece cuando un sitio genera parámetros sin ningún control: cada combinación de filtro, cada reordenación, cada enlace compartido con una etiqueta de campaña crea una URL técnicamente única. Un catálogo con veinte productos puede terminar exponiendo miles de URLs distintas sin haber añadido una sola página de contenido real. Esta guía separa qué parámetros importan de cuáles no, qué herramientas existen para controlarlos — con sus límites reales — y cómo comprobar qué es lo que Google ya tiene indexado de tu dominio.

De dónde salen los parámetros: los seis orígenes habituales

Casi ningún parámetro aparece por accidente; cada uno lo añade una pieza distinta del sitio, y eso ayuda a saber por dónde empezar a auditar.

Cada uno de estos orígenes se comporta de forma distinta de cara al rastreo, así que agruparlos todos bajo la etiqueta genérica de «parámetros» es precisamente el error que hace perder presupuesto de rastreo.

• Filtros de catálogo — color=rojo, talla=m, marca=nike en una tienda o un directorio.
• Ordenación — orden=precio_asc, sort=relevancia, que cambia el orden pero no el conjunto de resultados.
• Paginación — page=2, p=3, que reparte un mismo listado en varias URLs.
• Identificadores de sesión — sessionid=8f3a..., generados por el propio servidor para seguir a un visitante sin depender de cookies.
• Parámetros de seguimiento — utm_source=newsletter, ref=instagram, añadidos por herramientas de analítica o campañas.
• Búsqueda interna — q=zapatillas+running, que genera una URL distinta por cada término que alguien escribe en el buscador del sitio.

La distinción que decide todo: ¿cambia el contenido o no?

Divide cualquier parámetro que encuentres en tu sitio en una de estas dos categorías, porque el tratamiento correcto es opuesto en cada caso.

Los parámetros que cambian el contenido devuelven un conjunto de resultados distinto. color=rojo en una categoría de zapatillas muestra productos que no aparecen sin el filtro: es contenido nuevo, aunque el HTML alrededor sea el mismo. Estos parámetros pueden merecer indexación propia si representan una intención de búsqueda real — «zapatillas rojas» se busca; «zapatillas ordenadas de forma ascendente» no.

Los parámetros que no cambian el contenido devuelven exactamente los mismos elementos, solo presentados o rastreados de otra forma: sort=precio_asc reordena los mismos productos, sessionid=... no altera ni un carácter del contenido visible, y la mayoría de los utm_* solo sirven para que una herramienta de analítica sepa de dónde vino el clic. Estos son los que conviene consolidar en una sola URL indexable, y nunca dejarlos generar una página propia.

La prueba rápida es quitar el parámetro y comparar. Si el contenido principal de la página — el listado, el artículo, el producto — es idéntico con o sin él, no cambia el contenido y no necesita su propia URL indexable. Si es distinto, sí lo cambia y merece que lo trates con cuidado en lugar de bloquearlo por reflejo.

Por qué se multiplican las URLs y qué le cuesta eso al rastreo

Un rastreador no visita tu sitio con presupuesto ilimitado: reparte un número finito de peticiones entre todas las URLs que conoce, y ese número depende de la autoridad y el tamaño del sitio, no de cuánto contenido nuevo tengas. Cuando la combinación de filtros, orden y paginación es libre — es decir, cualquier parámetro se puede combinar con cualquier otro — el número de URLs posibles crece de forma multiplicativa, no aditiva. Tres filtros con cuatro valores cada uno, combinables entre sí y con dos formas de orden, ya generan más de cien URLs distintas para lo que sigue siendo el mismo catálogo de productos.

El coste no es solo teórico. Cada una de esas URLs que el rastreador visita en lugar de una página nueva o actualizada es una petición que no se dedica a encontrar contenido que sí importa. En sitios grandes esto se nota como páginas nuevas que tardan semanas en aparecer en el índice, o contenido actualizado que Google sigue mostrando en su versión antigua porque no ha vuelto a rastrear esa URL concreta. El síntoma casi siempre se confunde con «Google no valora mi contenido», cuando el problema real es que el rastreador está ocupado en variantes de una misma página.

Las herramientas para controlarlos — y lo que cada una no resuelve

Existen cuatro mecanismos distintos para manejar parámetros, y se usan mal casi siempre porque se tratan como intercambiables. No lo son: cada uno actúa en un momento distinto del proceso y tiene un coste que conviene conocer antes de aplicarlo.

En la práctica casi ningún sitio necesita elegir solo uno. Lo habitual es combinar los cuatro con un rol distinto cada uno: enlazado interno que solo apunta a la URL limpia, canonical como red de seguridad en las páginas con parámetro para cuando algo externo enlaza a ellas, y disallow reservado para los patrones que generan verdadero ruido — sesiones, búsqueda interna, tracking — donde no hay ningún escenario en que interese que esa URL se indexe.

• Etiqueta canonical — le dice a Google cuál es la versión preferida de un grupo de URLs equivalentes. Es una señal, no una orden: Google la respeta en la mayoría de los casos, pero puede ignorarla si el contenido difiere más de lo que sugiere el propio canonical. No impide que el rastreador visite la URL con parámetro; solo evita que la indexe como página separada.
• Disallow en robots.txt — impide que el rastreador solicite las URLs que coincidan con el patrón bloqueado. Es la única de las cuatro que ahorra presupuesto de rastreo de verdad, porque la petición nunca llega a hacerse. El coste: una URL bloqueada por robots.txt puede seguir apareciendo en resultados de búsqueda, sin descripción y solo como enlace, si otra página la enlaza, porque bloquear el rastreo no es lo mismo que bloquear la indexación.
• Noindex — permite el rastreo pero pide que esa URL concreta no entre en el índice. Resuelve exactamente el problema que el disallow deja abierto, a costa de que el rastreador sigue gastando peticiones en visitarla para leer la propia etiqueta.
• Enlazado interno consistente hacia la URL limpia — la medida más barata y la más ignorada: si ningún enlace interno del propio sitio apunta nunca a la versión con parámetros, gran parte del problema desaparece antes de necesitar canonical, disallow ni noindex, porque el rastreador prioriza las URLs que encuentra enlazadas con más frecuencia.

La herramienta de parámetros de Google ya no existe

Durante años, Search Console tuvo una función llamada «Parámetros de URL» donde se le indicaba manualmente a Google qué hacía cada parámetro: si cambiaba el contenido, si solo afectaba al orden, si podía ignorarlo por completo. Google la retiró y dejó de estar disponible para cualquier sitio. Cualquier artículo, curso o lista de comprobación que todavía diga «configura tus parámetros en la herramienta de Search Console» describe un producto que ya no existe.

La razón que dio Google al retirarla fue que sus sistemas automáticos ya identifican el comportamiento de los parámetros con precisión suficiente sin necesitar la configuración manual del sitio. Eso no elimina el problema — Google sigue gastando presupuesto de rastreo en URLs redundantes si tú no lo evitas — solo elimina esa vía concreta para reportarlo. El control pasó a depender por completo de las señales que sí siguen vigentes: canonical, robots.txt, noindex y la estructura de enlazado interno descritas arriba.

UTM y parámetros de seguimiento: nunca la forma enlazada

Los parámetros utm_source, utm_medium, utm_campaign y similares existen para que una herramienta de analítica sepa de dónde vino una visita: de un boletín, de un anuncio, de una publicación en redes. Cumplen su función en el instante en que alguien hace clic en ese enlace concreto desde fuera del sitio. No cumplen ninguna función una vez que esa persona ya está navegando dentro de tu web.

El error habitual es que esos mismos parámetros terminan filtrándose al enlazado interno: un menú, un banner o un botón de «producto relacionado» que copia la URL tal como aparece en la barra de direcciones — con el UTM todavía puesto — en lugar de enlazar a la URL limpia. El resultado es que el propio sitio genera y refuerza duplicados de sus páginas más enlazadas, justo las que más interesa mantener consolidadas en una sola URL indexable.

• Los enlaces internos — menú, breadcrumbs, enlaces de un artículo a otro, botones de llamada a la acción — deben apuntar siempre a la URL sin parámetros de seguimiento, nunca a la que trajo al usuario.
• Los enlaces de campaña con UTM son legítimos solo en canales externos — un correo, un anuncio, una biografía de red social — donde el parámetro nunca se convierte en un enlace que otra página del sitio pueda copiar.
• Si una plataforma de analítica exige el parámetro para atribuir la visita, resuélvelo en ese punto de entrada y no dejes que se propague al resto de la navegación.

IDs de sesión en la URL: el peor caso posible

De todos los parámetros, el identificador de sesión es el que más daño hace y el más fácil de evitar. Un sessionid (o PHPSESSID, jsessionid, según la plataforma) cambia en cada visita, a veces en cada petición, sin que el contenido de la página cambie ni un carácter. Eso significa que la misma página de producto puede generar un número prácticamente infinito de URLs únicas: una por cada visitante que llega sin cookie previa, incluido cada rastreador.

Un rastreador que sigue enlaces con sessionid puede terminar tratando cada visita a tu sitio como un recorrido por páginas «nuevas», porque desde su perspectiva la URL nunca se repite. Esto no solo desperdicia presupuesto de rastreo: en el peor de los casos filtra sesiones activas de usuarios reales a resultados de búsqueda o a páginas enlazadas externamente, lo cual es también un problema de seguridad y no solo de SEO. La solución no es ningún tag ni directiva: es dejar de depender de la URL para mantener la sesión y usar cookies o almacenamiento del lado del cliente, de forma que el identificador nunca llegue a formar parte del enlace.

Cómo auditar lo que Google ya tiene indexado

Antes de aplicar cualquiera de las medidas anteriores conviene saber qué tan extendido está ya el problema, y hay tres formas de comprobarlo sin herramientas de pago.

Si el operador site: devuelve un número alto de resultados con el mismo parámetro repetido en cientos de URLs distintas, esa es la señal más clara de que el rastreo se está gastando en duplicados en lugar de en contenido nuevo, y de que toca aplicar la combinación de enlazado interno, canonical y disallow descrita antes — no una sola de las tres por separado.

• Operador site: combinado con un parámetro conocido — buscar site:tudominio.com inurl:sessionid o site:tudominio.com inurl:sort= muestra si Google ya indexó variantes con ese parámetro concreto.
• Informe de indexación de páginas en Search Console — la sección de páginas indexadas permite inspeccionar URLs individuales y ver si una versión con parámetro fue indexada, excluida por duplicado o descartada por el propio canonical.
• Registros de servidor (log files) — revisar qué URLs solicita Googlebot con más frecuencia expone patrones de parámetros que el sitio genera pero que nadie audita a simple vista, porque no aparecen enlazados desde ninguna parte visible del sitio.