Crawlabilité et découverte : robots.txt, noindex, sitemaps et sécurité

Réponse directe

Utilisez robots.txt pour gérer l'accès des robots d'exploration, noindex pour indiquer à un robot de ne pas indexer une ressource récupérable, l'authentification pour protéger des données privées, et un statut HTTP ou une redirection appropriés pour représenter l'existence ou non d'une ressource. Utilisez les sitemaps pour aider la découverte et renforcer les URL canoniques. Aucun de ces contrôles ne garantit un classement.

L'erreur technique la plus fréquente consiste à bloquer une URL dans robots.txt tout en espérant que Google lise une balise noindex sur cette même page bloquée. Si Google ne peut pas explorer la page, il ne verra peut-être jamais la directive. L'erreur la plus dangereuse consiste à utiliser les règles robots comme mécanisme de sécurité. Un fichier robots est public, et une exploration respectueuse du protocole n'est pas un contrôle d'accès.

Choisissez le contrôle en fonction de l'état visé pour l'URL, puis testez la réponse effectivement déployée plutôt que de faire confiance au réglage du CMS.

Ce que vous saurez faire

À la fin de cette leçon, vous serez capable de :

• expliquer la découverte, le contrôle du crawl, le contrôle de l'indexation et le contrôle d'accès ;
• choisir entre robots, meta robots, X-Robots-Tag, authentification, codes de statut et redirections ;
• construire un sitemap canonique valide ;
• expliquer ce que lastmod, priority et changefreq peuvent et ne peuvent pas faire ;
• distinguer IndexNow des systèmes de découverte de Google ;
• prédire les conséquences pour le crawl, l'index, l'utilisateur et la sécurité pour une URL donnée.

Quatre missions différentes

Les contrôles techniques deviennent plus simples lorsqu'on sépare leurs missions.

Découverte

Comment un robot d'exploration apprend-il qu'une URL existe ?

Sources courantes :

• liens internes explorables ;
• liens externes ;
• redirections ;
• URL déjà connues ;
• sitemaps XML, RSS, mRSS ou texte.

Une URL peut être découverte sans jamais être explorée ni indexée.

Accès au crawl

Un robot d'exploration peut-il requêter l'URL ?

Le Robots Exclusion Protocol permet aux propriétaires de sites de publier des règles de crawl. La RFC 9309 standardise le protocole. Les robots conformes interprètent ces règles, mais robots n'est pas une autorisation d'accès.

Éligibilité à l'indexation

Si un système récupère la ressource, est-il autorisé et utile de la stocker ?

Pour les robots pris en charge, une directive noindex en HTML ou un en-tête HTTP X-Robots-Tag peut retirer l'éligibilité à l'indexation. Le robot doit récupérer la réponse pour lire la directive.

Sécurité

La ressource est-elle accessible à une personne ou un système non autorisé ?

L'authentification, l'autorisation, la politique réseau et une isolation correcte des tenants protègent les données. Les directives de recherche ne le font pas.

Comment fonctionne robots.txt

L'introduction de Google à robots.txt décrit ce fichier comme un mécanisme de contrôle du trafic des robots d'exploration.

Emplacement

Le fichier doit se trouver à la racine de l'hôte et du protocole qu'il contrôle :

https://www.example.com/robots.txt

Un fichier situé à /folder/robots.txt ne contrôle pas l'hôte. Les règles d'un hôte ou d'un sous-domaine ne contrôlent pas automatiquement un autre.

Groupes de user-agents

Les règles sont regroupées par nom de robot :

User-agent: *
Disallow: /internal-search/

Le groupe générique s'applique aux robots qui le correspondent selon le protocole et l'implémentation du robot.

Allow et disallow

Les règles s'appliquent à des chemins d'URL. Testez des exemples réels, car les détails de correspondance, l'encodage, la sensibilité à la casse et les extensions propres à chaque robot peuvent surprendre les équipes.

Limites

Les règles robots ne peuvent pas :

• garder une URL secrète ;
• exiger un mot de passe ;
• retirer de manière fiable une URL connue d'un index ;
• forcer l'exploration ;
• forcer l'indexation ;
• contrôler un robot qui ignore le protocole.

Une URL disallowed peut rester connue via des liens et apparaître comme un résultat sans description, car le robot ne peut pas récupérer le contenu pour une meilleure présentation.

Meta robots et X-Robots-Tag

Utilisez une directive meta HTML pour les pages HTML :

<meta name="robots" content="noindex, follow">

Utilisez un en-tête HTTP lorsque la ressource n'est pas du HTML, ou lorsqu'un pilotage au niveau de l'en-tête est plus fiable :

X-Robots-Tag: noindex

Cela est utile pour les PDF, les fichiers générés et les réponses média.

