Redirections & 404

Quand une URL de votre site renvoie 404, c'est en général l'une de celles-ci : le contenu n'est pas publié (ou pas publié encore), le mode d'URL ou le routage des langues a changé, une redirection ne peut pas faire son travail, ou la requête visait quelque chose volontairement exclu de votre sortie statique. Cette page passe chacune en revue, et quand corriger dans l'admin versus la configuration du serveur.

Le contenu n'est pas généré tant qu'il n'est pas dû

Seul le contenu publié et non supprimé est généré. Si une page planifie sa publication dans le futur, ou qu'une date de dépublication est déjà passée, la page n'est simplement pas générée, donc son URL est un 404 jusqu'au prochain build après qu'elle devient éligible. Après un changement d'état de publication ou d'une fenêtre de planification, rebuildez.

Décalages de routage des langues

Le comportement des URL dépend du Language URL Mode (Settings → Permalinks), qui est aussi l'endroit où démarre une classe courante de 404 :

• Si vous configurez none (pas de segments de langue) mais plus d'une langue, le builder le passe outre en mode path et avertit dans le log de build. Si vous voyez des chemins inattendus de type /en/…, vérifiez ce réglage.
• En mode sous-domaine, les URL sont des sous-domaines de langue (comme es.yourdomain.com), mais les fichiers sont toujours générés dans des répertoires output/{lang}/. Votre serveur doit router chaque sous-domaine vers son répertoire de langue ; l'oublier fait que le sous-domaine renvoie 404 ou sert la mauvaise langue.
• Un mode d'URL périmé sur un site monolingue (par exemple le mode path quand une seule langue existe) produit des 404 pour les chemins par défaut. Effacez le mode (ou fixez le bon mode) et rebuildez.

Le builder imprime des avertissements et des notes sur ces situations exactes dans la sortie de build, donc ouvrez d'abord le log de build quand les URL de langue se comportent bizarrement.

L'URL racine redirige vers une mauvaise page

L'endroit vers lequel la racine du domaine pointe est fixé par home_redirect (Settings → Permalinks). Si le slug que vous nommez n'est pas une page publiée, le log de build avertit "no published page with this slug found.", et la redirection racine cesse de fonctionner correctement. Corrigez le réglage ou publiez/restaurez la page cible, puis rebuildez.

Les redirections qui ne s'appliquent pas en silence

Les redirections ne s'appliquent qu'aux anciens chemins qui ne contiennent pas déjà du contenu publié. Si une page ou un post vit toujours à l'ancien slug, il continue de servir 200 cette URL et la redirection est sautée ; le log de build le marquera quand même par l'avertissement "old slug is still active" que l'admin affiche à la création d'une telle redirection. Pour qu'une redirection gagne, dépubliez ou supprimez d'abord l'ancienne page (ou gardez la redirection et le contenu dépublié en basculant l'état de publication).

Les redirections doivent être actives (la case active de l'écran des redirections). Seules les redirections actives génèrent de la sortie de redirection au moment du build ; une redirection désactivée disparaît de la sortie statique jusqu'à ce que vous l'activiez (activer déclenche un build).

Les formats restrictifs gagnent : les redirections simples utilisent le code 301/302/307 que vous avez choisi et s'appliquent dans la configuration de redirection serveur générée ; les redirections à motif (ancien slug finissant par * avec substitution $1 dans la destination) ne fonctionnent que comme pages de redirection HTML dans le build statique, et sont sautées par les configurations serveur générées.

Quand un 404 lui-même est cassé

Le site statique embarque une page 404 générée. Si cette page échoue à se rendre dans un build, le log de build enregistre une ligne d'erreur pour elle mais continue ; le site reste debout, tandis qu'un 404 personnalisé manquant laisse la réponse « Page not found » ordinaire de votre serveur aux commandes jusqu'au prochain bon build.

Les sondes ne reçoivent pas le 404 ordinaire

La configuration serveur d'origine route les chemins de sondes d'attaque courants (fichiers de réglages, chemins de gestion de versions, URL admin d'autres plateformes) à travers un proxy qui n'a rien à voir avec votre sortie statique, au lieu de servir votre page 404 normale. Si vous voyez des 404 journalisés pour ces chemins exacts, ce sont des sondes, pas des liens cassés.

Pourquoi un 404 peut brièvement flasher pendant les déploiements

La publication échange la sortie atomiquement. Quand l'emplacement du contenu en production est un symlink, la mise en ligne est un unique rename atomique, zéro downtime. Sinon c'est un renommage en deux étapes sur le même système de fichiers, avec un bref intervalle entre les deux renommages pendant lequel une requête pourrait frapper un répertoire manquant. Dans les deux cas un échange atterrit entièrement ou la sortie précédente reste en place, jamais un site partiellement écrit.

Où aller ensuite

Une fois que vous savez qu'une URL devrait exister mais renvoie 404, dépubliez ou supprimez l'ancienne page, publiez la nouvelle, et créez une redirection depuis le chemin journalisé via le lien Create redirect par ligne du moniteur 404 ou la sélection en masse (Admin → Health → onglet 404s). Le journal 404 enregistre les chemins manquants avec leurs comptes de hits et les URL référentes pour que vous puissiez prioriser les correctifs.