Indexation : exploration, robots.txt, canonique, sitemaps

Indexation : être trouvé, exploré, compris, et retenu

1. Le cycle réel : découvrir, explorer, indexer

   Google ne « lit » pas un site page par page comme un navigateur. Le processus comporte des étapes distinctes, et un échec à l'une d'elles passe inaperçu tant que les autres semblent fonctionner.

   Les étapes

   1. Découvrir. Trouver les URLs : liens internes, sitemaps, liens externes. Une page absente des trois est découverte quand même, mais tardivement.
   2. Explorer. Récupérer la page. Le code de réponse HTTP décide de la suite : 200 = indexable, 3xx = redirection à suivre, 4xx = erreur à corriger, 5xx = erreur serveur, à traiter comme urgente.
   3. Rendre. Exécuter le JavaScript nécessaire pour voir la page finale. Cette étape est optionnelle et coûteuse : Google peut indexer le HTML initial, pas le DOM obtenu après exécution.
   4. Indexer. Décider ce qui est conservé. Un contenu dupliqué, un contenu jugé peu utile, une page en noindex sortent de l'index.

   Pourquoi une page peut être en ligne et invisible

   Le cas le plus fréquent en audit est celui d'une page qui répond 200, dont le contenu est dans le HTML, et qui n'apparaît nulle part. Les raisons, dans l'ordre de fréquence :

   • Elle n'est liée depuis aucune page crawlable — un lien généré en JavaScript, ou une page orpheline.
   • Elle porte un noindex, souvent hérité d'un gabarit ou d'une variable de requête.
   • Son contenu n'apparaît qu'après exécution JavaScript, et le rendu n'a pas eu lieu.
   • Elle est bloquée par robots.txt : Google ne l'explore pas, mais peut l'indexer sans l'explorer (voir plus bas).
   • Elle est canonisée vers une autre URL, et c'est cette autre URL qui est indexée.

   Ces cinq causes se diagnostiquent avec l'outil d'inspection d'URL, qui affiche l'état de l'indexation et la page rendue telle que Google la voit.

2. robots.txt : ce qu'il fait, et ce qu'il ne fait surtout pas

   La documentation de Google est catégorique, et la formulation est à retenir parce qu'elle est contre-intuitive : « N'utilisez pas robots.txt comme mécanisme pour empêcher l'indexation d'une page. »

   Ce que robots.txt fait

   • Gérer le trafic d'exploration — limiter ou interdire l'accès à des zones sans valeur, sur un site très sollicité.
   • Empêcher l'exploration de pages dupliquées ou de paramètres d'URL qui génèrent des millions de combinaisons.

   Ce qu'il ne fait pas

   • Il ne protège rien. Les instructions robots.txt sont publiques et ne sont pas une mesure de sécurité. Le seul moyen de protéger une ressource est l'authentification.
   • Il n'empêche pas l'indexation. Une page bloquée peut quand même apparaître dans les résultats, avec une URL et sans aucune description. Elle est même promulguée sans son texte : c'est le pire des deux mondes.
   • Il ne dépose pas la page. Pour retirer une page de l'index, la méthode est noindex — mais elle suppose que le robot puisse explorer la page pour y lire le noindex. D'où la règle contre-intuitive : on autorise l'exploration et on pose noindex.

   Les deux tests à faire systématiquement

   1. Lire le robots.txt réel, pas supposé. Y chercher les Disallow qui bloquent des pages à indexer, et vérifier que les sitemaps sont bien déclarés.
   2. Vérifier les codes de réponse des pages et des ressources : une feuille de style en 403 casse le rendu et le moteur ne voit pas la mise en page.

   L'erreur qui coûte le plus cher

   Disallow: / sur un site en production. Symptôme : le site fonctionne, les visiteurs voient tout, et le trafic organique tombe à zéro en quelques semaines. C'est l'erreur la plus grave possible et elle est fréquente, parce qu'elle est parfois appliquée « pour tester » puis oubliée, ou laissée par un staging.

3. Duplication et URL canonique : ne montrer qu'une version

   La duplication n'est pas interdite par Google, et la documentation le précise : c'est un problème d'expérience et de gaspillage d'exploration, pas une faute. Mais mal traitée, elle disperse les signaux.

   Les duplications légitimes

   Elles sont dues à l'architecture, pas à une erreur : une page accessible par plusieurs chemins (avec et sans .html, avec et sans barre finale), une version imprimable, une version AMP, des variantes de langue. Pour elles, une rel="canonical" qui désigne la version de référence suffit.

   Les duplications à supprimer

   Celles qui n'apportent rien : des pages « quasi identiques » générées pour chaque combinaison de filtres, des pages de résultats de recherche internes indexées, des paramètres d'URL de tracking. Elles se traitent par une redirection 301 vers la version propre, ou par le blocage de l'exploration des paramètres dans robots.txt.

   Canonical vers soi-même : une erreur d'implémentation

   La règle qui surprend le plus : une page doit se déclarer canonique à elle-même. Le moteur a besoin de l'indice de confiance — il n'en déduit pas qu'une page est canonique, il le lit. Une page sans canonique sur un site qui en a partout ailleurs envoie un signal de duplication involontaire.

   Canonique et redirection : ne pas se contredire

   Si une page redirige en 301 vers une autre, elle ne doit pas aussi se déclarer canonique vers cette autre : les deux signaux se contredisent et le moteur choisit au hasard. De même, le canonique ne doit pas pointer vers une page en noindex : le résultat est une page indexée qui ne peut pas l'être.

4. Sitemaps : ce qu'ils garantissent, et ce qu'ils ne garantissent pas

   La documentation est claire : « Google ne limitera pas l'exploration aux seules pages listées dans vos sitemaps, mais il priorisera l'exploration de ces pages. » Le sitemap est donc une aide à la priorisation, pas une contrainte.

   Ce qu'un sitemap apporte réellement

   • Il dit quelle version de l'URL est la bonne, ce qui est utile quand les URLs paramètres sont nombreuses.
   • Il donne une date de modification, qui sert à explorer plus souvent ce qui change.
   • Il fournit les URLs de contenus non textuels — images, vidéos — que le moteur ne découvrirait pas autrement.
   • Sur un site dont le contenu change vite, il accélère la découverte des nouveautés.

   Ce qu'il ne fait pas

   • Il n'indexe rien. Une page listée dans un sitemap mais marquée noindex, ou bloquée par robots.txt, ne sera pas indexée.
   • Il ne compense pas un maillage interne absent. Si une page n'est liée nulle part, elle reste isolée.

   Les règles de forme

   • Une seule URL canonique par page, avec le protocole et le domaine de production — un sitemap filled d'URLs en http, en www ou avec des paramètres disperse les signaux.
   • Pas d'URL non canonique, pas d'URL en redirection, pas d'URL en 404.
   • Déclaré dans robots.txt par une ligne Sitemap:, et soumis dans Search Console.
   • Généré, jamais écrit à la main : un sitemap manuel finit toujours désynchronisé.

   Le point de vigilance sur ce site

   Le contrôleur de sitemaps de ce projet génère ses URL à la volée, et il a un garde-fou documenté : quand la région d'une ville est inconnue, il saute la ville au lieu de produire une URL contenant -region-inconnue. Une URL de ce type est un 404 dans un sitemap, c'est-à-dire une instruction contradictoire envoyée au moteur. C'est le genre de détail qui se voit dans un audit et qui ne se voit pas sur la page.