Comment diagnostiquer un site inaccessible après la configuration d’une redirection 301 ?

Après la configuration d’une redirection 301, si le site ne s’ouvre plus, commencez par déterminer à quelle étape la requête s’arrête : l’ancienne URL ne répond pas, plusieurs adresses se redirigent en boucle, ou la requête atteint la nouvelle URL, mais le nouveau site renvoie une erreur. L’expression « 301エラー », fréquemment utilisée dans les recherches, ne signifie pas que le code 301 est lui-même défectueux : 301 indique une redirection permanente. Les éléments à vérifier sont plutôt la règle de redirection, l’adresse de destination et le chemin de la requête.

Notez d’abord le chemin complet de la redirection, puis modifiez la configuration concernée. Modifier en même temps la résolution du domaine, le certificat et les règles de réécriture rendra l’origine du problème plus difficile à déterminer.

Déterminez d’abord où la requête s’arrête

Ouvrez les outils de développement du navigateur, accédez à l’onglet « Réseau », cochez « Conserver le journal », puis consultez à nouveau l’URL complète concernée. Vérifiez notamment le code d’état et l’en-tête de réponse Location, qui indique l’adresse de la redirection suivante.

• Message indiquant un trop grand nombre de redirections : vérifiez si deux adresses se redirigent mutuellement ou si une adresse redirige sans cesse vers elle-même.
• Erreur 404 ou 5xx après la redirection : la requête a atteint l’adresse de destination. Vérifiez le chemin de la page, le service applicatif ou la passerelle.
• Erreur de certificat, domaine introuvable ou délai de connexion dépassé : commencez par résoudre les problèmes de certificat, de DNS ou de réseau. Il se peut que la requête n’ait pas encore atteint la règle 301.

Si vous disposez d’un terminal, utilisez curl -I https://old.example.com/path pour consulter les en-têtes de réponse, puis curl -IL --max-redirs 10 https://old.example.com/path pour suivre les redirections successives. Certains sites traitent différemment les requêtes HEAD. En cas de doute, fiez-vous à la requête GET réellement effectuée par le navigateur, ou vérifiez avec curl -sS -D - -o /dev/null URL.

En cas de boucle, vérifiez en priorité le protocole, le domaine et la configuration du proxy

Les boucles les plus courantes sont une redirection de HTTP vers HTTPS suivie d’un retour vers HTTP, ou des redirections réciproques entre un domaine avec www et un domaine sans www. Par exemple, si le serveur redirige example.com vers www.example.com, mais que le panneau d’administration du site redirige cette dernière adresse vers la première, le navigateur ne peut pas atteindre la page.

Définissez d’abord une adresse officielle unique, puis vérifiez que le CDN, l’équilibreur de charge, le serveur et le panneau d’administration du site utilisent tous la même destination. Les règles peuvent être appliquées à plusieurs niveaux, mais elles ne doivent pas pointer vers des domaines ou des protocoles différents.

Si le site utilise un proxy inverse, vérifiez également comment le serveur d’origine détermine le protocole utilisé par le visiteur. Le visiteur accède au CDN en HTTPS, mais le CDN se connecte au serveur d’origine en HTTP. Si le serveur d’origine se base uniquement sur sa propre connexion, il peut exiger sans cesse un passage à HTTPS, ce qui crée une boucle.

Dans ce cas, vérifiez le protocole utilisé pour la connexion au serveur d’origine et assurez-vous que l’application reconnaît correctement les informations de protocole transmises par le proxy de confiance, par exemple X-Forwarded-Proto. Ne faites pas confiance à cet en-tête de requête lorsqu’il provient d’une source quelconque : limitez les sources aux proxys de confiance.

Même sans redirections réciproques, vérifiez le périmètre et l’ordre d’exécution des règles

Avant toute modification, sauvegardez la configuration existante, puis examinez une par une les règles de réécriture du serveur, les redirections du panneau de contrôle, les extensions du programme et les règles du CDN. Recherchez en particulier les trois problèmes suivants :

• La destination correspond toujours à la règle d’origine : la règle redirige toutes les requêtes vers une adresse sans exclure l’adresse de destination elle-même.
• Un joker ou une expression régulière couvre un périmètre trop large : une règle de redirection de la page d’accueil s’applique par erreur aux pages produit, à l’interface d’administration, aux API ou aux ressources statiques.
• Erreur de concaténation du chemin : répertoire dupliqué, traitement incohérent des barres obliques ou référence incorrecte à un groupe capturé, entraînant une redirection vers une page inexistante.

