Corriger les erreurs 404 dans la Google Search Console
Dans la Google Search Console, « Introuvable (404) » signale que Googlebot a demandé une URL et reçu un code 404. Tous ne sont pas à corriger : un 404 sur une URL de spam jamais créée est normal. La bonne démarche n'est pas de tout corriger, mais de trier : ignorer, passer en 410, rediriger en 301, ou restaurer.
Ouvrez le rapport « Indexation des pages » de la Google Search Console et le statut « Introuvable (404) » affiche un compteur qui ressemble à une liste de tâches. L'intuition est simple : autant de lignes, autant d'erreurs à régler. Elle est fausse. La plupart de ces 404 sont normales, et certaines sont même souhaitables : une page supprimée doit renvoyer un 404, c'est exactement ce que Google attend.
La vraie difficulté se déplace alors. Laquelle de ces URLs mérite réellement une action ? Et pour celle-là, faut-il rediriger, la laisser mourir proprement, ou la restaurer ? Et surtout : pourquoi la 404 la plus coûteuse pour votre trafic ne figure-t-elle même pas dans le rapport 404 ?
Le travail n'est pas la liste, c'est le tri. Le plus dur n'est pas de corriger une 404, c'est de trouver laquelle corriger.
« Introuvable (404) » : ce que Google signale exactement
« Introuvable (404) » signifie que Googlebot a demandé une URL et que votre serveur a répondu par un code HTTP 404. La page n'existe pas. Google ne l'indexe pas, et la retire de l'index si elle y figurait. C'est un constat technique brut, pas un jugement de gravité : le statut décrit une réponse serveur, il ne dit rien de l'importance de la page perdue.
Il faut le distinguer d'emblée d'un autre cas qui lui ressemble : le Soft 404. Là, le serveur répond par un code 200 (« la page existe ») alors que la page est vide ou sans valeur réelle. Google détecte l'incohérence et la signale séparément. Un 404 « dur » envoie le bon code ; un Soft 404 ment sur son propre état. Les deux problèmes n'ont ni la même cause ni la même correction. Nous revenons sur le Soft 404 plus bas, et l'article dédié au statut Introuvable (404) détaille la lecture du rapport.
Un 404 est-il toujours un problème ?
Non, et c'est le point que la plupart des audits ratent. Google est explicite : « les réponses 404 ne sont pas nécessairement un problème si la page a été retirée sans remplacement ». Une page que vous avez volontairement supprimée renvoie un 404, et c'est le comportement attendu. John Mueller, côté Google, répète régulièrement que les 404 font partie du fonctionnement normal d'un site : leur seule présence dans le rapport n'appelle aucune correction.
La distinction utile n'est pas « 404 ou pas 404 », mais « 404 sans coût » contre « 404 coûteuse ».
Une 404 normale, au coût nul, c'est une URL que plus personne d'important ne référence :
- une URL de spam ou inventée par un scrapeur, jamais créée par vous ;
- une faute de frappe dans un lien posé sur un autre site ;
- une page supprimée volontairement, sans équivalent, qui n'a plus de raison d'exister.
Une 404 coûteuse, c'est l'inverse : une page qui avait une valeur et qui a disparu.
- Une page utile perdue par accident : suppression involontaire, URL changée sans redirection, déploiement raté. Elle avait du trafic, des liens, des positions.
- Une 404 que votre propre site continue de pointer : un lien interne actif, ou une entrée encore présente dans votre sitemap. Vous envoyez visiteurs et Googlebot dans le vide.
C'est précisément ce second groupe que Google recommande de traiter. Sa formule est nette : « en règle générale, nous recommandons de corriger uniquement les erreurs 404 que vous liez vous-même ou que vous listez dans un sitemap ». Tout le reste peut rester en l'état.
Les causes d'une 404
Une 404 a toujours une origine technique précise, et c'est elle qui dicte la correction. Les causes se classent surtout par actionnabilité : celles qui viennent de votre site, que vous pouvez corriger, et celles fabriquées ailleurs, sur lesquelles vous n'avez aucune prise.
Côté votre site (à corriger)
- Suppression sans redirection. Vous retirez une page qui avait un équivalent, sans poser de redirection vers lui. La 404 devient un cul-de-sac évitable.
- Liens internes cassés. Un lien dans votre contenu pointe vers une URL erronée (faute de frappe, ancienne structure). La cible n'existe pas, alors qu'une bonne page existe peut-être à côté.
- Redirections cassées. Une chaîne de redirections dont la destination finale a, elle aussi, été supprimée. Le visiteur enchaîne les sauts pour finir sur un 404.
Côté extérieur (souvent à ignorer)
- Backlinks brisés. Un autre site vous lie avec une URL obsolète ou mal copiée. Vous ne contrôlez pas ce lien, mais s'il pointait vers une page utile, vous pouvez récupérer sa valeur par une redirection.
- URLs jamais créées, spam, fautes externes. Des adresses inventées, des variantes générées par des robots. La 404 est la bonne réponse : rien à corriger.
Un dernier cas mérite d'être cité sans s'y attarder : certaines pages remontent non pas en « Introuvable (404) » mais en « Bloquée : autre problème 4xx » (codes 401, 403…). C'est un statut voisin, avec ses propres règles, que nous traiterons dans un article à venir.
Soft 404 : le 404 déguisé en page valide
Un Soft 404 est une page qui répond par un code 200 (« tout va bien ») alors que son contenu signale en réalité une absence. Google la traite comme une 404 parce qu'elle n'apporte rien, mais elle n'apparaît pas dans le rapport « Introuvable (404) » : elle a son propre statut.
Les déclencheurs classiques :
- une page de catégorie ou de résultats vide (« aucun produit dans cette section ») qui renvoie quand même un 200 ;
- une page de message d'erreur (« cette fiche n'existe plus ») servie avec un code 200 au lieu d'un vrai 404 ;
- une page en rendu côté client (JS/CSR) dont le contenu ne se charge pas pour Googlebot : il ne voit qu'une coquille vide.
La règle de Google est directe : « renvoyez un code 404 pour les pages réellement introuvables ». Servir un 200 sur une page sans contenu crée plus de confusion qu'un honnête 404. Le mécanisme complet, ses causes et ses corrections sont détaillés dans l'article Soft 404.
L'arbre de décision : ignorer, 410, 301 ou restaurer
Pour chaque 404 qui mérite votre attention, quatre issues seulement. Le bon choix dépend de ce qu'était la page et de ce qui la remplace, pas d'une règle uniforme appliquée à toute la liste.
- Ignorer. La page n'a ni équivalent ni valeur résiduelle, et plus personne d'important ne la pointe. Laissez le 404 : c'est la bonne réponse. La faire disparaître du rapport ne sert à rien.
- Passer en 410 (Gone). La page est supprimée définitivement et assumée, et vous voulez le signaler sans ambiguïté. Le 410 affirme l'intention de suppression.
- Rediriger en 301. La page a un véritable équivalent. Une redirection 301 vers cet équivalent transfère visiteurs et signaux vers la bonne destination.
- Restaurer. Une page utile a disparu par erreur. Remettez-la en ligne à la même URL.
Sur le choix entre 404 et 410, gardez la mesure. En pratique, Google traite les deux de façon très proche : dans les deux cas, l'URL finit désindexée et le contenu n'est plus utilisé. Le 410 dit simplement « supprimé pour de bon » de façon plus explicite. Réservez-le aux suppressions délibérées et assumées (anciennes promotions, fiches discontinuées par lot). Pour le reste, un 404 par défaut convient parfaitement. Inutile de migrer en masse vos pages mortes vers du 410 : le gain est marginal et l'effort réel.
Cet arbre est facile à dérouler sur cinq URLs. La difficulté commence quand le rapport en compte des centaines.
Trier vos 404 à l'échelle
Trier des centaines de 404 revient à croiser trois informations par URL : son trafic passé, les liens internes qu'elle reçoit encore, et sa présence ou non dans le sitemap. C'est ce croisement qui classe chaque 404 dans une branche de l'arbre. Le problème, c'est que l'outil d'inspection d'URL de la Search Console ne traite qu'une seule URL à la fois : vous inspectez, vous lisez, vous passez à la suivante. Sur une poignée d'adresses, c'est tenable. Au-delà, le tri manuel devient impraticable.
C'est le mur que fait sauter IndexProbe : la version en masse de l'outil d'inspection d'URL de Google. Il interroge l'API officielle de la Search Console pour inspecter, en une seule analyse, la liste d'URLs que vous lui fournissez (import CSV, sitemap, copier-coller) ou que vous constituez depuis votre Search Console. Pour chaque URL, il renvoie le code de crawl officiel retenu par Google (404, 410, 200, redirection) et la date du dernier passage de Googlebot. Vous distinguez en un clin d'œil les URLs réellement en 404, celles qui répondent à nouveau en 200 après correction, et celles qui partent en redirection.
Mais le tri ne s'arrête pas aux codes de crawl. La 404 la plus dangereuse pour votre trafic n'est pas dans le rapport 404. C'est une page qui répond toujours en 200, qui avait des clics dans la Search Console, et qui n'a plus d'impression récente. Techniquement, elle n'a jamais renvoyé de 404 : aucun rapport d'erreur ne la signale. Pourtant elle a cessé de se positionner, ce qui trahit une sortie d'index probable, une régression silencieuse. C'est le genre de signal qu'un tri par code HTTP ne révèle jamais et que le croisement des clics passés avec les impressions récentes met au jour.
Ce que vous tirez de l'analyse dépend de la liste que vous apportez. IndexProbe n'explore pas votre site pour découvrir des URLs : il inspecte celles que vous lui donnez, et celles-là seulement.
- Une sélection de pages stratégiques (vos pages clés, votre sitemap des pages à indexer). Toute page importante qui ressort en 404 est un signal immédiat : une page utile disparue, à restaurer ou à rediriger vers son équivalent. Pas d'extrapolation à faire, le verdict porte sur des pages dont vous connaissez la valeur.
- Un export complet de vos URLs (sitemap entier, export de crawl). La segmentation par type de pages montre où les 404 se concentrent (un ancien blog, une famille de produits retirée) et oriente une décision par segment plutôt qu'au cas par cas.
💡 Vous voulez savoir lesquelles de vos 404 comptent vraiment, et repérer les pages qui ont décroché sans renvoyer de 404 ? IndexProbe inspecte votre liste d'URLs via l'API de la Search Console et vous donne la réponse en une analyse. Tester IndexProbe en accès anticipé →
Corriger : la bonne action selon le verdict de l'arbre
Une fois vos 404 triées, appliquez l'action qui correspond à chaque cas. Voici les quatre situations et leur correction.
- Lien interne erroné → corrigez l'URL du lien vers la bonne page. La cible existe déjà, seul le lien était faux.
- Page déplacée → posez une redirection 301 vers l'équivalent réel, et vérifiez qu'aucune chaîne de redirections ne s'intercale. Une redirection qui pointe vers une autre redirection dilue le signal et ralentit le crawl ; visez la destination finale en un seul saut. Le statut associé est détaillé dans Page avec redirection.
- Page supprimée définitivement → laissez le 404, ou passez en 410, puis retirez l'URL de votre sitemap et de vos liens internes. Tant qu'un lien interne ou une entrée de sitemap pointe vers la page morte, vous continuez d'y envoyer Googlebot.
- Page utile perdue → restaurez-la à la même URL. Rétablir l'adresse d'origine récupère les liens et les positions que la page avait acquis.
Un piège à dénoncer sans appel : ne redirigez jamais une page supprimée vers l'accueil « pour récupérer le jus ». Google considère une redirection vers une page sans rapport comme un Soft 404 : vous échangez un 404 honnête contre un autre problème, et le bénéfice espéré ne se matérialise jamais. La redirection ne se justifie que vers un équivalent réel.
Côté CMS, la mécanique varie mais la logique reste la même. Sous WordPress, une extension de redirection (ou le .htaccess) gère les 301, et il faut nettoyer les liens internes dans les articles. Sous Shopify, l'outil de redirections d'URL intégré couvre les produits et collections supprimés. Sous Magento, les règles de réécriture d'URL et la gestion des produits désactivés pilotent le comportement 404 et les redirections. Dans tous les cas, l'arbre de décision précède l'outil : on choisit d'abord l'action, on l'applique ensuite avec les moyens du CMS.
Vérifier que la correction a tenu
Corriger ne suffit pas, il faut confirmer que Google a pris acte. Après vos actions, demandez un re-crawl des URLs traitées dans la Search Console, puis suivez l'évolution dans le temps : les pages déplacées doivent répondre en 301 vers leur équivalent, les pages restaurées repasser en 200 puis réintégrer l'index, et les 404 maillées disparaître de votre sitemap et de vos liens. Une analyse unique ne le dit pas ; c'est la comparaison entre un état avant et un état après qui le prouve.
La vue COMPARAISON d'IndexProbe répond à ce besoin : elle met deux analyses en regard et chiffre les changements de code par URL, combien de 404 sont repassées en 200 ou en 301, et combien de nouvelles régressions sont apparues entre les deux passages. Un point de vigilance : une page restaurée à la même URL ne réintègre pas l'index instantanément. Le temps que Google la recrawle et décide de la réindexer, elle peut transiter par le statut Explorée, actuellement non indexée. Une 404 corrigée mais pas encore réindexée n'est donc pas un échec : c'est une étape à surveiller dans le temps, pas un verdict définitif.
Questions fréquentes
Faut-il corriger toutes les erreurs 404 ? Non. Selon Google, une 404 sur une page retirée sans remplacement est normale et n'appelle aucune action. Corrigez uniquement les 404 que vous liez encore en interne ou qui figurent dans votre sitemap, et restaurez les pages utiles disparues par erreur. Le reste peut rester en l'état.
404 ou 410 : que choisir ? Les deux indiquent à Google que la page n'est plus là, et l'URL finit désindexée dans les deux cas. Le 410 (« Gone ») affirme une suppression définitive de façon plus explicite. Réservez-le aux suppressions délibérées et assumées (anciennes promotions, fiches discontinuées par lot). Pour tout le reste, un 404 par défaut suffit ; inutile de migrer en masse vers du 410.
Faut-il rediriger une 404 vers l'accueil ? Non. Rediriger une page supprimée vers une page sans rapport, comme l'accueil, est traité par Google comme un Soft 404 : vous remplacez un problème par un autre. Redirigez seulement vers un équivalent réel ; sinon, laissez le 404 et retirez les liens internes qui pointent vers la page.
Comment trouver toutes ses 404 ? La Search Console les liste dans le rapport « Indexation des pages », mais son outil d'inspection ne traite qu'une URL à la fois pour vérifier le détail de chacune. Pour trier à l'échelle, un outil comme IndexProbe inspecte la liste d'URLs que vous lui fournissez via l'API officielle et renvoie, par URL, le code de crawl et la date du dernier passage de Googlebot.
Quelle différence entre une 404 et un Soft 404 ? Une « Introuvable (404) » renvoie réellement un code 404 : la page n'existe pas, et c'est la bonne réponse. Un Soft 404 renvoie un code 200 (« la page existe ») alors que son contenu est vide ou sans valeur. Google les classe dans deux statuts distincts et les corrige différemment.
Une 404 nuit-elle au SEO ? Une 404 sur une page volontairement supprimée ne nuit pas : c'est le comportement attendu. Le dommage vient de deux cas précis. Une page utile perdue par erreur fait disparaître son trafic et ses positions, et une 404 que vous liez encore gaspille du budget de crawl et envoie vos visiteurs dans le vide. Ce sont ces 404-là qu'il faut traiter, pas le simple compteur du rapport.
Comment vérifier sur un grand nombre d'URLs ? L'inspecteur d'URL de la Search Console ne traite qu'une URL à la fois, ce qui rend le contrôle à l'échelle impraticable. IndexProbe inspecte votre liste d'URLs en une seule analyse via l'API de la Search Console et affiche, pour chacune, le code de crawl officiel et la date du dernier passage de Googlebot. La vue COMPARAISON met deux analyses en regard pour mesurer l'effet de vos corrections.
Arrêtez de traiter vos 404 comme une liste d'erreurs à vider. IndexProbe se branche sur l'API officielle de la Search Console et inspecte votre liste d'URLs en une seule analyse : code de crawl par URL (404, 410, 200, redirection), date du dernier passage de Googlebot, tri des 404 par liens entrants, présence au sitemap et trafic passé. Vous isolez en quelques minutes les rares 404 qui comptent, vous repérez les pages qui ont décroché sans renvoyer de 404, et vous vérifiez vos corrections d'une analyse à l'autre grâce à la vue COMPARAISON.