Ir al contenido 
Rendimiento de la redirección HTTP determina de forma mensurable la rapidez con la que los usuarios y rastreadores llegan a sus URL de destino y cuánta autoridad se conserva al cambiar. En esta guía, te mostraré estrategias 301 y 302 específicas que reducen la latencia, SEO y evitar fuentes de error.
Puntos centrales
Resumo brevemente las directrices más importantes antes de entrar en más detalles. De este modo, se obtiene primero un hilo conductor y se pueden establecer prioridades. Me centro en la selección del código adecuado, la minimización de las rutas de redireccionamiento, las estrategias de caché y el diagnóstico. Luego paso a la implementación en configuraciones de alojamiento, monitorización y rendimiento móvil. Todas las recomendaciones tienen como objetivo minimizar la latencia, una indexación limpia y un rendimiento estable. Experiencia del usuario.
- Selección de código301 para permanente, 302/307 para temporal.
- Desmontar cadenasCada etapa cuesta tiempo y presupuesto.
- Cabecera caché: 301 caché largo, 302 mantener corto.
- Objetivos 1:1Las páginas de destino relevantes aseguran la clasificación.
- MonitoreoComprobar cuota 3xx, TTFB y bucles.
Me baso en reglas sencillas y caminos directos. Así es como mantengo el Latencia baja y evitar desvíos que prolonguen el tiempo de carga.
301 vs. 302: Efecto en SEO, caché y UX
A 301 señales de forma permanente, a 302 sólo temporalmente: esta elección determina el flujo de autoridad, el almacenamiento en caché y la experiencia del usuario. 301 transfiere la mayor parte del poder de enlace y suele ser más cacheado por el navegador. 302 mantiene el origen en el foco, lo que es útil para las pruebas, pero se vuelve a comprobar en cada visita. Para cambios permanentes como HTTPS, nueva estructura o traslado de dominio, utilizo 301. Para campañas, ventanas de mantenimiento o pruebas incrementales, utilizo 302 o 307 si se debe conservar el método de solicitud.
| Tipo de redirección | Señal | Transferencia SEO | Almacenamiento en caché | Utilice |
|---|---|---|---|---|
| 301 | Permanente | Alta | Fuerte | Migración, estructura, HTTPS |
| 302 | Temporal | Limitado | Débil | Pruebas A/B, acciones |
| 307 | Temporal | Medio | Débil | Recibir formulario-POST |
| 308 | Permanente | Alta | Fuerte | API, método de recepción |
Siempre elijo el código de estado por intención, no por costumbre. Así evito Ranking de pérdidas y reducir las repeticiones.
Costes de rendimiento: cada redirección cuenta
Cada reenvío provoca Viajes de ida y vueltaDNS, handshake, solicitud y respuesta. Incluso un solo paso suele costar entre 100 y 300 ms, dependiendo de la red y la distancia. En redes móviles, el impacto aumenta rápidamente, especialmente con múltiples saltos. Las redirecciones de recursos (CSS, JS, imágenes) son doblemente perjudiciales porque retrasan la renderización crítica. Por eso reduzco las redirecciones a un solo paso y mantengo todos los recursos directamente accesibles.
Acorto aún más las rutas agrupando los cambios de protocolo. Un 301 limpio de http:// a https:// y la normalización paralela www/no-www ahorra Solicitudes. Con HSTS, reduzco los futuros costes de redireccionamiento porque el navegador favorece directamente HTTPS. Una redirección de borde en el nodo CDN merece la pena para los usuarios internacionales. Esto minimiza el tiempo de espera antes de que se cargue la página.
Evitar las cadenas de redireccionamiento: Diagnóstico y acortamiento
Regala cadenas como A → B → C Presupuesto y el tiempo. Primero compruebo las URL de inicio, la navegación principal, los sitemaps internos y las páginas de destino enlazadas con frecuencia. Luego abro los registros de red en el navegador y sigo todas las respuestas 3xx. Abordo cada paso en su origen y conduzco directamente de A a C hasta que la cadena desaparece. El grado de ralentización de las cadenas se explica en este artículo sobre Por qué las cadenas de redireccionamiento aumentan el tiempo de carga vívidamente.
A continuación, limpio los enlaces internos para que no se creen nuevos saltos. Esto hace que el trabajo merezca la pena por partida doble: los robots llegan rápidamente a la URL final y los usuarios ahorran tiempo de clic. También compruebo las reglas del servidor en busca de condiciones duplicadas. Las excepciones que faltan a menudo crean bucles o Lúpulo. Otro rastreo al final confirma que todo termina en un solo paso.
Migración HTTPS sin rodeos
Para el cambio a HTTPS, establecí un parámetro global 301 de todas las rutas http al equivalente https. Al mismo tiempo, defino una canónica (con o sin www) y reenvío sistemáticamente la variante alternativa. Actualizo los enlaces internos, sitemaps y canonicals para que no queden saltos ocultos. Tras la puesta en marcha, activo HSTS cuando todos los subdominios están listos. Encontrará información más detallada en este artículo sobre Rendimiento de la redirección HTTPS con frecuentes errores de configuración.
A continuación, compruebo si las API, los webhooks y las devoluciones de llamada de pago siguen funcionando correctamente. Las rutas POST, en particular, a menudo necesitan 307/308 para que el método permanezca intacto. Bloqueo de forma proactiva el contenido mixto para evitar las devoluciones a http. Elimino los certificados antiguos para que los clientes no puedan utilizar Advertencias ver. Al final, compruebo las estadísticas 3xx y TTFB hasta que los valores sean estables.
Estrategias de caché y CDN
Con unas cabeceras de caché adecuadas, un 301 la primera redirección a futuras llamadas directas. Establezco una validez larga para 301 y la mantengo corta para 302 con el fin de seguir siendo flexible. En la CDN, muevo las reglas al borde para que los usuarios reciban la URL final en el siguiente nodo. Las peticiones de origen disminuyen, el tiempo hasta el primer byte es más corto. También compruebo si las cookies o las cabeceras Vary eluden innecesariamente las cachés.
Para un tráfico elevado, elijo un alojamiento 301 302 con E/S rápida para que los redireccionamientos respondan sin demora. Las reglas de borde ahorran viajes de ida y vuelta al origen y reducen los picos de carga. Evito las reglas duplicadas entre CDN y origen porque crean saltos. Las regiones de prueba revelan claramente diferencias de latencia. Esto significa que fluye más presupuesto hacia el contenido y menos hacia marcha en vacío.
Implementación del lado del servidor: Apache, Nginx, WordPress
Priorizo los redireccionamientos en el servidor porque reacciona más rápido y guía a los bots de forma fiable. En Apache, una breve regla de reescritura en el .htaccess suele ser suficiente. En Nginx, utilizo return o rewrite directamente en la configuración del servidor. Para casos especiales, trabajo con cabeceras PHP, pero no confío en los saltos JavaScript del lado del cliente. Una buena visión general de las prioridades se puede encontrar en esta guía para Reenvío de dominios y rendimiento.
# Apache (.htaccess)
RewriteEngine Activado
# Directo 301 de la antigua a la nueva URL
RewriteRule ^url-antigua$ /url-nueva [R=301,L]
# Nginx (contexto de servidor)
location = /old-url {
return 301 /nueva-url;
}
# PHP (como fallback)
header("Ubicación: https://example.com/neue-url", true, 301);
salir;
En WordPress, evito demasiadas reglas de plugin y prefiero almacenar las rutas principales en el servidor. Divido los grandes conjuntos de reglas según patrones para que la evaluación siga siendo rápida. Utilizo los marcadores de posición con moderación para minimizar los costes de regex. Mantengo el número de condiciones bajo y uso clear Prioridades. Tras el despliegue, compruebo la secuencia con solicitudes reales.
Control, medición y diagnóstico de averías
Mido los efectos de redirección con rizo (-I, -L), devtools del navegador, registros del servidor y comprobaciones externas. Los factores decisivos son el número de saltos, TTFB, aciertos de caché y estado HTTP. También controlo la tasa de 3xx en Analytics y los archivos de registro. Los picos notables indican nuevas cadenas o bucles. Comprobado desde varias regiones, reconozco las diferencias de latencia y los fallos de CDN.
Configuro advertencias para acciones 301/302 por encima de un umbral definido. Un rastreo regular descubre antiguos enlaces internos que siguen redireccionando. Para las campañas, establezco fechas de finalización para que los 302 se eliminen una vez finalizadas. Para las rutas API, compruebo si 307/308 funcionan correctamente. Compruebo cada corrección inmediatamente con un nuevo Solicitar.
Rendimiento móvil y vitalidad de la web
En el smartphone, más Viajes de ida y vuelta particularmente notable. Cada salto retrasa el LCP y desplaza la estabilidad visual. Por lo tanto, mantengo todas las rutas críticas sin redireccionamiento y entrego los activos importantes directamente. Si es necesario, utilizo la preconexión al dominio de destino y reduzco el tiempo de DNS. Para los usuarios que vuelven, HSTS evita el salto de protocolo en futuras llamadas.
Evito las redirecciones a recursos que se utilizan por encima del pliegue. Las imágenes y el CSS deben ser accesibles sin nuevas rutas. Establezco parámetros para archivos estáticos con moderación, porque de lo contrario las cachés de borde son menos precisas. Para los usuarios móviles, vale la pena un TTL ajustado en las pruebas 302 para que los cambios surtan efecto rápidamente. Esto mantiene el tiempo de carga y la interacción notable líquido.
Comercio electrónico: filtros, parámetros y campañas
Las tiendas dependen de muchos Parámetros pero cada redirección mal configurada cuesta ingresos. Actualizo las categorías con 301 para que lleguen las señales, mientras que las acciones temporales se ejecutan mediante 302. No reenvío ciegamente páginas de filtro, de lo contrario los usuarios pierden su contexto. Para los parámetros UTM, compruebo si el seguimiento funciona sin crear bucles de redireccionamiento. Desactivo las rutas temporales al final y redirijo a páginas de destino relacionadas con el tema.
Defino reglas claras: Producto eliminado, producto sustituido, producto agotado definitivamente. Cada una de estas situaciones requiere una redirección diferente. Utilizo canonicals y noindex cuando las variantes no deben clasificarse. Pruebo de antemano las URL de descuento fuerte con una sesión real para que se conserven las rutas de los formularios. Así, las UX consistente y baja fricción de conversión.
Errores comunes y soluciones rápidas
Un error común es la duplicación de reglas para protocolo y host, que juntas forman un Cadena forma. Combino ambas en una redirección y me ahorro un salto. Un segundo clásico: 302 para movimientos permanentes, lo que retrasa la indexación. Aquí cambio a 301 y mantengo la ruta activa durante mucho tiempo. En tercer lugar, los bucles de redirección bloquean el acceso, normalmente por falta de excepciones - corrijo específicamente esta condición.
La falta de actualización de los enlaces internos causa carga y costes. Corrijo la navegación, los pies de página, los sitemaps y los teasers populares inmediatamente. No utilizo saltos del lado del cliente mediante JavaScript o meta refresh porque son más lentos e inseguros para los bots. Detengo las redirecciones de recursos directamente en la fuente y ajusto las referencias en HTML y CSS. Esto elimina Obstáculos y el tiempo de visualización disminuye.
Arquitectura y prioridades de las normas
Organizo los redireccionamientos a lo largo de la cadena desde el usuario hasta la aplicación: DNS/CDN → WAF/equilibrador de carga → proxy inverso/servidor web → aplicación. Coloco las reglas con un alto índice de aciertos y baja complejidad lo antes posible (en la CDN/borde) y los casos individuales complejos más cerca de la aplicación. Esto ahorra viajes de ida y vuelta y mantiene las rutas de decisión cortas. Es importante que cada nivel conozca ya la URL canónica de destino: evito la duplicación o competencia de reglas entre la CDN y el origen mediante responsabilidades y pruebas claras.
Normalizo host, protocolo, ruta y minúsculas en un salto. Tengo en cuenta las excepciones (por ejemplo, rutas API, ruta de carga, área de administración) para evitar bucles. Marco claramente las reglas que evalúan parámetros de consulta y los protegen de errores de caché (Vary: cookie/agente de usuario solo si es absolutamente necesario).
Efectos de HTTP/2, HTTP/3 y TLS
Los protocolos influyen en los costes de redireccionamiento. Con HTTP/2, el sitio se beneficia de la multiplexación de la conexión, pero un 3xx adicional sigue siendo un retraso de ida y vuelta. Con HTTP/3 (QUIC), la reanudación 0-RTT ayuda con las revisitas, pero una redirección sigue costando tiempo y puede renegociar la conexión si cambia el host/puerto. Por tanto, aseguro ofertas ALPN coherentes (h2, h3) y establezco HSTS, para que las futuras llamadas seleccionen directamente HTTPS. Cuando procede, anuncio HTTP/3 a través de alt-svc para que los clientes cambien al protocolo óptimo más rápidamente. Mantengo las cadenas de certificados ligeras y activo el grapado OCSP para reducir aún más la latencia TLS durante la primera redirección.
Rutas por idiomas y países sin pérdidas de SEO
Para la internacionalización, me baso en una separación clara entre reconocimiento y reenvío. Para las visitas iniciales, un 302 a la ruta localizada, controlada a través de accept-language o geo-signals y asegurada con una cookie para que las llamadas posteriores puedan realizarse sin más redireccionamientos. Respeto los bots y los enlaces profundos al no forzar nunca una redirección cuando se llama a una URL en un idioma específico. Mantengo la coherencia de las señales de hreflang y utilizo una página predeterminada neutra sin salto forzado como alternativa. Esto mantiene el equilibrio entre la indexación, el control del usuario y el rendimiento.
Cadenas de consulta, normalización y alternativas de estado
Me aseguro de que el reenvío Cadenas de consulta correctamente, especialmente para los parámetros de campaña. En Nginx, aseguro esto con $is_args$args o $query_string, en Apache con las banderas apropiadas (por defecto es: mantener consulta, QSD eliminado deliberadamente). Elimino deliberadamente los parámetros superfluos en un solo paso si ya no tienen una función con el fin de aumentar las tasas de aciertos de la caché. En lugar de recurrir reflexivamente a 301, también configuro 410 Gone - esto acorta los ciclos de rastreo. Dirijo el contenido inexistente pero relacionado a alternativas sólidas. Evito específicamente los soft 404 (301 → página irrelevante) porque debilitan tanto la UX como las señales.
Mapas de redireccionamiento para grandes migraciones
Para relanzamientos extensos, trabajo con Asignaciones, que versiono e importo automáticamente. Para Nginx utilizo mapa-bloques o archivos de inclusión, para Apache Mapa de reescritura con backends de texto o DB. Esto permite mapear miles de rutas antiguas a nuevos destinos con un alto rendimiento sin tener que comprobar costosas regex en cada petición. Creo una comprobación de calidad por adelantado: cada URL antigua debe tener exactamente un destino, se define la gestión de consultas y se excluyen los conflictos. Una puesta en escena independiente valida la libertad de la cadena y los códigos de estado antes de que las reglas entren en funcionamiento.
# Nginx: Enrutamiento basado en mapas (ejemplo)
map $request_uri $redir_target {
/alt/ruta-1 /nuevo/ruta-1;
/alt/ruta-2 /nueva/ruta-2;
# ...
}
servidor {
if ($redir_target) {
return 301 $scheme://ejemplo.com$redir_target$is_args$args;
}
}
Ejemplo: Reenvío canónico en un solo paso
Combino la canonicalización del host y del protocolo de forma sencilla para evitar dobles saltos. Al mismo tiempo, resuelvo la normalización de las rutas (barra diagonal final, archivos de índice), con excepciones para los archivos.
# Nginx
servidor {
listen 80;
listen 443 ssl http2;
nombre_servidor www.example.com ejemplo.com;
# Una regla canónica host/HTTPS
if ($host != 'ejemplo.com') {
return 301 https://example.com$request_uri;
}
if ($scheme != 'https') {
return 301 https://example.com$request_uri;
}
# Barra oblicua final para directorios, pero no para archivos
if ($request_uri ~ ^(.+[^/])$) {
if ($uri ~ ^.*\.[a-zA-Z0-9]{2,5}$) { }
else { return 301 https://example.com$1/; }
}
}
# Apache
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^ejemplo.com$ [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]
# Barra oblicua final sólo para el aspecto "directorio
RewriteCond %{REQUEST_URI} !\.[a-zA-Z0-9]{2,5}$
RewriteCond %{REQUEST_URI} $
RewriteRule ^ https://example.com%{REQUEST_URI}/ [R=301,L]
API, webhooks y flujos de formularios
Los clientes máquina a menudo no siguen las redirecciones o pierden métodos/body. Para POST/PUT utilizo 307/308, para que el método permanezca intacto. En la medida de lo posible, mantengo estables las URL de destino de los webhooks y evito por completo las redirecciones. Para el mantenimiento, utilizo 503 con reintento posterior en lugar de 302 para que los remitentes redirijan correctamente. Documento las expectativas de redirección para las integraciones, pruebo con HEAD y compruebo que las cabeceras de autorización en los clientes persisten a través de las redirecciones.
Seguridad: redireccionamientos abiertos y control de caché
Prevengo Redirecciones abiertas, mediante una lista blanca estricta de parámetros de destino para hosts/rutas permitidos. Normalizo las rutas relativas en el servidor y descarto los destinos externos absolutos si no están permitidos explícitamente. Para las redirecciones dinámicas y dependientes del usuario, minimizo los riesgos de la caché: no configuro cabeceras de caché de larga duración, y Vary sólo es tan amplio como sea necesario. Para las rutas sensibles, evito el envenenamiento de la caché separando claramente las cookies y el estado de autorización y no haciendo depender las redirecciones de cabeceras manipulables.
Trabajadores de servicios, SPA y reescrituras
En las aplicaciones de una sola página, separo claramente las reescrituras de navegación (internas del servidor, 200) de las redirecciones reales (3xx). El servidor debe entregar las rutas /app sin un salto, mientras que las URL antiguas y públicas van a nuevos destinos semánticos mediante 301. En el service worker, me aseguro de que no se almacenen en caché respuestas de redireccionamiento involuntarias y compruebo los gestores de obtención para que las solicitudes de navegación no acaben en bucles. En el caso de los documentos críticos para el SEO, prefiero los 301 del lado del servidor a los saltos de enrutador del lado del cliente para transmitir las señales de forma fiable.
Configuración fina: minúsculas, codificación y ficheros índice
Las mayúsculas incoherentes, las barras inclinadas dobles o las diéresis codificadas incorrectamente reducen el rendimiento y crean variantes duplicadas. Normalizo las rutas (por ejemplo, las redirecciones en minúsculas), garantizo la codificación UTF-8 correcta en los destinos y elimino las secuencias de barras inclinadas duplicadas en un solo paso. Dirijo los archivos de índice (index.html, index.php) a la URL del directorio y me aseguro de que en las plantillas se enlace exactamente esta forma canónica. Los activos con extensiones de archivo se excluyen de estas reglas para evitar saltos innecesarios.
Estrategia de retroceso y navegadores “casados” con 301
Desde el navegador 301 menudo caché persistente, planifico un camino de vuelta. En las fases de prueba, utilizo inicialmente 302/307, y sólo cambio a 301/308 cuando se aprueba. Si se activa un 301 incorrecto, lo anulo con una nueva regla más específica, proporciono la URL de destino correcta sin más saltos y corrijo los enlaces internos. Informo al equipo y al soporte de que las cachés locales/listas HSTS pueden ser la causa de un comportamiento desviado y espero a que la mayoría vuelva a resolverse correctamente.
Profundizar en la medición: Presupuestos y segmentación
Defino presupuestos: máximo una redirección por navegación, TTFB objetivo por debajo de X ms, tasa 3xx por debajo de Y por ciento. Hago mediciones separadas por tipo de dispositivo, región y tipo de página (página de inicio, categoría, producto, pago). Las pruebas sintéticas revelan cadenas estructurales, el RUM muestra efectos reales en LCP/INP/FID. En los registros, marco las respuestas de redirección con cubos de latencia y los correlaciono con el estado de la caché (HIT/MISS/BYPASS). En caso de desviaciones, ajusto secuencias, excepciones y reglas de borde hasta que las curvas se estabilizan.
Lista de control de calidad antes de la puesta en marcha
- Todas las URL principales probadas: 200 sin desvíos, o un único 301/308 a la URL de destino final.
- Sin cadenas A→B→C, sin mezcla de reglas de protocolo y host en saltos separados.
- Las cadenas de consulta y los fragmentos se transfieren correctamente, los parámetros de campaña se conservan.
- APIs/webhooks/formularios: Método conservado para redirecciones (307/308), cuerpos intactos.
- Reglas de borde y origen sin conflictos, casos de prueba idénticos en ambos niveles.
- HSTS activo después de la terminación HTTPS, precarga sólo cuando está completamente preparado.
- Enlaces internos, canonicals, sitemaps actualizados; no más 3xx internos.
- Alarmas de monitorización establecidas para cuota 3xx y TTFB; prueba desde varias regiones.
Resumen y próximos pasos
Primero doy prioridad a la Selección del código apropiado, luego acortando todas las rutas a exactamente un salto. A continuación, aseguro el almacenamiento en caché: 301 largo, 302 corto, reglas de borde en el borde CDN. Al mismo tiempo, limpio los enlaces internos, sitemaps y canonicals para que las peticiones lleguen directamente. Mido TTFB, 3xx share y LCP hasta alcanzar valores estables. Por último, planifico auditorías a intervalos regulares para que las cadenas, los bucles y las pruebas temporales no se conviertan en obras permanentes.
Esta secuencia mantiene las redirecciones limpias, las señales de búsqueda intactas y las páginas rápidas. Así es como aumento el rendimiento de las redirecciones HTTP de forma mensurable y permanente. Cada corrección repercute en la experiencia del usuario, la eficacia del rastreo y la carga del servidor. Mantengo las reglas lo más concisas posible y las compruebo sistemáticamente. Esto ahorra tiempo, presupuesto y protege el Recursos.
