Robots.txt, sitemap et noindex sont souvent rangés dans la même catégorie : « technique SEO ». Pourtant, ils ne font pas la même chose. Les confondre peut produire l’effet inverse de celui recherché : cacher une page utile, laisser une page faible accessible, ou envoyer aux moteurs une liste d’URL qui ne devraient pas être mises en avant.
Pour une TPE, il n’est pas nécessaire de devenir spécialiste. Il faut surtout comprendre quel outil sert à quoi, puis vérifier que les pages commerciales et les ressources importantes restent bien accessibles.
Le sitemap aide à découvrir les pages importantes
Un sitemap est un fichier qui liste les URL que vous considérez importantes. Google explique dans sa documentation sur les sitemaps qu’ils peuvent être fournis sous plusieurs formats et soumis via Search Console, l’API ou une ligne dans robots.txt.
Sur un site vitrine, le sitemap doit contenir les pages publiques utiles :
- accueil ;
- pages services ;
- pages locales ;
- contact ;
- réalisations indexables ;
- articles de ressources ;
- guides importants.
Il ne doit pas devenir une poubelle d’URL. Une page de test, une page de brouillon, une page interne ou une page sans valeur pour un visiteur n’a pas vocation à être mise en avant dans le sitemap.
Le sitemap ne garantit pas l’indexation. Il donne une indication aux moteurs. La page doit encore être accessible, cohérente, utile et non bloquée.
Robots.txt gère surtout le crawl
Le fichier robots.txt indique aux robots quelles zones ils peuvent ou ne peuvent pas explorer. Google précise dans son introduction à robots.txt que ce fichier sert principalement à gérer le trafic de crawl, et qu’il ne doit pas être utilisé comme moyen fiable de cacher une page des résultats.
Exemple simple :
User-agent: *
Disallow: /admin/
Sitemap: https://www.exemple.fr/sitemap.xml
Cette règle demande aux robots de ne pas explorer /admin/ et indique l’emplacement du sitemap. Elle ne protège pas une information sensible. Si une page doit rester privée, elle doit être protégée par authentification ou retirée de l’espace public.
Pour une TPE, le risque principal est de bloquer trop large. Une règle mal écrite peut empêcher les moteurs d’explorer une partie utile du site.
Noindex demande de ne pas indexer une page
noindex est une directive placée dans le code HTML ou dans un en-tête HTTP. Elle demande aux moteurs compatibles de ne pas garder la page dans l’index. Google explique dans sa documentation sur noindex que la page doit rester accessible au robot pour que la directive soit vue.
C’est le point qui crée beaucoup d’erreurs : si une page est bloquée par robots.txt, Google peut ne jamais voir son noindex. Il ne faut donc pas mélanger les directives au hasard.
Cas où noindex peut être utile :
- page de remerciement ;
- résultat de recherche interne ;
- page de filtre sans valeur ;
- page temporaire ;
- page très proche d’une autre page ;
- contenu public mais non souhaité dans les résultats.
À l’inverse, une page service, une page locale utile ou un article publié ne devrait pas être en noindex.
Vérifier les pages commerciales en priorité
Le contrôle doit commencer par les pages qui génèrent de la valeur. Si une page peu importante est absente du sitemap, ce n’est pas grave. Si la page service principale est bloquée, c’est critique.
Vérifiez pour chaque page prioritaire :
| Point | Question |
|---|---|
| Sitemap | L’URL est-elle listée si elle doit être découverte ? |
| Robots.txt | Le chemin n’est-il pas bloqué par une règle large ? |
| Noindex | La page ne contient-elle pas une directive accidentelle ? |
| Canonical | La page se désigne-t-elle elle-même ou une URL pertinente ? |
| Liens internes | Peut-on la trouver depuis le site ? |
Notre article sur les pages indexées inutiles traite l’autre côté du sujet : repérer les pages qui apparaissent alors qu’elles n’aident ni les visiteurs ni le référencement.
Ne pas bloquer les ressources nécessaires
Un site moderne charge du CSS, du JavaScript, des images et parfois des polices. Si ces fichiers publics sont bloqués, les robots peuvent avoir une vision dégradée de la page. La règle pratique est simple : ne bloquez pas des fichiers nécessaires à l’affichage normal des pages publiques.
Si vous cherchez à protéger un espace interne, bloquez le dossier interne et protégez-le par authentification. Ne bloquez pas tout le site par prudence. Une règle Disallow: / en production peut retirer toute capacité d’exploration si elle est appliquée au mauvais environnement.
Lors d’une refonte, contrôlez particulièrement les redirections, les canonicals, le sitemap et les directives d’indexation. Notre méthode sur les redirections 301 pendant une refonte complète ce contrôle.
Mettre en place une routine simple
À chaque mise en ligne importante, vérifiez :
https://votresite.fr/robots.txt;https://votresite.fr/sitemap.xml;- le code source d’une page service ;
- le code source d’un article ;
- une page que vous ne voulez pas indexer ;
- la présence des nouvelles URL dans le sitemap.
Search Console permet aussi d’inspecter une URL pour comprendre ce que Google connaît d’une page et tester son indexabilité. Ce contrôle est particulièrement utile après une refonte ou après l’ajout d’une section ressources.
Documentez les règles appliquées. Une courte note indiquant pourquoi une zone est bloquée, pourquoi une page est en noindex ou pourquoi une URL est absente du sitemap évite les décisions contradictoires lors d’une prochaine modification du site.
Prochaine étape
Listez vos dix pages les plus importantes. Pour chacune, vérifiez qu’elle est accessible, présente dans le sitemap si elle doit l’être, non bloquée par robots.txt, sans noindex accidentel et reliée depuis une page logique.
Ces fichiers techniques ne remplacent pas un bon contenu. Ils évitent surtout qu’un contenu utile soit invisible pour de mauvaises raisons.