Você acordou e seu scraper parou de funcionar

Se você mantém qualquer tipo de ferramenta que extrai dados do Google Search, provavelmente já percebeu: desde o final de agosto de 2026, clicar num resultado do Google não te leva mais direto ao site. Existe um intermediário agora. Um redirect silencioso, quase invisível para quem navega no Chrome, mas absolutamente destrutivo para quem faz scraping.

O nome técnico é google.com/goto. E ele mudou as regras do jogo.

Eu vi gente no Hacker News (473 pontos e quase 400 comentários) chamando isso de “a maior mudança no Google Search em anos”. Exagero? Talvez. Mas quando a SerpApi, o Semrush e basicamente toda ferramenta de SEO do planeta precisam correr pra atualizar seus parsers no mesmo dia, o recado é claro: o Google quer que você pare de raspar os resultados de busca dele.

Como funcionava antes (e por que era fácil demais)

Até agosto de 2026, os links nos resultados do Google tinham um padrão simples. O HTML de cada resultado continha algo assim:

<a href="https://www.google.com/url?q=https://exemplo.com/artigo&sa=U&ved=...">

O parâmetro q= continha a URL de destino, codificada em URL encoding padrão. Qualquer script de 5 linhas em Python conseguia extrair isso:

from urllib.parse import urlparse, parse_qs

google_url = "https://www.google.com/url?q=https://exemplo.com/artigo&sa=U&ved=..."
destino = parse_qs(urlparse(google_url).query)["q"][0]
print(destino)  # https://exemplo.com/artigo

Simples. Rápido. Uma única request ao Google, e você tinha centenas de URLs limpas. Era tão trivial que existiam bibliotecas de scraping que faziam isso em uma linha de código.

O Google sabia disso. Sabia que dezenas de milhares de scrapers rodavam 24/7, extraindo resultados de busca para alimentar ferramentas de SEO, comparadores de preço, agregadores de notícias e, mais recentemente, modelos de IA que precisam de dados frescos da web.

O que o /goto muda

Agora o HTML de um resultado do Google se parece com isso:

<a href="https://www.google.com/goto?url=CAESBgBaAFoA&ved=...">

Percebeu? O parâmetro url= não contém mais a URL real. No lugar, tem um blob codificado em um formato proprietário do Google, começando com CAES. Esse blob não é Base64 padrão. Não é URL encoding. É uma codificação interna que não pode ser revertida offline.

Quando você (ou seu navegador) acessa esse endpoint /goto, o Google faz a mágica no servidor: decodifica o blob, resolve a URL de destino e retorna um redirect HTTP 302 para o site real.

# Para descobrir a URL real, agora você precisa fazer isso:
curl -s -o /dev/null -w "%{redirect_url}" \
  "https://www.google.com/goto?url=CAESBgBaAFoA&ved=..."
# Retorna: https://exemplo.com/artigo

Parece inofensivo, certo? Uma request a mais por link. Mas pense na escala.

A matemática cruel do /goto

Antes do /goto, um scraper que queria os 100 primeiros resultados de uma busca fazia 1 request ao Google. Uma. Parseava o HTML, extraía as URLs e pronto.

Agora, o mesmo scraper precisa de 1 + 100 = 101 requests. Uma para buscar a página de resultados e mais uma para cada link, resolvendo o redirect individualmente.

Para quem raspa milhões de resultados por dia (sim, existem empresas que fazem isso), o custo em requisições multiplicou por 10x ou mais. E cada request adicional ao /goto gera tráfego identificável nos servidores do Google, facilitando a detecção e o bloqueio de bots.

Como o pessoal da Autom resumiu: “slower, noisier”. Mais lento e mais barulhento. A combinação perfeita para ser pego.

O que o Google disse oficialmente

Um porta-voz do Google deu essa declaração ao Search Engine Land:

“Nós temos um longo histórico de implementar medidas técnicas contra formas de abuso em evolução, e regularmente tomamos medidas para proteger nossos serviços e usuários.”

Tradução: “a gente fez e vai continuar fazendo”.

