Cadenas de redirección: Cómo Ocurren, Cuánto Cuentan, Cómo Aplanarlas

Una cadena de redirección es el raro defecto técnico que se oculta tras una luz verde. Escribe el URL, obtén la página, estado 200 — cada prueba ordinaria pasa, porque cada cliente HTTP ordinario sigue toda la cadena silenciosamente y solo informa dónde terminó. Los saltos intermedios existen, se facturan en cada obtención, y nada en un navegador te dice cuántos hubo.

Un hallazgo útil de redirección muestra la entrada URL, destinos intermedios y página final. Ese registro permite al equipo responsable decidir qué regla debe enviar la solicitud original directamente al destino previsto. La observación también es fácil de verificar después de una reparación: inspecciona la secuencia de nuevo y compárala con la ruta guardada.

Una cadena de 4 saltos se arma a partir de 4 decisiones correctas separadas

Las cadenas acumulan una capa a la vez, y cada capa gana su lugar cuando llega:

1. TLS llega. Alguien añade una regla de borde enviando http:// a https://. El destino previsto ahora usa HTTPS.
2. Se elige un host canónico. El equipo estandariza en www, así el ápice redirige a él. El nombre de host hermano debería llevar al mismo destino previsto.
3. Se normalizan las barras finales. Un marco o el valor predeterminado CDN añade una regla que agrega o quita la barra final. Los enlaces publicados y las entradas del mapa del sitio deberían usar el estilo previsto de manera consistente.
4. Se lanza la internacionalización. Las rutas raíz comienzan a enrutar a un prefijo de localización, /blog/ a /en/blog/. Las páginas localizadas necesitan URLs estables distintas, aunque una redirección desde la raíz sea una elección de diseño del sitio.

Eso son 4 reglas correctas, y ahora http://example.com/blog llega a su destino a través de 4 redirecciones. Una migración CMS que reescribe /blog/* a /articles/* agrega un 5º sin tocar ninguno de los primeros 4, porque se implementa en la aplicación mientras que los demás viven en el borde, el servidor web y el router. Las reglas se disparan en el orden en que la solicitud atraviesa la pila, no en el orden que resolvería el URL más rápido. Nadie posee la composición.

Esto también explica por qué el resultado http‑to‑https en nuestros propios datos debe leerse con cuidado. Entre el 23 de mayo y el 31 de agosto de 2026, la normalización de HTTP‑a‑HTTPS se marcó en el 44 % de 171 evaluaciones pero solo en el 8 % de 48 sitios distintos. El nivel de sitio 8% es la cifra de prevalencia; la cifra de evaluación describe nuestras observaciones, no la web. Se evalúa una comprobación cada vez que se ejecuta una auditoría, por lo que un puñado de sitios auditados repetidamente mientras el defecto persistía contribuyen con muchas evaluaciones fallidas cada uno, y elevan la tasa de evaluación mucho por encima de la proporción de sitios afectados. Citar el 44% como "44% de sitios" sobrestimaría la prevalencia por más de un factor de 5.

Google sigue hasta 10 saltos y aconseja mantenerse por debajo de 5

El presupuesto de saltos está documentado, no es folklore. La documentación de rastreo de Google indica que por defecto sus rastreadores siguen hasta 10 saltos de redirección, y señala que los productos individuales difieren — las Herramientas de Inspección de Google no siguen redirecciones en absoluto. La guía de migración de sitios es más directa: Googlebot puede seguir hasta 10 saltos, pero "recomendamos redirigir directamente al destino final. Si esto no es posible, mantenga el número de redirecciones en la cadena bajo, idealmente no más de 3 y menos de 5." La documentación del presupuesto de rastreo lo reduce a una línea: evite cadenas de redirección largas, que tienen un efecto negativo en el rastreo.

El costo se divide en 3 partes, y tienen peso desigual:

Eficiencia de rastreo. Cada salto es una solicitud que el rastreador de Google gasta sin recibir contenido — la documentación es explícita en que el contenido devuelto por un URL redirigido se ignora y solo se procesa el contenido del objetivo final. En un sitio de unas pocas cientos de URLs esto es ruido. En un sitio donde la cadena se sitúa en el patrón URL cada enlace interno usa, se multiplica a través de todo el rastreo y compite con el límite de capacidad de rastreo que el mismo host ya está sujeto a.

Latencia, en cada obtención no almacenada en caché. Un salto es un viaje completo de ida y vuelta: DNS puede ya estar cálido, pero la reutilización de la conexión termina en el momento en que un salto cambia de host, lo que el paso example.com a www.example.com hace por definición. Los usuarios sienten esto una vez y luego dejan de sentirlo, porque los navegadores almacenan en caché redirecciones permanentes. Las máquinas que obtienen de forma fría, sin una caché cálida, lo sienten cada vez.

