Un 404 qui revient ? L'ancienne URL traîne dans le sitemap
0 7 minutes 22 heures

Un 404 qui revient toutes les semaines, alors que vous avez supprimé la page depuis des mois : la scène est classique. On vérifie les redirections, on fouille le serveur, on relance un crawl, et l’URL fantôme réapparaît encore. Le réflexe serveur est rarement le bon. Dans la plupart des cas, l’ancienne adresse traîne toujours dans le sitemap, et c’est ce fichier qu’il faut nettoyer, pas la configuration de votre hébergement.

L’ancienne adresse est encore dans le fichier

Le sitemap est un fichier que vous avez généré un jour, avec les URLs de l’époque. Quand une page disparaît, rien ne se met à jour tout seul : le fichier continue de pointer vers l’adresse morte, Google la recrawle, reçoit un 404, et vous retrouvez la notification dans la Search Console. Si vous n’avez jamais retouché ce fichier, le cycle peut durer des mois. Un peu de lecture sur les michel-hunault.com aide souvent à comprendre ce mécanisme d’indexation avant de toucher au serveur.

Le code 404 lui-même est défini par la liste des codes du protocole HTTP : il signifie « rien à cette adresse », point final. Il n’y a pas de panne sous-jacente, pas de bug à réparer. Votre serveur fait exactement son travail en répondant ça. Le problème n’est donc pas la réponse, mais la demande qui continue d’arriver.

Un cahier ouvert sur une table en bois contenant des esquisses de wireframes

Pourquoi l’erreur revient au lieu de disparaître

Une erreur 404 isolée s’efface d’elle-même. Google la classe, la retire, et le rapport de la Search Console la supprime généralement au bout d’environ un mois. Si la vôtre revient, c’est qu’elle est réalimentée en boucle : le sitemap renvoie la vieille URL, Google la recrawle, la note, et recommence au prochain passage. Vous corrigez le symptôme, la source reste intacte.

Les fausses pistes qu’on poursuit

Avant de tomber sur le sitemap, on passe par toute une série de vérifications qui ne règlent rien. Franchement, on y perd des soirées entières, et le 404 est toujours là le lundi suivant.

  • On cherche une redirection manquante dans le fichier .htaccess, alors que la page a bien été supprimée et ne doit plus exister.
  • On installe une extension de vérification des liens cassés sur WordPress : ces outils, selon les chiffres disponibles, manquent 83 % des erreurs 404 des sites Web.
  • Et si le problème venait simplement du fichier XML régénéré automatiquement à chaque publication ?
  • On contacte l’hébergeur pour un souci de serveur qui n’existe pas.

Cette dernière piste est la plus fréquente. Un site inaccessible ou une page blanche dans Google Chrome orientent vers l’hébergement, alors que le serveur répond correctement. La question « ce site est inaccessible » dans Chrome vient souvent d’un cache ou d’une extension, pas d’une panne. Ces fausses pistes coûtent du temps et détournent du vrai coupable.

Le passage au 410 pour les ressources mortes

Quand une page est supprimée pour de bon et que vous ne voulez pas la recréer ailleurs, le 404 n’est pas le meilleur choix. Le code 410 indique que la ressource a existé et qu’elle n’existe plus, de façon définitive. C’est plus clair pour le robot, et le signal est plus net : pas de doute sur une éventuelle réapparition.

Le 410 n’a rien de magique, il ne fait pas disparaître l’ancienne URL du sitemap non plus. Mais il accompagne bien un nettoyage : vous supprimez l’adresse du fichier, vous servez un 410 pour les vieux liens qui traînent, et le dossier se referme. Google recommande d’ailleurs de mettre à jour le sitemap lorsque l’URL envoyée pour l’indexation renvoie une erreur, ce qui confirme l’ordre des opérations. Sur ce point, voir aussi notre article sur organisateurs et risques.

Il faut aussi relativiser l’angoisse du 404. Selon Google, les erreurs 404 n’ont en règle générale aucune incidence négative sur les performances d’un site dans les résultats de recherche. Un site avec quelques adresses mortes bien gérées ne s’écroule pas. L’urgence est donc modérée : on nettoie, on ne panique pas.

Sauvegarde automatique : le filet invisible qui se tend tout seul

La méthode qui règle vraiment le problème

Le vrai travail tient en une vérification simple : ouvrez le sitemap, cherchez l’URL fautive. Si elle y est encore, retirez-la. Selon la façon dont le fichier est généré, ça passe par le CMS, par un module dédié ou par une édition manuelle. Une fois l’adresse sortie du fichier, le robot arrête de la visiter, et la notification s’éteint d’elle-même au bout du délai habituel.

Un détail compte : le sitemap peut être régénéré automatiquement et réintégrer la vieille URL si la page existe encore en brouillon ou dans une catégorie vide. Vérifiez la source, pas seulement le fichier final. Un peu de méthode ici évite de refaire le ménage tous les mois.

Arrêter de courir après le fantôme

Un 404 récurrent n’est pas un serveur capricieux, c’est un fichier oublié. Tant que l’ancienne URL figure dans le sitemap, le robot reviendra, et vous réouvrirez le même ticket. Nettoyez le fichier, servez un 410 pour les ressources vraiment mortes, et laissez le rapport se vider tout seul. La prochaine fois que la notification apparaît, irez-vous d’abord voir le sitemap ou le panneau de votre hébergeur ?

Laisser un commentaire