O Google não admitiu diretamente que o alvo principal são os scrapers, mas todo o contexto aponta pra isso. O timing não é coincidência: em dezembro de 2025, o Google processou judicialmente a SerpApi, a maior API de scraping de SERPs do mercado. O processo alegava violação de DMCA e uso não autorizado dos resultados de busca (o Google perdeu nas alegações de DMCA, mas o recado já tinha sido dado).

Além do /goto, o Google já vinha apertando o cerco nos últimos meses:

• Renderização obrigatória via JavaScript: os SERPs agora exigem execução de JS para exibir resultados. HTML puro não traz mais nada útil.
• Remoção do &num=100: o parâmetro que permitia pedir 100 resultados por página simplesmente parou de funcionar.
• Bloqueio agressivo de IPs de datacenter: proxies residenciais viraram quase obrigatórios.
• CAPTCHAs mais frequentes: qualquer padrão minimamente anômalo dispara verificação.

Quem foi afetado (spoiler: todo mundo)

Ferramentas de SEO

Semrush, Ahrefs, Moz, SE Ranking: todas essas ferramentas dependem, em algum grau, de dados extraídos dos SERPs do Google. O /goto quebrou pipelines de monitoramento de ranking que funcionavam há anos. Algumas empresas relataram que 10 a 15% dos seus crawlers passaram a exigir correções semanais por causa de mudanças no DOM do Google.

APIs de scraping

A SerpApi foi uma das primeiras a se pronunciar, publicando em 5 de setembro de 2026 que já havia corrigido o problema. A solução? Fazer a request ao /goto, ler o header Location do redirect (sem seguir o redirect) e retornar a URL final na resposta da API.

import requests

# Como as APIs de scraping resolvem o /goto
response = requests.get(
    "https://www.google.com/goto?url=CAESBgBaAFoA",
    allow_redirects=False  # Não segue o redirect
)
url_real = response.headers.get("Location")
print(url_real)  # https://exemplo.com/artigo

Outras APIs como ScrapingBee e Autom publicaram guias técnicos sobre como lidar com a mudança. A conclusão geral: não é impossível de contornar, mas adiciona custo, latência e complexidade.

Desenvolvedores independentes

Esse é o grupo mais afetado. Se você tinha um script simples em Python que monitorava rankings para um cliente ou extraía URLs do Google pra alimentar uma planilha, esse script morreu. E a correção não é trivial: além de resolver o redirect, você agora precisa lidar com fingerprinting de TLS, rotação de user agents e proxies residenciais para não ser bloqueado.

Modelos de IA

Vários LLMs e agentes de IA usam search grounding, buscando no Google em tempo real para complementar suas respostas. O /goto adiciona uma camada de complexidade na resolução de URLs, potencialmente quebrando fluxos de retrieval-augmented generation (RAG) que dependem de links do Google.

O truque do AdsBot (que pode não durar)

Uma descoberta interessante que circulou entre desenvolvedores: quando você envia uma request ao Google usando o user agent do AdsBot do próprio Google, o /goto não é aplicado. Os links voltam ao formato antigo, com URLs diretas.

curl -s -A "AdsBot-Google (+http://www.google.com/adsbot.html)" \
  "https://www.google.com/search?q=web+scraping" | grep -o 'href="[^"]*"'

Esse “bypass” existe provavelmente porque o AdsBot do Google é usado internamente para validar landing pages de anúncios, e o redirect quebraria esse fluxo. Mas confiar nesse truque é arriscado: o Google pode fechar essa porta a qualquer momento, e usar o user agent de outro serviço é, no mínimo, uma zona cinzenta.

Isso afeta SEO? Depende.

Se você é dono de um site e está preocupado com impacto em SEO: calma. O /goto é transparente para o usuário final. Quando alguém clica num resultado, o redirect acontece em milissegundos e a pessoa chega no seu site normalmente. O Google confirmou que o Search Console não é afetado, e os dados de tráfego orgânico continuam chegando como antes.

