Erreur 404 sur votre site : retrouver la page et réparer.Page introuvable, « Not Found », permaliens WordPress : la marche à suivre.

1. Regardez qui affiche la 404 : une page à vos couleurs, c'est WordPress qui répond ; une page blanche « Not Found », c'est le serveur.
2. Tout le site sauf l'accueil ? Réglages, puis Permaliens, puis « Enregistrer les modifications », sans rien changer.
3. Toujours en 404 ? Vérifiez le fichier .htaccess à la racine du site, et remettez le bloc de WordPress.
4. Une seule page ? Vérifiez son état (brouillon, privée, corbeille), son adresse et le lien qui y mène.
5. Une page déplacée ? Redirigez l'ancienne adresse en 301 vers la plus proche, jamais tout vers l'accueil.
6. Dans la Search Console, ne traitez que les 404 des pages qui comptaient : les autres sont normales.

Dans ce guide

• Les messages de l'erreur 404
• Grave ou normal ? Le tableau pour trancher
• Les causes, de la plus fréquente à la plus rare
• La marche à suivre, dans l'ordre
• Côté Google : les 404 de la Search Console
• Ce que nous ferions à votre place
• Questions fréquentes

• Une page à vos couleurs, avec votre menu, qui annonce que la page est introuvable : c'est la page 404 de votre thème. WordPress ou PrestaShop fonctionne ; il ne connaît simplement aucun contenu à cette adresse. Cherchez du côté de la page elle-même : son adresse, son état, le lien qui y mène. Une exception : si toutes les pages sauf l'accueil, ou tous vos produits, ou tous vos articles, affichent cette page, réenregistrez d'abord les permaliens (étape 2) : WordPress reçoit les adresses, mais ne sait plus les lire.
• « Not Found », suivi de « The requested URL was not found on this server. », sur une page blanche : la page d'erreur du serveur Apache. La demande n'est même pas arrivée jusqu'à WordPress : c'est la réécriture des adresses qui est en cause, le plus souvent le fichier .htaccess.
• « 404 Not Found » sur une page sobre, avec le mot nginx en dessous : un serveur nginx, même diagnostic. Certains hébergeurs affichent à la place leur propre page d'erreur, à leurs couleurs.
• HTTP ERROR 404 sur la page d'erreur du navigateur, dans Chrome ou Edge : le serveur a répondu 404 sans envoyer de page à afficher.
• « Introuvable (404) », dans le rapport d'indexation des pages de la Search Console : les adresses que Google a essayé de visiter et qui lui ont répondu 404.

Une cousine trompeuse : la soft 404. La page dit « introuvable », ou elle est presque vide, mais le serveur l'envoie avec le code 200 d'une page normale. Google la signale à part dans le même rapport ; nous y revenons plus bas, dans la partie consacrée à Google.

1. Une page supprimée ou déplacée sans redirection. Son adresse a été modifiée, la page a été refaite sous un autre nom, le site a été réorganisé ou refait. Google, les autres sites, vos e-mails et vos publications pointent toujours vers l'ancienne adresse.
2. Un lien faux : un lien du menu tapé à la main, un bouton, un article, la signature de vos e-mails, votre fiche Google. Ou simplement une adresse mal tapée par le visiteur.
3. Une page qui n'est plus publiée : en brouillon, programmée, privée ou à la corbeille ; un produit désactivé ou supprimé. Connecté à l'administration, vous la voyez encore ; vos visiteurs, non.
4. La réécriture des adresses cassée : le fichier .htaccess a disparu, a été écrasé par une extension, une migration ou une restauration, ou ne contient plus les lignes de WordPress. Le signe qui ne trompe pas : toutes les pages sont en 404, sauf l'accueil.
5. Une migration ou un changement de domaine : des images et des documents qui n'ont pas été copiés, ou des adresses restées sur l'ancien domaine, l'ancien dossier ou l'adresse provisoire de l'hébergeur.
6. Une extension désactivée qui créait ses propres pages (boutique, événements, annuaire, traduction) : ses adresses disparaissent avec elle. Ou une nouvelle structure des permaliens, qui modifie d'un coup l'adresse de tous vos articles.
7. Plus rarement, le serveur : module de réécriture inactif, serveur nginx sans la règle qu'attend WordPress. Ou les suites d'une intrusion : des pages de spam retirées depuis, que Google continue de visiter.

1. Regardez qui affiche la 404, et où

