HTTP 429 et SEO : limiter les bots sans freiner Google

Les requêtes automatisées ne viennent plus uniquement des moteurs de recherche traditionnels. Scrapers, outils de veille, bots de monitoring mal configurés et crawlers liés à l’IA peuvent solliciter un même site à une cadence difficile à absorber. Lorsque cette pression affecte les temps de réponse, le serveur web ou la base de données, la réponse HTTP 429 Too Many Requests devient un mécanisme de protection utile.

Mais un 429 n’est pas neutre pour le référencement naturel. Google considère cette réponse comme un problème temporaire côté serveur. Si Googlebot la reçoit de façon répétée, il peut ralentir ses passages. Si la situation perdure, les URL concernées peuvent devenir plus difficiles à explorer, à mettre à jour et, dans les cas les plus graves, à conserver dans l’index.

L’objectif n’est donc pas de supprimer tout rate limiting. Il consiste à limiter les bots qui consomment des ressources sans valeur SEO, tout en garantissant à Googlebot un accès stable aux pages canoniques, aux sitemaps, aux ressources de rendu et aux URL récemment modifiées. Cela demande une configuration sélective du WAF ou du CDN, puis une lecture précise des logs.

Pourquoi les réponses HTTP 429 se multiplient avec les bots IA et les scrapers

Le code HTTP 429 est défini pour indiquer qu’un client a envoyé trop de requêtes sur une période donnée. Il peut être accompagné de l’en-tête Retry-After, qui indique au client quand il peut réessayer. En pratique, cette réponse est souvent générée par un CDN, un WAF, un reverse proxy ou l’application elle-même.

Sur un site éditorial, e-commerce ou SaaS, les causes les plus fréquentes sont les suivantes :

• un scraper qui parcourt les fiches produits, les archives ou les pages de recherche interne à très haute fréquence ;
• un bot qui change constamment d’adresse IP et contourne un seuil limité à une seule IP ;
• un crawler qui explore des variantes infinies créées par des paramètres, des filtres ou un moteur de recherche interne ;
• un agent automatisé qui télécharge de nombreuses ressources lourdes, comme des images ou des fichiers ;
• une règle de sécurité trop large qui traite de la même manière un navigateur humain, un bot reconnu et un robot inconnu.

Les crawlers déclarés par certains services d’IA, par exemple GPTBot ou ClaudeBot, peuvent être identifiés par leur user-agent lorsqu’ils respectent les conventions publiées. Cela ne suffit toutefois pas à établir une identité fiable : un user-agent est une simple chaîne envoyée dans la requête et peut être imité. Les bots agressifs utilisent justement parfois le nom d’un navigateur courant ou d’un moteur connu.

Le problème est avant tout infrastructurel. Un grand volume de requêtes peut saturer les workers PHP, épuiser un pool de connexions base de données, remplir une file de cache miss ou dégrader le temps de réponse des visiteurs. Cette dégradation peut ensuite affecter le crawl utile. Un site qui répond lentement ou retourne des erreurs à tous les clients ne protège pas son SEO en bloquant quelques bots : il crée un problème général d’accessibilité.

Avant de déployer une limitation stricte, il faut donc séparer deux questions : quels robots produisent réellement la charge et quelles URL sont coûteuses. Une analyse des logs peut révéler qu’un seul endpoint, tel qu’une recherche interne ou une facette sans cache, concentre l’essentiel des requêtes. Dans ce cas, corriger la route, le cache ou les règles d’indexation est souvent plus efficace qu’un seuil global.

Pour approfondir cette démarche, consultez notre guide sur l’analyse des fichiers logs pour le SEO. Les logs permettent de distinguer une forte activité Googlebot d’un trafic automatisé moins utile, au lieu d’agir sur une impression ou sur un pic visible dans un outil de monitoring.

Ce que Googlebot interprète lorsqu’il reçoit un code 429

Google documente les réponses 429 dans la catégorie des erreurs de serveur. Pour Googlebot, un 429 indique que le site ne peut temporairement pas traiter la requête à la cadence demandée. La réaction attendue n’est pas une indexation immédiate d’un contenu d’erreur, mais un ralentissement des tentatives de crawl.

Ce comportement est logique : continuer à solliciter un serveur en difficulté nuirait au site et ne produirait pas de contenu exploitable. Google recommande de surveiller les erreurs serveur dans Search Console et de résoudre les causes qui les rendent fréquentes. Les détails généraux sont disponibles dans la documentation Google sur les codes d’état HTTP et les erreurs réseau.

