Générateur de robots.txt
Génère un brouillon de robots.txt, teste tes vrais chemins, compare le fichier en ligne et relis les avertissements de crawl avant de publier.
Ce générateur de robots.txt construit un brouillon propre pour WordPress, les sites publics génériques, les sections e-commerce, les blocs de staging ou les règles destinées aux crawlers IA, puis fait la partie que la plupart des générateurs zappent. Il fait passer tes vrais chemins à travers les règles que tu as écrites, pour que tu voies quelles URLs finissent autorisées ou bloquées et quelle directive l'emporte. Il récupère le robots.txt que tu sers déjà en ligne et le compare au brouillon, donc rien ne change par surprise. Il construit la ligne Sitemap, signale les erreurs habituelles comme un Disallow plein-site qui traîne ou un dossier d'assets bloqué, et te donne une checklist d'installation plus un rapport copiable. Dépose le fichier à la racine de chaque host, puis récupère-le et teste les chemins qui comptent avant de lui faire confiance.
Les requêtes passent par le service de lookup PeopleAreGeek. Nous ne journalisons rien.
Générateur de robots.txt, comparaison en direct, testeur de chemins et planificateur de règles de crawl WordPress
Soyons honnêtes, le robots.txt fait trébucher plus de monde qu'il ne le devrait. Cet outil te construit un brouillon propre pour WordPress, les sites publics, l'e-commerce, le staging ou les règles destinées aux crawlers IA. Ensuite il fait ce que la plupart des générateurs zappent : il teste tes vrais chemins contre ce brouillon, va chercher le fichier déjà en ligne que tu as, et te montre exactement ce qui changerait. Tu récupères les lignes Sitemap et les avertissements de crawl dans un résultat que tu peux vraiment passer à quelqu'un pour relecture.
Petit rappel : le robots.txt contrôle le crawl. Ce n'est ni du secret, ni une garantie d'indexation. Une fois publié à la racine du host exact, va tester le comportement réel en ligne.
Un générateur de robots.txt devrait produire un fichier auditable
Ce générateur de robots.txt construit un brouillon que tu peux lire, tester et défendre avant qu'il n'atteigne un host en ligne. Le fichier est minuscule. Le rayon d'explosion, lui, ne l'est pas. Un seul Disallow: / qui traîne sur un domaine en prod et tu as dit aux crawlers de tout laisser tomber. Oublie la ligne Sitemap après une migration et la découverte se met juste à crawler plus lentement qu'elle ne le devrait. Sur WordPress, le boulot est en général assez ennuyeux, et c'est tant mieux : garde les chemins admin hors d'accès, laisse passer l'endpoint AJAX parce que certains plugins en ont vraiment besoin, laisse le public ouvert, et donne ton sitemap aux moteurs.
Ce workflow ennuyeux, c'est tout l'intérêt de ce truc. Il génère des templates pour WordPress, les sites publics génériques, les sections e-commerce, les blocs de staging, les règles pour crawlers IA. Il fait passer tes chemins importants à travers les règles générées et signale les erreurs de crawl habituelles. Il ira aussi chercher le robots.txt que tu as en ligne là, maintenant, pour que tu voies ce qui change vraiment avant d'uploader quoi que ce soit.
Comment utiliser un robots.txt généré sans danger
Dépose le fichier à la racine du host, donc https://example.com/robots.txt, ou configure-le via le plugin SEO ou la couche d'hébergement qui pilote ton robots virtuel. Ensuite récupère le fichier en ligne et va tester ce qui compte : pages publiques, zones admin, pages de recherche, URLs de sitemap, et tout ce que la Search Console n'arrête pas de signaler comme bloqué. Un truc qui piège du monde : ces règles sont spécifiques au host. Si www et non-www répondent tous les deux, il faut vérifier les deux. Oui, les deux.
- Sers-toi du robots.txt pour l'accès au crawl. Il n'a jamais été conçu pour cacher du contenu privé.
- Utilise noindex sur une page accessible au crawl quand ce que tu veux vraiment, c'est faire disparaître la page des résultats.
- Garde des lignes Sitemap absolues et, tu vois, réellement à jour.
- Ne bloque pas le CSS ou le JavaScript dont tes pages publiques ont besoin pour s'afficher. Sinon les crawlers voient une page cassée.
- Recompare le fichier en ligne après chaque purge de cache, chaque plugin ou chaque changement d'hébergement. C'est en général là que les surprises se glissent.
Erreurs courantes de robots.txt
Le grand classique de la catastrophe, c'est d'expédier un bloc de staging en prod et de bloquer discrètement le site entier. Ça arrive plus souvent que personne ne l'avoue. Bloquer /wp-content/ est plus sournois, parce que le site a l'air nickel pour toi alors que les crawlers n'arrivent pas à charger les assets. Et voilà celle qu'on oublie : si une page a besoin d'un signal noindex mais que tu as bloqué le crawl, personne ne lira jamais ce signal. Le robots.txt est public aussi, donc ces noms de dossiers « secrets » que tu as disallow forment maintenant une liste publiée. Honnêtement, le fichier le plus sûr est juste court, réfléchi, et testé contre les chemins qui te tiennent vraiment à cœur.
Questions fréquentes
Le robots.txt garantit-il qu'une URL ne sera pas indexée ?
Non. Tout ce qu'il contrôle, c'est le crawl. Si tu veux vraiment sortir une URL de l'index, prends plutôt un noindex sur une page accessible au crawl, ou des redirections, ou un nettoyage de canonical, ou le bon code de statut. Ça dépend de ce que tu cherches à faire.
Tout site WordPress devrait-il bloquer wp-admin ?
La plupart des sites publics le font. Le schéma courant, c'est de bloquer /wp-admin/ tout en laissant /wp-admin/admin-ajax.php ouvert. Teste juste ton thème et tes plugins une fois la modif faite, parce que certains s'appuient sur cet endpoint.
Les règles pour crawlers IA peuvent-elles aller dans le robots.txt ?
Oui, ça peut. Un bon nombre de crawlers IA lisent bien les groupes user-agent dans le robots.txt. Mais perso je traiterais ça comme exprimer une préférence à voix haute, pas comme un mur. Tout ce qui ignore les règles va juste les ignorer, alors ne le prends pas pour une barrière de sécurité.
Que devrait contenir un robots.txt basique ?
Pas grand-chose, en vrai. Une ligne User-agent, les règles Disallow ou Allow dont tu as besoin, puis une ligne Sitemap pointant vers ton sitemap XML. Pour beaucoup de sites, le défaut honnête c'est : tout autoriser, ajouter la ligne Sitemap, terminé.
Interdire un chemin le cache-t-il de Google ?
Non, et celle-là surprend du monde. Disallow bloque le crawl, d'accord, mais l'URL peut quand même apparaître dans les résultats, juste sans extrait parce que Google n'a jamais pu lire la page. Tu la veux vraiment partie ? Fais l'inverse de ton instinct : autorise le crawl, et mets une directive noindex sur la page pour qu'elle puisse réellement être vue.
Où placer le robots.txt ?
À la racine de chaque host, exactement à /robots.txt. Range-le dans un sous-dossier et les crawlers l'ignorent, point. Et chaque sous-domaine compte ici comme son propre host, donc chacun a besoin de son propre fichier. La boutique et le blog sur des sous-domaines séparés ? Deux fichiers.