WAF et SEO
Le pare-feu applicatif filtre avant le CMS : quel code il renvoie, ce que Google en fait, et comment le prouver.
Un WAF, ou pare-feu applicatif web, inspecte les requêtes HTTP et refuse celles qu’il juge hostiles, avant que le serveur applicatif ne les traite. Son effet SEO ne tient pas à ce qu’il bloque mais au code HTTP qu’il renvoie : un 403 servi durablement à un robot d’exploration sort l’URL de l’index, là où un 503 signale une indisponibilité passagère. Comme le refus se produit en amont du CMS, il ne laisse aucune trace dans l’interface d’administration.
Que décide réellement un WAF sur une requête ?
Il additionne des points, puis compare le total à un seuil. Le Core Rule Set OWASP, jeu de règles de référence derrière ModSecurity et la plupart des pare-feux mutualisés, documente ce mécanisme sous le nom de notation d’anomalie. Chaque règle déclenchée ajoute un score selon sa sévérité : 5 points pour une règle critique, 4 pour une erreur, 3 pour un avertissement, 2 pour une remarque. Le seuil de blocage par défaut vaut 5 en entrée et 4 en sortie. Une seule règle critique suffit donc à faire refuser la requête. La documentation insiste sur un point que les tableaux de bord masquent : la détection est découplée du blocage, les règles accumulent des points sans agir, et la décision n’est rendue qu’à la fin de la phase. C’est pourquoi une requête refusée n’a presque jamais violé une règle unique et évidente.
Pourquoi un WAF refuse-t-il des requêtes légitimes ?
Parce que le réglage qui gouverne sa sévérité est un compromis assumé, pas un état de fait. Le CRS OWASP définit quatre niveaux de paranoïa, en pelure d’oignon : chaque niveau reprend les règles du précédent et en ajoute. Le niveau 1 vise une sécurité de base avec un minimum de faux positifs à corriger. Le niveau 2 ajoute des règles adaptées aux données réelles et attend des faux positifs. Le niveau 3 est décrit comme un niveau bancaire en ligne, avec beaucoup de faux positifs. Le niveau 4 protège ce que la documentation appelle les bijoux de la couronne. Elle avertit explicitement qu’activer un niveau élevé en mode bloquant sans réglage préalable est très risqué, et que l’élimination des faux positifs peut demander plusieurs semaines. Sur un hébergement mutualisé, ce niveau n’est pas choisi par le propriétaire du site : il est imposé par l’hébergeur, pour tous ses comptes.
Quel code HTTP le pare-feu doit-il renvoyer ?
La documentation Google sépare nettement deux familles, et le pare-feu se range presque toujours dans la mauvaise. Google écrit qu’il n’utilise pas le contenu des URL renvoyant un code 4xx, qu’il ne les indexe pas et qu’il retire de l’index celles qui y figuraient. Le 403 suit cette règle générale : l’URL cesse progressivement d’être explorée puis d’être servie. Les codes 5xx produisent l’effet inverse à court terme, puisque Google ralentit son exploration et conserve d’abord les URL déjà indexées. Le 429 est traité comme une erreur serveur, non comme une erreur client. Un pare-feu qui refuse une requête légitime avec un 403 déclare donc à Google que la ressource est interdite, alors qu’elle est simplement mal filtrée.
| Code renvoyé | Lecture par Google | Effet sur l’index |
|---|---|---|
| 403 | Erreur client, comme les autres 4xx hors 429 | L’URL cesse d’être utilisée, puis sort de l’index |
| 429 | Serveur surchargé | Exploration ralentie, URL conservées |
| 503 | Indisponibilité serveur | Exploration ralentie, URL conservées au début |
| 5xx durable | Panne installée | Suppression progressive des URL |
Comment bloquer volontairement sans perdre l’index ?
En servant 500, 503 ou 429, et en tenant une durée courte. C’est la recommandation explicite de Google pour un serveur surchargé par l’exploration. Elle est assortie d’une limite chiffrée : quelques heures, un à deux jours, pas davantage. Google précise que si ces codes persistent sur la même URL pendant plusieurs jours, celle-ci peut être supprimée de son index. Un pare-feu réglé pour limiter le débit d’un robot doit donc renvoyer 429, pas 403, et cette limitation doit être une mesure d’urgence, pas un réglage permanent. Le corollaire est valable en audit : un pic de 503 dans les journaux ne se lit pas comme une panne mais comme une décision, tant qu’on n’a pas identifié qui l’a prise.
Comment un WAF peut-il reconnaître un vrai Googlebot ?
Par l’adresse IP, jamais par le User-Agent seul, et Google donne les deux méthodes acceptées. La première est manuelle : résolution DNS inverse de l’adresse appelante, contrôle que le nom obtenu appartient à googlebot.com, google.com ou googleusercontent.com, puis résolution directe de ce nom pour vérifier qu’elle redonne l’adresse de départ. La seconde est automatique : comparaison de l’adresse aux plages publiées par Google dans des fichiers JSON, un par famille de robots. Google distingue trois familles, et la distinction compte pour le réglage d’un pare-feu. Les robots communs respectent le fichier robots.txt et se résolvent en googlebot.com. Les robots à cas particuliers peuvent l’ignorer et se résolvent en google.com. Les récupérateurs déclenchés par un utilisateur l’ignorent, puisque c’est une personne qui a demandé la requête. Une règle qui autorise sur la seule chaîne de User-Agent laisse passer n’importe quel client qui la recopie.
Un refus prononcé par le pare-feu n’apparaît ni dans les journaux de WordPress, ni dans une extension de sécurité installée dans WordPress, puisque la requête n’atteint jamais le CMS. Les deux seules traces exploitables sont les journaux du serveur et la réponse HTTP elle-même. C’est aussi ce qui rend le symptôme intermittent en apparence : selon le motif envoyé, la même page répond 200 ou 403.
Comment diagnostiquer un blocage par le pare-feu ?
En comparant une requête témoin et une requête suspecte au même instant, puis en lisant le temps de premier octet. Un refus rendu par le pare-feu arrive nettement plus tôt qu’une page produite par le CMS, puisqu’il économise l’exécution applicative et les requêtes en base. Un écart d’un facteur quatre ou plus entre les deux mesures situe le filtre en amont de l’application, ce qui écarte d’emblée les extensions et le thème. Trois contrôles suffisent ensuite à cadrer le problème. Le code renvoyé, qui dit ce que Google va faire. La présence ou l’absence d’un en-tête X-Robots-Tag sur la page d’erreur, qui dit si le refus est doublé d’une consigne d’indexation. Et le comportement face à un User-Agent de robot, qui dit si une exception existe. Ce protocole se déroule sans accès au serveur, ce qui le rend applicable en audit avant toute demande d’accès.
Cas mesuré sur un site en production
Mesure du 1er septembre 2026. Sur la recherche interne d’un site vitrine hébergé en mutualisé, quatre requêtes espacées ont été envoyées : une requête témoin ordinaire et trois motifs d’attaque classiques. La requête témoin et un motif d’injection SQL répondent tous les deux 200. Un motif de script et une traversée de répertoire reçoivent un 403, servi en 0,10 à 0,12 seconde, quand une page réelle demande 0,41 à 0,60 seconde : le filtre agit donc quatre à six fois plus vite que l’application, ce qui le situe avant elle. La page d’erreur pèse 17 006 octets, porte un titre 403 Forbidden, et ne contient ni balise noindex ni en-tête X-Robots-Tag. Rejouée avec un User-Agent Googlebot, la même requête reçoit le même 403 : le pare-feu ne fait aucune exception pour les robots des moteurs. Deux enseignements. Le pare-feu du compte est actif et sélectif sans avoir été configuré par le propriétaire du site. Et il annonce à Google une interdiction définitive là où le refus est une mesure de sécurité, ce qui est exactement le code que Google traite en retrait d’index.
Faire expliquer ce terme par une IA
Ouvre le moteur de ton choix avec un prompt pré-rempli sur ce terme.
Sources
- 1Google Search Central, HTTP status codes : traitement des 2xx, 3xx, 4xx, 429 et 5xx
- 2Google Search Central, Reduce the Googlebot crawl rate : codes 500, 503, 429 et durée maximale
- 3Google Search Central, Verifying Googlebot and other Google crawlers
- 4OWASP CRS Documentation, Anomaly Scoring : scores par sévérité et seuils de blocage
- 5OWASP CRS Documentation, Paranoia Levels : les quatre niveaux et leurs faux positifs
- 6OWASP CRS Documentation, False Positives and Tuning
Questions fréquentes
Un WAF peut-il faire chuter le référencement d’un site ?−
Oui, par le code qu’il renvoie. Google n’indexe pas les URL répondant en 4xx et retire celles qui y figuraient. Un pare-feu qui sert durablement des 403 à un robot d’exploration produit donc une désindexation, sans qu’aucune modification n’ait été faite dans le CMS.
Quel code renvoyer pour bloquer un robot temporairement ?+
500, 503 ou 429, selon la recommandation de Google, et pour une durée courte. Google cite quelques heures ou un à deux jours, et prévient que ces codes maintenus plusieurs jours sur la même URL peuvent en provoquer la suppression de l’index.
Pourquoi un pare-feu bloque-t-il des requêtes normales ?+
Parce qu’il additionne des points d’anomalie et bloque à partir d’un seuil. Dans le CRS OWASP, le seuil d’entrée par défaut vaut 5 et une règle critique en vaut 5 : un seul déclenchement suffit. Plus le niveau de paranoïa monte, plus les faux positifs sont nombreux, et la documentation les annonce à partir du niveau 2.
Comment autoriser Googlebot dans un pare-feu ?+
Par vérification de l’adresse IP, pas par le User-Agent. Google publie des plages d’adresses en JSON et documente la méthode par résolution DNS inverse puis directe. Une règle fondée sur la seule chaîne de User-Agent laisse passer tout client qui la recopie.
Quelle différence entre un WAF et un blocage User-Agent ?+
Le blocage User-Agent filtre sur l’identité déclarée du client. Le pare-feu applicatif inspecte le contenu de la requête, quelle que soit cette identité. Les deux peuvent coexister sur le même serveur, et les deux agissent avant le CMS.
Un blocage par le pare-feu apparaît-il dans Search Console ?+
Indirectement, sous la forme d’URL passées en erreur d’exploration ou retirées de l’index. Search Console rapporte le code reçu, pas la règle qui l’a produit : l’origine se retrouve dans les journaux du serveur, jamais dans le CMS.
Damien Hernandez
Consultant SEO senior, 17 ans d’expérience (Accor, Louvre Hotels, Infopro Digital). Spécialiste SEO technique, analyse de logs et optimisation pour les moteurs génératifs (GEO).