Ouvrez l'adresse en erreur dans une fenêtre de navigation privée, puis deux ou trois autres pages, puis l'accueil. Connecté à l'administration, vous voyez des pages que vos visiteurs ne voient pas, d'où la navigation privée. Trois questions tranchent presque tout. La page d'erreur est-elle à vos couleurs (c'est WordPress qui répond) ou blanche, en anglais (c'est le serveur) ? Toutes les pages sont-elles touchées, ou une seule ? L'erreur a-t-elle commencé après un changement : mise à jour, migration, nouvelle extension, page renommée ? Toutes les pages sauf l'accueil : étapes 2 à 4, ou 9 sur PrestaShop et Joomla. Une seule page : étapes 5 à 7.

2. Tout le site sauf l'accueil : réenregistrez les permaliens

Dans l'administration, ouvrez Réglages, puis Permaliens, et cliquez sur « Enregistrer les modifications » sans rien changer. WordPress recalcule ses règles d'adresses et réécrit son bloc dans le fichier .htaccess. C'est la réparation la plus fréquente après une migration, la restauration d'une sauvegarde ou l'activation d'une extension qui crée ses propres pages. Rechargez une page en navigation privée, après avoir vidé le cache de votre extension de cache s'il y en a une. Si la page des permaliens affiche, en bas, un message qui dit que le fichier .htaccess n'est pas modifiable, avec des règles à copier, passez à l'étape 3.

3. Toujours en 404 ? Vérifiez le fichier .htaccess

Par FTP ou avec le gestionnaire de fichiers de l'hébergeur, ouvrez la racine du site, là où se trouvent wp-config.php et les dossiers wp-admin, wp-content et wp-includes. Le fichier .htaccess est caché : dans FileZilla, menu Serveur, puis « Forcer l'affichage des fichiers cachés » ; dans le gestionnaire de fichiers de cPanel, ouvrez Paramètres, cochez la case des fichiers cachés (dotfiles) et enregistrez. S'il existe, téléchargez-en d'abord une copie. S'il manque, ou s'il ne contient pas les lignes de WordPress, créez-le ou complétez-le avec le bloc standard :

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Si WordPress est installé dans un sous-dossier, les deux / de RewriteBase et de la dernière règle deviennent /nom-du-dossier/ : le plus simple est alors de rendre le fichier modifiable (droits 644) et de laisser WordPress l'écrire, en réenregistrant les permaliens. Vos propres règles, redirections comprises, se placent au-dessus de la ligne # BEGIN WordPress : WordPress réécrit tout ce qui se trouve entre ses deux lignes de repère.

4. Le fichier est bon, rien ne change : le serveur ne le lit pas

Les lignes de WordPress sont entourées de <IfModule mod_rewrite.c> : si le module de réécriture du serveur, mod_rewrite, n'est pas actif, elles sont ignorées sans aucun message d'erreur, et seul l'accueil répond. La plupart des hébergements mutualisés lisent le fichier .htaccess (serveurs Apache ou LiteSpeed) : demandez à l'hébergeur si la réécriture est bien active pour votre site. Sur un serveur nginx, en revanche, aucun fichier .htaccess n'est lu : la règle se trouve dans la configuration du site. Voici celle que WordPress recommande, dans le bloc location / :

try_files $uri $uri/ /index.php?$args;

Sur un hébergement géré, c'est à l'hébergeur de l'ajouter ; sur un serveur à vous, à la personne qui l'administre.

5. Une seule page ou un produit en 404 : son état et son adresse

Dans Pages, Articles ou Produits, cherchez le contenu par son titre. Un brouillon, une page programmée ou une page privée répondent 404 à vos visiteurs. Une page à la corbeille aussi : ouvrez le filtre Corbeille, en haut de la liste, puis Restaurer ; depuis WordPress 5.6, la page revient en brouillon, il faut la republier. Comparez ensuite son adresse, affichée dans le panneau de réglages de l'éditeur, avec celle du lien en erreur. La fin de l'adresse, tirée du titre et propre à chaque contenu, s'appelle le slug : un slug modifié, ou terminé par -2 parce qu'un autre contenu portait déjà ce nom, suffit à casser les liens. Quand vous changez le slug d'un article ou d'un produit publié, WordPress garde l'ancien en mémoire et y renvoie en général tout seul ; pour une page, il ne le fait pas : posez une redirection, à l'étape 7.

Prudence avec la structure des permaliens, dans Réglages, puis Permaliens, et avec la base des produits de WooCommerce, sur la même page : les changer modifie d'un coup l'adresse de tous vos articles, ou de tous vos produits. À ne faire qu'avec une liste de redirections prête.

6. Corrigez le lien qui mène à la 404

Si la page existe sous une autre adresse, le lien faux est souvent dans le menu : Apparence, puis Menus avec un thème classique, ou Apparence, puis Éditeur, puis Navigation avec un thème à blocs. Dans un menu classique, une page ajoutée depuis la liste des pages suit ses changements d'adresse ; un lien personnalisé tapé à la main, non. Pensez aussi aux boutons de vos pages, à votre fiche Google, à vos réseaux sociaux et à la signature de vos e-mails. Pour trouver les liens cassés de tout le site, le rapport de la Search Console, décrit plus bas, ou un vérificateur de liens fait gagner beaucoup de temps.

7. Redirigez l'ancienne adresse vers la bonne page

Quand une page a été déplacée, renommée ou remplacée, son ancienne adresse doit renvoyer vers la nouvelle par une redirection permanente, dite 301 : vos visiteurs arrivent au bon endroit, et Google reporte sur la nouvelle adresse les liens de l'ancienne. Visez la page la plus proche : un produit retiré vers son remplaçant ou sa catégorie, jamais tout vers l'accueil. Le plus simple sur WordPress : l'extension gratuite Redirection, dans Outils, puis Redirection, avec l'ancienne adresse d'un côté et la nouvelle de l'autre. Elle note aussi les 404 de vos visiteurs et, si vous activez cette option dans ses réglages, crée la redirection quand vous changez l'adresse d'un article ou d'une page. Sans extension, ajoutez une ligne dans le fichier .htaccess, au-dessus de # BEGIN WordPress :

Redirect 301 /ancienne-page/ https://www.votresite.fr/nouvelle-page/

Attention : cette règle vaut aussi pour tout ce qui commence par /ancienne-page/, et y ajoute la suite de l'adresse. Testez chaque redirection en navigation privée, puis vérifiez qu'elle ne renvoie pas vers une autre redirection.

8. Des images en 404 après une migration

Ouvrez une image cassée dans un nouvel onglet et lisez son adresse. Si elle pointe encore vers l'ancien domaine, l'ancien dossier ou l'adresse provisoire de l'hébergeur, ce sont les adresses enregistrées dans la base de données qui n'ont pas suivi : après une sauvegarde, une extension de recherche et remplacement les corrige partout, de l'ancienne adresse vers la nouvelle. Ne le faites pas à la main dans un export SQL : vous risquez de casser des réglages enregistrés. Si l'adresse est la bonne, c'est le fichier qui manque : vérifiez par FTP que le dossier wp-content/uploads a été copié en entier, avec ses sous-dossiers par année et par mois.

9. Sur PrestaShop ou Joomla

Toutes les pages en 404 sauf l'accueil, sur PrestaShop 8 ou 9 : téléchargez d'abord par FTP une copie du fichier .htaccess de la boutique. Puis, dans l'administration, ouvrez Paramètres de la boutique, puis Trafic et SEO. L'option des URL simplifiées, dans le bloc de configuration des URL, ne fonctionne que si le serveur réécrit les adresses. Pour que PrestaShop réécrive son fichier .htaccess, laissez l'option à Oui et enregistrez ce bloc : il régénère le fichier à chaque enregistrement. S'il n'arrive pas à l'écrire, il repasse lui-même les URL simplifiées à Non et affiche une erreur : le fichier doit alors être rendu modifiable (droits 644). Depuis PrestaShop 9.2, avec un accès SSH, la commande bin/console prestashop:htaccess:generate --force, lancée dans le dossier de la boutique, le régénère aussi. Pour un produit désactivé, l'onglet SEO de sa fiche règle ce que voient ses visiteurs : une page introuvable, ou une redirection permanente vers un autre produit ou vers une catégorie.

Sur Joomla, la réécriture des adresses, dans la configuration globale, ne fonctionne qu'une fois le fichier htaccess.txt, livré avec Joomla, renommé en .htaccess, avec le point au début. S'il existe déjà un fichier .htaccess, téléchargez-en d'abord une copie : le renommage le remplace.

Où les voir

Dans la Search Console, le rapport d'indexation des pages (menu Indexation, puis Pages) range sous « Introuvable (404) », dans le tableau « Pourquoi des pages ne sont pas indexées », les adresses que Google a essayé de visiter et qui lui ont répondu 404. Cliquez sur la ligne pour en voir la liste.

Ce qu'en dit Google

Pas de panique devant le chiffre. Google l'écrit lui-même : les erreurs 404 n'ont pas d'incidence négative sur les performances de votre site dans ses résultats. Il retire de son index une adresse qui répond 404, et y repasse de moins en moins souvent, mais il continue un temps d'essayer : une ancienne adresse peut rester des semaines dans le rapport. Ce qui compte, ce sont les adresses qui avaient des visites, des liens d'autres sites ou une place dans Google.

La 410 dit que la page a été retirée pour de bon, là où la 404 ne dit pas si c'est pour un moment ou pour toujours. Sur un serveur Apache, une ligne Redirect 410 /ancienne-promo/ dans le fichier .htaccess suffit ; comme la 301, elle vaut pour tout ce qui commence par cette adresse. Réservez-la aux adresses qui ne serviront plus : une réponse 410 est gardée en cache par défaut. Pour Google, la différence ne compte pas : il traite de la même façon toutes les erreurs dont le code commence par 4, sauf la 429, qui signale un serveur débordé. Le bouton « Valider la correction », dans le détail de « Introuvable (404) », ne sert que si vous avez redirigé ou rétabli toutes les adresses de la liste, par exemple après avoir réparé les permaliens : Google revérifie alors, ce qui prend en général deux semaines environ. Tant que des adresses y restent volontairement en 404, la validation échouera ; ce n'est pas grave, ne la lancez pas. Retirez aussi de votre sitemap les adresses qui n'existent plus.

La soft 404, à éviter

La soft 404, décrite plus haut, est exclue des résultats de Google, qui la signale à part. Elle vient souvent d'un thème ou d'une extension qui affiche son message d'erreur sans le code 404, ou d'une page de catégorie vide. L'outil d'inspection d'URL de la Search Console montre le code que reçoit Google. Et ne redirigez pas toutes les pages mortes vers l'accueil : Google le déconseille, et vos visiteurs n'y trouvent pas ce qu'ils cherchaient.

Une page 404 qui aide à repartir

Gardez une vraie page 404, avec le code 404, mais utile : une phrase claire, un champ de recherche, des liens vers vos pages principales ou vos catégories, et un moyen de vous joindre. Avec un thème à blocs, elle se modifie dans Apparence, puis Éditeur, parmi les modèles ; sinon, dans les réglages du thème ou du constructeur de pages.

• Erreur 403 Forbidden, accès refusé. Droits des fichiers, règle du .htaccess, extension de sécurité, pare-feu de l'hébergeur ou de Cloudflare.
• ERR_TOO_MANY_REDIRECTS, redirections en boucle. Le site renvoie le navigateur en boucle : mode SSL de Cloudflare, http et https, avec ou sans www.
• Erreur 500 WordPress. « Internal Server Error » : le fichier .htaccess, une extension, la version de PHP ou la mémoire.
• Erreur critique WordPress. « Il y a eu une erreur critique sur ce site » : trouver l'extension ou le thème fautif, et le désactiver.

Toutes les erreurs, classées par message : Erreurs de site, trouver la cause et réparer. Des signes d'intrusion (redirections, pages inconnues, fichiers que vous n'avez pas mis) : suivez plutôt notre guide site WordPress piraté, que faire dans la première heure.