Ne bloquez pas le crawl avant que le robot pris en charge n'ait observé noindex. Après ce retrait, la politique de crawl peut être reconsidérée, mais notez le compromis : si vous empêchez toute récupération future, une directive modifiée ne pourra plus être lue.

Authentification et codes de statut

Contenu privé

Renvoyez une expérience authentifiée. Les requêtes non authentifiées ne devraient pas recevoir de contenu privé propre à un tenant dans une page 200. Utilisez un flux d'autorisation correct et testez-le sans cookies.

Contenu manquant

Renvoyez 404 ou 410 lorsqu'aucune ressource ni remplacement pertinent n'existe. Ne renvoyez pas 200 avec un message « introuvable », ce qui crée un schéma de type soft-404.

Contenu remplacé

Utilisez une redirection permanente directe lorsqu'un remplacement proche existe. Ne redirigez pas chaque page supprimée vers la page d'accueil.

Indisponibilité temporaire

Utilisez un statut temporaire fidèle à la réalité et un plan de rétablissement. Des erreurs serveur persistantes affectent le crawl et peuvent finir par affecter la présence dans l'index.

Vous examinerez les codes de statut et les signaux canoniques à l'étape 8.

Ce que font réellement les sitemaps

Un sitemap est une liste d'URL lisible par machine que vous souhaitez faire connaître à un moteur de recherche. Il aide la découverte, en particulier pour des inventaires nouveaux, volumineux, riches en médias ou faiblement liés.

Le guide de construction de sitemap de Google documente ces limites pour un sitemap :

• pas plus de 50 000 URL ;
• pas plus de 50 Mo non compressés ;
• des URL absolues et pleinement qualifiées ;
• un encodage UTF-8.

Utilisez un index de sitemaps lorsque vous avez besoin de plusieurs fichiers sitemap.

Incluez des URL canoniques indexables

Le sitemap est un signal canonique parmi d'autres. Ne le remplissez pas de redirections, d'erreurs, de doublons de paramètres, d'URL bloquées ou de pages noindex.

Utilisez un lastmod fidèle à la réalité

lastmod devrait représenter un changement significatif de la page, pas chaque déploiement ou modification de navigation. Google indique qu'il utilise cette valeur lorsqu'elle est régulièrement exacte.

Ne comptez pas sur priority ou changefreq

Google indique qu'il ignore les champs priority et changefreq du sitemap. Les inclure ne crée aucune urgence de crawl.

La soumission est une indication

Soumettez via Search Console, l'API Search Console, ou une ligne sitemap dans robots. La soumission ne garantit ni le crawl ni l'indexation.

Les sitemaps ne remplacent pas les liens internes

Une URL orpheline présente dans un sitemap peut être découverte, mais l'absence de liens internes contextuels nuit toujours à la navigation, aux relations entre pages et à la maintenabilité.

Le protocole Sitemaps définit le format XML partagé. Les moteurs de recherche peuvent ajouter leurs propres extensions et comportements pris en charge, il faut donc vérifier la documentation à jour de chaque moteur.

IndexNow soumet-il des URL à Google ?

IndexNow est un protocole distinct de notification de changement d'URL, pris en charge par des moteurs participants. Sa documentation officielle du protocole explique comment un site peut notifier les moteurs de recherche participants de l'ajout, de la mise à jour ou de la suppression d'URL.

Ne décrivez pas IndexNow comme l'API d'indexation de Google. Une notification ne garantit ni le crawl ni l'indexation, et la prise en charge par la recherche Google ne doit pas être présumée sans documentation officielle Google à jour.

Utilisez-le uniquement lorsque :

• les moteurs visés documentent leur prise en charge ;
• votre implémentation authentifie correctement la propriété du site ;
• les soumissions sont idempotentes et limitées en débit ;
• les états supprimé et mis à jour sont exacts ;
• cela ne remplace pas les liens internes et les sitemaps.

Le sélecteur de contrôles

Téléchargez le sélecteur de contrôles de crawl et d'index.

Une procédure de déploiement reproductible

1. Inventoriez les classes d'URL

Regroupez les leçons publiques, les routes de compte privées, les filtres, les fichiers, les aperçus, les URL retirées et les états d'erreur. Les politiques techniques doivent s'appliquer à des classes, pas à une mémoire au coup par coup.

2. Consignez l'état visé

Pour chaque classe, notez :

• publique ou privée ;
• crawl autorisé ou bloqué ;
• éligible à l'indexation ou exclue ;
• propriétaire canonique ;
• statut attendu ;
• inclusion dans le sitemap ;
• limite de sécurité.

3. Choisissez un seul contrôle par mission

