Scraper Google Search sans se faire bloquer : ce qui se passe réellement

« Google bloque les scrapers » est vrai mais trop vague pour agir. Voici ce qui se passe réellement, dans l’ordre, quand un script commence à lui envoyer des requêtes automatisées, et pourquoi le premier réflexe habituel (plus de proxies) ne fait que retarder le problème.

La limitation de débit est par IP, et elle est plus stricte qu’on ne le pense

Google régule en fonction du volume de requêtes provenant d’une seule adresse IP dans une courte fenêtre. Les plages d’IP de datacenter reçoivent une limite nettement plus stricte que les IP résidentielles, parce que Google peut déterminer qu’une requête vient d’AWS, de Google Cloud ou d’un hébergeur plutôt que de la connexion personnelle de quelqu’un. Une poignée de requêtes rapides depuis une IP de datacenter suffit souvent à déclencher un défi. C’est le premier mur que presque tout le monde rencontre, et c’est pourquoi « ajoutez juste un délai » fonctionne exactement tant que votre volume de requêtes reste anecdotique.

CAPTCHA et le mur de consentement

Au-delà de la limite de débit, la réponse suivante de Google n’est pas une erreur, c’est une page différente : un défi CAPTCHA, ou pour le trafic UE/UK, un interstitiel de consentement aux cookies qui doit être accepté avant même que les résultats de recherche s’affichent. Les deux cassent un script qui attend organic_results en haut du HTML. Aucun des deux ne se résout en réessayant : un CAPTCHA nécessite un humain (ou un service de résolution payant, qui a son propre coût et son propre problème de fiabilité), et un mur de consentement nécessite une session qui l’a déjà accepté, ce qui implique une gestion des cookies que la plupart des scrapers n’implémentent pas.

Le fingerprinting va au-delà de l’IP

L’adresse IP est le premier signal, pas le seul. Les systèmes anti-automatisation de Google examinent aussi les caractéristiques de la poignée de main TLS, l’ordre et l’exhaustivité des en-têtes HTTP, des signaux au niveau du navigateur quand un navigateur headless est impliqué (taille du viewport, polices installées, chaîne de rendu WebGL, si navigator.webdriver est défini), et des schémas comportementaux comme des requêtes arrivant à des intervalles suspicieusement réguliers. Une requête qui passe la limite de débit mais a un en-tête User-Agent nu et aucun des en-têtes qu’une vraie requête Chrome enverrait se lit toujours comme automatisée. C’est pourquoi changer de proxies sans corriger aussi le reste de l’empreinte de la requête n’apporte que très peu.

Le calcul de pagination que personne ne budgétise

Google n’honore plus le paramètre num=100 qui renvoyait autrefois 100 résultats en une seule requête. Obtenir « les 100 premiers résultats » pour une requête signifie désormais dix requêtes paginées séparées, dix résultats par page. Si votre tableur de suivi de classement a été construit autour de l’ancienne hypothèse, votre volume réel de requêtes, et votre exposition réelle aux problèmes de limite de débit et de fingerprinting ci-dessus, est 10 fois ce que dit le tableur. Cela seul a cassé des estimations de coût et des plans d’infrastructure écrits avant le changement et jamais revus.

Pourquoi les proxies seuls ne résolvent pas le problème

Les proxies résidentiels rotatifs corrigent exactement un des quatre problèmes ci-dessus : la limite de débit basée sur l’IP. Ils ne font rien contre les pages CAPTCHA déjà déclenchées, rien contre le fingerprinting TLS et des en-têtes, et rien contre le calcul de pagination. Un pool de proxies associé à un requests.get naïf et des en-têtes par défaut se fera quand même défier, simplement depuis un ensemble d’IP rotatif au lieu d’une seule. Résoudre les quatre problèmes vous-même signifie faire tourner un vrai moteur de navigateur (pour la parité d’empreinte TLS et JS), maintenir des profils d’en-têtes qui correspondent au trafic réel, gérer les flux de consentement, et payer pour de la bande passante proxy, en continu, à mesure que la détection de Google évolue. C’est un engagement d’infrastructure permanent, pas un script ponctuel.

La voie de l’API

L’alternative est de ne rien faire tourner de tout cela vous-même :

import requests

API_KEY = "faf_live_..."  # votre clé FastAF

resp = requests.get(
    "https://api.fastaf.co/v1/serp",
    params={"query": "web scraping api", "country": "us"},
    headers={"Authorization": f"Bearer {API_KEY}"},
    timeout=60,
)
resp.raise_for_status()

for result in resp.json()["organic_results"]:
    print(result["rank"], result["title"], result["link"])

La requête passe par une infrastructure conçue pour gérer la limitation de débit, le fingerprinting et les murs de consentement, et vous récupérez du JSON parsé en retour : organic_results, et people_also_ask, knowledge_graph, ads ou related_searches quand la requête les produit. Une recherche coûte 5 crédits, et les requêtes échouées ne sont jamais facturées, puisque les crédits sont réservés quand la requête démarre et rendus si aucun résultat ne revient.

En bref

Quatre mécanismes distincts s’accumulent contre un scraper brut : les limites de débit par IP, les CAPTCHA et murs de consentement, le fingerprinting au-delà de l’IP, et un coût de pagination 10 fois supérieur à ce qu’il paraît sur le papier. Un pool de proxies traite un seul des quatre. Que cela vaille la peine d’être construit dépend de la quantité de temps d’ingénierie que vous voulez consacrer à l’infrastructure de recherche plutôt qu’au produit qui consomme les résultats. Voir les tarifs pour le coût en crédits à votre volume.