Rédigé par l'équipe Boost de WS Agency, qui maintient et protège des sites WordPress, PrestaShop et Joomla. Publié le 30 octobre 2026. Manipulations vérifiées le 30 octobre 2026 ; elles valent pour WordPress 6 et 7, et pour PrestaShop 8 et 9 quand il est cité.

• WordPress, le fichier .htaccess de WordPress (bloc de réécriture par défaut) et WordPress sur nginx (try_files) ; code de référence : wp_check_for_changed_slugs (anciens slugs des articles et produits) et wp_untrash_post (retour en brouillon depuis WordPress 5.6).
• Google Search Central, codes HTTP et exploration (traitement des erreurs 4xx) et résoudre les erreurs d'exploration (soft 404, 301, 404 et 410).
• Aide de la Search Console, erreurs 404 et rapport sur l'indexation des pages (« Introuvable (404) », validation).
• MDN, 404 Not Found et 410 Gone.
• Apache, directive Redirect (301, 410, correspondance par début d'adresse).
• PrestaShop, SEO et URL (URL simplifiées), gestion des produits (redirection d'un produit hors ligne), commande prestashop:htaccess:generate et code de la commande dans PrestaShop 9.2.0 (absente de la 9.1).

Une erreur, une information à compléter, un droit de réponse ? Écrivez à contact@wsagency.fr : nous corrigeons, et nous indiquons ici ce qui a changé et quand.