Sitemap et robots.txt : les deux fichiers qu'on oublie

Un site peut être rapide, bien écrit et utile, et rester invisible pour une raison minuscule : un fichier de trois lignes mal placé. Le robots.txt et le sitemap.xml ne s'affichent à personne, mais ce sont eux qui décident si Google a le droit de lire vos pages et s'il sait qu'elles existent.

Les deux se vérifient en cinq minutes, sans outil payant. Ce guide donne les adresses à taper, les commandes à lancer, ce que vous devez y voir, et les défauts qui reviennent sur la majorité des sites.

Les deux adresses à ouvrir en premier

Tapez dans votre navigateur https://votresite.ci/robots.txt, puis https://votresite.ci/sitemap.xml. La première doit afficher un fichier texte de quelques lignes. La seconde, du XML : une liste d'adresses entre des balises <loc>.

Si l'une des deux affiche l'accueil du site, une page d'erreur ou un message « 404 », le fichier n'existe pas. Attention à un piège classique : certains serveurs renvoient une page d'erreur avec le code 200, ce qui veut dire « tout va bien » pour un robot. Le doute se lève avec cette commande :

curl -I https://votresite.ci/sitemap.xml

Regardez la première ligne. 200 OK : le fichier existe et se lit. 301 ou 302 : il est redirigé, souvent vers l'accueil, ce qui casse la lecture. 404 : il est absent. Contrôlez le Content-Type, qui doit indiquer application/xml ou text/xml, jamais text/html.

Quand rien ne répond à l'adresse standard, cherchez ailleurs : /sitemap_index.xml sur WordPress, /sitemap-index.xml, /sitemap.xml.gz, /page-sitemap.xml. Si l'un répond, c'est celui-là qu'il faut déclarer.

robots.txt : les quatre lignes qui comptent

Un robots.txt utile tient en quatre lignes. Voici celui d'un site marchand correctement configuré :

User-agent: *
Disallow: /panier/
Disallow: /recherche
Allow: /
Sitemap: https://votresite.ci/sitemap.xml

Chaque ligne a un rôle. User-agent: * adresse la règle à tous les robots. Disallow: /panier/ écarte le tunnel de commande, qui ne doit jamais se retrouver dans les résultats. Disallow: /recherche écarte les pages de résultats internes, qui créent des milliers d'adresses creuses. Allow: / autorise le reste. La ligne Sitemap: dit où trouver la liste des pages à indexer.

Le fichier se place à la racine du domaine, jamais dans un sous-dossier, et son nom s'écrit en minuscules, sans accent. Il est public : n'importe qui peut le lire, votre concurrent compris.

L'erreur qui bloque tout le site : le Disallow mal placé

La faute la plus lourde tient en une ligne : Disallow: / sous User-agent: *. Elle interdit l'exploration de tout le site, et vient presque toujours du robots.txt du site de test, copié en production et jamais retiré.

Le symptôme est net dans Search Console : la page « robots.txt » signale les adresses bloquées, et l'inspection d'URL affiche « Bloquée par le fichier robots.txt ». Le trafic ne s'effondre pas le jour même, puisque Google continue d'afficher un moment les pages qu'il connaît déjà : le problème peut rester invisible des semaines.

Une variante plus sournoise existe : le fichier est correct, mais une règle trop large attrape la moitié du site. Disallow: /p/ a l'air anodin, sauf que votre catalogue est rangé dans /produits/ : le préfixe avale chaque fiche produit. Relisez chaque règle en vous demandant quelles adresses réelles elle attrape, préfixe compris.

Le test prend une minute. Dans l'inspection d'URL de Search Console, saisissez une page importante, lancez le « Test de l'indexation en direct », puis ouvrez la section qui montre la page explorée. Si le robots.txt la bloque, c'est écrit noir sur blanc.

Ce qu'un robots.txt ne fait pas

Deux confusions coûtent cher. La première : croire qu'une page interdite d'exploration disparaît des résultats. Ce n'est pas le cas. Une page bloquée peut rester indexée, avec son titre seul et parfois une description tirée d'un autre site. Pour la retirer, il faut une balise noindex dans la page.

