Cómo verificar redirecciones de URL (y leer la cadena)

El enlace en el que haces clic a menudo no es la página a la que llegas. Por el camino puede haber un paso a HTTPS, un cambio de host, un servicio de seguimiento, un acortador de URL y una regla del CMS que agrega una barra final, y cada uno de ellos es una solicitud aparte que tu navegador hace sin avisarte.

Esta guía explica cómo ver esos pasos con TrueURL, curl y las herramientas para desarrolladores del navegador (DevTools), qué significa cada parte de una cadena de redirecciones y cómo solucionar los problemas más habituales.

Qué es una cadena de redirecciones

Una redirección se produce cuando un servidor responde con un código de estado 3xx y un encabezado Location que indica otra URL. El cliente, ya sea un navegador o un rastreador, solicita entonces esa URL y repite el proceso hasta recibir una respuesta que no sea una redirección.

Cada solicitud con su respuesta forma un salto. La secuencia completa, desde la primera URL hasta la respuesta final, es la cadena de redirecciones:

#  URL                              Status  Location
1  http://example.com/Shoes         301     https://example.com/Shoes
2  https://example.com/Shoes        301     https://www.example.com/Shoes
3  https://www.example.com/Shoes    302     /shoes/
4  https://www.example.com/shoes/   200

Son tres redirecciones y cuatro solicitudes para llegar a una sola página. El valor de Location del salto 3 es relativo: los clientes lo resuelven a partir de la URL que acaban de solicitar, como establece la RFC 9110, así que equivale a https://www.example.com/shoes/. Lo ideal sería que cada una de estas direcciones llegara a la URL final en un solo salto.

Una página también puede redirigir después de responder 200 OK, con una etiqueta <meta http-equiv="refresh"> o con JavaScript. Estas redirecciones del lado del cliente también forman parte de la cadena, pero las herramientas que solo leen los encabezados HTTP, como curl, se detienen en esa página.

Por qué importa comprobar las redirecciones

SEO: señales canónicas y presupuesto de rastreo

Los motores de búsqueda interpretan una redirección como una indicación de qué URL deben indexar. Google trata las redirecciones permanentes (301 y 308) como una señal fuerte de que el destino debe ser la URL canónica, y las temporales (302, 303 y 307), como una señal débil. Por eso, una página que cambió de URL de forma definitiva pero redirige con un 302 puede conservar su URL antigua en los resultados de búsqueda.

La longitud también cuenta. Googlebot sigue hasta 10 saltos de redirección; si para entonces no ha recibido contenido, Search Console muestra un error de redirección. La guía de Google sobre el presupuesto de rastreo (crawl budget) también aconseja evitar las cadenas de redirecciones largas porque, según indica, afectan negativamente al rastreo.

Velocidad de carga

La página final no puede empezar a cargarse hasta que se haya respondido la última redirección. Cada salto cuesta un viaje de ida y vuelta por la red, y un salto a otro host requiere además una consulta DNS, una conexión nueva y, con HTTPS, una negociación TLS (handshake). En conexiones móviles, tres o cuatro redirecciones pueden sumar varios cientos de milisegundos antes del primer byte de la página real. El Medidor de latencia de redirecciones muestra cuánto cuesta cada salto.

Seguridad de los enlaces cortos y desconocidos

Los enlaces acortados y muchos enlaces de seguimiento de los correos electrónicos ocultan su destino. Además, las campañas de phishing aprovechan las redirecciones abiertas (open redirects) de dominios conocidos, de modo que un enlace que empieza en un sitio de confianza puede acabar en un lugar totalmente distinto. El Desacortador de enlaces te muestra, antes de hacer clic, todos los dominios por los que pasa el enlace y si algún salto baja de HTTPS a HTTP sin cifrar.

Enlaces de afiliados y de seguimiento

Los enlaces de marketing suelen pasar por varios servicios antes de llegar a la página de destino, y cada uno debe transmitir la cadena de consulta (query string); si no, los parámetros UTM, los identificadores de clic y las etiquetas de afiliado se pierden sin que nadie lo note. La URL final muestra si se han conservado y si el enlace sigue llevando a la página prevista.

Migraciones, HTTPS y el host canónico