Ne laissez pas robots, noindex, canonical et redirection se contredire.

4. Générez à partir de données de routes stables

Utilisez le même inventaire canonique pour la navigation, le sitemap, les métadonnées et les données structurées. Cela réduit les dérives.

5. Testez la réponse déployée

Vérifiez :

• le statut final et la chaîne de redirection ;
• les en-têtes de réponse ;
• la récupération par robots ;
• les directives meta dans la source et dans le rendu ;
• l'accès non authentifié ;
• la syntaxe et les URL du sitemap.

6. Testez des robots représentatifs en toute sécurité

Utilisez des outils de test officiels et des journaux serveur vérifiés. Les chaînes de user-agent seules ne prouvent pas qu'une requête provient d'un vrai robot.

7. Surveillez le résultat

Utilisez la couverture Search Console, des échantillons de l'outil d'inspection d'URL, le traitement du sitemap et les journaux serveur. Un commit de configuration prouve seulement que la configuration a changé.

Exemple travaillé : une Academy aux états d'URL mixtes

Le site synthétique contient :

• des leçons Academy publiques ;
• des aperçus de préproduction ;
• des pages de compte privées ;
• des PDF de leçon générés ;
• des URL de recherche interne et de filtres ;
• des leçons retirées, avec ou sans remplacement.

Leçons publiques

Renvoyez 200, autorisez le crawl, utilisez des self-canonicals, liez-les depuis la navigation de l'Academy, et incluez les URL canoniques dans le sitemap.

Aperçus de préproduction

Protégez-les par une authentification ou une limite réseau. Excluez-les des sitemaps publics. Une ligne Disallow: /preview/ peut réduire le crawl conforme, mais elle ne peut pas sécuriser la préproduction.

Pages de compte privées

Exigez une autorisation sur chaque requête. Testez l'isolation entre tenants. Ne servez jamais de données de tenant à une requête non authentifiée en espérant que noindex la protège.

PDF générés

Si le PDF est une ressource indexable utile, ne l'incluez que s'il a un objectif distinct. Si la leçon HTML doit être canonique et que le PDF ne doit pas apparaître, utilisez une politique d'en-tête HTTP prise en charge et retirez le PDF du sitemap.

Listes filtrées

Décidez si une combinaison de filtres a une valeur durable pour l'utilisateur et la recherche. Ne bloquez pas tout en bloc avant de comprendre l'état actuel de l'index. Pour les combinaisons publiques à faible valeur, alignez les liens, les canonicals, les directives d'index et la politique de crawl.

Leçons retirées

Redirigez directement vers un remplacement proche. Renvoyez 404 ou 410 lorsqu'aucun équivalent n'existe. Retirez les anciennes URL des sitemaps et des liens internes.

Pourquoi cela peut échouer

Si le framework de routage renvoie 200 pour chaque leçon manquante, le sitemap peut sembler propre alors que la gestion des erreurs crée quand même des soft-404. Si un CDN met en cache du contenu authentifié sans les bonnes clés de tenant et d'autorisation, les directives de recherche n'ont aucune importance face à l'incident de sécurité.

Fichiers de test originaux SEOryon

Utilisez :

• le CSV du sélecteur de contrôles ;
• la suite de tests robots synthétique ;
• l'index de sitemap d'exemple.

Les URL d'exemple sont de la documentation, pas un fichier de production à copier aveuglément. Remplacez les routes et les dates par des données canoniques appartenant à votre dépôt.

Erreurs fréquentes

Disallow associé à noindex

Le robot peut ne pas récupérer la page et donc ne pas lire noindex.

Publier des secrets dans robots.txt

Le fichier est public. Des chemins sensibles peuvent attirer l'attention.

Supposer que chaque robot se comporte comme Google

Le support du protocole et les capacités JavaScript varient. Vérifiez la documentation du robot concerné.

URL relatives ou non canoniques dans le sitemap

Utilisez des URL canoniques visées, absolues.

Mettre à jour chaque lastmod à chaque build

Une fausse fraîcheur rend le champ moins fiable.

Traiter un sitemap comme une architecture

Créez des liens internes contextuels et explorables. Une liste machine ne remplace pas la navigation utilisateur.

Confondre IndexNow avec l'indexation Google

C'est un protocole distinct entre moteurs participants, et la soumission reste une simple notification.

Exercice : choisissez les contrôles pour dix intentions

Pour chaque intention, choisissez robots, directive d'index, statut ou authentification, état du sitemap et résultat attendu :

1. nouvelle leçon publique ;
2. page de facturation privée ;
3. événement expiré avec un remplacement annuel proche ;
4. page de test supprimée sans remplacement ;
5. PDF public qui doit quitter la recherche ;
6. URL à facettes déjà indexée mais qui n'a plus d'utilité ;
7. environnement de préproduction ;
8. résultats de recherche interne au site ;
9. image publique destinée à la recherche d'images ;
10. interruption de maintenance temporaire.