Consolidación de señal, donde vive el folclore. La antigua afirmación es que cada salto derrama un porcentaje de equidad de enlace. Google lo contradijo públicamente en julio de 2016, cuando Gary Illyes afirmó de manera categórica que las redirecciones 30x no pierden PageRank, aclarando lo que John Mueller ya había dicho sobre los movimientos http‑to‑https al principio de ese año. La versión duradera de la preocupación es más estrecha y aún real: un 301 es la señal de canonización más fuerte disponible, y el valor de una redirección es que nombra un destino de manera inequívoca. Una cadena todavía nombra un destino, por lo que el argumento de equidad es el más débil de las razones 3 para aplanar. La eficiencia de rastreo y la latencia llevan el caso.

Los buscadores y agentes de IA manejan las cadenas con menos indulgencia que los navegadores

Los navegadores son los clientes de redirección más permisivos con los que un sitio será jamás probado. Siguen cadenas largas sin comentario, almacenan en caché redirecciones permanentes de manera agresiva y presentan el destino como si fuera el URL solicitado. Los clientes programáticos — la capa por la que realmente obtienen los asistentes de IA, pipelines de recuperación y agentes — varían de maneras que una prueba de navegador no puede revelar.

curl no sigue nada sin -L; una cadena devuelve un 301 desnudo y un cuerpo vacío. Los clientes de la biblioteca HTTP cada uno elige su propio techo de salto y su propio valor predeterminado para seguir o no, y esos valores predeterminados son establecidos por quien escribió el código de obtención, no por el sitio. Los clientes compatibles con la especificación descartan credenciales cuando una redirección cruza orígenes, lo cual es precisamente lo que hace un salto apex‑to‑www. La semántica del método también cambia: 301 y 302 tienen una larga historia de reescribir un POST en un GET, mientras que 307 y 308 conservan el método original — una distinción que importa en el momento en que un agente está enviando en lugar de leer.

Añade la restricción de presupuesto. Un resumidor o agente que trabaja una página bajo un límite de tiempo dedica parte de él a saltos que no devuelven contenido, y una obtención que excede un techo interno de saltos parece idéntica a un sitio que está caído. La cadena no se reporta a sí misma como una cadena; se reporta como un resultado vacío. Esa es la misma forma de fallo que los conflictos de directiva en nuestros datos de indexabilidad — el sitio funciona para las personas y declina silenciosamente trabajar para las máquinas.

Aplana en pasos 4: inventario, colapso, reenlace, mantén el mapa

1. Inventario de los recuentos reales de saltos. Mide, no razona sobre la configuración. Para un solo URL:

curl -sIL -o /dev/null -w '%{num_redirects} hops -> %{url_effective}\n' http://example.com/blog
curl -sILD - -o /dev/null http://example.com/blog | grep -iE '^(HTTP/|location)'

La primera línea da el recuento, la segunda la ruta. Ejecútalo contra los formularios http:// y https://, apex y www, con y sin una barra diagonal final, y contra un URL representativo de cada plantilla — la cadena suele vivir en un patrón, no en una página. Una auditoría hace el mismo recorrido en la página principal, el objetivo canónico, y el host alternativo en una sola pasada, y reporta la ruta trazada como evidencia.

2. Colapsa cada cadena a un solo 301. Toma la entrada URL y el destino final del inventario y escribe una regla que mapee el primero directamente al último, en la capa más externa que pueda ver ambos — normalmente el borde o CDN. Luego retira las reglas intermedias de las que estaba compuesta la cadena, en lugar de dejarlas en su lugar detrás de la nueva. Usa 301 para un traslado permanente, y 308 cuando el método debe sobrevivir. El objetivo debe ser un 200 que se declare canónico; un redireccionamiento que llegue a una página cuyo canónico apunta a otro lugar reinicia la ambigüedad en un vocabulario diferente, que es la interacción a través de la cual funcionan nuestras etiquetas canónicas.

3. Apunta los enlaces internos a las URLs finales. Una regla aplanada sigue costando un salto en cada enlace interno que nombre el antiguo URL. Los mapas del sitio, la navegación, las anotaciones hreflang, las etiquetas canónicas y los enlaces en el cuerpo deberían referenciar directamente el destino, de modo que el redireccionamiento exista solo para enlaces externos entrantes y marcadores antiguos. Este paso es lo que convierte una corrección de configuración en una ganancia de eficiencia de rastreo.

4. Mantén el mapa de la cadena. Registra cada regla retirada, su entrada URL, y su destino final en un solo archivo que viva con la configuración de infraestructura. Las cadenas se vuelven a formar porque la próxima persona que añada un prefijo de localización o migre un esquema de ruta no tiene forma de ver las 4 reglas ya presentes en la ruta de solicitud. El mapa es lo que hace visible la composición a quien sea que envíe la capa 5, y es la entrada para el siguiente inventario. El tratamiento completo por chequeo vive en nuestra guía de redireccionamientos y normalización URL.

Una capa de redireccionamiento aplanada es una de las pocas mejoras técnicas sin dependencia de contenido, sin retraso de clasificación, y con un paso de verificación que toma un solo comando. Sigue rota en tantos sitios porque ninguna prueba que alguien ejecute manualmente reporta los saltos. Una vez que una traza forma parte de la auditoría, el punto de unión entre las decisiones correctas de los equipos 4 se convierte en un hallazgo con una ruta, un estado por salto, y una regla para escribir.