google.com/goto: o anti-scraping do Google
O que está a acontecer
O Google Search está a reescrever os links dos resultados orgânicos para google.com/goto?url=... em vez de expor a URL de destino diretamente no HTML.
Ao clicar, o Google redireciona para a página real. O parâmetro url usa uma codificação própria do Google. Não é um base64 simples da URL alvo. Na prática, parece uma referência opaca ao registo da página no índice Google.
Em finais de agosto de 2026, isto aparece de forma consistente em pesquisas com sessão terminada ou em modo privado. Pode ainda ser uma experiência, mas já não se limita a uma pequena fatia de SERP.
Não é o mesmo que google.com/url
O Google já usava wrappers de redirecionamento. O formato antigo é google.com/url?q=[URL codificada], onde o link de destino é legível na query string.
O novo formato goto é diferente:
- O
hrefdo resultado é/goto, não o destino - Não se consegue descodificar o blob
url=offline - A URL real está no cabeçalho
Locationde/goto. Peça essa URL. Não siga o redirecionamento.
O Google precisa na mesma do destino para desenhar a SERP (domínio, favicon, atribuição), por isso cópias da URL ficam na página. Isso é outra história do que ler Location. Como resolver: google.com/goto: ler Location com HEAD.
Esta mudança importa para quem constrói um índice de pesquisa a partir de dados SERP em escala.
Por que o Google faz isto
Encaixa na ofensiva mais ampla do Google contra a recolha automatizada de SERP, especialmente crawlers de IA e scrapers SEO que extraem URLs de resultados em massa para criar os seus próprios índices.
Com links em texto simples, um scraper podia parsear milhares de URLs do HTML sem voltar a contactar o Google. Com goto, cada resultado precisa de outro pedido ao Google só para saber o destino. Lê-se Location; não se segue até à página. É mais lento, mais ruidoso e dá ao Google um sinal claro quando o mesmo cliente resolve centenas de links seguidos.
Junto com movimentos anteriores como remover &num=100 e endurecer BotGuard/SearchGuard, o Google aumenta o custo do scraping SERP ingénuo.
O que vimos na Autom
Detetámos links goto primeiro numa pequena percentagem de SERP. A esse nível, era difícil lançar um fix fiável sem quebrar respostas para todos os outros.
Em finais de agosto de 2026, o padrão é muito mais consistente em sessões terminadas e privadas. As URLs de resultados no Google Search são efetivamente todas goto nessas condições.
Continuamos a monitorizar o rollout e a testar contra isto.
Atualização na Autom.dev
Atualizámos o nosso pipeline Google Search para resolver links google.com/goto (ler Location, sem seguir) e devolver a URL de destino final nas respostas API, nos mesmos campos estruturados que os clientes já usam.
Se chamar os endpoints Google Search da Autom, deve continuar a receber URLs de destino utilizáveis sem alterar a integração. Continuaremos a acompanhar o rollout do Google e a ajustar se o formato de redirecionamento mudar novamente.
Leituras relacionadas
- google.com/goto: ler Location com HEAD
- Google eliminou num=100
- Google processa SerpAPI: o que SearchGuard revela
- Scraping SERP com Google, Bing e Brave
Precisa de dados SERP live enquanto o Google muda as regras? Experimente 1.000 pedidos grátis nos preços Autom, ou obtenha uma chave API em app.autom.dev/register.