Un 429 ponctuel sur une URL secondaire n’a pas le même poids opérationnel qu’une série de 429 sur :

• la page d’accueil et les principales pages de catégories ;
• les URL canoniques de fiches produits ou d’articles ;
• les nouvelles pages à découvrir ;
• le sitemap XML ;
• les fichiers CSS et JavaScript nécessaires au rendu ;
• les redirections qui mènent vers des URL stratégiques.

Une confusion fréquente consiste à penser qu’un 429 est une consigne SEO comparable à un noindex. Ce n’est pas le cas. Le 429 est une indisponibilité temporaire. Il ne donne pas à Google une instruction éditoriale sur l’indexation ; il empêche surtout Googlebot d’accéder correctement au contenu pendant un certain temps.

La durée et la récurrence comptent donc davantage qu’un événement isolé. Si votre WAF bloque Googlebot quelques minutes lors d’un pic exceptionnel, l’effet peut être limité. En revanche, une règle qui renvoie des 429 à Googlebot chaque jour, ou qui touche régulièrement les nouvelles URL, crée une dette de crawl. Les contenus sont découverts plus lentement, les modifications sont prises en compte moins vite et la couverture d’exploration devient moins fiable.

Le rate limiting doit être envisagé avec les autres leviers de contrôle. Un robots.txt sert à demander aux robots conformes de ne pas explorer certains chemins. Une balise noindex demande l’exclusion d’une page accessible. Une canonique aide à consolider des variantes similaires. Aucun de ces signaux ne remplace un mécanisme de défense quand un client envoie trop de requêtes. Retrouvez les différences dans notre article robots.txt, noindex et canonical : choisir le bon levier.

Éviter le piège du blocage fondé uniquement sur le user-agent

Un filtrage fondé uniquement sur le user-agent est rapide à mettre en œuvre, mais il est fragile. Autoriser sans limite toute requête annonçant Googlebot revient à créer une porte d’entrée facile pour un scraper qui usurpe cette chaîne. À l’inverse, bloquer tout user-agent inconnu peut affecter des services légitimes, des outils d’accessibilité, des moniteurs externes ou des navigateurs dont les en-têtes sont atypiques.

Pour identifier Googlebot de façon fiable, Google recommande une vérification DNS en deux temps :

• effectuer une recherche DNS inverse sur l’adresse IP source ;
• vérifier que le nom résolu se termine par googlebot.com ou google.com selon le type de crawler ;
• effectuer ensuite une recherche DNS directe de ce nom afin de confirmer qu’elle renvoie bien vers l’adresse IP d’origine.

Google publie également des listes d’adresses IP pour ses crawlers dans sa documentation. Ces données peuvent aider à alimenter une règle de confiance dans un WAF, à condition d’automatiser leur mise à jour et de ne pas maintenir manuellement une liste vieillissante. La référence est la documentation Google sur la vérification de Googlebot.

Cette vérification est particulièrement importante lorsque vous créez une exception. Une exception doit viser Googlebot vérifié, pas toute requête déclarant être Googlebot. Sur Cloudflare, AWS WAF, Fastly ou un autre service de sécurité, la méthode exacte varie, mais le principe reste identique : utiliser un signal d’identité fiable avant d’accorder un traitement distinct.

Il faut aussi éviter une exemption absolue. Même Googlebot vérifié ne doit pas pouvoir contourner toutes les protections applicatives. Une URL qui déclenche une requête extrêmement coûteuse, une boucle de redirection ou une erreur serveur doit être corrigée. L’exception concerne la pression légitime de crawl, pas un dysfonctionnement technique à masquer.

Configurer un rate limiting sélectif sans freiner le crawl utile

Un bon rate limiting n’applique pas le même seuil à toutes les requêtes. Il tient compte de la route demandée, du coût de traitement, du cache, de la méthode HTTP, de l’identité du client et de la fréquence observée. La règle la plus sûre est généralement celle qui protège des zones précises plutôt que tout le domaine avec un seuil uniforme.

Prioriser les routes coûteuses ou sans intérêt organique

Les candidats fréquents au contrôle de débit sont les moteurs de recherche internes, les endpoints d’API publics, les pages de connexion, les formulaires, les exports, les pages générées par des paramètres et certaines facettes. Ces zones peuvent recevoir un seuil plus bas que les pages HTML publiques et canoniques.

