Ir al contenido 
Los redireccionamientos basados en reglas con NGINX garantizan la estructura, las clasificaciones y los tiempos de carga: yo utilizo redirección nginx reglas de forma clara, rápida y comprobable. Para ello, utilizo devolver para el rendimiento y reescribir para patrones, mantener limpios los códigos de estado y evitar cadenas y bucles [1][3].
Puntos centrales
- devolver para redireccionamientos únicos rápidos, reescribir para las muestras [1][3]
- 301 para permanente, 302 para transferencia temporal - nota de clasificación [3]
- HTTPS y forzar las cadenas de consulta con $is_args$args recibido [1][5]
- Regex económico, normas consolidar y prueba [3]
- Monitoreo de cadenas, 404 y Indexación después de la puesta en marcha
Breve explicación de las directivas NGINX
NGINX ofrece dos formas de reenvío: devolver y reescribir. Utilizo return si quiero redirigir una URL única y claramente definida porque entonces el servidor responde inmediatamente sin regex [1][3]. Si necesito evaluar patrones, grupos o variables, utilizo rewrite y regulo el flujo con banderas como permanent o break [1][7]. Ambos enfoques se complementan, pero return sigue siendo la primera opción para casos sencillos, ya que cada evaluación ahorrada reduce la latencia [3]. Así es como mantengo las configuraciones esbeltas, fáciles de leer y sin embargo Flexible.
Contextos y secuencia de ejecución en NGINX
Tengo en cuenta la Secuencia de procesamiento: NGINX selecciona en primer lugar el bloque de servidor apropiado a través de server_name, y a continuación tiene lugar la concordancia de ubicación (ubicaciones basadas en prefijos antes que regex, y gana la coincidencia más larga) [1]. reescribir-al inicio del servidor tienen efecto antes de tiempo, banderas como último iniciar una nueva búsqueda de ubicación, romper finaliza la fase de reescritura, mientras que devolver responde inmediatamente. Esto me permite planificar dónde debe vivir una regla: canónicos globales en server{}, patrones detallados en bloques location{} coincidentes.
# Ejemplo: redirecciones únicas tempranas
servidor {
listen 80;
nombre_servidor alt.ejemplo.tld;
return 301 https://neu.example.tld$request_uri;
}
¿Cuándo volver, cuándo reescribir?
He puesto devolversi no es necesario ningún patrón y la URL de destino es fija; de esta forma consigo los mejores resultados. Actuación [1][3]. Para patrones como grupos de rutas, insensibilidad a mayúsculas o minúsculas o preservación de rutas, necesito reescritura con expresiones regulares [5][7]. Ejemplo: Un traslado de dominio con transferencia de ruta puede resolverse elegantemente con reescritura y $1 [1]. Las páginas individuales de productos antiguos que apuntan a una nueva ruta pueden mapearse de forma más rápida y segura con rewrite [3]. Este esquema claro evita posteriores colisiones de reglas y facilita las auditorías.
Aplicar la canonicalización de forma coherente
Determino desde el principio los caminos normalizado se puede configurar: Barra inclinada final sí/no, eliminar archivos de índice, variante www y canonización de host [3]. Esto da lugar a menos casos especiales.
# variante sin barra: /categoría/ → /categoría
reescribir ^/(.+)/$ /$1 permanente;
variante # con barra: /categoría → /categoría/
rewrite ^/([^.?]+)$ /$1/ permanente;
# Normalizar los archivos de índice
rewrite ^/(.*)/index.(html|htm|php)$ /$1/ permanente;
Me atengo a $urisi necesito una base de ruta normalizada, y a $request_urisi la llamada original completa, incluida la consulta, es importante para el destino. Para una transferencia segura de parámetros, prefiero utilizar $is_args$args uno [5].
Seleccionar correctamente los códigos de estado
El código de estado controla cómo los rastreadores y los navegadores interpretan una redirección, por lo que decido que sea muy consciente. Para los movimientos permanentes, transfiero señales a través de 301 y así creo Claridad para el índice y el usuario [3]. Un 302 señala redireccionamientos temporales, por ejemplo para pruebas, banners o rutas A/B a corto plazo. Los 307/308 conservan el método y son adecuados para API o POST de formularios. La siguiente tabla muestra una categorización compacta de los códigos más comunes.
| Código | Utilice | Efecto SEO |
|---|---|---|
| 301 | Desvío permanente | Se transmiten las señales, se actualiza el índice [3] |
| 302 | Ruta temporal | La URL antigua permanece, las señales no van completamente con [3] |
| 307 | Temporal, el método se mantiene | Útil para formularios POST y API |
| 308 | Permanente, el método permanece | Estable para rutas API permanentes |
Refinar los códigos de estado: utilizar correctamente 410/451
Cuando el contenido eliminado permanentemente Utilizo 410 Goneen lugar de redirigir ciegamente a una categoría. De este modo, las URL obsoletas desaparecen del índice más rápidamente y los usuarios reciben una señal clara. Para los contenidos bloqueados legalmente, utilizo 451. La clave es la coherencia: mantengo una lista por series de productos anulados, que traslado periódicamente a la configuración.
# Eliminación selectiva
location = /aterrizaje/acción-2023 { return 410; }
Redirigir HTTP a HTTPS de forma segura
Reenvío sistemáticamente llamadas no cifradas a HTTPS para que los usuarios y los rastreadores sólo vean la variante segura [1]. La variante de retorno es corta, rápida y mantiene los parámetros de consulta automáticamente si utilizo $request_uri o $is_args$args utilizar. De este modo se evitan los contenidos duplicados y las cadenas innecesarias a través de destinos intermedios. Si desea obtener más información sobre el trasfondo de los certificados y las configuraciones SSL, encontrará consejos prácticos en este compacto Reenvío HTTPS. Sigue siendo importante: Defino exactamente una variante canónica de host para que los rastreadores mantengan estable la referencia correcta [3].
HTTPS seguro: HSTS y almacenamiento en caché
Después de un cambio HTTPS estable activo HSTSpara que los navegadores puedan hacer peticiones cifradas directamente en el futuro. Empiezo de forma conservadora y luego aumento la duración cuando todos los subdominios están preparados. También controlo el Almacenamiento en caché-para evitar revalidaciones innecesarias.
# Utilizar HSTS sólo en servidores HTTPS
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" siempre;
# Sugerencias explícitas de caché para redireccionamientos persistentes
location = /alt/kontakt {
add_header Cache-Control "public, max-age=86400";
return 301 /contacto/;
}
Redirecciones RegEx limpias
Para los patrones utilizo deliberadamente Regex pero manteniéndolo conciso y fácilmente comprobable [3][5]. El operador tilde activa patrones en el bloque de localización, mientras que ~* ignora mayúsculas/minúsculas y cubre así las variantes típicas de tipado [5]. Los grupos me permiten agrupar rutas relacionadas y tomar el camino restante con $1 [1]. Evito los patrones extremadamente amplios, como .*, y prefiero anclajes de ruta concretos para que el motor sea ágil [3]. Documento cada regla brevemente para que las ampliaciones posteriores puedan aplicarse sin interrupciones. función.
Evite las trampas if y utilice el mapa
He puesto si con moderación y prefiero utilizar mapatomar decisiones fuera de la tramitación de solicitudes para cumplir [3]. Así es como desacoplamos la lógica de las ubicaciones y mantenemos una configuración robusta.
# Bundle legado matriz con mapa
map $uri $legacy_target {
por defecto "";
/alt/acerca-de-nosotros /acerca-de-nosotros/;
/alt/envío /servicio/envío/;
}
servidor {
if ($legacy_target != "") { return 301 $scheme://$host$legacy_target$is_args$args; }
}
Mantener correctamente los parámetros de consulta
Guardo todos los parámetros con $is_args$args o $request_uri, para que se conserven el seguimiento, los filtros y la paginación [5]. Si sólo necesito un valor concreto, lo extraigo mediante $args y regulo la ruta de destino con set y las variables adecuadas [5]. De este modo, los usuarios aterrizan directamente en el producto o la página de búsqueda adecuados sin perder su selección. Esta diligencia reduce los rebotes porque se conservan el flujo y el contexto del usuario. Para los rastreadores, esto crea una clara, coherente Objetivo.
Limpiar parámetros en lugar de perderlos
A veces quiero ciertos parámetros de seguimiento Eliminarsin perder información. Trabajo con $args y mapapara crear una variante limpia y luego reenviarla canónicamente. De este modo, reduzco los duplicados sin interrumpir el flujo del usuario [3][5].
# Ejemplo: eliminar utm_*, mantener filtros esenciales
map $args $clean_args {
por defecto $args;
~*^(.*)(?:&)?utm_[^&]+(.*)$ $1$2;
}
location /category/ {
# sólo redirige si la consulta cambia realmente
if ($args != $clean_args) {
return 301 $scheme://$host$uri$is_args$clean_args;
}
}
Evitar moliendas y cadenas
Prevengo Bucleslimitando claramente las condiciones y no reenviando nunca de A a A [3]. Ralentizo las cadenas apuntando siempre directamente al destino final y eliminando las estaciones intermedias [3]. En las configuraciones CMS, también compruebo si los plugins generan ya redirecciones para que no se creen reglas duplicadas. En caso de problemas con plugins CMS, una comprobación rápida de trampas conocidas en torno a un Bucle de redirección en WordPress. De este modo, el servidor se mantiene ágil y el usuario llega a su destino de una sola vez. Lúpulo.
Seguridad: Evitar redireccionamientos abiertos
No permito ninguna redirección abierta que utilice objetivos externos a partir de parámetros ciego tomar el control. En su lugar, pongo en la lista blanca los hosts/rutas permitidos y bloqueo todo lo demás.
# Secure /go?dest=... con lista blanca
map $arg_dest $go_ok {
por defecto 0;
~^https?://(partner.tld|trusted.tld)(/|$) 1;
}
location = /go {
if ($go_ok = 0) { return 400; }
return 302 $arg_dest;
}
Reglas de agrupación y prueba
Resumo patrones similares en un Regla y mantengo la secuencia clara para que los bloques no interfieran entre sí [3]. Antes de cada despliegue, compruebo la sintaxis con nginx -t y recargo la configuración para evitar tiempos de inactividad. Utilizo curl -I para verificar el código de estado, el destino y la cabecera y guardo los casos de prueba en una pequeña lista de comprobación. Para las migraciones de Apache, comparo redirecciones htaccess y transferirlos a las estructuras de NGINX. Esto mantiene el archivo corto, mantenible y legible.
Registro y transparencia
Para ver el efecto y los efectos secundarios, separo Registros 3xx. Esto me permite reconocer rápidamente las cadenas, los valores atípicos y las reglas incorrectas, y realizar cambios específicos si es necesario [3].
# Escribir las peticiones 3xx en un registro separado
map $status $is_redirect {
por defecto 0;
~^30[12378]$ 1;
}
log_format redirects '$remote_addr - $time_local "$request" $status '
'$bytes_sent "$http_referer" "$http_user_agent"';
access_log /var/log/nginx/redirects.log redirects if=$is_redirect;
Ejemplos de relanzamiento y migración
Durante el relanzamiento, creo matrices de redireccionamiento que asignan cada URL antigua a exactamente una Objetivo asignar. Resumo las rutas de las categorías en patrones y las dirijo a la nueva lógica de la tienda, mientras que los top sellers individuales apuntan a las nuevas páginas detalladas mediante retorno. Al migrar dominios, siempre adopto la ruta completa para que los enlaces profundos y los backlinks permanezcan sin fricción [1]. Para las barras inclinadas finales, defino una línea clara para que cada ruta sólo tenga una variante válida. Lo mismo se aplica a www vs. no www: elijo una forma de host y redirijo estrictamente a ella. Variante [3].
Internacionalización y geotargeting
Para las actuaciones multilingües recurro a Estructuras URL estables (por ejemplo, /de/, /en/) y evitar redireccionamientos forzados basados en Accept-Language. Si utilizo el reconocimiento de voz, entonces cauteloso como un 302 con una opción clara para cambiar el idioma. Para las subtiendas de países, compruebo que los rastreadores puedan recuperar cualquier variante sin georredirecciones y que no se creen 301 no deseados [3].
Arquitectura de NGINX: por qué es rápido
Con los redireccionamientos, me beneficio de la basado en eventos de NGINX, ya que sirve muchas conexiones con pocos procesos [2]. El maestro gestiona trabajadores que aceptan y responden eficientemente a miles de peticiones en paralelo [2]. A diferencia de las configuraciones con muchos hilos, esto ahorra RAM y reduce los cambios de contexto, lo que se traduce en tiempos de respuesta cortos incluso con cargas elevadas [2]. Los valores TTFB más cortos ayudan a los rankings y aumentan la satisfacción de los clics. Esta arquitectura predestina a NGINX a utilizar redireccionamientos incluso durante picos de tráfico. rápido a entregar.
Cooperación con CDN y Upstream
Si una CDN ya utiliza Host/HTTPS canónicos Desactivo los duplicados en NGINX - o viceversa. Una fuente de verdad es importante. Para las redirecciones de borde, sólo utilizo el motor CDN si la decisión de utilizar datos en el borde todo lo demás permanece en NGINX. De este modo, evito conjuntos de reglas divergentes y mantengo la latencia y el mantenimiento bajo control [3].
Seguimiento tras la implantación
Después de desenrollar, observo Error de rastreocódigos de estado e indexación para que cada redirección funcione según lo previsto [3]. En Search Console, compruebo las cadenas 404, soft-404 y conspicuas, mientras reviso los informes de los rastreadores a intervalos. También compruebo los tiempos de carga, porque cada salto innecesario cuesta tiempo y presupuesto. En caso de anomalías, ajusto las reglas en una fase temprana y guardo un historial de los cambios para poder rastrear los efectos. Este control constante mantiene el panorama de las redirecciones saludable.
Brevemente resumido
He puesto devolver para objetivos sencillos, reescribir para detectar patrones y mantener códigos de estado únicos, de modo que se preserven las señales y las rutas permanezcan claras [1][3]. Las redirecciones HTTPS, la conservación de parámetros y una variante de host fija evitan el contenido duplicado y refuerzan la coherencia [1][5]. Unas pocas reglas bien agrupadas superan a muchas entradas pequeñas y con regex, ya que benefician el mantenimiento y el rendimiento [3]. Las pruebas con nginx -t y curl, así como la supervisión continua, garantizan la calidad durante todo el ciclo de vida. Si sigue estas directrices, puede crear una estrategia de redireccionamiento sencilla que apoye de forma fiable el flujo de usuarios y las clasificaciones.
