Scrapear Google Search sin que te bloqueen: qué pasa en realidad

“Google bloquea a los scrapers” es cierto pero demasiado vago para actuar sobre ello. Esto es lo que ocurre en realidad, en orden, cuando un script empieza a mandarle consultas automatizadas, y por qué el primer arreglo habitual (más proxies) solo retrasa el problema.

El rate limiting es por IP, y es más estricto de lo que crees

Google limita basándose en el volumen de solicitudes desde una sola dirección IP en una ventana corta. Los rangos de IP de datacenter reciben un límite notablemente más estricto que los residenciales, porque Google puede saber que una solicitud viene de AWS, Google Cloud o un proveedor de hosting en lugar de la conexión doméstica de alguien. Un puñado de solicitudes rápidas desde una IP de datacenter suele bastar para disparar un desafío. Este es el primer muro con el que choca casi todo el mundo, y por eso “simplemente añade un delay” funciona exactamente mientras tu volumen de solicitudes se mantenga trivial.

CAPTCHA y el muro de consentimiento

Superado el rate limit, la siguiente respuesta de Google no es un error, es una página distinta: un desafío CAPTCHA, o en tráfico de UE/Reino Unido, una pantalla intersticial de consentimiento de cookies que hay que aceptar antes de que se rendericen los resultados de búsqueda. Ambas rompen un script que espera organic_results al principio del HTML. Ninguna se resuelve reintentando: un CAPTCHA necesita a un humano (o un servicio de resolución de pago, que tiene su propio coste y su propio problema de fiabilidad), y un muro de consentimiento necesita una sesión que ya lo haya aceptado, lo que implica un manejo de cookies que la mayoría de scrapers no implementan.

El fingerprinting va más allá de la IP

La dirección IP es la primera señal, no la única. Los sistemas antiautomatización de Google también miran las características del handshake TLS, el orden y la integridad de los headers HTTP, señales a nivel de navegador cuando hay un navegador headless de por medio (tamaño de viewport, fuentes instaladas, cadena del renderer WebGL, si navigator.webdriver está activado), y patrones de comportamiento como solicitudes que llegan a intervalos sospechosamente regulares. Una solicitud que supera el rate limit pero tiene un header User-Agent desnudo y ninguno de los headers que enviaría una solicitud real de Chrome sigue leyéndose como automatizada. Por eso cambiar de proxies sin arreglar también el resto del fingerprint de la solicitud aporta muy poco.

La matemática de paginación que nadie presupuesta

Google ya no respeta el parámetro num=100 que antes devolvía 100 resultados en una sola solicitud. Conseguir “los 100 primeros resultados” de una consulta ahora implica diez solicitudes paginadas separadas, diez resultados por página. Si tu hoja de cálculo de seguimiento de rankings se construyó sobre la suposición antigua, tu volumen real de solicitudes, y tu exposición real a los problemas de rate limit y fingerprinting de arriba, es 10 veces lo que dice la hoja de cálculo. Esto por sí solo ha roto estimaciones de coste y planes de infraestructura escritos antes del cambio y nunca revisados.

Por qué los proxies solos no lo solucionan

Los proxies residenciales rotativos arreglan exactamente uno de los cuatro problemas de arriba: el rate limit basado en IP. No hacen nada contra las páginas de CAPTCHA que ya se dispararon, nada contra el fingerprinting de TLS y headers, y nada contra la matemática de paginación. Un pool de proxies combinado con un requests.get ingenuo y headers por defecto seguirá recibiendo desafíos, solo que desde un conjunto rotativo de IPs en lugar de una. Resolver los cuatro problemas por tu cuenta significa ejecutar un motor de navegador real (para paridad de fingerprint de TLS y JS), mantener perfiles de headers que coincidan con tráfico real, gestionar flujos de consentimiento, y pagar ancho de banda de proxy, continuamente, a medida que cambia la detección de Google. Eso es un compromiso de infraestructura permanente, no un script puntual.

La vía de la API

La alternativa es no ejecutar nada de eso tú mismo:

import requests

API_KEY = "faf_live_..."  # tu clave de 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 solicitud pasa por una infraestructura construida para gestionar rate limiting, fingerprinting y muros de consentimiento, y recibes de vuelta JSON analizado: organic_results, y people_also_ask, knowledge_graph, ads o related_searches cuando la consulta los genera. Una búsqueda cuesta 5 créditos, y las solicitudes fallidas nunca se cobran, ya que los créditos se reservan al iniciar la solicitud y se devuelven si no llega ningún resultado.

En resumen

Cuatro mecanismos distintos se suman en contra de un scraper directo: rate limits por IP, muros de CAPTCHA y consentimiento, fingerprinting más allá de la IP, y un coste de paginación que es 10 veces lo que parece sobre el papel. Un pool de proxies aborda uno de los cuatro. Si vale la pena construirlo depende de cuánto tiempo de ingeniería quieres dedicar a infraestructura de búsqueda en lugar de al producto que consume los resultados. Consulta precios para el coste en créditos a tu volumen.