Contents

Las reglas de redireccionamiento resuelven un problema común: las URL cambian. Los usuarios y los rastreadores todavía solicitan URL antiguas. Sin redireccionamientos, los enlaces antiguos generan errores 404.
Los redireccionamientos también controlan las URL duplicadas para el mismo contenido. Sin control, los motores de búsqueda pueden dividir las señales de clasificación entre variantes de URL. Las redirecciones faltantes o conflictivas provocan bucles, cadenas y 404 suaves.
Los usuarios pueden acceder a la página de inicio en lugar de a un reemplazo relevante. Esto aumenta las tasas de rebote y rompe la atribución. El búsqueda sufre cuando las redirecciones desperdician el presupuesto de rastreo y el rastreo es lento.
Las clasificaciones pueden caer cuando compiten duplicados. Las cadenas también añaden latencia para usuarios y bots. Los redireccionamientos respaldan la seguridad y el cumplimiento.
Los sitios deben forzar HTTPS, retirar puntos finales, bloquear rutas inseguras o mover áreas sensibles. Las reglas dispersas crean conflictos e implementaciones riesgosas.

Una regla de redireccionamiento asigna una solicitud a un nuevo destino. La regla verifica el esquema, el host, la ruta y la cadena de consulta. Algunas reglas también verifican el método o los encabezados.
En HTTP, una redirección utiliza un código de estado 3xx. La respuesta incluye un encabezado de Ubicación con la nueva URL. Luego, los clientes solicitan la URL de ubicación.
La mayoría de los sitios utilizan redireccionamientos del lado del servidor. Las CDN, los proxies y las aplicaciones pueden aplicarlas. Las redirecciones del lado del cliente dependen de HTML o JavaScript y debilitan la confiabilidad.
Las redirecciones del lado del servidor se ejecutan antes de que se cargue el contenido. Funcionan para cualquier tipo de recurso. También envían señales claras a los rastreadores.
Las redirecciones permanentes indican a los clientes que reemplacen la URL anterior con el tiempo. Las redirecciones temporales mantienen válida la URL anterior. Esta elección afecta el almacenamiento en caché y la indexación.

Las reglas hacen coincidir las solicitudes según rutas o patrones exactos. Los comodines y las expresiones regulares cubren muchas URL. Las capturas pueden reutilizar partes de la ruta en el objetivo.
Las reglas pueden normalizar hosts y esquemas. Por ejemplo, redirija https://prodigyfd.com/ a https://prodigydevelopmentcenter.com/. Redirigir HTTP a HTTPS.
Las reglas pueden requerir parámetros de consulta. El manejo de consultas debe ser explícito. Algunos sistemas mantienen las consultas de forma predeterminada y otros las descartan.
Conservar consultas para campañas y seguimiento. Elimine consultas que creen duplicados o filtren datos confidenciales. Indique esta elección en cada regla.
El orden controla los resultados porque la mayoría de los motores se detienen en el primer partido. Coloque reglas específicas antes que patrones amplios. Evite conflictos entre capas.
Las reglas pueden redirigir o reescribir. Los redireccionamientos cambian la URL que se muestra al cliente. Las reescrituras ofrecen contenido diferente sin cambiar la URL visible.
El diseño del objetivo debe evitar bucles y cadenas. Un bucle redirige a una URL anterior. Una cadena agrega saltos adicionales de una URL a la siguiente.
Construya el objetivo canónico final en un solo paso. Normalice las reglas de host, esquema, ruta y barra diagonal al mismo tiempo. Esto reduce los bucles y las cadenas.