Par exemple, il est cohérent de limiter une route de recherche interne si elle interroge directement une base de données à chaque appel. Il est moins prudent de mettre le même seuil sur toutes les pages produit, surtout si ces URL sont présentes dans le sitemap et font partie du maillage interne principal.

La maîtrise des facettes réduit aussi la nécessité de filtrer dans l’urgence. Des URL de filtres accessibles en volume peuvent attirer des robots et gonfler la charge. Notre article sur le SEO des facettes et le gaspillage de crawl détaille les choix de maillage, de canonisation et de contrôle qui évitent de multiplier les variantes explorables.

Utiliser une réponse adaptée à chaque situation

Le 429 convient lorsqu’un client dépasse une cadence acceptable et peut réessayer plus tard. Ajouter Retry-After donne une indication explicite aux clients qui le respectent. En revanche, une requête manifestement malveillante ou interdite de façon durable peut relever d’un refus différent selon votre politique de sécurité. Il ne faut pas transformer le 429 en réponse universelle.

Pour des URL qui ne doivent jamais exister, un code 404 ou 410 est souvent plus cohérent. Pour une ressource dont l’accès exige une authentification, un contrôle d’accès approprié est préférable. Pour une URL que vous souhaitez retirer des résultats mais qui doit rester accessible, le noindex est le bon type de signal. La cohérence sémantique aide à diagnostiquer les incidents et évite de mélanger sécurité, performance et indexation.

Mettre en place des seuils progressifs

Un déploiement progressif réduit les faux positifs. Commencez par observer le trafic en mode journalisation ou simulation si votre outil le permet. Ensuite, appliquez des seuils sur une route ciblée, surveillez les réponses et augmentez la protection uniquement si la charge reste problématique.

Les solutions comme Cloudflare, AWS WAF, NGINX ou Apache permettent d’implémenter des contrôles de débit, mais leur comportement exact dépend de la configuration : période d’observation, clé de comptage, action de blocage, gestion des IP derrière un proxy et règles de contournement. Le point critique est d’identifier correctement le client. Derrière un CDN ou un load balancer, l’adresse vue par le serveur d’origine peut être celle du proxy si les en-têtes de transmission ne sont pas configurés de façon sûre.

Une règle efficace protège une capacité limitée : une route, une application ou une infrastructure. Une règle trop large protège parfois le serveur au prix de l’accessibilité des pages importantes.

Préserver les URL essentielles dans le WAF et le CDN

Les WAF sont souvent déployés avec des règles génériques : seuil par IP, détection de comportement automatisé, règles anti-bot ou challenge. Ces mécanismes sont utiles, mais ils doivent être testés contre le trafic des robots de recherche. Un challenge JavaScript, un CAPTCHA ou une page d’interstitiel peut empêcher l’accès normal d’un crawler, même si le serveur ne renvoie pas un 429.

Pour Googlebot, vérifiez au minimum que les routes suivantes ne sont pas affectées de manière anormale :

• les URL déclarées dans le sitemap XML ;
• les pages canoniques liées depuis la navigation ;
• le fichier robots.txt et les sitemaps ;
• les pages nouvellement publiées ou récemment modifiées ;
• les ressources critiques nécessaires à l’affichage ;
• les URL mobiles si votre architecture les distingue encore.

Le cache joue un rôle complémentaire. Servir une page populaire depuis le cache du CDN réduit la pression à l’origine, y compris pendant un passage intense de crawler. Mais un cache mal réglé peut créer d’autres problèmes : contenu périmé, variation incorrecte selon les en-têtes, ou mise en cache de réponses d’erreur. Notre guide sur le CDN et le SEO explique comment équilibrer cache, accessibilité et contrôle du crawl.

Évitez notamment de mettre en cache un 429 de façon involontaire sur une durée trop longue. Un blocage ponctuel peut alors devenir visible pour d’autres clients, y compris Googlebot, bien après la fin du pic initial. Vérifiez les en-têtes de cache des réponses de limitation et le comportement réel du CDN sur les erreurs.

Mesurer les 429 dans les logs : les indicateurs à suivre

La Search Console est utile pour détecter des problèmes de crawl signalés par Google, mais elle ne remplace pas les logs serveur ou CDN. Les logs permettent de savoir qui reçoit un 429, sur quelles URL, à quel moment et à quel volume.

