Cuenta cada salto de la cadena de redirecciones hasta tu página

¿Qué es una cadena de redirecciones?

Dos o más respuestas HTTP 3xx interpuestas entre el enlace que toca un lector y la página que acaba renderizando forman una cadena de redirecciones, y cada salto cuesta una consulta DNS, una conexión TCP y un handshake TLS antes de que llegue un solo byte de tu página.

Una redirección suelta no es una cadena. Que http://example.com/sale responda 301 con Location: https://example.com/sale es un único salto, y ese es el precio de servir HTTPS. La cadena aparece cuando el acortador redirige al rastreador de clics, este redirige a la versión www, la versión www redirige a la versión con barra final y esa última por fin sirve HTML. Cuatro saltos, una página.

RFC 9110 define la clase 3xx y enumera los códigos que llevan una cabecera Location: 301 Moved Permanently, 302 Found, 303 See Other, 307 Temporary Redirect y 308 Permanent Redirect. La especificación pide a los clientes "detect and intervene in cyclical redirections" pero no fija ningún máximo, y añade una nota que recuerda que una versión anterior de la especificación "recommended a maximum of five redirections" y que "some clients might implement such a fixed limitation."

¿Qué cuesta cada salto de una cadena de redirecciones?

Cada salto cuesta un viaje completo de ida y vuelta a un servidor que no devuelve contenido, más una consulta DNS y un handshake TLS nuevos siempre que el salto cambia a un host al que el navegador todavía no se ha conectado. Un acortador, un shim de enlaces y tu propio sitio son tres hosts distintos, así que una cadena de tres saltos suele significar tres handshakes.

Las cabeceras también se tiran. RFC 9110 le dice a un agente de usuario que sigue una redirección de forma automática que elimine "resource-specific header fields, including (but not limited to) Referer, Origin, Authorization, and Cookie." El agente de usuario los sustituye por valores adecuados para la nueva petición, así que hace falta una política de referrer o un paso de HTTPS a HTTP en la cadena para que un clic aterrice en el tráfico directo en lugar de atribuirse a la red que lo envió.

Los rastreadores pagan otra factura. La documentación de rastreo de Google afirma que "any content Google receives from the redirecting URL is ignored, and the final target URL's content is processed instead", así que cada salto intermedio es una descarga que no produce nada indexable y aun así consume lo que Google está dispuesto a rastrear de tu sitio.

¿A cuántas redirecciones sigue un navegador o un rastreador?

Los navegadores paran en 20 y los rastreadores de Google paran en 10. Las cifras vienen de dos especificaciones distintas y ninguna es un objetivo al que apuntar.

El consejo del propio Google queda muy por debajo de su propio límite. La guía de mudanza de sitios pide "keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5", porque "chaining redirects adds latency for users, and not all user agents and browsers support long redirect chains."

¿Por qué los enlaces sociales añaden saltos que tú nunca creaste?

Las plataformas meten sus propios saltos antes del primero tuyo, y en casi todas las redes no puedes negarte. Esa es la parte de la cadena que toca presupuestar en lugar de arreglar.

X es el caso más descarado. Su centro de ayuda indica que los enlaces compartidos en X "will automatically be processed and shortened to an http://t.co link", y responde a la pregunta del opt-out sin rodeos: "You cannot opt out of link shortening." Cada post arranca por tanto con un salto antes siquiera de que se contacte con tu servidor, y el envoltorio t.co siempre cuenta como 23 caracteres por corta que fuera la URL original.

Facebook y Pinterest hacen lo mismo con otra maquinaria. Comprobado el 12 de septiembre de 2026:

Los dos son saltos que ocurren enteramente dentro de la plataforma. El shim de Facebook ni siquiera redirige a tu sitio en la primera respuesta: redirige a una segunda URL de Facebook, que después redirige hacia delante. El dominio corto de Pinterest entrega la petición a un host de API antes de resolver el destino. Ninguno de esos saltos es tuyo para acortarlo, y ese es todo el argumento para no apilarles encima un bit.ly.

Luego están los saltos que sí controlas: un acortador de marca, un rastreador de clics de automatización de marketing, un redirector de afiliados, un salto de http a https, una canonicalización de www y una regla de barra final. Apila un acortador y un rastreador detrás del shim de una plataforma y ya vas por cinco saltos antes de que tu CDN vea la petición.

¿Qué sobrevive de la query string a la cadena de redirecciones?

El fragmento sobrevive por especificación y la query string no. RFC 9110 es explícito: cuando un valor de Location no lleva fragmento propio, "a user agent MUST process the redirection as if the value inherits the fragment component of the URI reference used to generate the target URI." No hay regla equivalente para la query, así que ?utm_source=linkedin solo sobrevive a un salto cuando el servidor que emite la redirección la escribe en Location.

Que lo haga o no es un detalle de configuración del servidor, y los dos servidores web más comunes se comportan de forma lo bastante distinta como para pillar a la gente desprevenida:

• El Redirect de mod_alias en Apache la arrastra. La documentación dice que una petición a http://example.com/service/foo.pl?q=23&a=42 "will be redirected to http://foo2.example.com/service/foo.pl?q=23&a=42."
• El rewrite de nginx la arrastra salvo que lo impidas. La documentación dice que "if a replacement string includes the new request arguments, the previous request arguments are appended after them", y que "putting a question mark at the end of a replacement string avoids having them appended."
• El return de nginx no entra en esa regla. La documentación describe el añadido de argumentos solo para rewrite, así que return 301 https://example.com/new; envía exactamente lo que escribiste y return 301 https://example.com$request_uri; envía la ruta y la query que recibiste.
• Una cabecera Location montada a mano en el código de la aplicación lleva solo las partes de la URL que tu código copia dentro.

