Trouvez d’abord le scénario qui correspond à votre panne
L’accueil fonctionne, mais tous les articles affichent « Page introuvable ». Ou bien une seule page refuse de s’ouvrir après avoir changé de titre. Ces deux situations produisent parfois le même message 404, mais elles ne demandent pas la même réparation. Dans le premier cas, les règles qui dirigent les adresses vers WordPress peuvent manquer. Dans le second, le lien utilisé peut simplement ne plus correspondre à celui de la page.
Une réponse 404 signifie que le serveur n’a pas trouvé la ressource demandée à cette adresse. Elle ne prouve pas que votre article a disparu de la base de données. Commencez par ouvrir son écran de modification dans l’administration. Si le contenu s’y trouve toujours, vous avez une piste plus précise : il faut vérifier son état, son adresse et le chemin qui permet d’y accéder.
Ce guide propose trois approches. La première corrige le contenu ou les réglages de WordPress, sans modifier le serveur. La deuxième répare l’acheminement des adresses quand les permaliens échouent en série. La troisième traite les anciennes adresses après un déplacement volontaire. Choisissez selon le symptôme, puis contrôlez le résultat avant de passer à une autre branche.
Les opérations sur le serveur concernent les installations disposant d’un accès à l’hébergement. Sur WordPress.com ou une offre administrée, certaines corrections doivent être demandées au support. Une extension supplémentaire n’est nécessaire à aucune des trois approches principales.
Constituez une petite liste de liens à tester
Copiez trois ou quatre adresses exactes dans un document : l’accueil, un article qui fonctionne, une page qui échoue et, si nécessaire, une fiche produit. Ajoutez la date du dernier fonctionnement connu. Écrivez aussi ce qui s’est passé entre les deux : migration, changement de domaine, modification des permaliens, désactivation d’une extension ou renommage d’une page. Cette chronologie évite de corriger le mauvais niveau.
Ouvrez chaque lien dans une fenêtre privée. Comparez ensuite avec votre session connectée. Un brouillon ou un contenu privé peut être visible pour un administrateur et inaccessible au visiteur. Notez aussi l’adresse finale affichée dans la barre du navigateur : une redirection peut vous avoir envoyé sur un autre domaine avant le message d’erreur.
Avant une intervention sur les fichiers, téléchargez la configuration concernée dans un dossier local privé. Avant une modification importante des réglages, assurez-vous de disposer d’une sauvegarde restaurable des fichiers et de la base. Ne laissez pas les copies de configuration dans le répertoire public. Pour une simple correction de lien dans un menu, conserver l’ancienne valeur dans vos notes suffit généralement à préparer le retour arrière.
Approche 1 : corriger la page ou le lien depuis WordPress
Dans Pages ou Articles, recherchez le contenu par son titre. Examinez son état : publié, brouillon, privé ou placé dans la corbeille. Si la page doit être publique, vérifiez que sa publication correspond bien à votre intention. Ne rendez pas public un document privé uniquement pour faire disparaître une erreur. Une page supprimée par erreur peut être restaurée depuis la corbeille tant qu’elle y est encore disponible.
Ouvrez l’éditeur et repérez le lien du contenu dans ses réglages. Utilisez l’action permettant de voir la page publiée, puis comparez cette adresse avec le lien défaillant. Une différence de sous-dossier, de mot dans le slug ou de domaine suffit à expliquer le problème. Le slug est la portion lisible de l’adresse propre à la page ; il n’est pas nécessairement identique à son titre actuel.
Si le lien correct fonctionne mais que le menu utilise l’ancien, corrigez le menu. Avec un thème à blocs, ouvrez l’éditeur de site et la navigation concernée. Avec un thème classique, passez par l’écran des menus lorsque le thème le propose. Vérifiez surtout les liens personnalisés : ils peuvent conserver une adresse saisie manuellement alors que la page a changé.
Enregistrez le menu, puis cliquez dessus en visiteur déconnecté. Contrôlez aussi les boutons et liens placés dans le corps des pages. Modifier le menu ne corrige pas automatiquement une ancienne adresse envoyée dans une newsletter ou citée sur un autre site. Pour ces visiteurs, la troisième approche peut être nécessaire.
Régénérez les permaliens sans changer leur structure
Si plusieurs contenus publiés existent mais renvoient 404, ouvrez Réglages, puis Permaliens. Prenez une capture ou recopiez la structure actuellement choisie, ainsi que les bases de catégories et d’étiquettes personnalisées. Le but est de remettre les règles en état, pas de changer l’adresse de tous vos articles pendant le dépannage.
Conservez donc exactement les mêmes valeurs, puis cliquez sur Enregistrer les modifications. Cette action permet à WordPress de reconstruire ses règles. Lisez le message obtenu. Selon l’hébergement et les droits d’écriture, WordPress peut mettre à jour le fichier de configuration utilisé pour les permaliens, ou vous indiquer qu’une intervention manuelle est nécessaire.
Reprenez immédiatement votre liste de liens. Si les pages reviennent, vérifiez plusieurs types de contenus et une archive de catégorie. Ne vous contentez pas de l’accueil, qui pouvait déjà fonctionner. Notez la correction effectuée et surveillez si le problème revient après une mise à jour précise.
Évitez l’astuce consistant à choisir successivement plusieurs structures au hasard. Elle introduit de nouvelles adresses et peut brouiller vos observations. Évitez également d’ajouter un bout de code qui reconstruit les règles à chaque visite : cette opération a un coût et ne doit pas servir à masquer une mauvaise configuration persistante.
Vérifiez si l’échec concerne réellement la réécriture des adresses
Pour un article classique, son identifiant peut être relevé dans l’adresse de son écran de modification : le paramètre post= contient un nombre. Sur une installation ordinaire, vous pouvez comparer son adresse habituelle avec une URL de type https://exemple.com/?p=123, en remplaçant le domaine et le nombre par les bonnes valeurs. Pour une page, la forme ?page_id=123 peut servir au même diagnostic.
Ces exemples sont des tests, pas des liens à diffuser comme nouvelle structure du site. WordPress peut les rediriger vers l’adresse canonique ; observez donc aussi la destination finale. Si la requête identifiée retrouve le contenu alors que les adresses lisibles échouent, cela renforce la piste des règles de réécriture. Si les deux échouent, revérifiez l’état du contenu et l’installation interrogée.
Après une migration, assurez-vous que votre domaine arrive réellement sur le nouvel hébergement. Une ancienne copie du site peut répondre à certaines requêtes et manquer de pages récentes. Comparez une modification connue, le panneau d’hébergement et les informations du domaine. Une régénération de permaliens sur le nouveau serveur ne peut pas réparer une requête qui continue d’atteindre l’ancien.
Approche 2 : rétablir les règles sur un serveur Apache
Demandez à l’hébergeur quel serveur traite effectivement WordPress. Le nom affiché dans une réponse HTTP peut correspondre à un proxy placé devant un autre serveur. Ne choisissez pas une procédure Apache uniquement parce qu’un tutoriel mentionne le fichier .htaccess.
Sur Apache, ce fichier peut contenir les règles nécessaires aux adresses lisibles. Dans le gestionnaire de fichiers, activez l’affichage des fichiers cachés et ouvrez le répertoire de la bonne installation. Repérez .htaccess et téléchargez-en une copie. Il peut contenir, en plus des règles WordPress, des redirections, des protections et des réglages ajoutés par l’hébergement.
Si WordPress vous a fourni des règles après l’enregistrement des permaliens, faites vérifier leur emplacement et remplacez uniquement le bloc concerné. Ne remplacez pas tout le fichier par un exemple générique. Une installation dans un sous-dossier, un réseau multisite et un site installé à la racine n’utilisent pas forcément les mêmes chemins.
Si le fichier semble correct mais reste ignoré, demandez au support de contrôler la prise en compte des fichiers .htaccess, le module de réécriture, le répertoire racine du domaine et les permissions nécessaires. Augmenter tous les droits d’écriture ne résout pas une configuration Apache qui ignore ces directives.
Après la correction, testez un lien de votre liste. Une erreur 500 apparue immédiatement peut signaler une directive invalide : remettez la copie précédente et fournissez au support l’heure de l’essai. Ne poursuivez pas les changements sur un fichier devenu incertain.
Sur Nginx, faites corriger la configuration adaptée au site
Nginx utilisé directement comme serveur web ne lit pas les fichiers .htaccess. En créer un nouveau ne changera donc pas le traitement des adresses. Les règles sont définies dans la configuration du serveur, souvent gérée exclusivement par l’hébergeur. L’administration WordPress ne peut pas remplacer cette configuration à sa place.
Transmettez une demande précise : l’accueil répond, les contenus publiés existent, mais leurs permaliens renvoient 404 après telle opération. Donnez deux adresses de test et précisez si le site est installé à la racine, dans un sous-dossier ou dans un réseau multisite. Demandez de vérifier que les requêtes ne correspondant pas à un fichier réel sont correctement dirigées vers le point d’entrée WordPress.
Si vous administrez vous-même Nginx, sauvegardez la configuration du site et utilisez une procédure adaptée à votre arborescence. Faites valider la syntaxe avant le rechargement du service et gardez une session permettant le retour arrière. Un exemple conçu pour un site unique à la racine peut casser un sous-répertoire ou une autre application hébergée au même endroit.
Le contrôle final reste le même : ouvrez les URL concernées, puis une ressource réelle comme une image. Une règle trop large peut faire fonctionner les articles tout en perturbant les fichiers ou des routes particulières. La réparation doit préserver les deux comportements.
Variante pour les utilisateurs disposant de WP-CLI
WP-CLI permet de reconstruire les règles WordPress depuis une session SSH autorisée. Utilisez cette variante si l’outil est déjà disponible et si vous savez identifier la bonne installation. Elle n’exige pas l’ajout d’une extension dans le tableau de bord. Pour un débutant sans accès SSH, l’écran Permaliens reste plus simple.
Placez-vous dans le répertoire contenant l’installation concernée et vérifiez d’abord l’adresse configurée avec la commande de lecture ci-dessous. Si le domaine ne correspond pas, arrêtez-vous et corrigez votre contexte de travail. La seconde commande régénère les règles internes. Elle ne répare pas à elle seule une configuration Nginx incorrecte.
L’option --hard peut également viser les règles .htaccess dans les installations simples compatibles, avec des prérequis propres à WP-CLI et Apache. Ne l’ajoutez pas automatiquement. Sur un réseau multisite, le site ciblé et les règles réseau demandent une procédure distincte. N’utilisez pas non plus --skip-plugins sans comprendre son effet : un composant ignoré peut justement être celui qui déclare les adresses dont vous avez besoin.
wp option get home
wp rewrite flushSi seuls les produits ou un type de contenu renvoient 404
Un site peut afficher correctement les articles ordinaires alors que les fiches produit, événements ou réalisations échouent. Ces contenus sont souvent déclarés par une extension ou par le thème. Vérifiez si le composant correspondant est toujours actif et compatible. Sa désactivation peut laisser les données en base tout en retirant les routes qui les rendent accessibles.
Contrôlez également la base d’adresse prévue pour ce type de contenu. Une page ordinaire portant le même chemin qu’une archive de produits peut créer une ambiguïté. Relevez les deux adresses avant de renommer quoi que ce soit. Sur une copie de test, rétablissez la configuration attendue, puis régénérez les règles une seule fois.
Ne désactivez pas toutes les extensions d’une boutique ouverte pour mener ce diagnostic. Vous pourriez retirer le paiement ou des règles commerciales. Isolez le changement récent et demandez au responsable du composant quelles routes il doit enregistrer. Si la réparation disparaît à chaque activation ou mise à jour, il faut corriger cette déclaration plutôt que répéter indéfiniment l’enregistrement des permaliens.
Approche 3 : rediriger une ancienne adresse vers son vrai remplacement
Une page a été volontairement déplacée et sa nouvelle adresse fonctionne ? Il reste à traiter les liens qui pointent vers l’ancienne. Préparez un petit tableau contenant chaque ancienne adresse et sa destination exacte. Chaque paire doit correspondre au même contenu ou à un remplacement réellement pertinent pour le visiteur.
Commencez par les outils de redirection fournis par votre hébergeur ou votre plateforme. Selon l’interface, le champ source attend un chemin comme /ancien-guide/ ou une adresse complète. Lisez l’exemple affiché et ne mélangez pas les deux formats. Dans la destination, utilisez l’URL finale qui fonctionne, avec le protocole HTTPS et le domaine voulu.
Pour un déplacement permanent, utilisez le type de redirection permanent proposé, généralement 301. Vérifiez que la destination n’envoie pas elle-même vers la source. Créez d’abord une seule règle exacte, testez-la, puis poursuivez avec les suivantes. Les règles contenant des caractères génériques ou des expressions régulières demandent davantage de précautions, car une erreur peut toucher beaucoup de pages.
Mettez aussi à jour les liens que vous contrôlez : menus, boutons, articles et liens de navigation. Ils devraient pointer directement vers la destination finale. La redirection sert aux anciennes références encore en circulation, pas à maintenir volontairement tous vos liens internes dans un état obsolète.
Si aucun contenu équivalent n’existe, une vraie réponse 404 peut être correcte. Rediriger toutes les adresses inexistantes vers l’accueil n’aide pas le lecteur à retrouver ce qu’il cherchait et peut produire des signaux de type soft 404 pour les moteurs. Une page d’erreur utile peut proposer la recherche et des rubriques pertinentes, tout en conservant son statut d’erreur.
Option complémentaire : gérer les redirections avec une extension
Si vous avez beaucoup de redirections à maintenir et aucun outil adapté chez l’hébergeur, une extension spécialisée peut simplifier leur gestion. Redirection, disponible dans le répertoire WordPress, permet notamment de gérer des redirections et d’observer des erreurs 404. Vérifiez sa compatibilité avec votre environnement avant installation, puis commencez sur une copie ou avec une règle limitée.
Après activation, son interface se trouve dans Outils, puis Redirection. Configurez une source exacte et une destination déjà vérifiée. Évitez les expressions régulières pour votre premier essai. Testez le lien comme un visiteur, puis exportez les règles lorsque l’outil le permet afin d’en conserver une trace.
Les journaux peuvent enregistrer des informations sur les visites. Réduisez leur collecte et leur durée de conservation à ce qui vous sert au diagnostic. Surtout, cette extension ne remplace pas une réparation du serveur : si la requête n’atteint jamais WordPress, une redirection exécutée par WordPress ne pourra pas la traiter.
Contrôlez le résultat au-delà du simple affichage
Reprenez toutes les adresses notées au départ. Pour une page réparée, vérifiez que le bon contenu apparaît et que l’adresse finale est celle attendue. Pour un ancien lien, vérifiez le passage vers son remplacement. Pour une adresse volontairement inexistante, assurez-vous que le site ne renvoie pas discrètement l’accueil avec un message de succès.
Dans les outils de développement du navigateur, l’onglet Réseau permet de lire le statut de la requête principale après rechargement. Une page normale renvoie généralement 200 ; une redirection permanente renvoie 301 ou 308 avant la réponse de destination ; un contenu absent doit conserver un statut adapté comme 404. Le texte visible dans la page ne suffit pas à connaître ce statut.
Si vous voyez encore l’ancienne erreur après une correction confirmée, purgez le cache concerné : celui de la page, du serveur ou du CDN selon votre installation. Rechargez ensuite dans une fenêtre privée. Ne confondez pas un cache de réponse 404 avec une cause toujours présente. Notez à quel niveau vous avez purgé pour pouvoir expliquer la différence.
Enfin, vérifiez vos liens internes et le sitemap. Les adresses qu’ils annoncent doivent mener aux contenus actuels. Dans Search Console, les anciens rapports peuvent rester visibles jusqu’à une nouvelle exploration ; ils ne se mettent pas tous à jour dès votre correction. Une réparation est établie par le bon comportement actuel des URL, puis confirmée dans les observations ultérieures. Elle ne garantit pas à elle seule une indexation ni une position dans les résultats de recherche.