301 y 308 marcan redirecciones permanentes. 302 y 307 marcan redirecciones temporales. 307 y 308 conservan método y cuerpo.
Algunos clientes cambian las solicitudes 301 y 302 a GET. Esto puede romper formularios y API. Utilice 307 o 308 cuando la preservación del método sea importante.
Utilice 301 para movimientos de página estables. Utilice 302 para campañas cortas o mantenimiento. Utilice 308 para movimientos de API permanentes que requieran la preservación del método.
Utilice 307 para movimientos de API temporales que requieran la preservación del método. Mantenga las redirecciones a un salto. Las cadenas aumentan la latencia y reducen la eficiencia del rastreo.
Los cachés suelen almacenar redireccionamientos permanentes durante mucho tiempo. Una redirección permanente incorrecta puede persistir para los usuarios. Las redirecciones temporales reducen este riesgo.
Las redirecciones de HTTP a HTTPS interactúan con HSTS. HSTS actualiza las solicitudes antes de que el cliente se conecte. Luego, las configuraciones incorrectas perjudican a más usuarios.
Elija una regla para las barras diagonales. Elija una regla para los documentos predeterminados. Los conflictos provocan bucles e indexación duplicada.

Las reglas de redireccionamiento se pueden ejecutar en el borde, el proxy o la aplicación. Las reglas perimetrales se ejecutan más cerca del usuario. Suelen reducir la latencia.
Los cambios de borde afectan todo el tráfico rápidamente. También protegen los orígenes al hacer cumplir HTTPS y hosts canónicos. Las reglas de proxy centralizan el control de múltiples servicios.
Las reglas de la aplicación utilizan el contexto empresarial. Cuestan más computación. Es posible que pasen por alto solicitudes de activos estáticos manejadas en otros lugares.
Los redireccionamientos interactúan con el enrutamiento y el middleware. La autenticación, el enrutamiento local y las pruebas A/B pueden cambiar las rutas y los hosts. Los sitios multidominio a menudo necesitan redirecciones basadas en host.
Los sitios internacionales pueden redirigir por host, prefijo de ruta o encabezados de idioma. El alojamiento estático y las plataformas sin servidor pueden limitar la complejidad de las reglas. Los monolitos admiten una lógica compleja pero pueden ocultar cadenas.

Elija entre una redirección y una reescritura. Utilice redirecciones cuando la URL canónica deba cambiar. Utilice reescrituras cuando la URL visible deba permanecer.
Mantenga las etiquetas canónicas y los mapas del sitio alineados con la URL canónica prevista. Elija un código de estado según las necesidades de permanencia y método. Prefiera 307 o 308 para API y formularios.
Mantenga las reglas mínimas y que no se superpongan. Coloque reglas específicas por encima de patrones generales. Evite los mensajes generales que ocultan 404 reales.
Defina una política de URL canónica. Decida entre www versus apex, HTTP versus HTTPS y reglas de barra diagonal. Haga cumplir la política en un solo paso para evitar cadenas.
Maneje las consultas con intención. Conserve sólo los parámetros necesarios. Suelta o reescribe el resto.
Pruebe antes y después del lanzamiento. Verifique bucles, cadenas y objetivos incorrectos. Validar POST y flujos autenticados.
Implemente la puesta en escena cuando sea posible. Utilice liberaciones canarias o exposición limitada. Supervise registros, tasas de redireccionamiento, tasas 404 y objetivos principales.
Utilice herramientas de rastreo y datos de la consola de búsqueda. Confirme que las URL antiguas se consoliden en el conjunto canónico. Mantenga la documentación, la propiedad y el control de cambios.
Pruebe primero las rutas de mayor riesgo: URL de servicios antiguos, URL de campaña, HTTP a HTTPS, www a no www, variantes de barra diagonal y páginas con vínculos de retroceso.
No.
Redirija cada URL antigua al reemplazo relevante más cercano para que los usuarios y los motores de búsqueda lleguen a una página que aún coincida con la intención original.
Utilice un 301 para un movimiento permanente y un 302 cuando el cambio sea temporal o esté probando intencionalmente un cambio de ruta a corto plazo.
Asigne cada origen y destino antes del lanzamiento, pruebe con un rastreador y confirme que cada cadena de redireccionamiento termine en un destino final de 200 estados.
Have any questions or comments? Write them below!