Vous ouvrez le rapport sur les sitemaps dans Search Console et là, une ligne vous saute au visage : une URL déclarée renvoie une erreur 404. Le réflexe est de foncer dans le fichier XML pour la supprimer, et c’est justement l’erreur à ne pas commettre. Dans la majorité des cas, le sitemap dit la vérité sur un problème qui vit ailleurs, dans les liens de votre site. Comprendre qui parle, du fichier ou de Google, change tout au diagnostic.
Un sitemap décrit, il ne répare rien
Un sitemap est un fichier posé sur votre site qui indique à Google les pages que Google doit connaître. C’est une liste, rien de plus : il ne vérifie pas que les adresses qu’il contient répondent, il ne corrige aucun lien cassé, il ne remplace pas un maillage interne défaillant. Si vous débutez sur ces questions, les guides de web2l.fr détaillent la mécanique du crawl et ce que Google fait réellement de vos déclarations, avec des exemples concrets de diagnostics.
La confusion vient d’un mot : « envoyer ». On croit qu’on importe une liste dans Google, comme on téléverse un fichier sur un serveur. C’est inexact. Envoyer un sitemap signifie simplement indiquer à Google où trouver le fichier sur le site. Vous ne poussez aucun contenu, vous posez un panneau. Cette nuance explique la plupart des malentendus sur le rôle réel du fichier.
Ce que Google fait vraiment du fichier
Il le lit, à son rythme, quand ça l’arrange, souvent plusieurs fois par semaine sur un site actif, parfois beaucoup moins sur un site dormant. Puis il visite les URL une par une. Si l’une d’elles renvoie un code 404, Google note l’échec et continue sa route. Il ne vous signale pas une incohérence du fichier : il vous signale qu’une page déclarée n’existe pas à l’adresse indiquée.
Autrement dit, supprimer la ligne du XML ferait disparaître le symptôme dans le rapport, sans rien régler. Le lien cassé, lui, resterait dans vos menus, vos articles, vos boutons, et continuerait d’être suivi par Googlebot à chaque passage. C’est ce lien-là que vos visiteurs cliquent, et c’est lui qu’il faut traiter en priorité.
L’erreur 404 de la page n’est pas l’erreur de lecture du sitemap
Deux messages différents circulent dans Search Console et on les mélange en permanence. Le premier concerne une URL précise du sitemap qui renvoie un 404 : la page n’existe pas ou plus. Le second, « Impossible de lire le sitemap », concerne le fichier lui-même : Google n’a pas réussi à l’ouvrir, à le télécharger ou à le parser.
Le premier cas est un problème de contenu. Le second est un problème d’accès. Un sitemap inaccessible parce qu’il est bloqué par le robots.txt, protégé par un mot de passe ou servi avec un mauvais type de fichier n’a rien à voir avec une page supprimée. Confondre les deux, c’est perdre un temps précieux sur une piste qui ne mène nulle part.
Les causes qu’on retrouve le plus souvent
Quand une URL déclarée tombe en erreur 404, l’origine est presque toujours la même poignée de situations. Les voici, dans le désordre de fréquence où elles apparaissent sur le terrain, avec à chaque fois la même conclusion : le fichier n’y est pour rien.
- Une page a été supprimée ou renommée, mais son ancienne adresse figure encore dans le sitemap généré automatiquement.
- Le site a changé de structure d’URL sans redirection, ce qui casse d’un coup une série d’adresses.
- Un lien interne pointe vers une adresse mal recopiée, souvent une faute de frappe dans un slug.
- Un plugin génère le sitemap avant que la page ne soit réellement publiée.
- Le sitemap d’actualités n’intègre pas les articles de plus de 48 heures, ce qui n’a rien d’anormal.
Ce dernier point mérite qu’on s’y arrête, car il surprend beaucoup de rédacteurs et de responsables éditoriaux. Le sitemap d’actualités d’All in One SEO n’intègre un contenu que s’il a été publié au cours des dernières 48 heures, conformément aux exigences de Google. Un article plus ancien n’a rien à y faire, et son absence n’est pas un bug.
À l’inverse, un article tout juste publié peut apparaître dans le fichier avant que le cache du serveur ne serve la page, ce qui produit une erreur temporaire le temps que tout se mette à jour. Au bout de quelques heures, la ligne disparaît d’elle-même du rapport, sans intervention de votre part.
Réparer les liens, pas le fichier
Le vrai correctif se joue sur le site. Si une page a été supprimée définitivement, redirigez son ancienne adresse vers la plus proche parente, puis laissez le sitemap se régénérer tout seul. Si la page existe toujours mais à une autre adresse, c’est la même opération. Si l’erreur vient d’un lien interne fautif, corrigez le lien à la source, dans l’article ou le menu concerné. Sur ce point, voir aussi notre article sur certifications seo utiles.
Passer par le fichier XML pour masquer le problème ne règle rien : Google continuera de suivre les liens internes qu’il trouve sur vos pages, indépendamment de ce que raconte votre sitemap. L’erreur remontera par un autre chemin, dans le rapport sur l’exploration, et vous aurez perdu une semaine à nettoyer la mauvaise liste.
Comment reprendre la main dans Search Console
Pour envoyer un sitemap depuis le rapport dédié, il faut détenir les autorisations de propriétaire sur une propriété. Sans ce niveau d’accès, une solution de repli existe : répertorier le sitemap dans le fichier robots.txt, avec une ligne du type Sitemap: suivie de l’adresse complète du fichier.
Google recommande par ailleurs de placer le sitemap à la racine du site. Un fichier rangé dans un sous-dossier fonctionne parfois, mais la racine reste la position la plus simple à découvrir et la moins susceptible de casser lors d’une refonte. Un détail, mais qui évite un paquet de tickets au support.
Une fois le sitemap accessible et les liens corrigés, l’erreur disparaîtra d’elle-même quand les pages concernées répondront de nouveau. Comptez quelques passages de Googlebot, pas une heure. Le rapport n’est pas un tableau de bord en temps réel, c’est une photo prise au dernier crawl.
Et si vous n’aviez pas besoin de sitemap du tout ?
C’est la question qu’on pose trop rarement. Si votre site compte environ 500 pages maximum et que chacune est accessible via un ou plusieurs liens depuis la page d’accueil, un sitemap n’est probablement pas nécessaire. Google trouvera vos pages en suivant vos liens, comme il le fait depuis toujours.
Le sitemap devient utile au-delà de ce volume, ou quand des pages vivent loin de la navigation principale, ou quand vous publiez du contenu d’actualité qui doit être repéré vite. Sur un petit site bien maillé, le fichier ajoute surtout une source de maintenance : chaque page supprimée doit être répercutée, chaque redirection vérifiée.
Il y a une ironie à tout ça. Les sites qui souffrent le plus des erreurs déclarées dans leur sitemap sont souvent ceux qui n’avaient pas besoin d’en publier un. Le fichier est devenu un réflexe de checklist SEO, installé par un plugin, jamais relu. Puis un jour, la liste dérive de la réalité du site, et personne ne sait plus pourquoi.
Le fichier suit le site, pas l’inverse
Un sitemap qui déclare des URL en erreur vous dit quelque chose de simple : il est à jour, votre site ne l’est pas. La bonne réaction tient en trois gestes, corriger les liens cassés, poser les redirections manquantes, laisser le fichier se régénérer.
Modifier le XML pour faire taire le rapport revient à débrancher le voyant d’alerte sur le tableau de bord, en espérant que le moteur tienne. Si vous deviez expliquer demain à un collègue pourquoi cette ligne rouge est apparue, sauriez-vous désigner la page concernée sans ouvrir Search Console ?