Comprobar redirecciones 301: sigue toda la cadena

Un comprobador de redirecciones muestra lo que pasa de verdad entre hacer clic en un enlace y llegar a una página. Cada URL que escribes se solicita desde el servidor de Marqly con las redirecciones automáticas desactivadas, así que cada respuesta queda registrada por separado: el código de estado, el encabezado Location al que apunta, cuánto tardó y los encabezados que importan para el SEO. Después la herramienta sigue esa dirección y repite, hasta 10 redirecciones, el mismo límite que usan por defecto los rastreadores de Google. Obtienes la cadena de redirecciones completa, la URL y el estado finales, y avisos en lenguaje claro sobre bucles, redirecciones temporales, saltos lentos, parámetros de seguimiento perdidos y cadenas que conviene acortar.

Cómo comprobar una redirección

1. Pega una URL en el cuadro. Para una comprobación en bloque, pega hasta 10 URLs, una por línea.
2. Elige un user agent si lo necesitas. El predeterminado se identifica como el comprobador de Marqly; también puedes enviar el user agent de Chrome, de Safari en iPhone, de Googlebot para smartphones o de Googlebot de escritorio para detectar reglas que tratan de forma distinta a navegadores, teléfonos y rastreadores.
3. Marca Comprobar también las versiones http/https y con/sin www para probar las cuatro formas de la misma dirección a la vez. Es la manera más rápida de confirmar que un sitio tiene un único nombre de host canónico y que todas las variantes llegan a él en un solo salto.
4. Presiona Comprobar redirecciones. Cada URL tiene su propia tarjeta con el veredicto, los avisos y la cadena salto a salto.
5. Usa Copiar resultados para obtener un informe en texto, Descargar CSV para una hoja de cálculo con una fila por salto, o Copiar enlace para compartir para enviar un enlace que vuelve a ejecutar la misma comprobación.

Cómo leer los resultados

Cada tarjeta empieza con el código de estado final, la URL que escribiste, el número de redirecciones, el tiempo total y la URL final. Debajo, los avisos señalan lo que merece atención: desde errores (bucles, cadenas por encima del límite, una cadena que termina en un 404) hasta advertencias (redirecciones temporales, meta refresh, un paso de https a http, parámetros de consulta perdidos, unX-Robots-Tag: noindex en la página final) y notas neutras (cambios de barra final o de www, un traslado a otro dominio, saltos lentos).

La tabla de la cadena lista cada solicitud en orden. Estado es el código de estado HTTP que devolvió el servidor. URL es lo que se solicitó y, debajo, adónde envía ese salto al cliente, ya convertido en una dirección absoluta cuando el servidor envió una Locationrelativa. Tiempo es lo que tardó el servidor en devolver los encabezados de ese salto. Abre Encabezados en cualquier fila para ver Location,Cache-Control, Content-Type, X-Robots-Tag, Link (donde se puede declarar una canónica), Strict-Transport-Security, X-Redirect-By (WordPress y algunos plugins se identifican ahí) y Server. Los valores de las cookies nunca se muestran, solo cuántas se establecieron.

301, 302, 307 y 308: qué significa cada código de redirección

HTTP define los códigos de estado de redirección en laRFC 9110, sección 15.4. Dos preguntas los separan: ¿el cambio es permanente?, y ¿puede el cliente cambiar el método de la solicitud (por ejemplo, convertir un POST de formulario en un GET) al seguir la redirección? Ladocumentación de Google sobre códigos de estado HTTPexplica cómo tratan cada uno sus rastreadores y la indexación.

Para páginas normales, usa una 301 cuando el contenido se mudó para siempre: un slug renombrado, un artículo fusionado, una migración de dominio, el paso a HTTPS. Usa una 302 o una 307 cuando la URL original va a volver, como una página de mantenimiento, una campaña corta o una prueba. Recurre a la 308 cuando el método importa, por ejemplo en un endpoint de API o en un formulario que recibe solicitudes POST, porque la RFC 9110 permite a los clientes convertir un POST redirigido en GET con 301 y 302, pero lo prohíbe con 307 y 308.