O que muda é uma coisa sutil: o preview de URL na barra de status do navegador. Antes, quando você passava o mouse sobre um resultado, via a URL real do destino. Agora, vê google.com/goto?url=.... Para o usuário consciente, isso parece estranho. Para a maioria, passa despercebido.

Do ponto de vista técnico, o link juice continua fluindo normalmente. O Google não adicionou nofollow nem mudou como o PageRank é distribuído. É puramente uma mudança na camada de apresentação dos links.

Mas tem um efeito colateral indireto: se suas ferramentas de SEO pararam de funcionar direito por causa do /goto, os dados que você usa pra tomar decisões podem estar defasados ou incorretos. Então, mesmo que o SEO “técnico” não tenha mudado, sua visibilidade sobre o que está acontecendo pode ter piorado.

O que fazer se seu scraper quebrou

Aqui vai um guia prático pra quem precisa se adaptar.

Opção 1: Resolver o redirect manualmente

import requests

def resolver_goto(goto_url):
    """Resolve uma URL google.com/goto para a URL real de destino."""
    resp = requests.get(
        goto_url,
        allow_redirects=False,
        headers={"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"}
    )
    return resp.headers.get("Location", goto_url)

# Uso
url_real = resolver_goto("https://www.google.com/goto?url=CAESBgBaAFoA&ved=...")

Funciona, mas cada chamada é uma request extra ao Google que pode disparar rate limiting.

Opção 2: Usar uma API de SERP

Se volume é um problema, considere usar uma API dedicada como SerpApi, ScrapingBee ou Autom. Essas APIs já lidam com o /goto internamente e retornam URLs limpas. O custo mensal pode compensar comparado ao tempo gasto mantendo seu próprio scraper.

Opção 3: Mudar de fonte

Para alguns use cases, o Google não é a única opção. O Bing, o DuckDuckGo e o Brave Search ainda oferecem resultados com URLs diretas. Se você não precisa especificamente dos rankings do Google, pode ser hora de diversificar.

# DuckDuckGo ainda retorna URLs diretas
import requests

resp = requests.get(
    "https://html.duckduckgo.com/html/?q=web+scraping",
    headers={"User-Agent": "Mozilla/5.0"}
)
# Parse normalmente, sem redirects intermediários

Opção 4: Google Custom Search API (com prazo de validade)

O Google oferece a Custom Search JSON API, que retorna resultados estruturados sem o /goto. Mas atenção: o Google anunciou que essa API está fechada para novos clientes, e os existentes têm até 1 de janeiro de 2027 para migrar. Então essa opção tem data de expiração.

O panorama maior: a web aberta está encolhendo

O /goto é mais um capítulo numa tendência que vem se acelerando. O Google, que construiu seu império indexando a web aberta, agora blinda cada vez mais o acesso aos dados que ele coleta. Primeiro veio o fim do &num=100. Depois, a renderização obrigatória via JavaScript. Agora, o /goto.

Para quem trabalha com dados da web, a mensagem é clara: depender de uma única fonte (especialmente do Google) é um risco crescente. A diversificação de fontes de dados não é mais uma boa prática, é uma necessidade.

E pra quem acompanha o Hacker News, a ironia não passou despercebida. O Google, que literalmente começou como um web crawler, agora investe pesado em impedir que outros façam o mesmo. Como um comentário com 200+ upvotes resumiu: “o Google construiu um castelo usando pedras da estrada pública, e agora está fechando a estrada.”

Alternativas que estão ganhando tração

Com o Google dificultando cada vez mais o acesso, algumas alternativas estão crescendo:

Nenhuma dessas é um substituto perfeito para o Google. Mas juntas, formam uma estratégia mais resiliente do que depender de um único ponto de falha que muda as regras quando bem entende.

A era do scraping fácil no Google acabou. Quem se adaptar primeiro, ganha. Quem insistir nos scripts de 2024, vai continuar acordando com o scraper quebrado.

O código do seu crawler está pedindo um refactor. A questão é se você vai fazer isso agora ou quando o próximo bloqueio vier.

Fonte de inspiração: google.com/goto: Google’s anti-scraping update (Autom)