Tras un rediseño, un cambio de dominio o el paso a HTTPS, cada URL antigua debería llegar a su nueva equivalente con una sola redirección permanente. Las cuatro variantes básicas de un sitio (http:// y https://, con y sin www) deberían terminar todas en una única dirección canónica. Estas reglas fallan sin hacer ruido: una regla nueva en la CDN, la actualización de un plugin o un cambio de servidor pueden agregar un salto o un bucle sin que nadie se dé cuenta.

Cómo verificar una redirección con TrueURL

TrueURL ejecuta cada verificación en la red perimetral (edge) de Cloudflare, así que puedes inspeccionar enlaces que no te inspiran confianza sin abrirlos en tu navegador. El Verificador de redirecciones de URL de la página de inicio analiza una sola URL; el Verificador de cadenas de redirecciones y las demás herramientas especializadas usan el mismo motor.

Paso 1: indica la URL

Pega la URL e inicia la verificación. Si no indicas el esquema, se usa https://; escribe http:// para probar HTTP sin cifrar.

Paso 2: ajusta la Configuración avanzada si hace falta

De forma predeterminada, el verificador envía una solicitud GET con el User-Agent de una versión actual de Chrome para escritorio, sin cookies y con un límite de 20 redirecciones. En Configuración avanzada puedes cambiarlo:

• Método HTTP: GET, HEAD o POST. HEAD es más ligero, pero algunos servidores lo responden de otra manera y, sin cuerpo de respuesta, no se pueden detectar las redirecciones del lado del cliente. POST envía el cuerpo de la solicitud que escribas, útil para formularios y API. Los saltos siguientes aplican las reglas de los navegadores: después de un POST, un 301 o un 302 continúa como GET, un 303 siempre lo hace, y 307 y 308 conservan el método y el cuerpo.
• Máximo de saltos: el número de redirecciones que se siguen, de 1 a 50. El valor predeterminado, 20, es el límite que fijan el Fetch Standard, Chrome y Firefox. Ponlo en 10 para ver si una cadena cabe dentro del límite de Googlebot.
• User-Agent personalizado: si lo dejas vacío, se usa Chrome para escritorio. Los valores predefinidos incluyen Safari en iPhone, Chrome en Android, Googlebot (smartphone y escritorio), Bingbot, los bots de vista previa de enlaces de Facebook y X, y curl.
• Encabezados de solicitud personalizados: encabezados adicionales que se envían en cada salto, por ejemplo Accept-Language: fr-FR para provocar una redirección por idioma.
• Cookies: escribe name=value; other=value para reproducir una sesión iniciada, un consentimiento de cookies o una región concreta. Las cookies que se establecen a lo largo de la cadena se conservan para los saltos siguientes, igual que en un navegador.
• Redirecciones del lado del cliente: elige si se siguen las etiquetas meta refresh y las redirecciones JavaScript simples o si solo se indican.
• Ignorar errores SSL: la red perimetral de Cloudflare siempre valida los certificados, así que esta opción no permite saltarse uno defectuoso. Los errores de TLS se muestran en el salto en el que se producen.

Paso 3: interpreta el resultado

El resultado empieza con la URL final y su código de estado. Debajo, la cadena muestra una fila por salto con:

• la URL solicitada y el método HTTP utilizado;
• el código de estado y su frase de motivo (la referencia de códigos de estado explica cada uno);
• el tiempo de respuesta, desde que se envía la solicitud hasta que llegan los encabezados, incluidas la consulta DNS y el establecimiento de la conexión, si los hay;
• la dirección de destino indicada en Location;
• los encabezados de respuesta y los nombres de las cookies que estableció ese salto.

Cada redirección se etiqueta según cómo se produjo: código de estado HTTP, meta refresh (con su retraso en segundos) o JavaScript. También se indican las redirecciones del lado del cliente que se detectaron pero no se siguieron. Igual de importante es cómo terminó la verificación:

Las advertencias señalan una redirección temporal en la cadena, un paso de HTTPS a HTTP, más de tres redirecciones, una URL final en otro dominio, redirecciones del lado del cliente y solicitudes HEAD que no pudieron leer el cuerpo de la página.

Una de las advertencias requiere especial atención. Algunos sitios muestran al tráfico automatizado o procedente de centros de datos una verificación antibots, como la página “Just a moment...” de Cloudflare. TrueURL marca las respuestas que parecen una de estas páginas, porque en ese caso la verificación llegó a la capa de protección del sitio, no al destino. Un visitante real puede terminar en otro lugar.

Cómo verificar redirecciones desde la línea de comandos

curl viene preinstalado en macOS, Windows 10 y 11 y la mayoría de las distribuciones de Linux, y muestra exactamente lo que envía el servidor, sin que intervenga la caché del navegador. Los ejemplos usan un shell de Unix; en Windows PowerShell 5.1, escribe curl.exe, porque allí curl es un alias de Invoke-WebRequest, y usa NUL en lugar de /dev/null.

Ver un solo salto

curl -I https://example.com/old-page

-I envía una solicitud HEAD y muestra los encabezados de respuesta, incluidos la línea de estado y el Location, si lo hay. curl no sigue las redirecciones a menos que se lo pidas. Como algunos servidores tratan HEAD de otra manera, repite la verificación con GET cuando el resultado parezca extraño; -o /dev/null descarta el cuerpo y -D - muestra los encabezados:

curl -sS -o /dev/null -D - https://example.com/old-page

Seguir toda la cadena

-L sigue las redirecciones y, con -I o -D -, curl muestra los encabezados de cada salto. Un filtro con grep deja una vista compacta:

curl -sIL http://example.com/Shoes | grep -iE '^(HTTP/|location:)'

HTTP/1.1 301 Moved Permanently
Location: https://example.com/Shoes
HTTP/2 301
location: https://www.example.com/Shoes
HTTP/2 302
location: /shoes/
HTTP/2 200

De forma predeterminada, curl sigue hasta 50 redirecciones; --max-redirs 10 aplica el límite de Googlebot.

Mostrar solo la URL final

La opción -w (write-out) muestra datos al terminar la transferencia y convierte curl en un sencillo expansor de URL:

curl -sSL -o /dev/null -w '%{http_code} %{num_redirects} %{url_effective}\n' https://example.com/go

%{url_effective} es la última URL obtenida; %{num_redirects}, el número de redirecciones seguidas, y %{http_code}, el código de estado final. %{time_redirect} indica los segundos dedicados a las redirecciones antes de la solicitud final. Sin -L, %{redirect_url} muestra a dónde llevaría la primera redirección.

Probar solicitudes POST

-d envía un cuerpo y convierte la solicitud en un POST. Al seguir redirecciones, curl se comporta entonces como un navegador: cambia a GET después de un 301, 302 o 303, y reenvía el POST con su cuerpo después de un 307 o 308.

curl -sSL -o /dev/null -D - -d 'email=test%40example.com' https://example.com/subscribe

Evita combinar -X POST con -L. -X fuerza el método en todas las solicitudes, así que curl sigue enviando POST después de un 301, 302 o 303, donde un navegador cambiaría a GET, y acabas probando una cadena que ningún cliente real produce.

Cambiar el User-Agent, los encabezados y las cookies

# User-Agent de smartphone
curl -sIL -A 'Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.0 Mobile/15E148 Safari/604.1' https://example.com/

# Encabezado de solicitud adicional
curl -sIL -H 'Accept-Language: de-DE,de;q=0.9' https://example.com/

# Enviar una cookie y conservar las que se establezcan en la cadena
curl -sSL -o /dev/null -D - -b 'consent=yes' -c cookies.txt https://example.com/

-A define el User-Agent, -H agrega un encabezado y -b envía cookies. -c guarda en un archivo las cookies recibidas y activa el motor de cookies de curl, de modo que una cookie establecida en un salto se envía en el siguiente.

curl no ejecuta JavaScript ni sigue las etiquetas meta refresh. Si su última respuesta es una página HTML con 200 OK, pero tu navegador termina en otro sitio, la redirección se produce del lado del cliente.

Cómo verificar redirecciones en las DevTools del navegador

Las DevTools muestran la cadena tal como la ve tu propio navegador, con tus cookies, tus extensiones y tu ubicación:

1. Abre las DevTools (F12, o Cmd+Option+I en Mac) y selecciona la pestaña Network (Red).
2. Activa Preserve log (Conservar registro) en Chrome y Edge, o Persist Logs en el menú de configuración de red de Firefox. De lo contrario, la lista se borra con cada carga de página y las redirecciones del lado del cliente desaparecen de la vista.
3. Activa Disable cache (Inhabilitar caché) para que una redirección almacenada en caché no oculte lo que el servidor envía hoy.
4. Escribe la URL en la barra de direcciones.

Cada salto aparece en su propia fila con su código 3xx; selecciónala y abre Headers (Encabezados) para ver el encabezado de respuesta location. En Chrome, “(disk cache)” o “(memory cache)” en la columna Size (Tamaño) significa que la redirección salió de la caché, no del servidor.

A veces Chrome muestra un 307 Internal Redirect de http:// a https://. El servidor nunca lo envió: fue el propio navegador el que cambió la solicitud a HTTPS, normalmente porque tiene guardada una política HSTS para ese sitio. Para ver qué hace el servidor con HTTP sin cifrar, usa curl o TrueURL.

Problemas de redirección frecuentes y cómo solucionarlos

Cadenas de más de un salto

Las cadenas crecen por capas: una regla de una migración antigua apunta a una URL que una migración posterior volvió a redirigir. Haz que cada regla apunte directamente al destino final y actualiza los enlaces internos, las etiquetas canonical, las anotaciones hreflang y los sitemaps para que tu propio sitio nunca provoque una redirección. El Verificador masivo de redirecciones muestra qué URL antiguas siguen necesitando más de un salto.

Bucles de redirecciones

Chrome indica un bucle con el mensaje “te ha redirigido demasiadas veces” (ERR_TOO_MANY_REDIRECTS); Firefox muestra “La página no está redirigiendo adecuadamente”. Causas frecuentes:

• HTTPS detrás de un proxy o una CDN. El servidor de origen redirige HTTP a HTTPS, pero el proxy se conecta al origen por HTTP sin cifrar, así que el origen nunca ve HTTPS y redirige sin fin. En Cloudflare, es el resultado clásico del modo SSL/TLS Flexible; usa Full (strict) o haz que el origen compruebe X-Forwarded-Proto.
• Dos capas que se contradicen, como una regla de la CDN que quita www mientras el servidor lo agrega, o un framework que agrega una barra final que la CDN elimina.
• Redirecciones que dependen de cookies. Una página de inicio de sesión o de consentimiento devuelve al visitante a la URL original, que vuelve a redirigirlo a la página de inicio de sesión porque la cookie no se guardó.

El Detector de bucles de redirecciones muestra qué salto cierra el bucle. Después, deja cada regla a cargo de una sola capa.

301 y 302 mezclados en una misma cadena

Una cadena con un 301, luego un 302 y después un 200 es un traslado permanente con un paso temporal en medio. Suele deberse a un valor predeterminado: tanto res.redirect() de Express como header('Location: ...') de PHP envían un 302 si no se indica otra cosa. Usa un código permanente en todos los saltos y confírmalo con el Verificador de redirecciones 301. Nuestra guía de códigos de redirección HTTP explica cuándo conviene cada código.

Saltos dobles de HTTP a HTTPS y a www

Una cadena muy habitual es http://example.com → https://example.com → https://www.example.com: dos saltos donde bastaría uno. Redirige cada variante no canónica directamente a la URL HTTPS final y luego prueba las cuatro con el Verificador de redirecciones HTTPS.

Hay una excepción intencionada. Si tu host canónico es www y agregas el dominio a la lista de precarga de HSTS (HSTS preload), hstspreload.org exige que http://example.com redirija primero a https://example.com, para que los navegadores registren la política HSTS del dominio raíz.

Incoherencias con la barra final

/pricing y /pricing/ son URL distintas. Si ambas devuelven 200 OK, tienes contenido duplicado; si dos capas redirigen cada una a la otra, tienes un bucle. Elige una forma, redirige la otra a ella con un único 301 y enlaza siempre de la misma manera. El Verificador de barra final prueba las dos formas a la vez.

Redirecciones solo en móviles

Los sitios móviles separados, los avisos para instalar una app y la detección de dispositivos a veces envían los teléfonos a otra parte, a menudo a la página de inicio móvil en lugar de a la página equivalente. Con la indexación centrada en dispositivos móviles (mobile-first indexing), Google rastrea principalmente con su rastreador para smartphones, así que la cadena móvil es la que más pesa en la indexación. Compara ambas con la herramienta Redirecciones en móvil vs. escritorio.

Redirecciones en los sitemaps

Un sitemap (mapa del sitio) debe incluir las URL canónicas que quieres que aparezcan en los resultados de búsqueda, y esas URL devuelven 200 OK. Las entradas que redirigen desperdician solicitudes de rastreo y envían señales canónicas contradictorias. Ejecuta el Verificador de redirecciones en sitemaps después de cada migración y sustituye cada entrada que redirige por su URL final.

Redirecciones JavaScript y meta refresh

Google trata un meta refresh instantáneo como una redirección permanente y uno con retraso como temporal. Las redirecciones JavaScript solo las ve después de renderizar la página, un paso que llega después del rastreo y que puede fallar. Muchos otros rastreadores, bots de vista previa de enlaces y herramientas de línea de comandos no ejecutan JavaScript en absoluto, y algunos tampoco tienen en cuenta el meta refresh. Usa redirecciones del lado del servidor siempre que controles el servidor y localiza las del lado del cliente con el Verificador de meta refresh.

Lista de verificación de redirecciones

Repasa esta lista después de una migración o de un cambio de CDN, o antes de lanzar una campaña:

1. Cada URL antigua llega a su destino final en un solo salto.
2. Los traslados permanentes usan 301 o 308 en todos los saltos.
3. Las cuatro variantes de protocolo y host terminan en la URL HTTPS canónica.
4. Ningún salto pasa de HTTPS a HTTP.
5. Los parámetros de consulta, incluidos los UTM y los ID de afiliado, se conservan en toda la cadena.
6. Cada URL tiene una sola forma, con o sin barra final, y la otra forma redirige a ella.
7. Las solicitudes de escritorio, de smartphone y de Googlebot terminan en páginas equivalentes.
8. Las redirecciones del lado del servidor sustituyen a las de meta refresh y JavaScript siempre que es posible.
9. Los enlaces internos, las etiquetas canonical, las anotaciones hreflang y los sitemaps apuntan a las URL finales.
10. Las páginas eliminadas sin sustituto devuelven 404 o 410 en lugar de redirigir a la página de inicio.
11. Las redirecciones de un cambio de sitio se mantienen; Google recomienda conservarlas al menos un año.