La deuxième : empiler les deux. Une page à la fois bloquée par robots.txt et porteuse d'un noindex ne disparaîtra jamais, puisque Google n'a pas le droit de l'ouvrir pour lire l'instruction. L'ordre correct : on laisse la page explorable, on pose le noindex, on attend sa sortie des résultats, et seulement ensuite on bloque l'exploration.

Un robots.txt n'est pas une protection non plus. Il ne remplace ni un mot de passe, ni un pare-feu, ni une sauvegarde. Il sert à dire aux robots où passer. Le principe est le même que pour les données structurées : un fichier ne protège rien, il informe.

Sitemap : ce qu'on doit y voir

Un sitemap valide est une liste d'adresses que vous assumez voir dans Google, écrites en entier. Un extrait correct ressemble à ceci :

<url>
  <loc>https://votresite.ci/meubles-abidjan/</loc>
  <lastmod>2027-01-14</lastmod>
</url>

Quatre règles décident de sa qualité. Les adresses sont absolues, avec https:// et le bon domaine. Elles pointent vers des pages en 200, jamais vers une redirection. Elles correspondent à la version canonique de la page. Et la liste ne contient que des pages indexables : une page en noindex n'a rien à y faire.

Deux limites à connaître : un fichier accepte jusqu'à 50 000 adresses et 50 Mo. Au-delà, il faut le découper et regrouper les morceaux dans un fichier d'index. Les balises priority et changefreq existent toujours, mais Google les ignore.

Déclarer le sitemap dans robots.txt

Ajoutez une ligne Sitemap: à votre fichier robots.txt, avec l'adresse complète du fichier :

Sitemap: https://votresite.ci/sitemap.xml

L'adresse doit être absolue, sur le même domaine que le robots.txt, et la ligne peut se placer n'importe où dans le fichier. Si vous avez plusieurs sitemaps, ajoutez une ligne par fichier.

Elle sert de secours : le jour où vous oubliez de déclarer le sitemap dans Search Console, Google le retrouve par ce chemin.

Déclarer le sitemap dans Search Console

Ouvrez Search Console, choisissez la propriété de votre site, puis « Sitemaps » dans le menu de gauche. Saisissez sitemap.xml et validez. Le statut doit passer à « Réussite ».

Deux autres statuts existent. « Impossible de récupérer » signale une adresse fausse, un fichier en erreur ou un domaine qui ne correspond pas à la propriété. « Détectée » signale un fichier lu, mais pas traité comme une réussite.

Ne vous arrêtez pas à la couleur verte. Cliquez sur le sitemap déclaré : le nombre d'adresses découvertes s'affiche, avec les erreurs de lecture. Un sitemap « Réussite » qui annonce 240 adresses quand le site en compte 400 est un fichier incomplet, presque toujours généré avant la dernière publication.

Vérifier le sitemap ligne par ligne, en cinq minutes

Une fois par mois, lancez ces deux commandes. La première compte les adresses listées :

curl -s https://votresite.ci/sitemap.xml | grep -o '<loc>[^<]*' | wc -l

La seconde teste chaque adresse et affiche son code de retour :

curl -s https://votresite.ci/sitemap.xml | grep -o '<loc>[^<]*' | sed 's/<loc>//' | while read u; do printf '%s %s\n' "$(curl -o /dev/null -s -w '%{http_code}' "$u")" "$u"; done

Ce que vous devez voir : uniquement des 200. Chaque 404 est une adresse fantôme, à retirer ou à rediriger. Chaque 301 est une adresse qui n'est pas la version canonique de la page. Sur cinquante pages, le contrôle prend cinq minutes.

Les erreurs classiques, et ce qu'elles produisent

Six défauts reviennent sur presque tous les sites, chacun avec son symptôme dans Search Console et sa correction.

Le sitemap liste des adresses en 404. Symptôme : la colonne « Introuvable (404) » du rapport Sitemaps grimpe. Cause : des pages supprimées ou renommées sans redirection. Correction : rediriger vers la nouvelle adresse, ou retirer l'ancienne du fichier.

