Fazer scraping do Google Search sem ser bloqueado: o que realmente acontece

“O Google bloqueia scrapers” é verdade, mas vago demais para agir. Aqui está o que realmente acontece, em ordem, quando um script começa a mandar buscas automatizadas para ele, e por que a primeira correção habitual (mais proxies) só adia o problema.

Rate limiting é por IP, e é mais rígido do que você imagina

O Google limita com base no volume de requisições de um único endereço de IP em uma janela curta de tempo. Faixas de IP de datacenter recebem um limite visivelmente mais apertado que as residenciais, porque o Google consegue identificar que a requisição vem da AWS, do Google Cloud, ou de um provedor de hospedagem, em vez da conexão doméstica de alguém. Um punhado de requisições rápidas de um único IP de datacenter já costuma bastar para disparar um desafio. Esse é o primeiro muro que quase todo mundo esbarra, e é por isso que “só coloca um delay” funciona exatamente enquanto seu volume de requisições continuar irrelevante.

CAPTCHA e o muro de consentimento

Depois do rate limit, a próxima resposta do Google não é um erro, é uma página diferente: um desafio de CAPTCHA, ou, em tráfego da UE/Reino Unido, uma tela intersticial de consentimento de cookies que precisa ser aceita antes dos resultados de busca aparecerem. Ambos quebram um script que espera organic_results no topo do HTML. Nenhum dos dois se resolve tentando de novo: um CAPTCHA precisa de um humano (ou de um serviço pago de resolução, que é um custo à parte e um problema de confiabilidade à parte), e um muro de consentimento precisa de uma sessão que já o aceitou, o que significa manejo de cookies que a maioria dos scrapers não implementa.

O fingerprinting vai além do IP

O endereço IP é o primeiro sinal, não o único. Os sistemas antiautomação do Google também olham para características do handshake TLS, ordem e completude dos headers HTTP, sinais de nível de navegador quando um navegador headless está envolvido (tamanho de viewport, fontes instaladas, string do renderizador WebGL, se navigator.webdriver está definido), e padrões comportamentais como requisições chegando em intervalos suspeitosamente regulares. Uma requisição que passa pelo rate limit mas tem um header User-Agent básico e nenhum dos headers que uma requisição real do Chrome enviaria ainda assim é lida como automatizada. É por isso que trocar de proxies sem também corrigir o resto do fingerprint da requisição resolve muito pouco.

A matemática da paginação que ninguém coloca no orçamento

O Google não respeita mais o parâmetro num=100 que costumava retornar 100 resultados em uma única requisição. Conseguir “os 100 melhores resultados” para uma busca agora significa dez requisições paginadas separadas, dez resultados por página. Se sua planilha de rastreamento de ranking foi montada em torno da suposição antiga, seu volume real de requisições, e sua exposição real aos problemas de rate limit e fingerprinting acima, é 10x o que a planilha diz. Isso sozinho já quebrou estimativas de custo e planos de infraestrutura escritos antes dessa mudança e nunca revisados.

Por que só proxies não resolvem

Proxies residenciais rotativos corrigem exatamente um dos quatro problemas acima: o rate limit baseado em IP. Eles não fazem nada contra páginas de CAPTCHA já disparadas, nada contra fingerprinting de TLS e headers, e nada contra a matemática da paginação. Um pool de proxies combinado com um requests.get ingênuo e headers padrão ainda vai ser desafiado, só que a partir de um conjunto rotativo de IPs em vez de um único. Resolver os quatro problemas por conta própria significa rodar um motor de navegador de verdade (para paridade de fingerprint de TLS e JS), manter perfis de header que combinem com tráfego real, lidar com fluxos de consentimento, e pagar por banda de proxy, continuamente, conforme a detecção do Google muda. Isso é um compromisso permanente de infraestrutura, não um script de uma vez só.

O caminho da API

A alternativa é não rodar nada disso você mesmo:

import requests

API_KEY = "faf_live_..."  # sua chave 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"])

A requisição passa por infraestrutura construída para lidar com rate limiting, fingerprinting e muros de consentimento, e você recebe JSON já parseado de volta: organic_results, e people_also_ask, knowledge_graph, ads ou related_searches quando a busca os gera. Uma busca custa 5 créditos, e requisições falhas nunca são cobradas, já que os créditos são reservados quando a requisição começa e devolvidos se nenhum resultado voltar.

Resumindo

Quatro mecanismos separados se somam contra um scraper bruto: rate limits por IP, muros de CAPTCHA e consentimento, fingerprinting além do IP, e um custo de paginação que é 10x o que parece no papel. Um pool de proxies resolve um dos quatro. Se vale a pena construir isso depende de quanto do seu tempo de engenharia você quer gastar em infraestrutura de busca em vez de no produto que consome os resultados. Veja preços para o custo em créditos no seu volume.