Votre accueil s'affiche normalement. Vous cliquez sur n'importe quel élément du menu, un article, la page de contact, et vous tombez sur une erreur 404. Les contenus sont pourtant toujours là, vous les voyez dans le tableau de bord, ils ne sont ni en brouillon ni à la corbeille.
Ce guide traite ce cas précis, le 404 généralisé, celui où tout tombe sauf l'accueil. Pas le 404 d'une page isolée, pas la fabrication d'une jolie page d'erreur. La procédure donnée ici est celle qu'on applique en intervention, avec les chemins de fichiers exacts et la façon de revenir en arrière.
Ce que vous voyez, et ce que ça vous dit déjà
Avant de toucher à quoi que ce soit, regardez la page d'erreur elle-même. Il en existe deux, elles n'ont rien à voir, et personne ne vous propose ce tri alors qu'il prend une seconde.
La page nue, sans habillage
Fond blanc, police par défaut, un titre Not Found et une seule phrase : « The requested URL was not found on this server. » Aucun menu, aucun logo, aucune couleur de votre site.
Cette page vient du serveur web, pas de WordPress. Mesurée sur notre installation de test, elle pèse 287 octets. Elle signifie une chose et une seule : la requête n'a jamais atteint WordPress. Le serveur a cherché sur le disque un fichier portant le nom de l'URL demandée, il ne l'a pas trouvé, il s'est arrêté là. PHP n'a pas démarré, votre thème n'a pas été chargé, vos extensions n'ont rien à voir avec ce que vous voyez.
La page aux couleurs du site
En-tête, menu, pied de page, et un texte du genre « Page non trouvée » suivi du nom de votre site. La même mesure donne 59 582 octets, deux cents fois plus lourd que la précédente.
Là, WordPress a répondu. La réécriture a fonctionné, la requête est arrivée jusqu'à index.php, WordPress a cherché le contenu correspondant à l'URL et ne l'a pas trouvé. Toute la partie serveur de ce guide ne vous concerne pas.
Ce tri commande le reste. Une page nue envoie vers les causes 1 à 4, une page habillée envoie directement à la cause 5.
En trente secondes
1. Regardez l'habillage de la page d'erreur. Nue, c'est le serveur. Aux couleurs du site, c'est WordPress. Vous venez d'éliminer la moitié des causes.
2. Vérifiez que l'accueil répond vraiment, et pas depuis un cache. Rechargez avec Ctrl+F5, ou ouvrez le site depuis un téléphone en 4G.
3. Ne perdez pas de temps avec le test ?p=. Vous allez le trouver partout, il ne fonctionne pas. Explication plus bas.
Et notez la structure de permaliens en place, dans Réglages, Permaliens. Une ligne à recopier quelque part. Sans elle, une fausse manœuvre vous laisse avec un site qui marche mais dont toutes les adresses ont changé.
Pourquoi l'accueil, lui, continue de marcher
C'est la question que personne ne pose et c'est elle qui explique la panne entière.
Sur un site WordPress, aucune de vos pages n'existe sur le disque. Il n'y a pas de fichier contact.html dans votre hébergement. Les adresses sont fabriquées à la volée : le serveur reçoit /contact/, constate qu'aucun fichier ne porte ce nom, et une règle de réécriture lui dit de passer la requête à index.php, qui interroge la base et renvoie la bonne page.
L'accueil est le seul cas où cette règle est inutile. La racine du site est servie par le mécanisme d'index par défaut du serveur, celui qui va chercher index.php tout seul quand on demande /.
Quand la réécriture meurt, l'accueil survit donc et absolument tout le reste disparaît. « L'accueil marche, tout le reste est en 404 » n'est pas un symptôme parmi d'autres, c'est la signature d'une réécriture morte. Nous l'avons vérifié sur une installation propre : accueil à 200, article à 404, page à 404, et wp-login.php toujours à 200 puisque c'est un vrai fichier sur le disque. C'est pour cette raison que vous pouvez encore vous connecter alors que le site public est mort.
Le geste que tout le monde donne en premier, et ce qu'il ne peut pas faire
Douze sources sur douze, dans le corpus que nous avons dépouillé, ouvrent par le même clic : Réglages, Permaliens, Enregistrer les modifications, sans rien changer.
Faites-le. C'est gratuit, ça prend cinq secondes, et quand la cause est un .htaccess vidé sur un serveur Apache correctement configuré, ça répare vraiment. Enregistrez deux fois plutôt qu'une, l'habitude vient des forums et elle ne coûte rien.
Si le deuxième essai ne change rien, le troisième ne changera rien non plus, et voici pourquoi.
Ce clic ne fait qu'une chose : demander à WordPress de réécrire le .htaccess. Il ne vérifie pas que le serveur lit ce fichier, ni même que ce serveur sait ce qu'est un .htaccess. Nous avons reproduit le cas : avec la directive AllowOverride None active côté Apache, la régénération s'exécute sans la moindre erreur, le fichier ressort identique à l'octet près, le tableau de bord affiche « Réglages enregistrés », et le site reste en 404.
L'explication est dans le cœur de WordPress. Le fichier wp-admin/includes/misc.php contient une fonction got_mod_rewrite() censée dire si la réécriture est disponible. Elle appelle apache_mod_loaded(), qui a besoin de apache_get_modules(). Cette fonction n'existe pas quand PHP tourne en FPM, ce que nous avons vérifié. Or PHP-FPM est la pile standard chez OVH et chez o2switch, entre autres. Sur ces hébergements, WordPress est structurellement aveugle à l'état de mod_rewrite, et il répond « enregistré » quoi qu'il arrive.
C'est la raison mécanique pour laquelle « j'ai réenregistré mes permaliens dix fois, rien ne change » revient dans tous les fils de forum.
Et le test ?p= ne tranche rien non plus
L'autre conseil universel consiste à ouvrir un article par son adresse non réécrite, votre-domaine.fr/?p=7. S'il s'affiche, dit-on, la réécriture est en cause.
Mesuré : ?p=7 renvoie un 301 vers le permalien joli, dans l'état sain comme dans l'état cassé. Le navigateur suit la redirection, atterrit sur la même adresse que tout à l'heure, et vous obtenez le même 404. Vous en concluez que la réécriture n'est pas en cause, ce qui est exactement l'inverse de la vérité. Servez-vous du tri par l'habillage, il est fiable et ne demande aucun outil.
Les causes, et ce qui les trahit
Nous ne donnerons pas de pourcentages, personne ne les a mesurés. Ce tableau vient de seize pages du premier écran de Google en quatre langues et d'une trentaine de fils de discussion lus en entier.
| Cause | Page d'erreur | Ce qui la trahit |
|---|---|---|
.htaccess supprimé, vidé ou écrasé |
nue | Le fichier est absent de la racine, ou il ne contient plus le bloc # BEGIN WordPress |
AllowOverride None côté Apache |
nue | Le fichier est présent et correct, et réenregistrer les permaliens ne change rien |
Serveur nginx, try_files absent |
nue | L'en-tête de réponse dit nginx. Le .htaccess n'a jamais servi à rien sur ce site |
Module mod_rewrite non chargé |
nue | Serveur que vous administrez, souvent après une réinstallation |
| Filtre du thème sur la requête principale | habillée | Le site remarche entièrement avec un thème par défaut |
| Type de contenu personnalisé mal déclaré | habillée | Seules les fiches d'un type précis tombent, produits ou références |
siteurl et home faux en base |
variable | La panne date d'un changement d'adresse dans Réglages, Général |
| Domaine pointé sur le mauvais répertoire | nue | L'accueil lui-même ne répond pas, ou un site inattendu s'affiche |
Le déclencheur est plus prévisible que la cause. Huit fils sur une trentaine partent d'une migration ou d'un changement d'hébergeur, les autres d'un changement de structure de permaliens, d'une restauration de sauvegarde, ou d'une extension de sécurité qui a réécrit le .htaccess. Première question à se poser : qu'est-ce qui a changé, et quand.
L'arbre de diagnostic
Quelle page d'erreur obtenez-vous ? Nue, avec « The requested URL was not found on this server. » : la requête n'atteint pas WordPress, continuez ci-dessous. Habillée aux couleurs du site : WordPress répond, la réécriture fonctionne, sautez à la cause 5.
Quel serveur web sert votre site ?
Depuis le tableau de bord, Outils puis Santé du site, onglet Informations, section Serveur : la ligne qui nomme le logiciel du serveur web. Depuis un terminal :
curl -I https://votre-domaine.fr
La ligne Server: de la réponse vous le dit. Certains hébergeurs la masquent, demandez-leur alors directement.
- Apache ou LiteSpeed. Le
.htaccessest lu. Causes 1, 2 et 4. - nginx. Le
.htaccessn'est jamais lu, quoi qu'il contienne. Cause 3, et uniquement elle.
Le .htaccess existe-t-il à la racine, avec le bloc WordPress ? Non, cause 1. Oui, intact, et réenregistrer les permaliens ne fait rien : cause 2, puis cause 4.
La réparation, cause par cause
Deux précautions avant de commencer. Téléchargez une copie de votre .htaccess sur votre ordinateur avant de le modifier, c'est un fichier de quelques centaines d'octets qui vous évitera de paniquer. Et ne changez qu'une chose à la fois, en testant entre chaque. Le vrai coût du bricolage n'est pas le temps perdu, c'est l'état inconnu dans lequel il laisse le site.
Cause 1 : le .htaccess a disparu ou a été vidé
Le fichier vit à la racine du site, dans le dossier qui contient aussi wp-config.php et wp-admin, appelé public_html, www ou httpdocs selon l'hébergeur.
Vous ne le voyez pas ? C'est normal, son nom commence par un point, donc il est caché. Dans le gestionnaire de fichiers de votre hébergeur, cherchez un réglage « Afficher les fichiers cachés ». Dans FileZilla, c'est Serveur puis « Forcer l'affichage des fichiers cachés ». Beaucoup de gens concluent que le fichier n'existe pas alors qu'il est simplement invisible.
Le contenu attendu, à recréer si le fichier manque ou si le bloc a disparu :
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
Si le site est installé dans un sous-répertoire, remplacez / par /le-sous-repertoire/ dans RewriteBase et dans la dernière RewriteRule. Tout ce qui se trouve en dehors des marqueurs BEGIN et END est à vous, WordPress n'y touche pas.
Les droits du fichier. 644 pour le .htaccess, 755 pour les dossiers. Vous lirez ailleurs des conseils à 666 ou à 777 : ne les suivez pas, ils ouvrent le fichier en écriture à n'importe qui sur le serveur pour un gain nul. À l'inverse, un fichier verrouillé en lecture seule stricte empêche WordPress de le régénérer, et l'échec est silencieux. 644 laisse le propriétaire écrire, c'est le bon compromis.
Vérifiez ensuite en ouvrant une page interne. Si vous obtenez toujours la page nue à 287 octets, le fichier n'est pas le problème.
Un cas à repérer tout de suite. Si le fichier contient des lignes que vous ne reconnaissez pas, redirections vers un domaine inconnu, bloc FilesMatch qui autorise un fichier PHP au nom bizarre, ne les effacez pas : gardez une copie du fichier entier. Un .htaccess qui redevient fautif tout seul après correction n'est pas une panne de réécriture, c'est une intrusion, et la réparation est alors le nettoyage complet du site.
Cause 2 : AllowOverride None, la cause dont personne ne parle en français
Voilà le cas qui fait perdre le plus de temps, et le plus mal documenté du marché francophone.
Le .htaccess peut être présent, parfaitement écrit, contenir exactement le bloc ci-dessus, et Apache peut l'ignorer complètement. La directive AllowOverride, définie dans la configuration du serveur et non dans votre espace, décide si les fichiers .htaccess sont pris en compte pour un répertoire donné. Quand elle vaut None, votre fichier existe et ne sert à rien.
Le symptôme est rigoureusement identique à celui d'un .htaccess supprimé. Nous avons mesuré les deux états côte à côte : même code 404, même page de 287 octets, à l'octet près. Rien ne les distingue depuis le navigateur. La seule différence est que dans un cas le fichier manque, et dans l'autre il est là, correct, et inutile.
Sur un serveur que vous administrez. La directive se trouve dans le bloc <Directory> qui couvre la racine du site, en général dans /etc/apache2/apache2.conf, parfois surchargée par le fichier du site dans /etc/apache2/sites-available/. Il faut y lire AllowOverride All. Attention à l'ordre : c'est le bloc le plus spécifique qui l'emporte, donc une valeur correcte dans apache2.conf peut être annulée par celle du vhost. Après modification :
sudo systemctl reload apache2
Sur un hébergement mutualisé. Vous n'avez pas accès à cette configuration, et aucune manipulation depuis le FTP ne peut y changer quoi que ce soit. Écrivez au support en posant la question précisément, sinon vous recevrez en réponse le conseil de réenregistrer vos permaliens :
Mon site répond 200 sur l'accueil et 404 sur toutes les autres pages. Le fichier
.htaccessest présent à la racine avec le bloc WordPress standard. Pouvez-vous me confirmer quemod_rewriteest chargé sur mon compte et queAllowOverridevautAllsur le répertoire de mon site ?
Cette formulation obtient une réponse utile beaucoup plus souvent que « mon site ne marche plus ».
Cause 3 : votre site tourne sous nginx
Si l'en-tête Server dit nginx, arrêtez immédiatement de travailler sur le .htaccess. nginx ne lit jamais ce fichier, quel que soit son contenu, ses droits ou son emplacement. Vous pouvez y coller le bloc WordPress, le supprimer, le recréer, changer son propriétaire : rien ne le lira.
C'est le trou le plus béant du corpus français. Sur onze pages françaises dépouillées, dix ne parlent que du .htaccess et aucune ne demande d'abord quel serveur tourne sous le site. Or o2switch, Infomaniak et certaines offres d'OVH servent en nginx ou en LiteSpeed. Un lecteur hébergé chez eux peut suivre les dix premiers articles de Google sans que rien ne bouge.
Sous nginx, la réécriture se déclare dans le bloc server du site :
location / {
try_files $uri $uri/ /index.php?$args;
}
La ligne se lit ainsi : cherche un fichier portant ce nom, sinon un dossier, sinon passe la main à index.php avec les paramètres. La faute la plus courante est une configuration qui se termine par =404 au lieu de /index.php?$args, autrement dit qui renvoie littéralement une erreur 404 en dernier recours.
Un piège. Une réécriture globale du type rewrite ^/(.*)$ /index.php?$1; remet le site public debout et coupe l'accès à /wp-admin : vous réparez le site et vous vous fermez la porte.
Sur un mutualisé en nginx, vous n'éditez pas cette configuration vous-même. La demande à formuler au support est celle-là, et pas autre chose : la directive try_files du bloc location de mon site.
Cause 4 : mod_rewrite n'est pas chargé
Sur un serveur Apache que vous administrez, notamment après une réinstallation ou une migration, le module qui exécute les règles de réécriture peut ne pas être actif. Le .htaccess est alors lu, son contenu enrobé dans <IfModule mod_rewrite.c> est ignoré, et le résultat visible est le même que dans les trois cas précédents.
sudo a2enmod rewrite
sudo systemctl restart apache2
Ne comptez pas sur le tableau de bord pour vous prévenir : sous PHP-FPM, il n'a aucun moyen de savoir si le module est chargé.
Cause 5 : la page 404 est habillée, donc ce n'est pas la réécriture
WordPress a démarré, il a reçu l'URL, il a cherché le contenu et ne l'a pas trouvé. Le serveur est hors de cause, inutile d'y toucher.
Le thème filtre la requête principale. Du code ajouté dans le functions.php du thème, souvent pour trier les articles affichés sur l'accueil, s'applique en réalité à toutes les requêtes du site. Les autres pages ne remontent aucun enregistrement, et WordPress en conclut logiquement à un 404. Le test qui tranche : activez un thème par défaut depuis Apparence, Thèmes. Si le site remarche intégralement, la cause est dans le vôtre. Cherchez alors dans son functions.php les appels à pre_get_posts ou à query_posts, et vérifiez qu'une condition les limite bien à l'accueil.
Un type de contenu personnalisé mal déclaré. Si seules les fiches d'un type précis tombent, produits ou références par exemple, regardez du côté de l'extension qui déclare ce type. Un slug de réécriture mal choisi peut capturer toutes les URL du site, et un type enregistré trop tard dans le chargement produit des fiches en 404 tant que les règles n'ont pas été régénérées. Dans ce dernier cas, et dans ce cas seulement, le passage par Réglages puis Permaliens est bien la réparation.
L'adresse du site est fausse en base. La panne date du moment où vous avez modifié un champ dans Réglages, Général. Corrigez siteurl et home dans la table wp_options avec phpMyAdmin, sans barre oblique finale et en respectant le https://. Sur un multisite déplacé, c'est la constante DOMAIN_CURRENT_SITE restée sur l'ancien domaine dans wp-config.php qui produit ce symptôme.
Deux variantes qui ne se diagnostiquent pas pareil
Les articles sont en 404, les pages passent
Cette dissymétrie exclut d'emblée la réécriture globale : si le .htaccess ou le try_files était en cause, vos pages tomberaient aussi. Regardez la base d'URL des articles, dans Réglages, Permaliens. Si votre structure commence par un préfixe fixe, vérifiez qu'aucune page ne porte le même identifiant : une page dont le slug est blog et une structure en /blog/%postname%/ entrent en collision, et c'est la page qui gagne. Le préfixe de catégorie, réglable sur le même écran, crée le même genre d'ambiguïté quand on le vide. Enfin, les extensions de boutique, de portfolio et de traduction posent leurs propres règles de réécriture, et deux bases identiques mettent les articles au tapis en laissant les pages debout.
Le site public marche, mais l'administration est en 404
Premier tri : quelle page obtenez-vous sur /wp-admin/ ? Si c'est la page nue du serveur, ce n'est plus WordPress qui répond, et le problème rejoint ce qui est traité plus haut. Regardez aussi s'il existe un wp-admin/.htaccess déposé par une extension de sécurité, et renommez-le en .htaccess-off pour tester.
Si c'est une page 404 habillée, c'est presque toujours une extension de sécurité qui a changé l'adresse de connexion et qui refuse l'ancienne. Renommez le dossier de cette extension dans wp-content/plugins/ pour retrouver l'accès.
Si la connexion ne renvoie pas un 404 mais tourne en boucle de redirection, vous n'êtes pas sur la bonne panne : le guide de l'administration WordPress inaccessible traite ce cas, qui relève d'un désaccord d'adresse ou d'un proxy en HTTPS.
Dernier cas, celui des 404 intermittents dans l'administration, qui apparaissent surtout pendant les opérations lourdes, envoi de nombreux produits ou import massif. Regardez si des erreurs 503 apparaissent en parallèle. Une limite serveur mal traduite par un pare-feu applicatif est une explication crédible, et elle se traite comme une erreur 503, pas comme un problème de réécriture.
Si rien n'a marché
Le site ne remarche qu'en permaliens « Simple ». Beaucoup s'arrêtent là et croient avoir réparé. En mode Simple, les adresses sont du type ?p=12 et n'ont besoin d'aucune réécriture. C'est un bon test, il confirme que la base va bien et que le contenu est intact, mais toutes vos adresses ont changé, vos liens externes sont morts et votre référencement avec.
Vous avez tout essayé et rien ne bouge. Nous avons lu des fils où huit manipulations successives ont précédé une réparation qui a pris vingt secondes au support de l'hébergeur, pour un fichier d'index manquant. L'acharnement coûte plus cher que le diagnostic, et c'est ce que couvre une intervention sur un site WordPress cassé : identifier qui répond avant de toucher à quoi que ce soit.
La page d'erreur n'est pas un 404 mais un 500. La cause est alors différente, souvent une directive refusée dans le .htaccess, et le guide de l'erreur 500 reprend ce cas depuis le début.
Le site marche pour vous et pas pour vos visiteurs. C'est un CDN ou un pare-feu en amont, pas WordPress. Videz le cache de ce service : un 404 mis en cache reste servi longtemps après que l'origine a été réparée.
Ce que nous ne faisons pas. Notre forfait couvre la panne, remettre le site en ligne et documenter la cause. Il ne couvre pas la reconstruction d'une mise en page abîmée dans un constructeur, ni la refonte d'un thème, ni le développement de fonctionnalités.
Comment éviter que ça recommence
Sachez sur quel serveur vous êtes, avant d'en avoir besoin. Apache, nginx ou LiteSpeed, noté à froid à côté de vos identifiants d'hébergement. Le jour de la panne, cette ligne vous évite une heure de travail sur un fichier que personne ne lit.
Gardez une copie de votre .htaccess fonctionnel, et de votre structure de permaliens, dans le même fichier de notes. Les extensions de sécurité et de cache écrivent toutes dans ce fichier, et certaines l'écrasent.
Après une migration, testez une page interne, pas seulement l'accueil. L'accueil répond même quand la réécriture est morte, c'est tout le sujet de ce guide. Ouvrez un article, une catégorie, et la connexion à l'administration.
Questions fréquentes
Comment réparer erreur 404 not found ?
Regardez d'abord la page d'erreur. Nue, avec la phrase « The requested URL was not found on this server. », la requête n'atteint pas WordPress et la cause est côté serveur : .htaccess absent, AllowOverride None, ou nginx sans try_files. Habillée aux couleurs du site, WordPress a répondu et la cause est dans le thème, dans un type de contenu ou dans l'adresse enregistrée en base. Réenregistrer les permaliens ne répare que le premier cas, et le tableau de bord affichera « enregistré » même quand ça n'a servi à rien.
Pourquoi une page est introuvable ?
Sur WordPress, aucune page n'existe sous forme de fichier sur le disque. Le serveur reçoit une adresse, ne trouve rien à ce nom, et une règle de réécriture doit alors passer la requête à index.php, qui va chercher le contenu en base. Quand cette règle est absente ou ignorée, le serveur s'arrête à la première étape et répond 404. La page existe toujours, elle est juste devenue inatteignable.
Quelles sont les causes de l'erreur 404 not found et comment la corriger ?
Quand tout le site est touché sauf l'accueil, elles sont cinq. Le .htaccess supprimé ou vidé, qu'on recrée avec le bloc WordPress standard. La directive AllowOverride None côté Apache, qui rend ce fichier inutile et se corrige dans la configuration du serveur. Un serveur nginx, où le .htaccess n'est jamais lu et où la réécriture passe par try_files $uri $uri/ /index.php?$args;. Le module mod_rewrite non chargé, qu'on active avec a2enmod rewrite. Et les cas où WordPress répond lui-même, reconnaissables à une page 404 habillée : filtre du thème, type de contenu mal déclaré, adresse du site fausse en base.
Que veut dire « The requested URL was not found on this server » ?
C'est le texte de la page d'erreur d'Apache, affiché en anglais sur la quasi-totalité des hébergements français. Il signifie que le serveur n'a trouvé sur le disque ni fichier ni dossier correspondant à l'adresse demandée. Sur un site WordPress, c'est le signe que la règle de réécriture vers index.php n'a pas été appliquée. La page pèse moins de trois cents octets et n'affiche aucun élément de votre site, c'est à ça qu'on la reconnaît.
Pourquoi seul l'accueil de mon site fonctionne ?
Parce que l'accueil est la seule adresse qui n'a besoin d'aucune règle de réécriture : il est servi par le mécanisme d'index par défaut du serveur, qui va chercher index.php tout seul quand on demande la racine. Toutes vos autres adresses dépendent de la réécriture. Quand elle tombe, l'accueil survit et le reste disparaît.