Un recul du crawl accompagné de 403 ou 429 dans les logs peut venir d’un WAF trop strict, d’un rate limiter applicatif, d’un CDN, d’une saturation ou d’un faux bot. Désactiver la protection pour « laisser passer Google » ouvre un risque majeur sans prouver la cause. Bloquer tout user agent contenant Googlebot est tout aussi mauvais : une chaîne déclarative s’usurpe facilement et n’identifie pas l’origine réelle.
Le diagnostic doit suivre la requête à travers DNS, CDN, WAF, load balancer, proxy et application. Chaque couche possède son statut, sa règle, son identifiant et sa latence. L’équipe vérifie ensuite que l’adresse appartient réellement aux plages publiées par Google ou qu’un contrôle DNS aller-retour concorde. Ce n’est qu’après cette preuve qu’une exception limitée peut être envisagée.
Google documente deux méthodes : vérification manuelle par reverse DNS puis forward DNS, ou comparaison automatique avec les plages IP officielles. Le pilotage SEO technique de Dawap relie cette vérification aux logs de sécurité, aux codes HTTP, au crawl, au cache et aux procédures de déploiement.
Le vrai enjeu est de garder le principe de moindre privilège. En pratique, cette méthode permet de décider quelle condition contourner pour le trafic vérifié, sur les seules routes et méthodes nécessaires. Un canari mesure l’effet sur Googlebot et sur les attaques simulées. Le rollback est automatique si la surface d’accès s’élargit, si les 5xx montent ou si la règle ne rétablit pas les réponses attendues.
Pour qui : qualifier le symptôme sans désactiver le WAF
Partir d’une chronologie commune
Le responsable incident aligne déploiements WAF, changements applicatifs, pics de trafic, 403, 429, 5xx, TTFB et activité de crawl. La fenêtre couvre avant, pendant et après le début du problème. Un identifiant de règle ou de politique est plus utile qu’un total de réponses : il indique la décision exacte prise à l’edge.
Les logs sont segmentés par route, méthode, host, IP, user agent, ASN, pays et cache. Les volumes de vrais visiteurs servent de témoin. Si tous les clients reçoivent des 429, le WAF n’est peut-être pas la cause spécifique. Si une seule règle bloque des requêtes dont le user agent annonce Googlebot, la vérification d’origine devient prioritaire.
Préserver la sécurité pendant l’enquête
Le mode observation compte les matchs sans autoriser automatiquement les requêtes. Une règle peut passer de blocage à journalisation sur une route canari et un échantillon d’adresses vérifiées. Les autres protections — injection, traversal, bot management — restent actives. Le changement expire automatiquement après la fenêtre prévue.
En réalité, une liste blanche globale de Googlebot fragilise la protection. Les IP évoluent et plusieurs catégories de crawlers existent ; une confiance fondée seulement sur le user agent est exploitable par un attaquant. Une solution automatique actualise les plages officielles, journalise la version et refuse par défaut une adresse qui ne correspond pas.
Vérifier les requêtes provenant de Google
Appliquer le double contrôle DNS
La référence officielle Vérifier les requêtes des crawlers Google demande, pour une vérification manuelle, un reverse DNS de l’adresse, le contrôle d’un domaine attendu, puis un forward DNS du nom obtenu qui doit revenir à l’adresse initiale. Une simple résolution inverse vers un nom ressemblant à Google ne suffit pas.
La procédure de diagnostic enregistre IP, résultat PTR, résultat A/AAAA, timestamp et résolveur. Les domaines attendus dépendent de la catégorie : crawlers communs, crawlers spéciaux ou fetchers déclenchés par l’utilisateur. L’équipe ne suppose pas qu’ils suivent tous exactement les mêmes règles robots.txt ou qu’ils doivent tous recevoir la même politique WAF.
Automatiser avec les plages publiées
À grande échelle, Google propose des fichiers JSON de plages IP au format CIDR. Un job les télécharge depuis la source officielle, valide le schéma, calcule une empreinte et publie un artefact signé dans la configuration. Le WAF ou le service de décision compare l’adresse source après avoir correctement traité les proxies de confiance.
La mise à jour est atomique et conserve la dernière version saine. Une erreur de téléchargement ne vide jamais la liste. Le monitoring alerte sur âge de l’artefact, nombre de plages et différence inhabituelle. Les logs indiquent la version utilisée pour chaque décision, ce qui rend un faux positif reproductible.
Corréler les journaux de toute la chaîne HTTP
Propager un identifiant de requête
Le CDN génère un identifiant transmis au WAF, au proxy et à l’application. Chaque couche journalise statut entrant, décision, durée et origine de la réponse. Une requête bloquée à l’edge n’apparaît pas dans les logs PHP ou Node ; l’absence côté application devient une preuve de localisation, pas une absence d’incident.
Le schéma commun contient timestamp UTC, host, route normalisée, méthode, IP client validée, chaîne de proxies, user agent, statut, octets, cache, règle WAF et limite de débit. Les données sensibles sont minimisées et leur rétention définie. Le responsable sécurité contrôle l’accès ; le SEO consulte des agrégats et des exemples nécessaires au diagnostic.
Distinguer réponse de sécurité et panne d’origine
Un 403 généré par le WAF porte un header interne ou un code de règle. Un 403 applicatif peut venir d’une authentification. Un 429 peut être émis par l’edge, le proxy ou l’API. Sans attribution, l’équipe modifie la mauvaise limite. Le pipeline normalise l’émetteur tout en conservant la réponse brute.
Le dashboard compare taux par couche et par version. Une règle mise à jour à 10 h 02, suivie d’une hausse des blocs vérifiés à 10 h 04, offre une hypothèse forte. L’équipe reproduit pourtant la requête avant de conclure. Les changements simultanés et les latences de cache sont annotés.
Isoler règle, signature, score et quota
Lire la décision complète du moteur
Un WAF peut bloquer une signature précise, un score cumulé, une réputation IP, une anomalie de protocole ou une règle personnalisée. Le log doit exposer identifiant, version, champ déclencheur et action. Une URL longue de pagination peut ressembler à une injection ; un rendu JavaScript peut charger un chemin que la politique considère automatisé. La correction vise le mécanisme exact.
L’équipe reproduit avec méthode, chemin, query string et headers identiques depuis une adresse de test contrôlée. Elle varie un seul élément pour identifier le déclencheur. Le corps de réponse, le code, la latence et la règle sont conservés. Une simulation sans même route ni mêmes headers n’est pas une reproduction.
Séparer sécurité et capacité
Le rate limiting protège la capacité ; il ne devrait pas dépendre d’une signature d’attaque. Les limites peuvent s’appliquer par host, route, classe de client et coût, avec un burst et une fenêtre. Un crawler vérifié n’obtient pas une capacité infinie : il reçoit un compartiment adapté à la charge que l’origine peut soutenir.
Les pages SSR coûteuses, les routes de recherche et les assets ne partagent pas le même poids. Le budget utilise le TTFB, le CPU, le cache hit ratio et les files. Un 304 consomme moins qu’un rendu complet. Le backend et la plateforme fixent les seuils à partir d’un test de charge, pas d’un souhait SEO.
Interpréter 403, 429 et 5xx pour le crawl
Comprendre le signal envoyé
Google indique dans sa documentation sur les statuts HTTP que les 4xx hors 429 conduisent à ne pas utiliser le contenu, et que 401/403 ne doivent pas servir à limiter le crawl. Le 429 signale une surcharge et est traité comme une erreur serveur. Les 5xx font ralentir le crawl.
Retourner 200 à Googlebot tout en servant une erreur aux utilisateurs serait du cloaking et masque la panne. La réponse doit refléter l’état réel. Une page disponible retourne 200 avec son contenu ; une surcharge temporaire peut justifier 429/503 avec récupération ; une ressource privée retourne 401/403 pour tous les clients concernés.
Ne pas réduire le crawl avec des erreurs artificielles
La documentation Google sur le budget de crawl explique que latence, 5xx et 429 réduisent la capacité de crawl. Elle recommande d’améliorer les performances et de gérer l’inventaire plutôt que de provoquer des erreurs. Le WAF n’est donc pas un outil de pilotage éditorial du crawl.
Pour réduire la charge, l’équipe élimine les URL inutiles, stabilise le cache, sert 304 lorsque pertinent, raccourcit les redirections et améliore le rendu. Robots.txt encadre des espaces qui ne doivent pas être crawlés, sans corriger une capacité insuffisante. La demande et la capacité sont surveillées séparément.
Concevoir une exception minimale et réversible
Réduire la portée sur quatre axes
L’exception précise identité vérifiée, host, routes, méthodes et règle contournée. Elle n’autorise pas les POST si seul le GET est nécessaire. Elle ne désactive pas toutes les signatures pour une plage entière lorsqu’un faux positif concerne un paramètre. Elle possède une expiration, un responsable et un commentaire lié à l’incident.
La politique est générée depuis un dépôt versionné, relue par sécurité et testée en CI. Une simulation confirme que le vrai Googlebot passe et qu’un user agent usurpé depuis une autre IP reste contrôlé. Les requêtes malveillantes conservent leurs blocages. Le diff de configuration est archivé avec l’artefact de plages.
Déployer en observation puis en application
La nouvelle condition tourne d’abord en mode d’observation : elle calcule « aurait autorisé » sans modifier la réponse. L’équipe mesure faux positifs et faux négatifs sur une fenêtre représentative. Elle active ensuite 5 % des requêtes vérifiées ou une route pilote. Les autres continuent sous l’ancienne politique.
Le rollback est automatique si les blocs d’attaques baissent, si les 5xx augmentent de 0,5 point, si le TTFB P95 dépasse la limite ou si des adresses non vérifiées empruntent l’exception. La configuration précédente reste chargée. Une purge globale de CDN n’est pas nécessaire si la décision WAF n’est pas cachée dans les réponses.
Rejouer les scénarios d’attaque et de faux positif
Scénario A : user agent usurpé
Exemple concret. Depuis une adresse hors plages officielles, envoyer un GET avec le user agent Googlebot sur une page publique, puis répéter avec une charge simulant une injection dans la query string. La première requête reçoit la politique publique normale ; la seconde est bloquée par la signature. Aucune ne doit profiter de l’exception réservée aux IP vérifiées.
Les logs montrent verified_google=false, la version des plages et la règle appliquée. Un seuil de zéro passage par la branche privilégiée est exigé. Le test couvre aussi les headers de proxy falsifiés : seule l’adresse extraite depuis la chaîne de proxies de confiance sert à la décision.
Scénario B : crawler vérifié sur URL limite
Depuis un environnement autorisé représentant une plage de test, rejouer la route et les headers qui déclenchaient le faux positif, avec cache chaud et froid. La réponse attendue est 200, canonical correct et HTML complet. Une variante malveillante de la même requête doit rester bloquée. Le test mesure TTFB et coût d’origine.
Le canari exécute cent requêtes au débit attendu, puis un burst contrôlé. Le compartiment crawler absorbe le nominal sans 429 et protège la surcharge au-delà du seuil. Le monitoring confirme que les visiteurs ne perdent pas de capacité. Si la route dépasse le budget CPU, l’équipe optimise cache ou rendu au lieu d’élargir la limite.
Surveiller simultanément crawl et sécurité
Construire deux tableaux reliés
La vue sécurité suit matchs de règles, sources, attaques, exceptions et faux positifs. La vue crawl suit requêtes vérifiées, statuts, TTFB, pages, profondeur et cache. Elles partagent release, règle et plage IP. Un pic de crawl n’est pas présenté comme une attaque sans analyse ; une attaque usurpant Googlebot n’est pas intégrée aux métriques SEO.
Les alertes prioritaires sont : hausse de 403 vérifiés, 429/5xx vérifiés, baisse de cache, vieillissement des plages, exception empruntée par une adresse inconnue et chute des blocs malveillants. Chaque alerte possède un responsable, une fenêtre, une procédure de traitement et une condition de fermeture.
Suivre la récupération au-delà du correctif
Après rétablissement des 200, le crawl peut mettre du temps à retrouver son rythme. L’équipe observe logs et Search Console sans forcer des inspections massives. Elle distingue la disponibilité immédiate de la redécouverte. Les sitemaps restent propres et les pages importantes conservent leurs liens.
La rétrospective compare temps de détection, vérification, correction et restauration. Elle met à jour les cas de test, la liste de routes coûteuses et les responsables. Une exception temporaire est supprimée lorsque la règle WAF amont est corrigée ; elle ne devient pas une dette invisible.
Erreurs fréquentes avec un WAF devant Googlebot
Ces raccourcis créent soit une faille, soit une panne de crawl. La revue d’incident doit explicitement confirmer leur absence avant de fermer le ticket.
- Faire confiance au seul user agent
Googlebot. - Valider un reverse DNS sans vérifier le retour vers l’adresse initiale.
- Désactiver globalement le WAF pour toutes les plages Google.
- Confondre le 429 du CDN avec celui de l’application.
- Utiliser 401 ou 403 comme outil de réduction du crawl.
- Augmenter les limites sans test de charge ni coût par route.
- Déployer une exception sans expiration, responsable, mode d’observation ni rollback.
- Tester uniquement le passage du bot et oublier les attaques simulées et l’usurpation.
Plan d’action
Première heure : préserver et prouver
Nommer un incident commander, figer les changements non essentiels et aligner les horloges. Extraire les requêtes bloquées avec identifiants de règle. Segmenter les statuts par couche. Vérifier manuellement plusieurs IP par DNS aller-retour ou plages officielles. Ne modifier aucune politique globale tant que l’origine et la règle ne sont pas confirmées.
Passer la règle suspecte en observation uniquement sur une route et une cohorte vérifiée si le risque le permet. Conserver toutes les autres protections. Reproduire la requête exacte avec ses headers et sa query string. Écrire le résultat attendu et le seuil de repli avant l’activation.
Journée 1 : corriger et recetter
Automatiser l’artefact de plages avec validation et dernière version saine. Implémenter une exception limitée à l’identité, la méthode, la route et la signature. Propager l’identifiant de requête dans toute la chaîne. Ajouter métriques par règle, émetteur et cache.
Exécuter les scénarios usurpé, vérifié, malveillant et surcharge. Déployer en observation, puis en canari. Surveiller sécurité, 403, 429, 5xx, TTFB et cache. Le responsable du déploiement replie au premier signal de fuite ou de dégradation. Les responsabilités et dépendances restent inscrites dans la procédure d’exploitation.
Semaine 1 : stabiliser la capacité
Optimiser les routes coûteuses, la revalidation et le cache. Nettoyer les URL inutiles plutôt que piloter le crawl par erreur. Ajuster les compartiments de rate limiting selon les tests de charge. Surveiller la reprise du crawl et la stabilité des pages prioritaires.
Corriger la signature amont si possible, puis retirer l’exception temporaire. Organiser un exercice de rollback et mesurer le temps. Documenter les plages, les catégories de crawlers, les proxies de confiance et les preuves à collecter. La prochaine alerte devient un diagnostic routinier.
L’instrumentation reçoit comme entrées l’adresse vérifiée, la route et la règle ; ses sorties portent statut, latence et décision. Les responsabilités, le seuil d’arrêt, le monitoring et le rollback sont inscrits dans le contrat de déploiement.
La journalisation relie dépendances CDN et application, tandis que la file de tests conserve retries et traçabilité. La procédure d’exploitation nomme le responsable de reprise et le mode de repli lorsque l’artefact de plages ou le proxy de confiance devient indisponible.
- D’abord, bloquer toute exception fondée sur le seul user agent.
- Ensuite, valider le vrai crawler et refuser l’usurpation avec les scénarios opposés.
- Enfin, ouvrir la politique seulement si sécurité, TTFB, 403, 429 et 5xx respectent leurs seuils.
Approfondir capacité, caches et quotas
Préparer la charge d’un crawl
La protection anti-bot sans challenge pour les robots détaille concurrence, identité et protection des dépendances. Elle aide à définir le trafic que la plateforme peut réellement accepter avant de configurer le compartiment du WAF.
La capacité doit être mesurée sur les routes chères et le cache froid, pas sur une moyenne confortable. Les queues, TTFB, CPU et taux d’erreur donnent une enveloppe. Le WAF applique cette enveloppe ; il ne remplace pas l’optimisation du rendu.
Distinguer limitation saine et blocage
Le rate limiting appliqué au crawl permet d’attribuer la réponse à la saturation, au WAF ou au proxy. Cette attribution évite d’augmenter une limite qui n’a jamais émis le statut observé.
Le schéma de logs commun et l’identifiant propagé sont la dépendance centrale. Ils lient sécurité, plateforme et SEO autour d’un même événement, raccourcissent le temps de restauration et rendent le rollback vérifiable.
Conclusion : autoriser par preuve, protéger par défaut
Un user agent n’est pas une identité. Les requêtes Google se vérifient par DNS aller-retour ou plages officielles, puis se suivent avec la version de preuve utilisée. Le diagnostic localise la couche et la règle avant toute exception.
La correction reste minimale : identité, host, route, méthode et signature. Elle passe en observation, puis canari, tout en rejouant attaques et usurpation. Les seuils protègent à la fois le crawl, la capacité et la sécurité.
Les 403, 429 et 5xx expriment des états différents. Ils ne doivent pas servir artificiellement à piloter Googlebot. Un inventaire propre, un rendu efficace et des caches stables améliorent la capacité sans ouvrir une brèche.
Vous faire accompagner par un expert pour auditer les blocages WAF
