robots.txt modifié : cacher le site ou accélérer le spam

Deux intentions opposées, un même fichier

L'attaquant veut soit que Google ignore votre vrai contenu (pour que le spam prenne toute la place dans l'index), soit que Google aille plus vite dans un répertoire de pages générées. Les deux tiennent en dix lignes. Vous, vous voyez encore la home. L'index, lui, dérive.

Un troisième cas : `User-agent: *` / `Disallow: /` posé « en urgence » par une agence ou un plugin de maintenance. Ce n'est pas un pirate, c'est une balle dans le SEO. Le traitement est le même : remettre un fichier juste, demander une réindexation. L'intention change le ton du constat, pas la mécanique.

Ne jugez pas le fichier à l'œil « il est court donc inoffensif ». Cinq lignes suffisent.

Lire l'URL publique, pas seulement le FTP

Ouvrez `https://votre-domaine.fr/robots.txt` en navigation privée. Comparez au fichier sur le disque. Un plugin (Yoast, Rank Math, WordPress 5.5+) peut servir un robots virtuel plus prioritaire que le fichier. Vous nettoyez le FTP, Google lit l'autre.

Un CDN, un WAF, une règle Nginx peut aussi servir un autre corps. L'inspection d'URL Search Console sur `/robots.txt` montre ce que Googlebot reçoit. C'est la version qui compte, pas celle de FileZilla.

Gardez une capture de l'URL publique datée. Elle explique les extraits `site:` de la semaine suivante.

• URL publique en navigation privée.
• Inspection Search Console de `/robots.txt`.
• Fichier disque + réglage plugin SEO.
• Sous-domaines : chacun son robots.

Disallow trop large : vos pages disparaissent

`Disallow: /` ou `Disallow: /blog` sur un site dont le métier est le blog : Google cesse de découvrir. Les pages déjà indexées ne tombent pas en une nuit, mais les mises à jour cessent, et les titres spam déjà là restent. C'est l'inverse de ce qu'on croit (« je bloque, le spam part »).

Bloquer `/wp-admin` est normal. Bloquer `/` ne l'est pas, sauf le temps d'un staging clairement noindexé. Un staging oublié sur le domaine de prod avec `Disallow: /` et un sitemap spam dans le même fichier, vous avez les deux problèmes.

Corriger le robots ne « ramène » pas les positions le lendemain. Ça autorise le recrawl. Les positions, c'est une autre horloge — voir positions après piratage.

Allow sur un dossier que vous n'avez pas créé

`Allow: /wp-content/uploads/2024/xx/` ou `/jp/` : l'attaquant accélère le crawl d'un kit. Allez dans ce dossier. S'il est aléatoire, traitez-le comme dossier uploads, pas comme un réglage SEO.

`Crawl-delay` n'est plus suivi par Google. Une valeur absurde n'est pas le sujet. Les `User-agent: Googlebot` spécifiques avec un Allow étroit sur un path bizarre, si.

Un `Disallow` de vos vraies rubriques plus un `Allow` du spam : le fichier orchestre le remplacement dans l'index. C'est plus rusé qu'un simple générateur.

La ligne Sitemap : le piège le plus rentable

`Sitemap: https://votre-domaine.fr/sitemap-news.xml` que vous n'avez jamais soumis. Google le découvre et avale des milliers d'URL. Retirer les pages sans retirer cette ligne, le robot revient. Traitez le sitemap pirate dans la même heure que le robots.

Plusieurs lignes Sitemap : une légitime (Yoast `/sitemap_index.xml`), une pirate. Gardez la première, ôtez la seconde. Vérifiez aussi Search Console → Sitemaps : un fichier peut y être soumis sans figurer dans robots.txt.

Un sitemap en 200 qui liste du spam, même non cité dans robots, suffit. robots.txt n'est pas le seul annuaire.

WordPress, Yoast, et le robots virtuel

Réglages → Lecture → « demander aux moteurs de ne pas indexer » coche un robots virtuel `noindex`. Après un incident, des sites se retrouvent cochés. Décochez si le site doit être public. Ce n'est pas un fichier ; c'est une option `blog_public`.

Yoast : Réglages SEO → Outils → Fichier robots. Rank Math similaire. Un contenu collé là survit à la suppression du fichier physique. Lisez l'UI, puis l'URL publique.

Un mu-plugin peut `header('X-Robots-Tag')` ou intercepter `/robots.txt`. Si l'URL et le disque divergent, cherchez ça. Voir must-use.

Ce que `site:` et Search Console montrent

`site:votre-domaine.fr` compte encore les URL déjà connues. Un robots trop large n'efface pas ce compteur du jour au lendemain. L'onglet Couverture / Pages dans Search Console montre « exclue par robots.txt » : si vos pages métier y sont, le fichier (ou le virtuel) est trop agressif.

Les URL spam « valides » alors que vous les avez effacées : le générateur ou le sitemap vit. robots.txt ne désindexe pas ; il guide. La désindexation se fait par 404/410 + retrait de préfixe. Voir pages inconnues.

Ne déposez pas un réexamen Safe Browsing pour un robots.txt. Mauvais outil. Sauf si l'URL `/robots.txt` elle-même redirige vers un kit — rare, alors là oui, après correction, 24 à 72 h.

Remettre un fichier honnête

Minimal : autoriser le site, disallouer `wp-admin` (sauf `admin-ajax` si besoin), une ligne Sitemap vers le plan réel. Pas de `Disallow: /`. Pas de sitemap inconnu. Les réglages fins (paramètres, facettes) viennent après, pas dans la nuit de l'incident.

Si un plugin SEO gère le fichier, videz le champ pirate dans l'UI et laissez-le régénérer. Deux sources (fichier + plugin) se battent et produisent un mix illisible.

Testez l'URL publique. Puis demandez une inspection de la home et de trois pages métier. Le robots est un feu vert de crawl, pas une baguette de positions.

Empêcher la réécriture

Si le fichier sale revient, un cron ou un shell l'écrit. Même réflexe que pour `.htaccess`. Permissions 644, panel changé, mu-plugins lus.

Un générateur de pages réécrit souvent robots + sitemap + un index « news ». Traitez le trio, pas le seul robots. Sinon Google retrouve le sitemap par Search Console ou par un lien interne injecté.

Vous pouvez créer un espace. En attendant : capture de l'URL, comparaison plugin/disque, ligne Sitemap contrôlée.

• URL publique = disque = plugin.
• Une seule ligne Sitemap, la vôtre.
• Pas de Disallow: / sur la prod.
• Contrôle à J+1 si le fichier bouge.