Velocidad de redirección: por qué las redirecciones son lentas y cómo solucionarlo
Respuesta directa
Un solo redireccionamiento servido cerca del visitante añade solo decenas de milisegundos. Los redireccionamientos se vuelven lentos cuando están encadenados (cada salto es otra solicitud y, a menudo, otra conexión), cuando se ejecutan dentro de una aplicación lenta en lugar de en el servidor o en el borde, o cuando el servidor está lejos del visitante. Apunta cada redireccionamiento directamente a la URL final, incluido https, el host correcto (con www o sin él) y la barra final, ejecútalo en el servidor o en el borde, y prueba el resultado con una prueba de velocidad de redireccionamientos.
¿Un redireccionamiento ralentiza tu sitio web?#
Un poco, cada vez. Antes de que el navegador pueda empezar a cargar la página real, tiene que enviar una solicitud a la URL القديمة, esperar la respuesta de redireccionamiento y luego empezar de nuevo en la nueva dirección. Ese tiempo forma parte de la carga de la página: la métrica Time to First Byte de Google cuenta el tiempo de redireccionamiento como su primera fase, y considera 0,8 segundos o menos como un TTFB bueno[1]. Cada milisegundo que tarda un redireccionamiento es un milisegundo menos para todo lo demás.
Un redireccionamiento rápido rara vez es el problema. Varios seguidos sí lo son: Lighthouse marca una página con dos o más redireccionamientos, porque cada viaje de ida y vuelta adicional puede retrasar la carga en cientos de milisegundos[2], especialmente en redes móviles.
Los motores de búsqueda también siguen los redireccionamientos. Google dice que Googlebot generalmente sigue 10 saltos de redireccionamiento[3], así que una cadena corta todavía se rastreará, pero cada salto es otra solicitud para el rastreador y otra oportunidad de que algo en la cadena falle.
Qué hace lento a un redireccionamiento#
La respuesta de un redireccionamiento es pequeña, así que su tiempo es casi todo espera: buscar el dominio, abrir una conexión, el saludo HTTPS y que el servidor decida a dónde enviar al visitante. Estas son las razones habituales que lo hacen acumularse:
| Cause | Por qué cuesta tiempo | Fix |
|---|---|---|
| Cadena de redireccionamiento | Cada salto es una solicitud y respuesta completas; un salto a otro host también necesita una nueva búsqueda DNS, conexión y handshake TLS | Dirige la primera redirección directamente a la URL final |
| Falta https, www o la barra final en el destino | El sitio de destino añade su propia redirección para corregir la URL | Copia la URL final exacta en la regla de redirección |
| Servidor lejos del visitante | Cada ida y vuelta cruza la distancia de nuevo, varias veces por salto | Sirve las redirecciones desde una CDN o red perimetral cerca de los visitantes |
| Redirección gestionada por la aplicación | Un plugin del CMS o el código de la aplicación tiene que iniciarse, cargar la configuración y a menudo consultar una base de datos antes de responder | Mueve las redirecciones al servidor web, a las reglas del CDN o a un servicio de redirección |
| Meta refresh o redirección de JavaScript | El navegador tiene que descargar y empezar a renderizar una página antes de poder abandonarla | Usa en su lugar un HTTP 301 o 302 |
| HTTP sin cifrar primero | HTTP a HTTPS es un salto extra en cada primera visita | Enlaza a URLs HTTPS y activa HSTS en tu sitio |
Cadenas de redirecciones: la causa más común#
Una cadena de redirecciones es una redirección que lleva a una URL que vuelve a redirigir. La mayoría son accidentales: alguien configura una redirección a https://mybrand.com, pero el sitio en sí vive en https://www.mybrand.com/en/, así que el visitante rebota dos veces más antes de ver algo.
Sucede mucho más a menudo de lo que la gente espera. Cuando comprobamos una muestra de redirecciones de dominios activos en nuestra plataforma, alrededor de una de cada tres enviaba a los visitantes a un destino que volvía a redirigir. El salto extra se repartía de forma bastante equilibrada entre añadir o quitar www, un cambio de ruta en el mismo sitio (una barra final, una carpeta de idioma o una página de inicio de sesión) y un traslado a un dominio completamente distinto (datos de la plataforma RedirHub, octubre de 2026). Ninguno de esos saltos era necesario: copiar la URL final en la redirección los elimina.
Cómo encontrar y corregir una cadena de redirecciones#
- Introduce la URL antigua en nuestra prueba de velocidad de redirecciones. Enumera cada salto con su código de estado y muestra el número de saltos.
- Si hay más de un salto, copia la URL final que se muestra en «Dónde termina».
- Cambia el destino de la redirección a esa URL exacta: https, el mismo host (con o sin www) y la misma barra final.
- Actualiza los enlaces internos, las etiquetas canónicas y tu mapa del sitio para que también usen la URL final, en lugar de pasar por la redirección.
- Vuelve a probar. El resultado debería mostrar un salto y un 200 al final.
¿Tu redirección funciona? Introduce tu dominio. Verás el código de estado (301 o 302), a dónde llega, si HTTPS es válido y qué tan rápido responde desde Washington, Fráncfort y Tokio, comparado con todas las redirecciones probadas en los últimos 7 días.
Probar mi redirecciónLas cadenas se acumulan después de cada cambio de sitio, porque se añaden nuevas redirecciones encima de las antiguas. Cuando planifiques una migración de sitio web, redirige las redirecciones antiguas a las nuevas URL finales en lugar de encadenarlas. Si una redirección no funciona en absoluto, consulta por qué una redirección 301 no funciona.
Cómo hacer más rápidas las redirecciones#
- Un solo salto, siempre. Esta es la mayor mejora y no cuesta nada.
- Redirige antes de la aplicación. Las reglas en Nginx, Apache, tu CDN o un servicio de redirección responden antes de que se ejecute cualquier código de la aplicación. Un plugin de redirección que carga primero todo tu CMS es el lugar más lento para hacerlo.
- Responde cerca del visitante. Una redirección desde un solo servidor en una región es rápida cerca y lenta al otro lado del mundo. Una red de edge responde desde la ubicación más cercana.
- Usa redirecciones HTTP, no meta refresh ni JavaScript. Un 301 o 302 se responde en una sola respuesta breve; una página que se redirige a sí misma tiene que cargarse primero.
- Evita el salto http. Enlaza a URLs https y activa HSTS en tu sitio web para que los navegadores recurrentes vayan directamente a https sin preguntar antes a la red.
- Elige 301 cuando el cambio sea permanente. Ambos responden igual de rápido, pero los navegadores pueden almacenar en caché un 301, así que los visitantes recurrentes pueden omitir por completo la solicitud.
¿Qué tan rápida debe ser una redirección?#
Nuestra prueba de velocidad de redirecciones mide solo la respuesta de la redirección (el tiempo hasta el primer byte, sobre una conexión nueva) desde Washington D. C., Fráncfort y Tokio, y la compara con cada redirección probada en los últimos siete días. El 24 de octubre de 2026, el promedio de siete días fue de 157 ms. Según el proveedor, las medianas oscilaron desde unos 10 ms para las CDN más grandes hasta más de 500 ms para los servicios de enlaces cortos más lentos, y la propia redirección de RedirHub respondió en 17 ms. Algunos proveedores solo tuvieron una o dos URL probadas, así que lee la lista de proveedores como una guía, no como una tabla de clasificación.
Como regla general, una redirección de menos de 100 ms no se notará. Unos pocos cientos de milisegundos merece la pena corregirlo en páginas donde la velocidad importa, como anuncios, campañas de correo electrónico y tráfico móvil. Y una cadena multiplica lo que cueste cada salto.
RedirHub: redirecciones rápidas sin ejecutar un servidor#
Si los dominios que rediriges no están alojados en ningún sitio (marcas antiguas, dominios de campañas, dominios con errores tipográficos), RedirHub responde las redirecciones por ti desde 130 ubicaciones perimetrales globales, cerca de cada visitante, en un solo salto al destino que configures. Solo cambias los registros raíz y www, así que DNS y correo permanecen donde están, y ambos obtienen HTTPS automático emitido y renovado para ti.
| Tu propio servidor o complemento de CMS | RedirHub | |
|---|---|---|
| Dónde se responde la redirección | Dondequiera que esté el servidor | 130 ubicaciones perimetrales globales, cerca de cada visitante |
| HTTPS para el dominio antiguo | Instalas y renuevas certificados | Emitido y renovado automáticamente para raíz y www |
| Paths | Reglas de reescritura que mantienes | Mantén la ruta o asigna cada URL antigua a su propia nueva página |
| Tipos de redirección | Lo que configures | Redirecciones 301, 302, 307, 308 y de marco |
| Muchos dominios o URL | Un archivo de configuración o la pantalla del plugin | Varios dominios de origen por redirección; importación CSV en todos los planes |
| Visibility | Registros del servidor | Clics y visitantes únicos con los bots filtrados; DNS verificado de nuevo cada 10 minutos |
| Price | Tu alojamiento web | Desde $49/mes (Core), prueba gratuita de 14 días |
Eso es más útil cuando gestionas muchos dominios: un portafolio de dominios redirigidos, o miles de URL antiguas cargadas con una importación masiva de CSV. Si tu sitio ya está detrás de una CDN con reglas de redirección, estas son igual de rápidas, y no necesitas otro servicio para las redirecciones de ese sitio.
Lista de comprobación de velocidad de redirección#
- Cada redirección lleva su página final en un solo salto.
- Los destinos usan la URL final exacta: https, el host correcto y la barra final correcta.
- Las redirecciones se ejecutan en el servidor web, la CDN o un servicio de redirección, no en el código de la página.
- Los enlaces internos, las etiquetas canónicas y los sitemaps apuntan a las URL finales.
- Las redirecciones clave se vuelven a probar después de cada cambio o migración del sitio.
¿Qué tan rápida es tu redirección? Prueba una URL y observa su tiempo hasta el primer byte desde tres continentes, cada salto que realiza y cómo se compara con todas las redirecciones probadas en los últimos 7 días.
Ejecutar la prueba de velocidadFuentes
Preguntas frecuentes
Un poco. El navegador tiene que solicitar la URL القديمة y recibir la redirección antes de poder cargar la nueva página, y ese tiempo cuenta para el Time to First Byte. Una sola redirección respondida cerca del visitante suele costar solo decenas de milisegundos; las cadenas y los servidores lejanos son lo que la hacen perceptible.
Una redirección rápida responde en bastante menos de 100 ms. El 24 de octubre de 2026, el promedio de las redirecciones probadas en nuestra prueba de velocidad de redirecciones durante los siete días anteriores fue de 157 ms, con los proveedores más rápidos en torno a 10 a 20 ms y los más lentos por encima de 500 ms.
Más de una. Lighthouse marca las páginas con dos o más redirecciones, y cada salto adicional añade otra solicitud. Google dice que Googlebot generalmente sigue 10 saltos de redirección, pero intenta usar una sola redirección directamente a la URL final.
Cadenas de redirecciones, destinos que redirigen de nuevo (https, www o una barra final faltantes), servidores lejos del visitante, redirecciones gestionadas por un plugin del CMS o por código de la aplicación en lugar del servidor web o la CDN, y redirecciones meta refresh o JavaScript que necesitan que una página cargue primero.
La respuesta en sí es igual de rápida. La diferencia es el almacenamiento en caché: los navegadores pueden almacenar en caché una 301, así que un visitante recurrente puede saltarse la solicitud de redirección, mientras que una 302 normalmente se solicita de nuevo cada vez. Elige según el significado: 301 para movimientos permanentes, 302 para los temporales.
Una conexión HTTPS necesita un handshake de TLS, lo que añade un viaje de ida y vuelta, así que una redirección sobre https tarda un poco más que la misma redirección sobre http sin cifrar. El coste mayor es un salto adicional de http a https; enlaza a URLs https y habilita HSTS para que los navegadores vayan directamente a https.
Introduce la URL en una prueba de velocidad de redirecciones que cronometre la propia respuesta de la redirección, desde más de una ubicación, y enumere cada salto. La prueba de velocidad de redirecciones gratuita de RedirHub mide desde Washington, D.C., Frankfurt y Tokio y clasifica el resultado frente a todas las redirecciones probadas en los últimos 7 días.
RedirHub responde a las redirecciones desde 130 ubicaciones globales de edge, cerca de cada visitante, en un solo salto al destino que configuras, con HTTPS emitido automáticamente. Solo cambias los registros DNS de la raíz y de www, así que nada más de tu dominio se mueve.
TC is the Operations Manager at RedirHub, leading the company’s operational strategy and execution to ensure reliable, scalable redirect infrastructure. He oversees internal processes, cross-team coordination, and platform readiness while supporting customers through complex redirect implementations. With a strong understanding of large-scale domain operations and real-world edge cases, TC plays a key role in aligning product and customer success to deliver stable, high-performance redirection solutions.
Artículos Relacionados
Ver Todos los Artículos