Le sitemap pointe vers le mauvais domaine. Symptôme : Search Console refuse le fichier ou découvre zéro adresse. Cause : un fichier généré en http:// au lieu de https://, avec www quand la version canonique n'en a pas, ou depuis le domaine de test. Correction : régénérer depuis le domaine réel.

Le sitemap contient des pages en noindex. Symptôme : dans le rapport Pages, des adresses « Explorée, actuellement non indexée », avec la mention « Exclue par la balise noindex ». Cause : un fichier généré sans filtre. Correction : exclure ces pages du fichier.

Le sitemap est absent de robots.txt et de Search Console. Symptôme : aucun, et c'est le problème. Le fichier existe, il est correct, personne ne le lit. Correction : la ligne Sitemap: plus la déclaration dans Search Console.

Le sitemap n'est plus régénéré. Symptôme : le compteur d'adresses stagne alors que vous publiez. Cause : un fichier écrit à la main, ou un module désactivé. Correction : automatiser la génération et vérifier le compteur après chaque publication.

Le sitemap répond, mais c'est une page d'erreur. Symptôme : le fichier s'ouvre et affiche l'accueil du site, ou une page « introuvable » avec un code 200. Cause : une règle de réécriture qui renvoie tout vers l'accueil. Correction : créer le fichier à la racine et contrôler le code de retour avec curl -I.

Le cas des sites WordPress, Shopify et sur mesure

Sur WordPress, les extensions SEO — Yoast, Rank Math, SEOPress — génèrent le sitemap sans intervention. Vérifiez que l'option est active, notez l'adresse affichée, souvent /sitemap_index.xml, puis déclarez-la dans robots.txt et Search Console. Si vous changez d'extension, l'adresse change : l'ancienne doit rediriger.

Sur Shopify et sur les constructeurs en ligne — Wix, Squarespace, Webflow — le sitemap est créé automatiquement et vous ne pouvez pas le modifier. Vous pouvez seulement le déclarer. Le point de vigilance porte alors sur les adresses en double : filtres de collection, variantes de produit, versions de langue. Le choix de la plateforme se traite dans WordPress, Shopify ou mesure.

Sur un site écrit à la main ou un site statique, le fichier n'existe pas tant que personne ne le crée. Il faut le générer à chaque publication. Un site sans sitemap n'est pas condamné : Google explore les liens, mais chaque page découverte par un lien l'est plus tard qu'avec une liste. Sur deux cents pages, l'écart se compte en semaines.

Ce qui doit sortir du sitemap

La règle tient en une phrase : le fichier ne contient que des pages que vous assumez voir dans les résultats de recherche.

Restent donc dehors : pages de confirmation de commande, paniers, résultats de recherche interne, filtres de catalogue, étiquettes d'articles, pages de test, versions imprimables, adresses avec paramètres de suivi, et toute page portant une balise noindex.

Une exception se discute : les mentions légales et la politique de confidentialité. Ces pages se déclarent, parce qu'un client peut les chercher et que leur présence rassure.

La routine de contrôle, cinq minutes par mois

Cinq gestes, dans cet ordre. Le même passage s'impose après une refonte ou un changement de domaine.

Un. Relisez robots.txt ligne par ligne. Cherchez un Disallow: / seul, et vérifiez qu'aucune règle n'attrape un dossier plus large que prévu.

Deux. Ouvrez sitemap.xml. Le fichier s'affiche, il commence par des balises <url>, il ne renvoie pas l'accueil.

Trois. Comptez les adresses et comparez au nombre de pages publiées.

Quatre. Testez cinq adresses au hasard. Si une seule répond en 404, testez-les toutes : le défaut est presque toujours groupé.

Cinq. Dans Search Console, onglet Pages, surveillez les lignes « Explorée, actuellement non indexée » et « Exclue par la balise noindex ».

Ces fichiers ne rapportent aucune visite : ils évitent surtout d'en perdre. Quand une page importante reste absente de Google malgré un robots.txt propre et un sitemap à jour, la cause est ailleurs : elle se cherche avec la méthode des erreurs d'indexation. Et si le problème est apparu après une refonte ou un changement d'hébergement, commencez par le contrôle post-refonte.

FAQ — Sitemap et robots.txt