Verificador de redirecciones: mira adónde lleva cualquier URL o enlace
Un verificador de redirecciones sigue una URL salto a salto y muestra el estado HTTP de cada salto hasta que termina la cadena. Si introduces http://github.com, registra dos saltos: el salto 1 responde 301 Moved Permanently y apunta a https://github.com/, que responde 200 OK. Eso supone una sola redirección, lo cual es correcto; cada redirección adicional añade otro viaje de ida y vuelta. Este verificador sigue las respuestas 301, 302, 303, 307 y 308, así como las etiquetas meta refresh de HTML, señala los bucles y las cadenas largas, y puede enviar la solicitud como Googlebot o como un teléfono móvil.
Una URL por línea, hasta 10. Cada URL se rastrea por separado y luego puedes exportar todo el lote.
Resultados del lote
| URL inicial | Redirecciones | Estado final | URL final | Tiempo (ms) | Nota |
|---|---|---|---|---|---|
Destino final
Cadena de redirecciones
Esta URL pasa por más de una redirección antes de llegar a la página final. Cada salto adicional cuesta un viaje de ida y vuelta; haz que la primera URL apunte directamente al destino final.
Bucle de redirecciones detectado
Esta URL redirige a una página que ya estaba en la cadena, así que nunca llega a un destino final.
Cadena de redirecciones demasiado larga
La cadena seguía redirigiendo después de 10 saltos, así que la comprobación se detuvo ahí.
Se detuvo tras 20 segundos
La cadena seguía avanzando cuando se agotó el tiempo máximo por comprobación. Abajo se muestra la última URL alcanzada.
Cadena de redirecciones
Herramientas populares
Acerca de Verificador de redirecciones
Este verificador de redirecciones rastrea lo que ocurre realmente entre la URL que escribes y la página que finalmente se carga. Desde nuestro servidor envía una solicitud GET por salto, sin cookies, registra el código de estado, el encabezado Location y el tiempo que tardó cada salto, y pasa a la siguiente URL hasta llegar a una respuesta que no sea una redirección, o hasta completar 10 saltos, una cifra que ya equivale al máximo que siguen los rastreadores de Google y a más o menos la mitad de los cerca de 20 saltos que permite un navegador antes de rendirse con ERR_TOO_MANY_REDIRECTS.
Cuando un salto responde 200 con una página HTML, lee como máximo los primeros 64 KB en busca de una etiqueta meta refresh, porque ese tipo de redirección está en la página y no en los encabezados. No se ejecuta nada de la página, y por eso las redirecciones JavaScript también quedan fuera de su alcance: solo existen cuando un navegador ejecuta los scripts de la página.
El resultado es deliberadamente literal. El salto 1 es la URL que introdujiste, y cada fila siguiente es la URL exacta a la que te envió el salto anterior, incluidos el cambio de esquema, el www añadido o eliminado, la barra final y la cadena de consulta; un salto al que se llega mediante una etiqueta meta refresh se marca como tal, con su retardo. Eso es lo que hace útil la herramienta en las migraciones: una regla que parece correcta en una configuración de nginx a menudo se comporta de otra manera cuando entran en juego a la vez HSTS, una regla en el edge de la CDN y una redirección canónica en la propia aplicación, y la única forma fiable de ver el resultado es seguirlo desde fuera.
Como algunos sitios envían a los móviles, a los rastreadores y a los navegadores de escritorio a destinos distintos, la solicitud puede salir como nuestro propio rastreador, como Chrome en Windows, como Safari en un iPhone, como Googlebot (para smartphones o de escritorio) o como Bingbot.
El modo por lotes admite hasta diez URLs a la vez, las rastrea una tras otra y te ofrece una tabla que puedes exportar como CSV o pegar directamente en una hoja de cálculo o en un ticket, con el número de redirecciones, el estado final, la URL final y el tiempo total. El botón de variantes genera las cuatro combinaciones de http y https, con y sin www, para la dirección que introdujiste y las rastrea de una sola vez: es la forma más rápida de confirmar que todos los puntos de entrada convergen en una única URL canónica.
Resuelve en segundos dudas habituales como si la URL antigua de un producto sigue llevando a la nueva con un único 301, si la regla de HTTP a HTTPS ha sobrevivido al último despliegue, si un enlace de afiliado conserva su cadena de consulta hasta el final y adónde lleva exactamente un enlace acortado. Se rechazan las direcciones privadas, localhost y los endpoints de metadatos de la nube, y cada comprobación se detiene a los 20 segundos, así que el verificador no se puede usar para sondear una red interna.
Casos de uso
Cómo comprobar adónde redirige una URL
Pega la URL o el enlace que quieras probar, por ejemplo http://github.com, o haz clic en uno de los ejemplos que aparecen debajo del campo.
Si quieres, elige quién envía la solicitud: nuestro rastreador predeterminado, Chrome, un iPhone, Googlebot o Bingbot. Los sitios que tratan de forma distinta a los móviles o a los bots mostrarán una cadena diferente.
Pulsa Intro o haz clic en Comprobar redirecciones. Nuestro servidor solicita cada salto y sigue las respuestas 301, 302, 303, 307 y 308 y las etiquetas meta refresh, hasta un máximo de 10 saltos.
Lee el resumen: cuántas redirecciones se encontraron, el estado HTTP final, el tiempo total y la URL final. Aparece un aviso cuando la URL entra en un bucle o pasa por más de una redirección.
Recorre la cadena numerada para ver cada salto con su URL, su distintivo de estado (por ejemplo, 301 Moved Permanently), si fue una redirección meta refresh y cuánto tardó ese salto.
Para probar varias direcciones, cambia al modo por lotes (hasta 10 URLs) o haz clic en el botón de variantes para rastrear a la vez las versiones http, https, con www y sin www; después, exporta los resultados como CSV.
Consejos Pro
- Procura que haya un único 301 directo a la URL final. Cada salto adicional cuesta un viaje de ida y vuelta completo, un salto que cambia a HTTPS añade un handshake TLS y uno que cambia de host suma además una consulta DNS: en conjunto, normalmente entre 100 y 300 ms en una conexión móvil antes de que se muestre nada.
- Usa 308 en lugar de 301 cuando la solicitud redirigida pueda ser un POST. Con 301 y 302, los clientes pueden cambiar el método a GET; con 307 y 308, deben conservar el método y el cuerpo.
- Prueba las versiones http:// y www además de la https://; el botón de variantes comprueba las cuatro a la vez. Muchos sitios redirigen correctamente en HTTPS mientras una regla antigua para HTTP sin cifrar sigue apuntando a un host dado de baja.
- Fíjate en el estado del último salto, no solo en el número de redirecciones. Una cadena que termina en 404 o 405 está rota aunque cada redirección del camino fuera un 301 impecable.
- Después de una migración, pasa tus URLs principales de Search Console por el modo por lotes, descarga el CSV y compáralo con la misma lista una semana después para detectar reglas que algún despliegue haya revertido sin avisar.
Solución de problemas
La comprobación devuelve 403 cuando elijo Googlebot.
Muchos sitios grandes confirman que un visitante que dice ser Googlebot procede realmente de la red de Google y rechazan a todos los demás, incluido este verificador. Compara con el agente predeterminado o con el de Chrome; para ver lo que recibió el propio Google, usa la herramienta de inspección de URLs de Search Console.
La cadena termina en 403, 405 o 503, pero la página se abre en mi navegador.
Probablemente el sitio está filtrando clientes: una protección antibots o un desafío de la CDN que requiere cookies y JavaScript, o un bloqueo de los rangos de IP de servidores. Prueba con el agente de Chrome o el de iPhone; si la respuesta no cambia, el filtro se basa en la red o en el comportamiento, y una comprobación desde un servidor no puede sortearlo.
Mi navegador muestra ERR_TOO_MANY_REDIRECTS, pero el verificador muestra una cadena normal.
Probablemente el bucle depende de algo que este verificador no envía: una cookie, una sesión iniciada o la entrada HSTS que guarda tu navegador. Borra las cookies del sitio o abre una ventana privada y, después, compara las versiones http:// y https:// con el botón de variantes para encontrar la regla que devuelve a los visitantes a una URL anterior.
Un salto falla con un error de certificado SSL en lugar de un código de estado.
El certificado de ese host ha expirado, es autofirmado o se emitió para otro nombre, así que la conexión se rechaza antes de poder leer ninguna redirección. Los navegadores se detienen en el mismo punto. Renueva o corrige el certificado, o haz que el salto anterior apunte a un host con un certificado válido.
Preguntas frecuentes
Muestra adónde envía realmente una URL a los visitantes y a los buscadores. Obtienes cada salto entre la dirección que escribiste y la página que finalmente responde, con el código de estado y el tiempo de cada uno. Así resuelves tres preguntas a la vez: si la redirección se activa, si apunta al destino correcto y cuántos saltos se desperdician por el camino. También es la forma segura de ver adónde lleva un enlace acortado o de afiliado antes de hacer clic en él.
Un 301 indica que el cambio es permanente: los navegadores lo guardan en caché, y Google consolida las señales de posicionamiento de la URL antigua en la nueva dirección y conserva la antigua solo como nombre alternativo, por lo que normalmente deja de aparecer en los resultados, aunque todavía puede mostrarse cuando una búsqueda sugiere que los usuarios confían en ella. Un 302 indica que el cambio es temporal, así que la URL original suele seguir indexada y la respuesta no se guarda en caché salvo que los encabezados lo permitan. Usa 301 para migraciones y para el paso a HTTPS, y 302 solo para pruebas A/B y páginas de mantenimiento.
Lo ideal es una, dos se pueden tolerar y tres o más deberían reducirse a una sola. Los navegadores se rinden tras unos 20 saltos, y los rastreadores de Google siguen hasta 10 saltos de redirección antes de tratar la URL como un error. Cada salto adicional cuesta un viaje de ida y vuelta, un salto que cambia de esquema añade un handshake TLS y uno que cambia de host añade además una consulta DNS, de modo que una cadena de tres redirecciones puede sumar varios cientos de milisegundos en móvil antes de que llegue el primer byte de contenido real.
Introduce tu dominio y haz clic en el botón de variantes. Rastrea http://, https://, http://www. y https://www. para la misma ruta en un solo lote. En una configuración correcta, las cuatro terminan en la misma URL final con un 200: la versión canónica no muestra ninguna redirección y cada una de las otras tres, un único 301 o 308. Dos redirecciones en la versión http://www. suelen indicar que el esquema y el host se corrigen con reglas separadas que se pueden fusionar en una sola.
Sí. Elige el agente de usuario antes de lanzar la comprobación: Chrome en Windows, Safari en un iPhone, Googlebot para smartphones o de escritorio, o Bingbot. Los sitios que envían a los visitantes móviles a un subdominio m. o que tratan de otra forma a los rastreadores mostrarán una cadena distinta para cada uno. Una advertencia: muchos sitios grandes verifican que un visitante que dice ser Googlebot procede realmente de la red de Google y, si no, responden 403, así que un 403 con el agente de Googlebot suele significar exactamente eso. Para ver con precisión lo que recibió Google, usa la herramienta de inspección de URLs de Search Console.
Las meta refresh, sí. Cuando un salto responde 200 con una página HTML, el verificador lee sus primeros 64 KB, localiza una etiqueta meta refresh que contenga una URL y la sigue como siguiente salto, que se marca como meta refresh con su retardo en segundos. Las de JavaScript, no: solo se producen cuando un navegador ejecuta los scripts de la página, y este verificador nunca ejecuta nada. Si el último salto es un 200 pero tu navegador acaba en otro sitio, lo más probable es que la causa sea un script; la pestaña Red (Network) de DevTools lo muestra como una navegación iniciada por un script.
Hay cuatro causas habituales. Tu navegador tiene el sitio en su caché HSTS, así que cambia http:// por https:// antes de que ninguna solicitud salga del equipo. El sitio varía su respuesta según las cookies, el encabezado de idioma o el país, y, para él, nuestro servidor no se parece a ti. El sitio envía a los móviles y a los equipos de escritorio a destinos distintos, algo que puedes reproducir cambiando el agente de usuario. O bien una redirección JavaScript completa el recorrido cuando la página ya ha cargado, algo que un rastreo desde el servidor nunca ve.
Sí. Cambia al modo por lotes y pega hasta diez URLs, una por línea. Cada una se rastrea por separado y los resultados se reúnen en una sola tabla con el número de redirecciones, el estado final, la URL final y el tiempo total. Descarga esa tabla como CSV o cópiala como texto separado por tabulaciones, que se pega limpiamente en Sheets, Excel o un ticket de Jira sin necesidad de reformatear nada. El botón de variantes rellena esa misma tabla con las cuatro versiones (http/https, con y sin www) de una dirección.
Abre DevTools con F12, ve a la pestaña Red (Network), marca Conservar registro (Preserve log) y carga la URL. Cada salto aparece en su propia fila con un estado 301 o 302; haz clic en uno y lee el encabezado Location en Encabezados de respuesta (Response Headers). El inconveniente es que DevTools muestra lo que hizo tu navegador, con tus cookies, tu caché HSTS y tus extensiones incluidas, así que un compañero en otro equipo puede ver una cadena diferente.
Un único 301 o 308 transmite las señales de posicionamiento y no supone ningún problema. Las cadenas sí, por dos motivos: los rastreadores de Google siguen hasta 10 saltos de redirección y notifican cualquier cadena más larga como error de redirección, y cada salto retrasa el primer byte, lo que repercute directamente en las Core Web Vitals. Los bucles son peores, porque la página nunca llega a ser accesible y desaparece por completo del índice. Acorta las cadenas para que la primera URL apunte directamente a la última.