Redirecciones meta refresh y de JavaScript

La guía de Google sobre redireccionesrecomienda una redirección permanente del lado del servidor siempre que sea posible. Trata un meta refresh instantáneo como una redirección permanente y uno con retraso como temporal, y aconseja las redirecciones de JavaScript solo cuando no se puede usar ni una redirección del servidor ni un meta refresh, porque el renderizado puede fallar. Este comprobador sigue las etiquetas meta refresh y el encabezado Refresh y los marca, pero no ejecuta JavaScript.

¿Qué es una cadena de redirecciones y por qué perjudica?

Una cadena de redirecciones es cualquier recorrido con más de un salto: http://example.com/page →https://example.com/page → https://www.example.com/page →https://www.example.com/page/. Las cadenas casi nunca se crean a propósito. Se acumulan cuando un sitio pasa a HTTPS, elige si usar www o no, cambia de CMS, renombra secciones y redirige redirecciones antiguas en vez de reescribirlas. Cada capa funciona por sí sola; juntas se van sumando.

• Velocidad. Cada salto es otra solicitud completa antes de que la página empiece a cargar, y un salto a un nombre de host nuevo añade una consulta DNS y un handshake TLS. La columna de tiempo muestra lo que cuesta cada salto.
• Rastreo. Google indica que sus rastreadores siguen hasta 10 saltos de redirección de forma predeterminada, y su informe de indexación de páginas incluye una cadena de redirecciones demasiado larga, un bucle de redirección y una URL incorrecta o vacía en la cadena entre loserrores de redirección. La guía de Google para mover un sitioaconseja redirigir directamente al destino final, y señala que encadenar añade latencia y que no todos los user agents y navegadores admiten cadenas largas.
• Otros clientes. La RFC 9110 recuerda que una especificación HTTP anterior recomendaba un máximo de cinco redirecciones y que algunos clientes todavía pueden aplicar un límite fijo así, de modo que una cadena que Googlebot tolera puede seguir fallando en otro software.
• Fragilidad y datos perdidos. Cada salto es otra regla que se puede editar, borrar o quedar tapada por otra. Un salto que reconstruye la URL puede eliminar sin avisar la cadena de consulta, y así es como desaparecen las etiquetas UTM antes de que la analítica llegue a verlas; el comprobador avisa cuando un parámetro de tu URL original falta en la final.

Cómo arreglar una cadena de redirecciones

1. Encuentra la URL final. Pasa la URL antigua por el comprobador y copia la última URL de la cadena.
2. Apunta la primera redirección a la URL final. Si A redirige a B y B redirige a C, cambia la regla de A para que vaya directa a C y conserva B → C para quien todavía tenga B. En un mapa de redirecciones o en un plugin, busca reglas cuyo destino sea a su vez el origen de otra regla.
3. Combina las reglas de protocolo y de nombre de host. La cadena más común es http → https seguida de sin www → con www. Escribe una sola regla que envíe todas las variantes a la forma canónica en un único paso, como en este ejemplo de nginx:

# Un solo salto desde cada variante hasta https://www.example.com
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}
server {
    listen 443 ssl;
    server_name example.com;
    # líneas ssl_certificate omitidas
    return 301 https://www.example.com$request_uri;
}

4. Actualiza los enlaces en el origen. Cambia los enlaces internos, las etiquetas canónicas, las anotaciones hreflang y los sitemaps XML a las URLs finales; la guía de Google para mover un sitio pide actualizar los enlaces internos a las nuevas URLs. Las redirecciones deben atrapar los enlaces antiguos de otros sitios, no sostener tu propia navegación.
5. Mantén las redirecciones. Google sugiere mantenerlas todo el tiempo posible, en general al menos un año. Acortar una cadena significa cambiar su destino, no borrar las reglas antiguas.
6. Vuelve a probar. Ejecuta de nuevo las mismas URLs, a ser posible con la opción de variantes marcada, y confirma que cada una llega a una página 200 en un solo salto.