Corrigé

• Nouvelle leçon : allow, 200, inclure l'URL canonique dans le sitemap, lier en interne.
• Facturation et préproduction : protéger par authentification ou contrôles réseau, exclure du sitemap.
• Événement remplacé : redirection permanente directe, retirer l'ancienne URL du sitemap.
• Page de test supprimée : 404 ou 410, retirer les liens et l'entrée sitemap.
• Retrait du PDF : autoriser le crawl, envoyer X-Robots-Tag: noindex, exclure du sitemap.
• Facette indexée : autoriser jusqu'au traitement de la directive de désindexation, aligner liens et politique canonique.
• Recherche interne au site : exclure généralement de l'index ; choisir la politique de crawl selon l'échelle et l'état actuel.
• Image publique : autoriser l'image et ses ressources, fournir un contexte de page utile.
• Maintenance : renvoyer un état d'échec temporaire fidèle, se rétablir rapidement, et surveiller.

Une réponse valide doit indiquer explicitement que robots ne peut pas protéger les données de facturation ou de préproduction.

Checklist finale

• Chaque classe d'URL a un état visé écrit.
• Les données privées sont protégées par une authentification et une autorisation.
• Robots n'est utilisé que pour l'accès des robots d'exploration.
• Un robot d'exploration peut récupérer toute directive noindex qu'il doit traiter.
• Les directives d'index non HTML utilisent un en-tête de réponse pris en charge.
• Les ressources manquantes renvoient des codes de statut significatifs.
• Les redirections mènent directement à des remplacements pertinents.
• Les sitemaps ne contiennent que des URL publiques canoniques.
• Chaque sitemap reste sous 50 000 URL et 50 Mo non compressés.
• lastmod représente des changements significatifs et fidèles à la réalité.
• priority et changefreq ne sont pas traités comme des contrôles Google.
• Les pages importantes ont des liens internes explorables.
• IndexNow est limité aux moteurs participants documentés.
• Les réponses déployées sont testées sans session connectée.
• Le suivi confirme les résultats de crawl et d'index après mise en production.

Questions fréquentes

Chaque site a-t-il besoin d'un fichier robots.txt ?

Non. Un site sans restriction de crawl peut fonctionner sans règles personnalisées. Un fichier valide est utile quand vous avez besoin d'une politique de robots explicite ou d'un point de découverte de sitemap.

Robots.txt supprimera-t-il une page de Google ?

Pas de manière fiable. Il empêche le crawl par les robots conformes. Une URL connue peut rester indexée sans contenu. Utilisez un noindex récupérable, un processus de suppression, une redirection ou un état d'absence selon le cas.

Un sitemap améliore-t-il le classement ?

Il aide la découverte et le signalement canonique. Il ne garantit pas directement le crawl, l'indexation ou le classement.

Les pages privées doivent-elles utiliser noindex ?

Les pages privées doivent utiliser l'authentification et l'autorisation. noindex peut être une instruction publique supplémentaire pour la recherche, pas la limite de sécurité.

Chaque mise à jour doit-elle déclencher IndexNow ?

Ne soumettez que des URL ajoutées, mises à jour ou supprimées et exactes, aux moteurs participants. Construisez l'idempotence et la limitation de débit, et ne soumettez pas de bruit inchangé.

Sources et méthodologie

Les recherches communautaires ont montré une confusion persistante autour de robots.txt, noindex, la surindexation et la suppression massive d'URL. Ces questions ont façonné l'ordre et les exemples de la leçon. Les réponses communautaires n'ont pas été utilisées comme autorité.

1. Google Search Central, introduction à robots.txt, mis à jour le 10 décembre 2025 et vérifié le 28 juillet 2026. Comportement et limites officiels de Google.
2. RFC 9309, Robots Exclusion Protocol, publiée en septembre 2022 et vérifiée le 28 juillet 2026. Norme Internet pour le protocole.
3. Google Search Central, créer et soumettre un sitemap, mis à jour le 8 juillet 2026 et vérifié le 28 juillet 2026. Formats, limites et modalités de soumission officiels de Google pour les sitemaps.
4. Sitemaps.org, format XML des sitemaps, vérifié le 28 juillet 2026. Définition du protocole partagé.
5. IndexNow, documentation du protocole, vérifiée le 28 juillet 2026. Protocole officiel de notification entre moteurs participants. Une notification ne garantit pas l'indexation.

Précédent : Comment fonctionne la recherche en 2026
Suivant : Indexation, canonicals, redirections et statuts HTTP