Pour chaque réponse 429, conservez si possible les champs suivants :

• horodatage ;
• code HTTP ;
• méthode HTTP ;
• URL complète ou chemin avec paramètres ;
• user-agent ;
• adresse IP ou identifiant client, dans le respect de vos obligations de protection des données ;
• référent lorsqu’il est disponible ;
• règle WAF ou identifiant de règle ayant déclenché l’action ;
• temps de réponse, statut de cache et serveur d’origine.

Une analyse mensuelle est rarement suffisante après un changement de WAF. Durant le déploiement, observez les logs quotidiennement, voire en temps réel lors d’une campagne ou d’un incident. Recherchez notamment :

• la part des 429 attribuables à Googlebot vérifié ;
• les URL canoniques les plus touchées ;
• les sitemaps ou robots.txt ayant reçu une limitation ;
• un pic de 429 concomitant à une baisse des requêtes Googlebot ;
• une hausse des erreurs 5xx, qui peut indiquer que la protection intervient trop tard ;
• des paramètres ou chemins récurrents à l’origine d’un trafic inutile.

Des outils comme Elasticsearch et Kibana, Grafana Loki, Datadog ou Splunk peuvent aider à agréger ces événements si votre volume de logs le justifie. Pour un site plus modeste, des exports CDN et une analyse structurée des access logs restent suffisants, à condition que les informations nécessaires soient présentes.

Ne vous contentez pas d’un taux global de 429. Un faible volume peut être grave s’il touche exclusivement des sitemaps ou les nouvelles pages. À l’inverse, un volume élevé sur une route de recherche interne non indexable peut être acceptable s’il protège efficacement l’origine et ne déborde pas sur le reste du site.

Corriger les faux positifs avant qu’ils ne deviennent un problème d’indexation

Un faux positif est une requête légitime limitée par une règle conçue pour arrêter un comportement abusif. Dans le contexte SEO, le faux positif le plus sensible est Googlebot vérifié qui reçoit des 429 sur des URL importantes. Mais il faut aussi surveiller les visiteurs réels derrière une même adresse IP partagée, les outils de paiement, les partenaires API et les robots de monitoring autorisés.

Lorsqu’un faux positif est identifié, ne commencez pas par désactiver toute la protection. Cherchez la cause précise :

• le seuil est-il trop bas pour cette route ?
• la clé de comptage est-elle mal choisie ?
• une règle englobe-t-elle des URL canoniques avec des URL à risque ?
• le cache est-il contourné par une variation de paramètres ou de cookies ?
• Googlebot a-t-il été identifié sur la seule base de son user-agent, sans vérification ?
• un problème de performance à l’origine fait-il déclencher les protections plus souvent que prévu ?

Après correction, validez avec plusieurs sources : logs du CDN, logs de l’origine, rapport de crawl de Search Console et inspection d’URL lorsque cela est pertinent. Il est aussi utile de comparer la fréquence de passage de Googlebot sur les URL stratégiques avant et après le changement. Une baisse nette et durable mérite une investigation, particulièrement si elle coïncide avec des 429 ou des erreurs serveur.

Le budget de crawl ne se résume pas au nombre de requêtes de Google. Il dépend aussi de la qualité des URL proposées, de la vitesse du serveur et de la capacité de Googlebot à obtenir des réponses stables. Notre dossier sur l’analyse et l’optimisation du budget de crawl permet de replacer le rate limiting dans une stratégie technique plus large.

Conclusion : protéger la capacité serveur sans fermer la porte à Google

Les réponses HTTP 429 sont un outil légitime pour absorber la pression des scrapers et des crawlers excessifs. Elles deviennent dangereuses pour le SEO lorsqu’elles sont appliquées sans distinction, lorsqu’elles touchent Googlebot vérifié ou lorsqu’elles masquent une faiblesse structurelle de l’application.

La bonne approche repose sur quatre principes : identifier les clients dans les logs, limiter d’abord les routes coûteuses, vérifier rigoureusement Googlebot avant toute exception et suivre les 429 après chaque modification de WAF ou de CDN. En procédant ainsi, vous conservez un serveur disponible pour les visiteurs tout en préservant le crawl des pages qui comptent réellement. Un audit ciblé des logs est souvent le meilleur point de départ pour ajuster vos règles avec précision.