Ese único detalle explica la mayoría de los informes de campaña rotos. Tus parámetros UTM van pegados a la URL que publicaste, el shim de la plataforma los reenvía como un bloque opaco dentro de su propio parámetro u=, y después tu propia redirección de limpieza reescribe la ruta y descarta la query en silencio. Analytics registra una sesión sin campaña, y nadie puede rastrear el tráfico de redes sociales hasta el post que lo consiguió.

Los parámetros que añade la plataforma se comportan igual. Meta engancha un identificador de clic a los destinos de anuncios, documentado como ClickID: "a Meta-generated parameter that is passed with the URL of an advertiser's website when a user clicks an ad on Facebook and/or Instagram", con la forma ?fbclid=IwAR2F4.... Una regla de redirección que tira la query se lleva fbclid por delante, y la Conversions API pierde la unión que necesitaba.

¿Cómo encuentras y aplanas una cadena de redirecciones?

Trázala con un comando antes de discutirla. curl -sIL -w '%{http_code} %{url_effective}\n' -o /dev/null <url> recorre la cadena e imprime lo que encontró, y curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' <url> muestra un salto cada vez cuando quieres ver exactamente qué servidor entrega a cuál.

Aplanarla es sobre todo contabilidad. Apunta cada regla de redirección a la URL final en lugar de a la regla siguiente, para que un viejo /blog/post vaya directo a https://www.example.com/blog/post/ en un solo 301 en vez de pasar por tres. Conserva la query string en el valor de Location en toda regla que pueda llevarla. Sáltate tu propio acortador en las redes que ya envuelven los enlaces, porque un t.co que apunta a un bit.ly que apunta a un rastreador son tres saltos que resuelven a la misma página.

Preguntas frecuentes

¿Una cadena de redirecciones es mala para el SEO?

Las cadenas largas dañan el rastreo más que el posicionamiento. La documentación de Google dice que sus rastreadores siguen hasta 10 saltos de redirección por defecto y que se ignora el contenido de las URL que redirigen, así que los saltos más allá de ese número nunca se alcanzan y los de dentro malgastan capacidad de rastreo. La guía de mudanza de sitios de Google pide no pasar de tres.

¿Cuántas redirecciones son demasiadas?

Más de tres es más de lo que Google recomienda. Los techos duros son 20 saltos para los navegadores que implementan el Fetch Standard y 10 para los rastreadores de Google, pero la recomendación de la documentación de mudanza de sitios de Google es "ideally no more than 3 and fewer than 5."

¿Una 301 transmite más valor que una 302 dentro de una cadena?

Google trata las dos de forma distinta como señales de canonicalización. Su documentación describe el 301 como una señal fuerte de que el destino de la redirección debería ser el canónico y el 302 como una débil, con el 308 equivalente al 301 y el 307 equivalente al 302. El salto cuesta el mismo viaje de ida y vuelta en ambos casos.

¿Los parámetros UTM sobreviven a una redirección?

Solo cuando el destino de la redirección los incluye. HTTP obliga al agente de usuario a heredar el fragmento original cuando Location no lleva ninguno, pero no tiene esa regla para la query string, así que una redirección a una ruta pelada tira todos los parámetros UTM de la URL entrante.

¿Puedo impedir que X, Facebook o Pinterest añadan un salto?

No. El centro de ayuda de X dice sin rodeos que no puedes desactivar el acortado de enlaces t.co, y los shims de Facebook y Pinterest son comportamiento de servidor en sus propios dominios. Los únicos saltos que puedes quitar son los de tu lado de la entrega.

¿Cuál es la diferencia entre una cadena de redirecciones y un bucle de redirección?

Una cadena termina en una página real y un bucle nunca lo hace. RFC 9110 pide a los clientes "detect and intervene in cyclical redirections (i.e., 'infinite' redirection loops)", que es por lo que un bucle sale como error del navegador en lugar de como página lenta.

¿Qué cuenta como un salto en una cadena de redirecciones?

Un salto es una única respuesta HTTP 3xx con un encabezado Location, de las que RFC 9110 enumera como 301, 302, 303, 307 y 308. Una 301 de http://example.com/sale a https://example.com/sale es un salto, no una cadena. Una cadena empieza solo cuando sigue una segunda respuesta 3xx.

¿Sobrevive un fragmento de URL a una cadena de redirecciones?

El fragmento sobrevive cuando el encabezado Location no trae uno propio. RFC 9110 exige que el user agent herede en ese caso el fragmento de la URL original. La query string no tiene esa garantía, por eso el fragmento y un parámetro UTM se comportan distinto dentro de la misma cadena.

¿Por qué el tráfico de una cadena de redirecciones aparece como directo en analítica?

Porque el referrer se puede perder por el camino, no porque una cadena lo borre por sí sola. RFC 9110 hace que el user agent elimine el encabezado Referer en cada salto y lo sustituya por un valor adecuado para la nueva petición, así que el encabezado sobrevive a una redirección salvo que algo más lo tire. Una política de referrer restrictiva o un paso de HTTPS a HTTP es lo que deja la última petición sin referrer, y entonces la analítica registra la sesión como directa en lugar de atribuirla a la plataforma que envió el clic.

¿La directiva return de nginx conserva la query string?

No por sí sola. Nginx documenta el añadido de parámetros de consulta solo para la directiva rewrite, así que return 301 https://example.com/new; envía exactamente lo que escribiste y descarta lo que traía la URL del visitante. Añadir $request_uri al destino, como en return 301 https://example.com$request_uri;, es lo que reenvía la ruta y la query.