Cómo arreglar un bucle de redirección

Un bucle es una cadena que vuelve a una URL que ya visitó, así que nunca termina; los navegadores muestran un error de demasiadas redirecciones. Las causas habituales son dos capas que no se ponen de acuerdo: una CDN que habla con el servidor de origen por HTTP mientras el origen fuerza HTTPS, una regla de barra final en el servidor web que choca con la regla contraria en la aplicación, o reglas de www configuradas a la vez en el reenvío a nivel de DNS y en el propio sitio. Fíjate en el salto donde la URL vuelve atrás; sus encabezados Server y X-Redirect-By suelen decirte qué capa lo envió. Algunos bucles solo ocurren sin cookies (redirecciones de consentimiento o de inicio de sesión) y no afectan a los visitantes que ya las tienen; el comprobador no envía cookies, así que también los saca a la luz.

Comprobar redirecciones en bloque

Pega hasta 10 URLs, una por línea, para comprobarlas en una sola ejecución; los duplicados se eliminan y cada URL recibe su propio resultado. La exportación CSV tiene una fila por salto con la URL de entrada repetida, así que puedes filtrar por estado, ordenar por número de saltos o pasarle el archivo a quien gestione las reglas de redirección. Si quieres revisar enlaces antiguos guardados en el navegador, primero exporta tus marcadores de Chrome a un archivo HTML y copia de ahí las URLs que te interesen. Para un sitio entero, usa un rastreador o los registros de tu servidor para encontrar las URLs redirigidas y luego revisa aquí las importantes con el user agent de Googlebot.

HTTPS, www y barras finales

La mayoría de los sitios deberían responder en una sola combinación de protocolo y nombre de host, con todas las demás formas redirigiendo a ella de forma permanente y en un solo salto. La opción de variantes comprueba http://example.com, https://example.com,http://www.example.com y https://www.example.com con la misma ruta, e indica si las cuatro terminan en la misma URL y cuántos saltos necesita cada una. Los avisos señalan un paso a HTTPS que llega tarde en la cadena, una cadena que cambia entre www y sin www más de una vez, y saltos que solo añaden o quitan una barra final o cambian mayúsculas y minúsculas, que son fáciles de integrar en la primera redirección.

Por qué los resultados pueden diferir de tu navegador

Si tu navegador llega a otro sitio, normalmente es porque recuerda algo. La RFC 9110 permite guardar en caché una 301, así que un navegador puede saltarse una redirección antigua, o seguir aplicando una que ya quitaste. Cuando un navegador ha visto el encabezado HSTS de un sitio (o el sitio está en la lista de precarga HSTS), cambia http:// por https:// internamente antes de que ninguna solicitud salga de tu equipo. Las cookies, tu idioma y tu ubicación pueden activar sus propias redirecciones. El comprobador empieza limpio cada vez y muestra lo que envía el servidor, que es la vista que importa para los rastreadores y para quien visita el sitio por primera vez.

Cómo funciona el comprobador

Cada salto es una solicitud GET desde el servidor de Marqly en Cloudflare con las redirecciones en modo manual, así que no se sigue nada hasta que el comprobador lo ha registrado. Cada nombre de host se resuelve y debe apuntar a una dirección pública; se rechazan las redes privadas, localhost y las direcciones de metadatos de la nube, también cuando una redirección apunta a una de ellas a mitad de la cadena. Cada salto tiene un tiempo límite de 6 segundos, una cadena completa se detiene a los 20 segundos o a las 10 redirecciones, y el contenido de las páginas se descarta salvo los primeros 64 KB de una página HTML final, que se analizan en busca de un meta refresh. No se guarda nada: los resultados existen solo en la pestaña de tu navegador.

Si preparas enlaces de campaña, el generador de UTM los crea y este comprobador confirma que los parámetros sobreviven a cada salto. Para equipos que publican y migran páginas a menudo, Marqly también sirve como archivo de referencia: mira cómo lo usan losdesarrolladores para guardar documentación y los equipos demarketing para reunir landings, campañas y competencia en un solo lugar.