Si la désactivation temporaire d’une règle rétablit l’accès, cela indique uniquement que cette règle, ou sa combinaison avec d’autres règles, pose problème. Vérifiez ensuite les conditions de déclenchement afin de ne pas supprimer par erreur les paramètres nécessaires à la normalisation du domaine. Avec Apache, vérifiez l’ordre des règles et leur héritage ; avec Nginx, examinez les relations de correspondance entre server, location et rewrite. Après modification, vérifiez la syntaxe de la configuration avant de la recharger.

Si l’URL de destination ne s’ouvre pas, vérifiez le DNS, le certificat et la correspondance des pages

Accédez directement à l’adresse complète indiquée dans Location. Si la destination ne s’ouvre pas non plus, poursuivez le diagnostic sur le site de destination au lieu de modifier sans cesse la redirection 301 de l’ancien site.

Lors d’une migration de domaine, vérifiez que les enregistrements A, AAAA ou CNAME du nouveau domaine pointent vers le service attendu. Si IPv4 et IPv6 sont configurés simultanément et que l’un des deux ne fonctionne pas, certaines connexions réseau peuvent réussir tandis que d’autres échouent.

Pour HTTPS, gardez à l’esprit que l’ancien domaine doit d’abord établir la négociation TLS pour que le navigateur puisse recevoir la réponse 301 qu’il renvoie. Ainsi, même si l’ancien domaine ne sert qu’à effectuer une redirection, il doit disposer d’un certificat valide et correspondant au domaine. Vérifiez également les accès avec et sans www : un certificat valide sur le site de destination ne remplace pas celui de l’ancien domaine.

Si la page d’accueil fonctionne, mais que les pages produit ou les pages multilingues renvoient une erreur 404, vérifiez la correspondance entre les anciens et les nouveaux chemins. Une redirection 301 demande au navigateur d’accéder à la nouvelle adresse, mais ne crée pas automatiquement la page. Lors de la migration d’un site de commerce international, associez en priorité les anciennes pages produit, catégories et langues aux contenus correspondants, au lieu de tout rediriger vers la page d’accueil.

Que faire si le serveur est réparé, mais que le navigateur échoue encore ?

Une redirection 301 peut être mise en cache par le navigateur ou le CDN. Si la ligne de commande renvoie désormais le résultat attendu, mais que le navigateur habituel pointe toujours vers l’ancienne destination, refaites le test avec un nouveau profil de navigateur ou un autre appareil, puis videz le cache pour les domaines concernés. Si vous désactivez le cache à l’aide des outils de développement, laissez ces outils ouverts pendant le test.

Le CDN peut également continuer à renvoyer l’ancienne réponse de redirection. Il faut alors vider le cache des URL concernées. La mise à niveau automatique de HTTP vers HTTPS par le navigateur peut aussi être liée à HSTS. Fiez-vous aux requêtes réellement effectuées sur le réseau et ne considérez pas systématiquement ce comportement comme un cache de redirection 301.

Pendant les ajustements, vous pouvez d’abord utiliser une redirection temporaire lorsque le contexte s’y prête afin de vérifier la destination et le chemin, puis passer à une redirection 301 une fois la configuration stabilisée. Les redirections permanentes déjà mises en cache doivent toutefois être traitées séparément.

Après le rétablissement de l’accès, vérifiez les points d’entrée utilisés par les clients

Testez au minimum HTTP et HTTPS, les domaines avec et sans www, la page d’accueil, les pages de détail produit et les répertoires de langue. Accédez-y également à partir d’anciennes URL présentes dans les pages de destination publicitaires ou les résultats de recherche. La page finale doit se charger normalement et le chemin de redirection doit être aussi direct que possible, sans étapes intermédiaires superflues.

Si le site comporte des formulaires de demande de renseignements, un panier ou des rappels de paiement, testez séparément le processus d’envoi. Certains clients peuvent transformer une requête POST en GET lors d’une redirection 301. Ces interfaces ne doivent pas être soumises directement aux règles de redirection ordinaires des pages. Si la méthode de requête doit être conservée, évaluez l’utilisation de 307 ou 308 en fonction de la logique de l’application.

Vérifiez également que les paramètres publicitaires sont conservés et que les liens internes ainsi que le plan du site ont été mis à jour. Si vous utilisez une plateforme de création de sites, fournissez au prestataire les URL concernées, la chaîne de redirections, l’heure du problème et les modifications récentes de configuration. Ces éléments permettent de déterminer plus rapidement s’il faut intervenir au niveau de la plateforme, du CDN ou du serveur.