Le scraping des résultats de recherche Google échoue pour une raison précise : Google interprète un flux de requêtes provenant d'une seule adresse IP exactement pour ce qu'il est, un bot, et commence à servir des CAPTCHAs et des erreurs 429 au bout de quelques dizaines de requêtes. La solution n'est pas un en-tête astucieux ni un délai plus long. Il s'agit d'envoyer chaque requête depuis une adresse IP différente qui passe pour un vrai utilisateur, ce que fait la rotation de proxies. Choisissez le bon modèle de rotation et le bon type d'IP, et le scraping de SERPs devient une opération de routine ; faites une erreur sur ces points, et vous passerez votre temps à résoudre des pages de consentement plutôt qu'à analyser des résultats.
Cet article est la version pratique : pourquoi Google bloque de la façon dont il le fait, pourquoi la rotation par requête est préférable à un pool statique pour les SERPs, quel type d'IP résiste réellement, un exemple Python fonctionnel que vous pouvez exécuter, et le moment où un endpoint SERP géré représente simplement moins de travail que de maintenir votre propre rotation. Si vous souhaitez d'abord en apprendre les fondamentaux sur les proxies, qu'est-ce qu'un serveur proxy couvre la couche d'indirection sur laquelle tout le reste repose.
Pourquoi Google bloque si agressivement les scrapers
L'ensemble du modèle commercial de Google consiste à servir des humains, et ses défenses contre les abus sont donc calibrées pour détecter tout ce qui n'en est pas un. Un scraper déclenche plusieurs de ces défenses simultanément. Le signal le plus visible est le volume de requêtes provenant d'une seule adresse : un vrai utilisateur lance une poignée de recherches par heure, tandis qu'un scraper naïf en lance des centaines par minute depuis une seule IP. Ce rythme seul suffit à déclencher une page de consentement sorry/index ou un CAPTCHA.
L'IP elle-même est le deuxième signal. Google sait quelles plages d'adresses appartiennent aux fournisseurs cloud et d'hébergement, de sorte que le trafic provenant d'une IP de datacenter part avec un déficit de confiance avant même que vous n'envoyiez une seule requête. S'y ajoutent des vérifications de forme de requête : en-têtes manquants ou robotiques, une empreinte TLS qui ne correspond pas au navigateur revendiqué par votre User-Agent, absence de cookies, et timing identique entre les requêtes. La rotation des IPs règle les deux premiers signaux. Elle ne corrige pas le reste, ce qui fait qu'elle est nécessaire mais insuffisante, un point sur lequel nous revenons plus loin.
Pourquoi la rotation par requête est le bon modèle pour les SERPs
La rotation consiste à changer l'IP de sortie afin que les requêtes consécutives ne proviennent pas toutes de la même adresse. Il existe deux modèles de livraison, et la différence compte particulièrement pour Google.
Une session sticky maintient une IP pour une série de requêtes, ce qui est utile pour les flux connectés où un changement soudain d'IP paraît suspect. La rotation par requête change l'IP à chaque appel. La recherche Google n'a pas de connexion ni de session à préserver, donc il n'y a aucun intérêt à conserver une IP, et toutes les raisons de répartir les requêtes sur beaucoup d'adresses différentes. La rotation par requête est le modèle adapté aux SERPs : mille requêtes réparties sur mille adresses ressemblent chacune à un utilisateur curieux plutôt qu'à une machine. Pour la mécanique de l'intégration de la rotation dans un scraper, comment utiliser des proxies rotatifs va plus loin, et adresse IP rotative couvre le concept par lui-même.
La taille du pool derrière la rotation représente l'autre moitié de l'équation. Alterner entre dix IPs à fort volume ne fait que limiter ces dix IPs plus lentement. Un grand pool est ce qui permet de maintenir chaque adresse en dessous du radar de Google par IP, ce qui explique pourquoi rotation et taille du pool forment vraiment une seule décision.
Le type d'IP détermine si la rotation est utile
La rotation n'apporte quelque chose que si les IPs que vous utilisez sont de confiance. Alterner mille IPs de datacenter, et Google bloque les mille sur le même signal ASN, juste réparti sur davantage de requêtes. Le type d'IP est le choix structurant pour le scraping de SERPs.
| Type d'IP | Comment Google la traite | Coût et vitesse | Adapté aux SERPs |
|---|---|---|---|
| Datacenter | Reconnue par l'ASN, faible confiance, bloquée rapidement | La moins chère, la plus rapide | Insuffisante seule |
| Résidentielle | Passe pour un vrai utilisateur à domicile, résiste aux défis | Facturée à la bande passante, plus lente | Choix par défaut solide |
| Mobile | La plus difficile à bloquer (NAT de qualité opérateur) | La plus chère, la plus lente | Excessif pour la plupart des travaux SERP |
Pour la recherche Google, la réponse pratique est la résidentielle : des IPs que les fournisseurs d'accès Internet ont attribuées à de vrais foyers, de sorte qu'une requête rotative ressemble à un visiteur ordinaire plutôt qu'à un serveur. Les IPs de datacenter conviennent pour des cibles tolérantes, mais sont rapidement signalées sur les SERPs, et le mobile offre plus de confiance (et de coût) que les résultats de recherche n'en nécessitent généralement. Le compromis complet est détaillé dans proxies datacenter vs résidentiels, et le terrain intermédiaire statique-résidentiel dans proxies ISP vs résidentiels. Les chiffres ici décrivent le cas typique ; votre taux de blocage exact varie selon le volume de requêtes, la région, et le niveau de défense des pages de résultats spécifiques.
Changer d'IP neutralise la limite par IP et la vérification du datacenter-ASN. Cela ne fait rien contre une empreinte TLS robotique, des cookies manquants ou un timing de requêtes identique. Une IP résidentielle propre associée à une requête manifestement automatisée reçoit quand même un CAPTCHA. Considérez la rotation comme une couche parmi d'autres et associez-la à des en-têtes crédibles, un timing varié, et une vraie empreinte de navigateur lorsque les pages se rendent côté client.
Configurer la rotation de proxies en Python
La façon la plus propre de faire pivoter est de pointer votre client vers un unique endpoint rotatif et de le laisser échanger l'IP de sortie par requête, plutôt que de maintenir et surveiller vous-même une liste d'IPs brutes. Pour votre code, c'est simplement un proxy : un hôte, un port, votre token comme identifiant. Crawlbase Smart AI Proxy fonctionne ainsi, donc l'intégration tient en quelques lignes.
Installez la seule dépendance :
pip install requests
Faites ensuite transiter les requêtes par l'endpoint rotatif. L'exemple recherche plusieurs requêtes, varie le délai entre elles, et affiche si chacune est revenue proprement :
import requests import random import time from urllib.parse import quote_plus # One rotating endpoint swaps the exit IP per request. proxy_url = "http://[email protected]:8012" proxies = {"http": proxy_url, "https": proxy_url} headers = { "User-Agent": ( "Mozilla/5.0 (Windows NT 10.0; Win64; x64) " "AppleWebKit/537.36 (KHTML, like Gecko) " "Chrome/124.0 Safari/537.36" ), } queries = ["web scraping", "residential proxies", "serp api"] for query in queries: url = "https://www.google.com/search?q=" + quote_plus(query) resp = requests.get(url, proxies=proxies, headers=headers, verify=False) print(query, resp.status_code, "blocked" if "/sorry/" in resp.url else "ok") # Vary timing so requests do not arrive on a fixed clock. time.sleep(random.uniform(2, 5))
Remplacez _USER_TOKEN_ par le token de votre compte Crawlbase. Notez ce que le code fait au-delà de la rotation : il envoie un User-Agent réaliste, randomise l'intervalle entre les requêtes, et vérifie la redirection /sorry/ que Google utilise pour les pages de défi. Ces détails font la différence entre une rotation qui fonctionne et une rotation qui renvoie silencieusement des pages de consentement que vous analysez ensuite comme s'il s'agissait de vrais résultats.
Bonnes pratiques pour maintenir la rotation en état de marche
Quelques habitudes permettent à un scraper SERP rotatif de rester opérationnel durablement plutôt que juste pour la première heure.
- Limitez le débit par IP, pas seulement globalement. Un grand pool vous permet de maintenir un débit total élevé tout en gardant chaque adresse à un niveau raisonnable. Le pool absorbe le volume ; le taux par IP reste humain.
-
Variez le timing et les en-têtes. Des délais fixes et un seul
User-Agentstatique constituent une empreinte. Variez les deux. La rotation des User-Agents en parallèle des IPs est couverte dans comment scraper des sites sans être bloqué. -
Détectez les blocages, ne les parsez pas. Surveillez la redirection
/sorry/, le markup CAPTCHA, et les conteneurs de résultats vides. Traitez-les comme des échecs à relancer sur une nouvelle IP, pas comme des données. - Reculez si vous êtes challengé. Si les taux de blocage augmentent, ralentissez et élargissez le pool plutôt que de frapper plus fort. L'agressivité après un signalement aggrave ce signalement.
- Utilisez un navigateur uniquement quand la page en a besoin. Le HTTP pur est plus rapide et moins coûteux ; réservez le rendu headless aux types de résultats qui se chargent côté client. Le scraping web avec Python et Selenium montre cette voie.
Si votre objectif est spécifiquement le classement et la recherche de mots-clés, les proxies SEO couvre l'angle du géociblage, car les SERPs diffèrent selon les pays et l'emplacement de l'IP de sortie détermine les résultats que vous voyez.
Quand un endpoint SERP géré est préférable à votre propre rotation
Tout ce qui précède est réalisable, et pour de faibles volumes cela vaut la peine de le construire. Le coût apparaît à grande échelle. La rotation seule vous laisse gérer le reste : maintenir la santé du pool, correspondre aux empreintes TLS, résoudre ou contourner les CAPTCHAs, rendre les pages de résultats qui se chargent côté client, et relancer sur chaque défi. C'est l'essentiel d'une pile de scraping SERP, et la rotation n'en était que la première couche.
Un endpoint géré réduit tout ce travail à une seule requête. Vous envoyez une URL ou une requête ; il choisit une IP résidentielle de confiance, envoie une empreinte crédible, rend quand la page a besoin d'un navigateur, réessaie côté serveur en cas de blocage, et renvoie le résultat final. La Crawling API est conçue exactement pour ça : là où un proxy rotatif brut vous fournit une IP propre et s'arrête là, l'API absorbe les blocages et vous remet le succès. Le compromis entre les deux est exposé dans proxy backconnect vs Crawling API.
Évitez de construire la rotation de zéro. Smart AI Proxy est un endpoint unique sur un grand pool résidentiel, datacenter et mobile qui pivote par requête et réessaie en cas de blocage, de sorte que le bon type d'IP est associé à Google plutôt que vous ne vérifiez une liste. Quand les pages de résultats ont besoin d'un navigateur ou que vous préférez ne pas gérer la couche anti-bot vous-même, la Crawling API enveloppe le rendu et les relances autour du même pool. Lancez vos vraies requêtes dessus en niveau gratuit d'abord.
Points clés
- Google bloque en premier sur le volume et la réputation de l'IP. Une adresse qui envoie de nombreuses requêtes, surtout depuis une plage datacenter, est le signal à neutraliser.
- La rotation par requête est adaptée aux SERPs. La recherche n'a pas de session à conserver, donc répartissez chaque requête sur un grand pool plutôt que de rester sur une seule IP.
- Le type d'IP détermine le résultat. Le résidentiel est le choix par défaut solide pour Google ; la rotation d'IPs datacenter ne fait que les bloquer plus lentement.
- La rotation est nécessaire, mais pas suffisante. Associez-la à des en-têtes réalistes, un timing varié, la détection des blocages, et le rendu uniquement quand la page en a besoin.
- Optez pour la voie gérée quand le volume arrive. Un SERP ou une API de crawling gère les empreintes, les CAPTCHAs, le rendu et les relances que la seule rotation laisse sur vos épaules.
Foire aux questions
Pourquoi Google bloque-t-il les scrapers aussi rapidement ?
Google calibre ses défenses contre les abus pour détecter tout ce qui ne ressemble pas à un humain qui navigue. Une seule IP qui lance de nombreuses recherches par minute déclenche une limite de débit par IP, et le trafic provenant d'une plage datacenter connue part avec une faible confiance avant même la première requête. Ajoutez des en-têtes robotiques, pas de cookies et un timing identique, et le résultat est un CAPTCHA ou une page de consentement /sorry/ au bout de quelques dizaines de requêtes.
Combien de proxies me faut-il pour scraper Google de façon fiable ?
Suffisamment pour qu'aucune IP ne dépasse un taux de requêtes d'apparence humaine à votre volume cible. Il n'y a pas de chiffre fixe : cela évolue selon le nombre de requêtes par minute que vous faites tourner. Alterner entre dix IPs à fort volume ne fait que limiter ces dix IPs plus lentement, donc un grand pool rotatif, et non une poignée d'adresses statiques, est ce qui maintient chaque IP sous le radar de Google.
Quel type de proxy est le meilleur pour scraper les résultats de recherche Google ?
Les proxies résidentiels. Ils sortent par des IPs que les FAI ont assignées à de vrais foyers, de sorte qu'une requête rotative ressemble à un visiteur ordinaire plutôt qu'à un serveur. Les IPs datacenter sont reconnues par l'ASN et bloquées rapidement sur les SERPs, et le mobile offre généralement plus de confiance (et de coût) que la recherche n'en requiert. Commencez avec le résidentiel et n'escaladez que si des pages de résultats spécifiques continuent à vous défier.
Dois-je utiliser des sessions sticky ou la rotation par requête pour les SERPs ?
La rotation par requête. Les sessions sticky existent pour maintenir une identité sur un flux connecté, et la recherche Google n'a pas de connexion ni de session à préserver. Changer l'IP de sortie à chaque requête répartit vos requêtes dans le pool de sorte que chaque adresse ressemble à un utilisateur occasionnel plutôt qu'à une machine.
La rotation des proxies est-elle suffisante pour éviter les CAPTCHAs Google ?
Pas seule. La rotation neutralise la limite de débit par IP et la vérification datacenter-ASN, mais ne fait rien contre une empreinte TLS robotique, des cookies manquants ou un timing de requêtes fixe. Une IP résidentielle propre sur une requête manifestement automatisée reçoit quand même un CAPTCHA. Associez la rotation à des en-têtes réalistes, des délais variés, et une vraie empreinte de navigateur lorsque les pages se rendent côté client.
Quand un SERP ou une API de crawling est-il meilleur que construire ma propre rotation ?
Dès que le volume dépasse quelques milliers de requêtes, ou quand les pages de résultats se rendent côté client. La rotation n'est que la première couche ; vous gérez encore la santé du pool, les empreintes, la gestion des CAPTCHAs, le rendu et les relances. Un endpoint géré réduit tout cela à une seule requête : vous envoyez une requête et obtenez un résultat parsé, avec la rotation et la gestion anti-bot traitées côté serveur.
Crawlez n'importe quel site à grande échelle, sans combattre l'infrastructure.
Crawlbase gère les proxies, les empreintes et les CAPTCHA afin que votre équipe livre des pipelines de données au lieu de maintenir la plomberie de crawl. 1 000 requêtes gratuites, sans carte requise.