Passer au contenu 
Les redirections basées sur des règles avec NGINX garantissent la structure, le classement et les temps de chargement - j'utilise pour cela nginx redirect règles de manière claire, rapide et testable. Pour ce faire, j'utilise retour pour la performance et rewrite pour les motifs, garder les codes d'état propres et éviter les chaînes et les boucles [1][3].
Points centraux
- retour pour des redirections individuelles rapides, rewrite pour les échantillons [1][3]
- 301 pour de façon permanente, 302 pour temporaire - tenir compte du report de classement [3].
- HTTPS et forcer les chaînes de requête avec $is_args$args obtenu [1][5]
- Regex économe, règles consolider et tester [3]
- Suivi de chaînes, 404 et Indexation après le déploiement
Les directives NGINX expliquées en bref
Pour les redirections, NGINX offre deux possibilités : retour et rewrite. J'utilise return lorsque je veux rediriger une URL unique et clairement définie, car le serveur répond alors immédiatement sans regex [1][3]. Si je dois évaluer des modèles, des groupes ou des variables, j'utilise rewrite et je régule le flux avec des indicateurs comme permanent ou break [1][7]. Les deux approches se complètent, mais return reste le premier choix pour les cas simples, car chaque évaluation économisée réduit la latence [3]. C'est ainsi que je garde les configurations légères, lisibles et néanmoins flexible.
Contextes et ordre d'exécution dans NGINX
Je tiens compte des Ordre du traitement : d'abord NGINX choisit le bloc serveur approprié par server_name, puis la correspondance de localisation intervient (localisations basées sur le préfixe avant les regex, et la correspondance la plus longue gagne) [1]. rewrite-Les instructions en début de serveur agissent tôt, les indicateurs comme last lancent une nouvelle recherche de lieux, break termine la phase de réécriture, tandis que retour répond immédiatement. Cela me permet de planifier où une règle doit vivre : des canons globaux dans server{}, des modèles à granularité fine dans des blocs location{} appropriés.
# Exemple : redirections précoces et uniques
serveur {
écouter 80 ;
nom_du_serveur alt.example.tld ;
return 301 https://neu.example.tld$request_uri ;
}
Quand retourner, quand réécrire ?
Je mets retourSi aucun modèle n'est nécessaire et que l'URL cible est définie, j'obtiens le meilleur résultat possible. Performance [1][3]. Pour les modèles tels que les groupes de chemins, l'insensibilité aux cas ou la conservation des chemins, j'ai besoin de rewrite avec des expressions régulières [5][7]. Exemple : un déménagement de domaine avec reprise de chemin peut être résolu de manière élégante avec rewrite et $1 [1]. Les anciennes pages de produits individuelles qui pointent vers une nouvelle route peuvent être reproduites plus rapidement et plus sûrement avec return [3]. Ce schéma clair évite les collisions de règles ultérieures et facilite les audits.
Mettre en œuvre la canonicalisation de manière cohérente
Je détermine tôt comment les sentiers normalise sont utilisés : Trailing Slash oui/non, supprimer les fichiers d'index, variante www et canonisation de l'hôte [3]. Ainsi, il y a moins de cas particuliers.
# Variante sans slash : /catégorie/ → /catégorie
rewrite ^/(.+)/$ /$1 permanent ;
# Variante avec slash : /catégorie → /catégorie/
rewrite ^/([^. ?]+)$ /$1/ permanent ;
# Uniformiser les fichiers d'indexation
rewrite ^/(.*)/index.(html|htm|php)$ /$1/ permanent ;
Je m'en tiens à $urisi j'ai besoin d'une base de chemin normalisée, et à $request_urisi l'appel original complet, y compris la requête, est important pour la cible. Pour une prise en charge sûre des paramètres, j'utilise de préférence $is_args$args un [5].
Choisir correctement les codes d'état
Le code d'état contrôle la manière dont le crawler et le navigateur interprètent une redirection, c'est pourquoi je le décide très conscient. Pour les déménagements permanents, je transfère les signaux par 301 et crée ainsi Clarté pour l'index et l'utilisateur [3]. Un 302 signale des redirections temporaires, par exemple pour des tests, des bannières ou des itinéraires A/B de courte durée. Les 307/308 préservent la méthode et conviennent pour les API ou les POST de forme. Le tableau suivant présente une classification compacte des codes courants.
| Code | Utilisation | Effet SEO |
|---|---|---|
| 301 | Déviation permanente | Les signaux sont transmis, l'index est mis à jour [3]. |
| 302 | Itinéraire temporaire | L'ancienne URL reste, les signaux ne suivent pas complètement [3]. |
| 307 | Temporaire, la méthode reste | Utile pour les Form-POSTs et les APIs |
| 308 | Durable, la méthode reste | Stable pour les routes API durables |
Affiner les codes de statut : bien utiliser les 410/451
Si le contenu définitivement retiré j'utilise de manière ciblée 410 Goneplutôt que de rediriger aveuglément vers une catégorie. Ainsi, les URL obsolètes disparaissent plus rapidement de l'index et les utilisateurs reçoivent un signal clair. Pour les contenus bloqués légalement, j'utilise 451. La clé est la cohérence : pour les séries de produits supprimés, je gère une liste que je transfère périodiquement dans la configuration.
# Suppression ciblée
location = /landing/action-2023 { return 410 ; }
Rediriger HTTP vers HTTPS en toute sécurité
Je redirige systématiquement les appels non cryptés vers HTTPS pour que les utilisateurs et les robots d'exploration ne voient que la variante sécurisée [1]. La variante return est courte, rapide et conserve automatiquement les paramètres de la requête si j'utilise $request_uri ou $is_args$args de la même manière. J'évite ainsi les contenus en double et les chaînes inutiles via des destinations intermédiaires. Ceux qui souhaitent approfondir le contexte des certificats et des configurations SSL trouveront des conseils pratiques dans cette brochure compacte. Redirection HTTPS. Ce qui reste important : Je définis exactement une variante canonique de l'hôte pour que les crawlers conservent la bonne référence de manière stable [3].
Sécuriser le HTTPS : HSTS et mise en cache
Après une conversion HTTPS stable, j'active HSTSpour qu'à l'avenir, les navigateurs effectuent directement des requêtes cryptées. Je commence de manière conservatrice et j'augmente ensuite la durée lorsque tous les sous-domaines sont préparés. En outre, je contrôle les Mise en cache-Sémantique des redirections pour éviter les revalidations inutiles.
# Utiliser HSTS uniquement sur les serveurs HTTPS
add_header Strict-Transport-Security "max-age=31536000 ; includeSubDomains ; preload" always ;
# Indications de mise en cache explicites pour les redirections permanentes
location = /alt/contact {
add_header Contrôle de cache "public, max-age=86400" ;
return 301 /contact/ ;
}
Mettre en place proprement les redirections RegEx
Pour les motifs, j'utilise délibérément Regex mais je les trouve concis et faciles à tester [3][5]. L'opérateur tilde active des modèles dans le bloc location, tandis que ~* ignore la casse et couvre ainsi les variantes typiques de frappe [5]. Les groupes me permettent de regrouper des itinéraires apparentés et de reprendre le reste du chemin avec $1 [1]. J'évite les modèles extrêmement larges comme .* et je préfère les ancres de chemin concrètes pour que le moteur reste léger [3]. Je documente brièvement chaque règle afin que les extensions ultérieures puissent se faire sans rupture. fonctionnent.
Éviter les pièges If et utiliser map
Je mets if avec parcimonie et préfère utiliser des mappour prendre des décisions en dehors du traitement des demandes de rencontrer [3]. C'est ainsi que je dissocie la logique des lieux et que je conserve une configuration robuste.
# Regrouper la matrice legacy avec map
map $uri $legacy_target {
par défaut "" ;
/alt/ueber-uns /ueber-uns/ ;
/alt/expédition /service/expédition/ ;
}
serveur {
if ($legacy_target != "") { return 301 $scheme://$host$legacy_target$is_args$args ; }
}
Conserver correctement les paramètres de requête
Je sécurise tous les paramètres avec $is_args$args ou $request_uri, afin de conserver le suivi, le filtre et la pagination [5]. Si je n'ai besoin que d'une valeur précise, je l'extrais via $args et régule l'itinéraire de destination avec set et les variables appropriées [5]. Ainsi, les utilisateurs arrivent directement sur la bonne page de produit ou de recherche, sans perdre leur sélection. Ce soin permet de réduire les rebonds, car le flux d'utilisateurs et le contexte sont conservés. Pour les robots d'exploration, il en résulte un résultat clair, cohérent Objectif .
Nettoyer les paramètres au lieu de les perdre
Parfois, je veux certains paramètres de suivi supprimersans perdre d'informations. Je travaille avec $args et mappour former une variante nettoyée, puis la transmettre canoniquement. Je réduis ainsi les doublons sans perturber le flux d'utilisateurs [3][5].
# Exemple : supprimer utm_*, conserver les filtres essentiels
map $args $clean_args {
default $args ;
~*^(.*)(?:&)?utm_[^&]+(.*)$ $1$2;
}
location /catégorie/ {
# ne rediriger que si la requête est vraiment modifiée
if ($args != $clean_args) {
return 301 $scheme://$host$uri$is_args$clean_args ;
}
}
Éviter le meulage et les chaînes
J'empêche PonçageJ'évite les chaînes en délimitant clairement les conditions et en ne passant jamais de A à A [3]. Je freine les chaînes en pointant toujours directement vers la destination finale et en supprimant les étapes intermédiaires [3]. Dans les configurations CMS, je vérifie en outre si les plugins génèrent des already-redirects afin d'éviter la création de règles doubles. En cas de problèmes avec des plug-ins CMS, une vérification rapide des pièges connus autour d'un Boucle de redirection dans WordPress. Ainsi, le serveur reste léger et l'utilisateur atteint sa destination en un seul clic. Hop.
Sécurité : empêcher les redirections ouvertes
Je n'autorise pas les redirections ouvertes qui visent des destinations étrangères à partir de paramètres aveugle n'acceptent pas. Au lieu de cela, je mets en liste blanche les hôtes/chemins autorisés et je bloque tout le reste.
# Sécurisé /go?dest=... avec liste blanche
map $arg_dest $go_ok {
par défaut 0 ;
~^https?://(partner.tld|trusted.tld)(/|$) 1 ;
}
location = /go {
if ($go_ok = 0) { return 400 ; }
return 302 $arg_dest ;
}
Regrouper et tester les règles
Je regroupe des modèles similaires dans une Règle et je garde l'ordre clair afin que les blocs ne se perturbent pas mutuellement [3]. Avant chaque déploiement, je vérifie la syntaxe avec nginx -t et recharge la configuration par rechargement afin d'éviter les temps d'arrêt. Avec curl -I, je vérifie le code d'état, la cible et l'en-tête et je garde les cas de test dans une petite liste de contrôle. Pour les migrations Apache, je compare les fichiers Redirections htaccess et le transfère de manière légère dans des structures NGINX. Ainsi, le fichier reste court, maintenable et lisible.
Journalisation et transparence
Pour voir l'effet et les effets secondaires, je sépare 3xx-Logs. Je détecte ainsi rapidement les chaînes, les valeurs aberrantes et les règles erronées, et je peux effectuer des rotations ciblées si nécessaire [3].
# Écrire les requêtes 3xx dans un journal séparé
map $status $is_redirect {
par défaut 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 ;
Exemples de relancement et de migration
Lors du relancement, je crée des matrices de redirection qui associent chaque ancienne URL à un seul site. Objectif assigner les produits. Je regroupe les chemins d'accès aux catégories en modèles et les dirige vers la nouvelle logique de la boutique, tandis que les topsellers individuels renvoient vers de nouvelles pages détaillées. Lors d'une migration de domaine, je reprends toujours le chemin complet afin que les liens profonds et les backlinks restent sans friction [1]. Pour les trailing slashes, je définis une ligne claire afin que chaque route n'ait qu'une seule variante valable. Il en va de même pour www vs. non-www - je choisis une forme d'hôte et je dirige strictement vers celle-ci Variante [3].
Internationalisation et géociblage
Pour les présentations multilingues, je mise sur des structures d'URL stables (par ex. /fr/, /en/) et éviter les redirections forcées basées sur Accept-Language. Si j'utilise la reconnaissance vocale, alors prudent comme 302 avec une possibilité claire de changer de langue. Pour les sous-boutiques par pays, je vérifie que les crawlers peuvent récupérer chaque variante sans géo-redirection et qu'il n'y a pas de 301 indésirables [3].
Architecture NGINX : pourquoi c'est rapide
Avec les redirections, je profite de la contrôlé par l'événement architecture de NGINX, car elle sert de nombreuses connexions avec peu de processus [2]. Le maître gère des travailleurs qui acceptent et répondent efficacement à des milliers de requêtes en parallèle [2]. Contrairement aux configurations chargées en threads, cela permet d'économiser de la RAM et de réduire les changements de contexte, ce qui permet d'obtenir des temps de réponse courts même en cas de charge élevée [2]. Des valeurs TTFB plus courtes aident les classements et augmentent la satisfaction des clics. Cette architecture prédestine NGINX à gérer les redirections même en cas de pics de trafic. rapide à livrer.
Collaboration avec CDN et Upstream
Si un CDN met déjà en place Canoniques hôte/HTTPS je désactive les doublons dans NGINX - ou inversement. L'important est d'avoir une source de vérité. Pour les redirections Edge, je n'utilise le moteur CDN que si la décision Données au bord tout le reste reste dans NGINX. J'évite ainsi les jeux de règles divergents et je maîtrise la latence et la maintenance [3].
Monitoring après le déploiement
Après l'avoir déroulé, j'observe Erreur de crawlLes codes d'état et l'indexation, pour que chaque redirection fonctionne comme prévu [3]. Dans la Search Console, je contrôle les 404, les soft-404 et les chaînes qui attirent l'attention, tandis que je vérifie les rapports d'exploration à intervalles réguliers. Je vérifie également les temps de chargement, car chaque saut inutile coûte du temps et du budget. En cas d'anomalies, j'adapte rapidement les règles et je tiens à disposition un historique des modifications afin de pouvoir suivre les effets. Ce contrôle permanent permet de maintenir le paysage des redirections. en bonne santé.
En bref
Je mets retour pour des objectifs simples, rewrite pour les modèles et garder les codes d'état uniques - ainsi, les signaux sont conservés et les routes sont claires [1][3]. Les redirections HTTPS, la conservation des paramètres et une variante d'hôte fixe empêchent les contenus dupliqués et renforcent la cohérence [1][5]. Un petit nombre de règles bien regroupées l'emportent sur un grand nombre d'entrées fragmentées et chargées de regex, car la maintenance et la performance en profitent [3]. Des tests avec nginx -t et curl ainsi qu'une surveillance continue garantissent la qualité tout au long du cycle de vie. En respectant ces lignes directrices, on construit une stratégie de redirection légère qui soutient de manière fiable le flux d'utilisateurs et les classements.
