Testeur de robots.txt
Teste un robots.txt en direct, fais passer plusieurs paths pour n'importe quel token de crawler, et vois quel groupe a ete retenu et quelle regle a gagne.
Ce testeur de robots.txt recupere le fichier en direct a la racine du domaine cote serveur, puis transforme le mur de directives en un verdict clair. Tape un hote et un token de crawler, colle les paths qui t'interessent, et il sort les groupes user-agent, les regles Allow et Disallow et les lignes Sitemap, puis fait passer chaque path et te dit quel groupe a ete selectionne et quelle regle a vraiment gagne. Il reproduit la selection de groupe facon Google et la precedence des paths : groupe le plus specifique, correspondance la plus longue, Allow tranche les egalites, et il gere le wildcard etoile et le marqueur de fin dollar. Il signale aussi un Disallow generique sur un site public, verifie les sitemaps declares, et garde le fichier brut a l'ecran pour comparer avec ce qu'un plugin croit avoir configure. Souviens-toi : robots controle le crawl, pas l'indexation.
Les requêtes passent par le service de lookup PeopleAreGeek. Nous ne journalisons rien.
Récupération du robots.txt en direct et simulation des règles de path
Lire un robots.txt a l'oeil, c'est exactement la ou je fais des erreurs. Cet outil va chercher le fichier en direct cote serveur, en sort les lignes Sitemap et les groupes de crawlers, fait passer quelques paths pour le token que tu choisis, et te dit simplement quel groupe a ete retenu et quelle regle Allow ou Disallow a vraiment gagne. Fini de plisser les yeux sur un mur de texte en esperant l'avoir bien lu.
Le simulateur de paths reproduit la selection de groupe facon Google et la precedence des paths pour les regles courantes. Ca te met dans le bon, a peu pres. Pour tout ce qui compte vraiment, confirme quand meme avec tes vrais outils de crawl et le comportement reel de l'hote en live.
Ce qu'un testeur de robots.txt devrait rendre limpide
Un testeur de robots.txt devrait transformer un mur de directives en un verdict clair. Le robots.txt a l'air simple. C'est le piège. Tu le survoles, tu crois avoir compris, et en fait tu as lu un Allow imbriqué comme un blocage total. Un vrai fichier mélange un groupe général User-agent: * avec un groupe de crawler plus précis, glisse une exception Allow au milieu d'un Disallow plus large, éparpille une ligne Sitemap ou deux par-ci par-là, et enterre la partie qui compte vraiment sous un commentaire. Du coup un testeur qui vaut le coup doit te montrer les deux choses en même temps : le fichier brut que tu peux lire ligne par ligne, et le verdict clair pour le seul path que tu es venu vérifier.
Voilà ce qu'il fait. Il tape le fichier en direct à la racine du domaine via le backend, parse les groupes de crawlers, fait passer plusieurs paths d'un coup, puis dit quelle règle a gagné pour le token que tu lui as donné. Honnêtement, le moment où il gagne sa place, c'est juste après que tu as touché à quelque chose : une mise à jour WordPress, un thème ou un plugin qui réécrit en douce le robots virtuel, un changement de plugin sitemap, une migration. Ou un rapport Search Console qui te signale une URL bloquée et tu n'as aucune idée du pourquoi.
Le robots.txt contrôle le crawl, pas tout ce qui touche à l'indexation
Une règle robots dit à un crawler bien élevé s'il a le droit de demander un path. Point. Ce n'est pas un mur de confidentialité, et encore moins un bouton de suppression propre pour une page. Bloque une URL au crawl et tu viens peut-être d'empêcher le moteur de jamais lire la balise canonical ou robots meta posée sur cette page. Donc pour un vrai nettoyage d'index, fais correspondre le signal au boulot : des redirections quand le contenu a bougé, une balise noindex sur ce que tu laisses crawler mais ne veux pas voir indexé, le bon code de statut quand quelque chose a disparu. Les règles robots, c'est pour l'accès au crawl, un point c'est tout.
Comment le crawler et la correspondance des paths sont lus ici
Le simulateur est construit autour de la seule décision dont un SEO technique a vraiment besoin. Il attrape le groupe de crawler le plus précis qui colle au token que tu as tapé, y ajoute les groupes aussi précis, puis déroule les règles Allow et Disallow. La correspondance la plus longue gagne. Quand deux règles aussi précises s'affrontent, Allow l'emporte. Et oui, il gère le wildcard * et le marqueur de fin $ que les moteurs modernes utilisent quand ils parsent les fichiers robots.
- Tape l'hôte exact que tu veux auditer. Les règles robots sont liées à l'hôte et au scheme du fichier qui a été récupéré, rien d'autre.
- Balance-lui un vrai path public, plus un path admin ou de recherche, plus l'URL qui t'a été signalée comme bloquée.
- Lis la règle gagnante. Pas le nombre de règles, le vrai gagnant.
- Jette un oeil aux URLs de sitemap déclarées et assure-toi qu'elles parsent encore.
- Garde la sortie brute à l'écran quand tu compares le fichier live avec ce qu'un plugin croit avoir configuré.
Les vérifications robots.txt qui valent le coup sous WordPress
Sur un site WordPress public, tu verras presque toujours /wp-admin/ bloqué avec une exception Allow taillée pour /wp-admin/admin-ajax.php. Très bien. C'est normal, et ça ne prouve rien sur le reste de ta config de crawl. Teste aussi tes pages qui rapportent, les articles et les outils qui comptent vraiment. Puis les patterns de recherche ou de paramètres que tu voulais limiter. Puis la découverte du sitemap. Et n'oublie pas ce que ton plugin de sécurité ou ton hébergeur a injecté en douce pendant que tu regardais ailleurs.
Les bonnes habitudes SEO technique autour du robots.txt
- Récupère à nouveau le fichier live dès que tu as touché à un plugin SEO, un sitemap, un cache, ou fait une migration.
- Quand les règles ont l'air partagées, teste exactement la même URL deux fois : une fois en Googlebot, une fois avec le groupe étoile générique.
- Ne bloque pas le CSS et le JS dont les crawlers ont besoin pour rendre une page publique. Pas sans une très bonne raison, en tout cas.
- Garde les lignes Sitemap absolues et à jour. Les vieilles, on les oublie vite.
- Associe la vérif robots à un coup d'oeil indexabilité et canonical sur les pages que tu veux vraiment voir ranker.
Questions fréquentes
Un résultat robots autorisé garantit-il l'indexation ?
Non. Tout ce qu'il fait, c'est lever un doute : le crawler peut atteindre la chose. L'URL doit encore le mériter. Du contenu utile, un code de statut sain, un canonical qui a du sens, quelques liens internes qui pointent dessus, et aucun noindex égaré qui défait tout l'effort.
Un path bloqué est-il toujours une erreur ?
Pas du tout. Les pages admin, les paniers, les résultats de recherche, les URLs en doublon ou de workflow privé sont souvent bloqués exprès. La vraie question est plus simple : est-ce que bloquer ce path colle à ce que tu veux que le site fasse ?
Pourquoi tester plusieurs paths d'un coup ?
Parce que les fichiers robots adorent les règles larges avec une exception étroite planquée au milieu. Mets une page publique, une zone bloquée et le path d'exception côte à côte et le pattern saute aux yeux. Beaucoup plus dur de se mentir comme ça.
Le robots.txt empêche-t-il une page d'être indexée ?
Non, et celle-là fait trébucher les gens en permanence. Il bloque le crawl, pas l'indexation. Une URL en Disallow peut quand même atterrir dans l'index sans snippet si d'autres pages pointent dessus. Tu la veux disparue ? Autorise le crawl, puis sers un noindex.
Quelle est la différence entre Disallow et noindex ?
Disallow arrête le crawl. Noindex (une balise meta ou un header) dit au moteur de ne pas indexer. Voilà le piège que la plupart des gens ratent : bloque une page avec Disallow et le crawler n'atteint jamais le noindex que tu y as mis, donc la page que tu voulais virer reste juste là.
Où doit vivre le robots.txt ?
Pile à la racine de l'hôte, exactement /robots.txt. Colle-le dans un sous-dossier et il est ignoré, tout simplement. Ah, et chaque sous-domaine a besoin du sien.