Vérifier que l’adresse redirige réellement
Vous ouvrez une adresse qui devrait être introuvable. WordPress affiche un autre contenu dont l’adresse commence par les mêmes caractères. Le forum décrit ce cas avec une adresse courte qui ouvre une page d’archives au nom proche. La réponse du forum distingue deux mécanismes possibles. WordPress peut connaître un ancien slug associé à un contenu. Il peut aussi essayer de deviner une destination lorsqu’une requête aboutit à une 404. La seule ressemblance entre les adresses ne suffit pas à établir la cause.
Ouvrez les outils de développement du navigateur et affichez l’onglet Réseau. Activez la conservation du journal, puis rechargez l’adresse d’origine dans une session de recette ou une fenêtre privée. Repérez la première réponse du document. Une réponse 301 ou 302 avec Location établit une redirection HTTP. Si le document initial répond 200 et que l’adresse change ensuite, examinez la navigation déclenchée par la page ou un script. Si le code est 200 et que l’adresse ne change pas, le serveur peut afficher un contenu inattendu ou un document d’erreur avec un statut de succès. Ce guide vise le premier cas, une redirection publique mesurable.
Notez le premier saut, puis ouvrez la destination. Vérifiez qu’elle est accessible et qu’elle ne renvoie pas vers une troisième adresse. Une redirection de protocole ou de nom d’hôte peut se produire avant le comportement qui vous intéresse. Comparez les chemins au niveau du domaine de recette et du même protocole. Enregistrez le statut final et le titre du contenu obtenu. Un navigateur peut garder une redirection permanente en mémoire. Refaites la mesure dans une session neuve et, si possible, à l’aide d’une commande qui ne conserve pas le cache du navigateur.
- Relevez le chemin demandé, le premier statut, la valeur de
Locationet le chemin final. Retirez les paramètres sensibles avant de partager un relevé. - Ouvrez le même chemin depuis une session publique. Comparez le résultat à celui d’une session connectée si le contenu a des règles d’accès.
- Vérifiez si le même comportement apparaît avec une autre URL inexistante. Si toutes les erreurs redirigent vers l’accueil, recherchez d’abord une règle générale.
Construire quatre adresses de contrôle
Sur une recette, préparez une publication accessible avec un slug distinctif, par exemple fiche-temoin-archive. Vérifiez son adresse dans la liste des articles et ouvrez-la en visiteur. Assurez-vous qu’aucun contenu publié ne possède le chemin plus court /fiche-temoin/. Sur une copie qui a servi à d’autres essais, vérifiez aussi que cette adresse n’est pas un ancien slug. Choisissez un troisième chemin sans lien avec les noms utilisés et relevez une quatrième adresse dont la redirection a été voulue et documentée. Par exemple, prenez l’ancien slug confirmé d’un article renommé sur la recette.
Les chemins du bloc suivant sont fictifs. Remplacez le domaine et les quatre chemins par ceux de la copie, en conservant le préfixe si WordPress est servi depuis un sous-dossier. Exécutez le bloc dans un shell Bash. Dans PowerShell, lancez curl.exe pour chaque URL avec les mêmes options et utilisez NUL à la place de /dev/null. Les demandes sont des GET et la commande s’arrête à la première réponse. Ouvrez ensuite l’adresse de destination séparément pour relever son code et son contenu.
Comparez les quatre résultats. Si le chemin exact répond 200, le chemin sans rapport donne 404 et le préfixe renvoie vers le contenu exact, la piste de la devinette devient plausible. Vérifiez toujours l’historique du slug et les règles existantes. Le comportement dépend des règles de permaliens et de la requête comprise par WordPress. Un préfixe court ne déclenche donc pas une redirection sur toutes les installations. Si la publication exacte est elle-même introuvable, reprenez d’abord le diagnostic de cette publication.
base='https://recette.example.test'
for chemin in /fiche-temoin/ /fiche-temoin-archive/ /introuvable-71/ /ancien-nom-confirme/; do
printf '\n%s\n' "$chemin"
curl --silent --show-error --max-time 15 --dump-header - \
--output /dev/null --write-out 'code=%{http_code}\n' "$base$chemin"
doneCorriger la source du lien avec un accès éditorial
Si le lien court figure dans un menu, un bloc ou un article et que l’intention est d’ouvrir la publication existante, modifiez sa source. Dans un thème à blocs, cherchez le lien dans Apparence > Éditeur, puis dans la navigation ou le modèle qui le contient. Pour un menu classique, utilisez Apparence > Menus lorsqu’il est disponible. Dans un contenu, sélectionnez le lien dans l’éditeur et choisissez l’adresse exacte. Sur la recette, ouvrez ensuite la page qui émet ce lien et suivez-le comme visiteur. Le résultat doit atteindre la publication prévue directement.
Si le chemin court correspond à une autre page qui aurait dû être publique, ouvrez cette page dans le tableau de bord. Vérifiez son état, son slug et sa page parente. Un brouillon, une page privée ou une page déplacée sous un parent peut être accessible en aperçu avec une session d’administration sans répondre de la même façon en public. Confirmez le chemin affiché et l’objectif éditorial avant de publier ou de renommer. Après correction sur la copie, vérifiez que le chemin voulu répond avec le titre attendu et que le contenu d’archives garde son adresse propre.
Lorsque le chemin court a réellement été diffusé et doit continuer à fonctionner, préparez une redirection explicite entre deux adresses confirmées. Utilisez l’outil de redirection déjà géré par votre équipe, ajoutez une correspondance limitée à ce seul chemin et testez-la d’abord avec une redirection temporaire. Si l’adresse doit être introuvable, corrigez les liens éditoriaux qui l’utilisent et faites examiner la couche qui provoque le saut. Remettre l’ancienne cible du menu ou retirer la règle ajoutée permet de revenir à l’état relevé au début.
Distinguer le slug historique, la devinette et une règle explicite
Commencez par les règles que vous pouvez consulter. Vérifiez l’outil de redirection du site, puis le panneau de l’hébergement ou du CDN si vous y avez accès. Cherchez une correspondance exacte et une règle qui couvre un ensemble de chemins. Les conditions peuvent dépendre de la langue, du domaine ou de la présence d’un paramètre. Un en-tête X-Redirect-By, lorsqu’il existe, aide à identifier le composant, mais plusieurs mécanismes peuvent produire le même en-tête. Comparez la première réponse publique à celle de l’origine uniquement par le chemin de diagnostic autorisé.
Examinez ensuite l’historique de la publication qui reçoit le trafic. Si vous avez accès à WP-CLI, recherchez ses métadonnées _wp_old_slug avec wp --path="/chemin/recette" --url="https://recette.example.test" post meta list 123 --keys=_wp_old_slug --fields=meta_key,meta_value. Remplacez 123 par l’identifiant du contenu de destination. La présence du slug court donne une raison de vérifier s’il s’agit d’une ancienne adresse connue. Cette lecture est un indice pour le contenu inspecté. Elle n’exclut pas une règle dans une extension ou un historique sur un autre objet. Le cœur dispose d’un traitement séparé pour certaines anciennes adresses. Sur une recette, testez un ancien slug dont vous connaissez l’historique et comparez-le au chemin court.
La devinette native intervient dans certaines requêtes qui aboutissent à une 404 et pour lesquelles WordPress a interprété un nom de contenu. Le cœur peut chercher un slug qui commence par ce nom, en tenant compte des informations de la requête telles que le type de publication ou une date. Cela explique pourquoi deux sites ayant des structures d’URL différentes peuvent réagir différemment à une adresse ressemblante. Si la redirection disparaît et laisse une 404 lorsque vous désactivez uniquement la devinette pour cette adresse en recette, vous disposez d’un indice plus précis que le seul nom de destination.
- Relevez les règles de redirection qui s’appliquent au chemin, puis confirmez si le contenu de destination a porté le slug court.
- Si la redirection est volontaire et correspond à une ancienne adresse utile, gardez-la dans les témoins de validation. Si une règle explicite est erronée, corrigez cette règle et refaites la mesure.
- Si aucune règle ou ancienne adresse connue n’explique la réponse, utilisez le contrôle ciblé ci-dessous avec le mainteneur de la copie.
Vérifier et désactiver la devinette pour un seul chemin
Cette voie convient lorsque vous gérez les fichiers de la recette et que le chemin doit rester introuvable. Le code utilise un filtre de WordPress pour refuser la devinette sur deux formes du même chemin, avec et sans barre finale. Il tient compte de l’identifiant du site pour que le même fichier ne change pas la réponse d’un autre sous-site. Remplacez 7 par l’identifiant de la cible, par exemple la valeur de get_current_blog_id() lue dans WP-CLI avec l’URL de ce site. Sur un site installé dans un sous-dossier, saisissez le chemin complet demandé par le navigateur. L’exemple vise des adresses sans paramètres. Comparez séparément les variantes avec paramètres si elles font partie du signalement.
Dans le dossier des extensions indispensables de la recette, habituellement wp-content/mu-plugins/, créez le fichier atelier-404-cible.php avec le contenu suivant. Les fichiers PHP au premier niveau de ce dossier sont chargés automatiquement. Si vous disposez d’un terminal, validez d’abord la syntaxe avec php -l atelier-404-cible.php. Vérifiez la première réponse des quatre adresses de contrôle après chargement. Si le chemin court donne maintenant une 404 et que l’adresse exacte et le témoin d’ancien slug fonctionnent, le résultat soutient l’hypothèse de la devinette. Si le saut persiste, retirez le fichier de recette et continuez la recherche de la règle qui produit la réponse.
Le filtre laisse agir les autres mécanismes. Une redirection historique ou une règle explicite peut encore répondre pour ce chemin. Une autre extension peut aussi modifier le même filtre. L’effet se mesure sur l’URL réelle, sans tirer de conclusion à partir de la présence du fichier. Évitez de retirer toute la fonction de canonicalisation WordPress pour résoudre une seule 404. Elle traite aussi d’autres formes d’URL. Pour revenir à la configuration de recette précédente, retirez uniquement le fichier ajouté et relisez les réponses des témoins.
<?php
/**
* Plugin Name: Atelier. Contrôle d’une devinette 404
*/
if (!defined('ABSPATH')) {
exit;
}
add_filter('do_redirect_guess_404_permalink', static function (bool $enabled): bool {
if ((int) get_current_blog_id() !== 7 || !is_404()) {
return $enabled;
}
$method = $_SERVER['REQUEST_METHOD'] ?? '';
$uri = $_SERVER['REQUEST_URI'] ?? '';
if (in_array($method, ['GET', 'HEAD'], true)
&& in_array($uri, ['/fiche-temoin/', '/fiche-temoin'], true)) {
return false;
}
return $enabled;
});Interpréter les résultats lorsque plusieurs règles se superposent
Il peut y avoir plusieurs réponses avant l’article. Si la première mène vers le même chemin avec une barre finale, relevez ce premier saut puis interrogez le chemin qui figure dans Location. Si le saut suivant mène au contenu ressemblant, c’est ce deuxième chemin qu’il faut comparer avec le témoin. Faites de même lorsque l’hébergement redirige d’abord vers le domaine préféré. Le filtre de la recette agit dans WordPress. Une redirection prise en charge avant que la demande atteigne WordPress peut donc masquer le résultat du test.
Lorsque le chemin nu répond comme prévu, répétez les mesures avec une variante utile, par exemple un paramètre de suivi fictif, le préfixe de langue ou la même adresse sur le sous-site témoin. Le filtre d’exemple compare l’adresse brute. Une variante avec paramètres ne correspond pas au chemin visé et peut continuer à rediriger. Décidez séparément si elle doit répondre de la même manière. Pour un lien interne, corriger la source du lien peut suffire. Pour une campagne déjà diffusée, vérifiez ce que l’adresse promettait au lecteur et préparez une règle explicite si elle doit rester utilisable.
Lorsque les deux adresses de départ renvoient des destinations différentes pour un même contenu, comparez d’abord leurs chemins et le type de requête compris par WordPress. Une adresse courte placée sous le chemin d’un type de publication peut être traitée autrement que la même chaîne à la racine. Un changement de structure de permaliens agirait sur beaucoup plus de liens. Gardez les réglages actuels pendant l’essai et choisissez un témoin dans le même type de publication.
Si la redirection historique attendue cesse aussi de fonctionner en recette, retirez la modification et refaites la comparaison. Vérifiez si une autre règle a été changée en même temps. La réparation doit produire un résultat distinct pour l’adresse sans contenu et pour le lien conservé. Une seule réponse corrigée ne valide pas les deux.
Confirmer le statut et les liens qui doivent continuer à fonctionner
Reprenez les quatre adresses dans une session publique. Le chemin corrigé doit produire le résultat voulu. Si la page n’existe pas, vérifiez un vrai statut 404 et le document d’erreur prévu. Si le lien devait mener à un contenu valide, vérifiez le premier saut et la destination exacte, ou une réponse directe si vous avez corrigé le lien à la source. Confirmez que la publication au nom proche répond encore et que l’ancien lien conservé atteint sa destination. Si le site possède plusieurs langues, un sous-dossier ou un réseau, essayez aussi un témoin hors du chemin visé.
Un ancien 301 peut persister dans le navigateur ou un cache partagé même après une correction à l’origine. Comparez le résultat en session neuve à celui d’un accès de recette sans cache. Si une ancienne réponse reste dans le cache du site ou du CDN, invalidez le chemin touché selon la procédure de l’équipe, puis relisez la première réponse. Évitez de prendre un changement de paramètres pour preuve de purge, car le cache peut traiter ces adresses séparément. Gardez les quatre relevés, le domaine de test, la règle modifiée et le retour prévu. Si un lien conservé cesse de fonctionner, rétablissez la configuration précédente et reproduisez le problème sur la copie avant d’élargir la correction.





