Reconnaître un blocage d’exploration
La Search Console indique qu’une page importante est bloquée par robots.txt, alors qu’elle s’ouvre dans votre navigateur. Ce résultat est possible : le fichier adresse des consignes aux robots et ne ferme pas la page aux visiteurs ordinaires. Le but est de rétablir l’exploration des seuls chemins publics concernés, sans retirer les restrictions encore utiles.
Un blocage robots.txt n’est pas une directive noindex. Il empêche le robot de lire la page ; il ne garantit pas qu’une adresse connue par ailleurs disparaisse des résultats. Noindex exige au contraire que le robot puisse récupérer la ressource pour y lire cette consigne. Identifiez donc le motif précis avant de modifier un fichier.
Commencez par une URL finale touchée et une autre URL qui doit conserver son traitement actuel. Gardez aussi une copie des règles reçues et leur date. Évitez les modèles présentés comme le meilleur robots.txt pour tous les sites WordPress : un site vitrine, une boutique et une installation en sous-dossier n’ont pas forcément les mêmes chemins ni les mêmes besoins d’exploration.
Retrouver le fichier de la bonne origine
Le fichier est recherché à /robots.txt à la racine de l’origine concernée. Le protocole, l’hôte et le port comptent. Le fichier d’un sous-domaine ne commande pas automatiquement celui du domaine principal, et celui de HTTPS ne représente pas toutes les variantes HTTP. Utilisez la version finale réellement utilisée par les pages publiques.
Si WordPress est installé dans un sous-dossier, ne déduisez pas que le fichier doit se trouver dans ce sous-dossier. Pour une page publique située sous /blog/, le fichier applicable reste celui de la racine de son hôte. Plusieurs applications peuvent donc partager les règles d’une même origine, même si leurs administrations sont différentes.
Notez l’adresse du robots.txt consulté à côté de l’URL touchée. Si vous devez le modifier, identifiez le répertoire public correspondant dans l’hébergement ; il ne s’agit pas nécessairement du dossier contenant wp-admin. En multisite, faites vérifier la portée par l’administrateur réseau. Une correction à la racine peut affecter plusieurs sites partageant le même hôte, tandis qu’un domaine distinct possède son propre fichier effectif.
Lire la réponse publique avant toute modification
Ouvrez l’adresse exacte du robots.txt sans connexion. Vérifiez que vous recevez un texte de règles et non une page de connexion, un écran de protection ou une erreur HTML. Un titre de navigateur rassurant ne prouve pas que le fichier est lu correctement. Conservez le contenu et le statut de la réponse dans votre relevé.
Avec un terminal autorisé, l’exemple ci-dessous effectue un GET borné et affiche les en-têtes ainsi que le texte. Remplacez le domaine fictif. Sous Windows, utilisez curl.exe pour appeler le programme attendu. Le paramètre -q doit rester le premier ; aucun cookie ni mot de passe n’est fourni. Cette lecture ne modifie pas le site.
La commande ne suit pas automatiquement les redirections. Si elle en reçoit une, identifiez la destination avant de poursuivre. Un succès depuis votre poste ne garantit pas que Google a déjà récupéré cette même version. Le fichier peut aussi différer selon une protection intermédiaire ; une comparaison avec le rapport Google permet de préciser cet écart sans inventer le contenu de sa dernière lecture. L’absence d’erreur du programme ne suffit pas : sans --fail, curl peut terminer avec le code 0 après un HTTP 403. Lisez le statut et le contenu reçus.
curl -q --silent --show-error --connect-timeout 5 --max-time 15 --include 'https://exemple.invalid/robots.txt'Comparer avec le rapport robots.txt de la Search Console
Dans la propriété appropriée, ouvrez Paramètres, puis le rapport robots.txt lorsqu’il est disponible. Ce rapport concerne les propriétés de domaine ou de préfixe à la racine d’un hôte ; une propriété limitée à un sous-chemin ne donne pas le même accès. Son absence dans cette dernière ne signifie pas qu’aucun fichier existe. Une propriété de domaine n’affiche que ses vingt principaux hôtes dans ce rapport. Si le sous-domaine concerné manque, vérifiez une propriété adaptée à ce sous-domaine plutôt que de conclure à l’absence de robots.txt.
Sélectionnez l’adresse du fichier concerné et relevez la date de récupération ainsi que les avertissements ou erreurs. Consultez la version récupérée pour la comparer au texte actuel. Lorsque l’historique Versions est proposé, il peut aider à rapprocher le début du blocage d’une ancienne modification.
Vous cherchez une différence exploitable : Google a lu un ancien blocage, il ne parvient pas à récupérer le fichier, ou la règle actuelle bloque réellement le chemin. Ne réécrivez pas le contenu pour résoudre une simple absence de données dans une mauvaise propriété. Gardez le résultat daté et l’URL précise ; ce sont les éléments à reprendre après correction, avec l’inspection de la page touchée.
Identifier le groupe applicable au robot
Les lignes User-agent désignent les robots visés par un groupe de règles. Pour Google, un groupe spécifique correspondant au robot est retenu plutôt que le groupe général *. Les règles générales ne sont pas automatiquement ajoutées à ce groupe spécifique. Si plusieurs groupes correspondent au même user-agent spécifique, leurs règles peuvent être regroupées.
Dans cet exemple fictif, l’autorisation générale ne débloque pas /guides/ pour Googlebot, car son groupe propre l’interdit. Il s’agit d’un fragment de diagnostic, pas d’un fichier à remplacer intégralement sur votre site. Recherchez le groupe applicable avant de modifier une ligne ; ajouter une exception dans un autre groupe peut laisser le problème inchangé.
L’ordre visuel des groupes ne suffit pas à choisir celui qui gagne. N’essayez pas de déplacer un bloc en bas du fichier en supposant qu’il annule tout ce qui précède. Comparez le nom du robot, la structure des groupes et les chemins réellement visés. Conservez les groupes dédiés à d’autres usages lorsque leur rôle reste justifié.
User-agent: *
Allow: /guides/
User-agent: Googlebot
Disallow: /guides/Lire les chemins et la priorité des règles
Dans le groupe retenu, Allow autorise un chemin et Disallow l’interdit à l’exploration. La correspondance commence au début du chemin et tient compte de sa casse. Une restriction sur /Guide/ ne décrit pas nécessairement /guide/. Le chemin le plus spécifique détermine le résultat ; à correspondance équivalente entre autorisation et interdiction, l’autorisation est privilégiée.
Une règle Disallow: / vise tout le chemin de l’origine, tandis qu’une valeur vide après Disallow ne porte pas cette interdiction générale. La barre finale compte aussi : une exception sur /dossiers/publics/ ne correspond pas à l’adresse exacte dépourvue de cette dernière barre. Utilisez les URL finales exactes et leurs éventuelles variantes pendant le contrôle.
Les motifs contenant * ou $ peuvent élargir ou borner une correspondance. Ne les ajoutez pas pour reproduire vaguement un dossier lorsque son chemin simple suffit. Une règle visant des paramètres peut aussi toucher des pages utiles. Si le fichier est complexe, réduisez le cas à quelques adresses représentatives et faites examiner leur correspondance par une personne compétente, plutôt que de changer toutes les lignes à la fois.
Modifier le fichier physique responsable avec une sauvegarde
Ce parcours convient si un vrai fichier robots.txt sert la réponse à la racine publique de l’hôte. Il demande un accès SFTP ou au gestionnaire de fichiers autorisé de cet hébergement. Identifiez d’abord le répertoire du domaine et téléchargez une copie privée du fichier. Le nom visible dans l’URL ne permet pas de deviner un chemin disque universel.
Si aucun fichier physique n’est trouvé, ne créez pas un fichier vide pour essayer : WordPress peut produire une version virtuelle. Passez alors à son gestionnaire réel. Un fichier physique ajouté à la place pourrait masquer ses règles et les références de sitemap.
- Ouvrez le fichier confirmé dans un éditeur de texte brut, avec la copie d’origine conservée hors du répertoire public.
- Repérez le groupe applicable et la seule restriction démontrée responsable de l’URL publique.
- Préparez la correction limitée, par exemple l’exception de chemin de la section suivante, en gardant les autres règles.
- Enregistrez sous le nom exact robots.txt en UTF-8, puis remplacez uniquement ce fichier par votre accès habituel.
- Relisez sa réponse publique et les chemins témoins. En cas de résultat inattendu, remettez immédiatement le fichier sauvegardé et vérifiez aussi cette restauration.
Autoriser un sous-chemin public sans ouvrir tout le dossier
Supposons que /dossiers/ doit rester limité, mais que /dossiers/publics/ doit être exploré. L’exemple fictif ci-dessous conserve l’interdiction générale et ajoute une autorisation plus précise. Adaptez les chemins à votre site et placez cette exception dans le groupe réellement applicable ; si un groupe Googlebot spécifique existe, le bloc général présenté ici ne suffit pas à le modifier.
Le résultat attendu est une exploration permise pour /dossiers/publics/guide/, tandis que /dossiers/interne/ reste interdit par cette politique. Testez aussi l’adresse /dossiers/publics sans barre finale : elle n’est pas couverte par l’exception montrée. Si elle est une variante réelle, examinez sa redirection ou préparez une règle adaptée au lieu d’élargir aveuglément toute la famille.
Ce fragment ne remplace pas votre fichier complet. Préservez les autres groupes et règles, ainsi que les références au sitemap. Pour annuler cet essai, retirez seulement l’exception ajoutée et vérifiez la réponse, ou rétablissez le fichier initial si c’était la seule intervention. Le répertoire appelé interne dans l’exemple reste à protéger par un contrôle d’accès si son contenu est confidentiel.
User-agent: *
Disallow: /dossiers/
Allow: /dossiers/publics/Retirer un blocage global hérité seulement quand il est confirmé
Un ancien Disallow: / peut avoir été copié depuis la préproduction. Si le groupe concerné doit désormais explorer les chemins publics et si cette restriction n’a plus de raison d’être, corrigez cette seule directive après validation du périmètre. Ne supprimez pas tout le fichier, car il peut contenir d’autres choix encore nécessaires.
Pour un groupe qui n’a plus aucune restriction à porter, une ligne Disallow: laissée sans valeur exprime l’absence de cette interdiction. Conservez une structure de groupes claire : enlever la dernière règle d’un bloc sans examiner le suivant peut rendre la lecture du fichier trompeuse. Si une partie du site doit rester limitée, employez plutôt des règles ciblées comme dans l’exemple précédent.
La case de visibilité native de WordPress ne produit plus automatiquement ce blocage global dans la génération actuelle du cœur. Décochez-la si son noindex est involontaire, mais ne supposez pas que cela effacera une ligne physique ou un filtre personnalisé. Après correction, vérifiez le fichier effectif et une page publique, puis contrôlez la préproduction séparément. Le retour arrière consiste à restaurer la règle initiale, sans confondre cette consigne avec une protection des données.
Utiliser l’éditeur de Yoast SEO s’il est déjà disponible
Si Yoast SEO est déjà installé et si son éditeur de fichiers est autorisé, il peut éviter une modification par SFTP. Au 3 novembre 2026, la version du répertoire est 28.8, par Yoast, avec WordPress 7.0 et PHP 7.4 minimum, et un test déclaré jusqu’à WordPress 7.1.4. Cet outil gratuit n’exige pas un achat Premium pour cette manipulation.
Conservez d’abord le fichier existant dans un emplacement privé. Si le menu manque ou refuse l’écriture, utilisez le responsable des fichiers ; ne changez pas les restrictions globales d’édition pour forcer cet outil. Le résultat attendu reste la réponse publique corrigée, pas seulement un message de sauvegarde.
- Dans le tableau de bord, ouvrez Yoast SEO, Tools, puis File Editor.
- Dans la zone intitulée robots.txt, retrouvez le groupe et la règle identifiés. Ne modifiez pas la zone .htaccess distincte qui peut apparaître sur le même écran.
- Modifiez seulement cette règle ou ajoutez l’exception ciblée, puis utilisez Save changes to robots.txt.
- Relisez l’URL publique du fichier et inspectez la page témoin.
- Pour annuler, remettez le texte initial dans cette même zone et sauvegardez.
- Si seul Create robots.txt file est proposé, vérifiez d’abord la génération virtuelle et les effets d’une création. Ne remplacez pas ses règles par un fichier neuf sans les avoir inventoriées.
Traiter une génération virtuelle sans ajouter un second fichier
WordPress peut servir robots.txt sans fichier physique correspondant. Sa fonction do_robots produit une base, puis le filtre robots_txt permet aux composants de la modifier. L’hébergement, un thème ou une extension peut donc expliquer une règle que vous ne retrouvez pas dans un fichier à la racine.
Comparez la sortie reçue avec les réglages du composant propriétaire. S’il s’agit d’un code personnalisé, faites rechercher le filtre robots_txt et la ligne exacte qui ajoute l’interdiction dans le thème enfant ou le module concerné. Conservez son original, essayez une correction de cette seule condition sur copie et vérifiez la sortie complète. Ne modifiez pas directement le fichier du cœur qui contient do_robots : une mise à jour pourrait effacer la modification et l’origine du problème resterait masquée.
Sur un service hébergé ou un multisite, les accès et la portée peuvent être limités. Utilisez les réglages documentés ou le responsable de ce générateur plutôt qu’une seconde extension de robots.txt. Pour annuler un essai de code, rétablissez le seul fichier modifié. Un fichier physique créé en parallèle peut cacher la génération virtuelle ; inventoriez donc lequel répond avant de conclure que le filtre ne fonctionne pas.
Préserver l’accès aux ressources nécessaires au rendu
Une page HTML autorisée peut dépendre de styles, de scripts ou de données que le robot ne peut pas récupérer. Le rendu de son contenu peut alors être incomplet. Examinez les ressources effectivement utilisées par une page témoin au lieu de ne contrôler que son adresse principale.
Dans l’inspection de l’URL active, ouvrez Afficher la page testée, puis Plus d’infos pour les ressources et erreurs disponibles ; consultez aussi la capture lorsque l’outil la propose. Si le contenu essentiel manque ou si une ressource publique nécessaire est bloquée, rapprochez son chemin de la règle applicable à son propre hôte. Un sous-domaine de ressources possède son propre robots.txt.
Évitez une interdiction de tous les scripts, styles ou du dossier de contenu simplement pour réduire l’exploration. Corrigez les chemins qui empêchent réellement le rendu, tout en conservant les contrôles d’accès aux données privées. Une autorisation robots.txt ne donne pas au robot une session d’utilisateur et ne doit pas rendre publics des fichiers sensibles. Reprenez ensuite le même test et comparez le contenu rendu, sans conclure à une indexation garantie à partir d’une capture correcte.
Distinguer une règle restrictive d’un fichier indisponible
Un robots.txt introuvable avec un statut 404 n’est pas équivalent à un fichier contenant Disallow: /. Pour Google, les erreurs 4xx de ce fichier, sauf 429, sont traitées comme une absence de restrictions robots. Une erreur 5xx, un délai dépassé ou une limitation de requêtes exige au contraire d’examiner la récupération et la dernière version connue, plutôt que d’interpréter un texte que Google n’a pas reçu.
Si la réponse est une page de protection, rapprochez son heure des journaux de la couche concernée. Faites corriger le blocage de cette lecture légitime, sans désactiver toute la sécurité du site. Conservez les réglages précédents pour annuler une exception trop large ou inefficace.
Un cache peut maintenir l’ancien fichier après votre sauvegarde. Corrigez d’abord sa source, puis invalidez la copie de robots.txt avec le système existant si nécessaire. Relisez-la une fois le cache reconstruit. Si le contenu change de nouveau après une synchronisation, identifiez l’étape de déploiement qui l’écrase. Une purge répétée ne résout pas cette réintroduction de règle. La version conservée par Google constitue encore un cache distinct de celui de votre hébergement. Sa mise à jour n’est pas provoquée automatiquement par votre purge locale.
Faire contrôler le fichier corrigé et la page concernée
Après une correction importante, relisez d’abord le fichier public pour confirmer que la bonne version est effectivement servie. Dans le rapport robots.txt de la Search Console, le menu de paramètres placé à côté du fichier permet de demander une nouvelle exploration. Utilisez cette action pour une modification critique ou une erreur résolue ; elle ne garantit pas une récupération ni une exploration immédiates des pages débloquées.
Inspectez ensuite l’URL finale de la page témoin et lancez Tester l’URL active. Vérifiez si le motif de blocage actuel a disparu. Gardez à part la dernière version connue de l’index : elle peut encore décrire l’état précédent. Contrôlez aussi l’adresse qui devait conserver son traitement initial, en tenant compte du groupe et du chemin applicables.
Si l’exploration est désormais possible mais qu’une consigne noindex demeure, traitez cette autre source séparément. Si la page est techniquement accessible et toujours non indexée, poursuivez l’analyse de son contenu et de sa découverte. Le retrait d’une restriction robots résout un obstacle d’accès ; il ne décide pas à lui seul de l’indexation ou du classement.
Prévenir le retour du blocage et transmettre les preuves utiles
Attribuez la responsabilité du fichier à un seul système clairement identifié : fichier physique, génération WordPress ou service d’hébergement. Documentez les exceptions et leur raison, afin qu’un prochain nettoyage ne les retire pas sans comprendre leur portée. Une règle commentée avec sa fonction est plus facile à maintenir qu’une longue liste copiée depuis plusieurs recettes.
Dans votre procédure de mise en ligne, comparez la production et la préproduction. Vérifiez leurs origines, leurs protections et le fichier effectivement servi après déploiement. Gardez un petit jeu d’URL publiques et d’URL volontairement limitées pour ce contrôle. N’utilisez pas le seul nom du fichier ou la réussite de son transfert comme preuve que le bon hôte le sert.
Pour demander une aide ciblée, transmettez l’URL du robots.txt, la page touchée, le user-agent concerné, le groupe et la règle suspectés, ainsi que les versions avant et après avec leurs dates. Ajoutez le résultat actuel de l’inspection et le statut de récupération du fichier. Ne joignez ni identifiants SFTP ni sauvegarde complète du site. Ces éléments permettent d’expliquer un blocage précis et de vérifier la correction sans recommencer tout le fichier.
