Google.com/goto: atualização anti-scraping do Google torna cada resultado mais difícil de extrair

O Google adicionou uma solicitação extra entre os resultados de busca e as páginas de destino, criando um conflito direto com ferramentas que coletam URLs de resultados em escala. A mudança, conhecida como google.com/goto: atualização anti-scraping do Google, substitui muitos links orgânicos diretos por endereços opacos de redirecionamento do Google.

O resultado de busca continua parecendo familiar para uma pessoa. Seu título, domínio exibido, favicon e descrição permanecem visíveis. No entanto, o link subjacente agora pode apontar para google.com/goto?url=... em vez da página do editor.

Essa distinção importa porque o valor codificado não expõe a URL de destino completa. Um navegador pode pedir ao Google que a resolva automaticamente. Um scraper precisa fazer outra solicitação, processar a resposta e evitar acionar as defesas do Google.

O Google descreve a implementação como uma medida técnica contra abusos. A mudança não bloqueia completamente a coleta automatizada. Em vez disso, transforma uma tarefa barata de análise de HTML em uma sequência mais ruidosa de solicitações que o Google consegue observar.

Este é o conflito central. Usuários de busca ainda precisam de links de saída confiáveis, enquanto o Google busca maior controle sobre o acesso automatizado aos seus resultados. Empresas de APIs de SERP, plataformas de SEO, pesquisadores e desenvolvedores de IA agora atuam dentro dessa tensão.

Google.com/goto: atualização anti-scraping do Google altera a camada de links

O Google não mudou o que um resultado orgânico exibe, mas mudou como o software chega ao destino do resultado.

Um resultado tradicional do Google inseria a página de destino diretamente no atributo href do elemento âncora. Um software podia baixar uma página de resultados de busca, analisar seu HTML e extrair várias URLs completas.

A nova estrutura insere um redirecionamento controlado pelo Google. A âncora do resultado pode apontar para um endereço /goto contendo um valor que frequentemente começa com CAES. Esse valor representa o destino sem publicá-lo como texto legível.

Quando uma pessoa clica no resultado, o navegador solicita o endereço /goto. O Google então retorna um redirecionamento HTTP que envia o navegador para a página real. A transição normalmente é rápida demais para que o usuário perceba.

O Google confirmou a implementação em 26 de agosto de 2026. Um porta-voz afirmou que a empresa regularmente adota medidas técnicas contra abusos em evolução para proteger seus serviços e usuários. A confirmação descreveu o redirecionamento como uma dessas medidas.

A empresa não publicou uma especificação técnica para o token. Também não explicou todos os sinais que determinam quais navegadores, regiões ou sessões recebem os links reescritos.

Observações iniciais surgiram antes da confirmação. Especialistas em busca relataram o padrão em junho e julho, quando ele ainda parecia um teste limitado. No fim de agosto, vários provedores de dados observavam uma implementação muito mais ampla.

A confirmação da implementação relatou cobertura quase completa entre diversos provedores de IPs residenciais. Essa estimativa veio de Derek Perkins, da empresa de monitoramento de rankings Nozzle, e não do Google.

A Autom, provedora de APIs de dados de busca, relatou uma progressão semelhante. Sua equipe encontrou /goto inicialmente em uma pequena parcela das páginas de resultados. Depois, passou a ver o formato de forma consistente em sessões desconectadas e de navegação privada.

O relato técnico do provedor afirma que o parâmetro opaco não pode ser convertido no destino por meio de decodificação local comum. O destino chega, em vez disso, pela resposta de redirecionamento.

Esse formato difere do wrapper /url mais antigo do Google. Esse wrapper frequentemente incluía um destino legível e codificado em URL na sua string de consulta. O software podia extrair esse valor sem contatar o Google novamente.

Com /goto, o resultado visível da busca e o destino acionável tornam-se partes separadas dos dados. O Google ainda exibe informações suficientes para que uma pessoa avalie o resultado. No entanto, o código-fonte da página já não garante uma URL de saída reutilizável.

Essa é a mudança relevante. O Google transferiu a resolução do destino do HTML estático para uma interação com seu próprio servidor.

Por que um redirecionamento extra pressiona os provedores de dados de busca

O redirecionamento cria um custo marginal para cada resultado resolvido, e esse custo se acumula em sistemas de coleta de alto volume.

Um scraper básico antes precisava de uma solicitação para coletar vários destinos orgânicos de uma página de resultados. No novo formato, ele pode precisar da solicitação original mais uma solicitação de resolução para cada token /goto único.

Considere um serviço que monitora muitas consultas em diferentes locais, dispositivos e idiomas. Ele pode coletar várias páginas para cada consulta e repetir essa coleta ao longo do dia. Uma solicitação extra por resultado rapidamente se torna um trabalho substancial de infraestrutura.

O custo não se limita à largura de banda. Cada resolução adiciona latência, gerenciamento de conexões, lógica de repetição e outra oportunidade de falha. Também cria um fluxo identificável de solicitações direcionadas ao endpoint de redirecionamento do Google.

O Google pode observar com que rapidez um cliente resolve links. Pode comparar essas solicitações com cookies, identidades de rede, características do navegador e atividades de busca anteriores. O Google não divulgou quais sinais utiliza nesse caso.

Isso torna a atualização mais do que um novo formato de análise. Ela cria um ponto de controle no servidor entre a obtenção da página de resultados e o conhecimento de cada destino exato.

O monitoramento tradicional de rankings ilustra a pressão. Um rastreador de posições precisa identificar qual página é ranqueada para uma consulta, e não apenas qual domínio aparece. Caminhos exatos importam quando um site tem várias páginas competindo pelo mesmo tema.

Uma ferramenta que armazena o redirecionamento do Google em vez da URL do editor pode produzir registros enganosos. Ela pode relatar resultados ausentes, mesclar páginas distintas ou fazer mudanças de landing page parecerem alterações de ranking.

As APIs de busca enfrentam um problema relacionado. Seus clientes esperam URLs de destino limpas e estruturadas. Esses clientes não deveriam precisar entender o wrapper de links atual do Google nem reescrever suas integrações sempre que o formato mudar.

A Autom afirma que modificou seu pipeline para resolver links /goto enquanto preserva seus campos de resposta existentes. Essa abordagem transfere a responsabilidade de compatibilidade dos clientes da API para o provedor de dados.

Essa correção ainda depende de o serviço de redirecionamento do Google permanecer disponível ao coletor. Também pressupõe que o comportamento atual da resposta permanecerá estável. O Google não assumiu compromisso com nenhuma dessas condições.

Produtos de busca e pesquisa com IA enfrentam outra forma de pressão. Alguns sistemas usam APIs comerciais de busca, enquanto outros coletam páginas de resultados por meio de sua própria infraestrutura. Ambas as abordagens dependem de acesso previsível às URLs de origem.

O redirecionamento não impede um modelo de ler um destino depois que alguém o fornece. Ele afeta o processo de descoberta anterior, que encontra, classifica e recupera fontes antes do início da análise.

Profissionais do conhecimento podem encontrar o efeito indiretamente. Um assistente de pesquisa pode deixar de encontrar fontes quando seu conector de busca lida incorretamente com URLs de redirecionamento. Ele também pode armazenar wrappers do Google onde os usuários esperam links estáveis de editores.

Isso torna a proveniência mais difícil de inspecionar. Um registro de pesquisa confiável deve preservar a página que sustentou uma alegação, e não um endereço temporário de roteamento pertencente ao mecanismo de busca.

Portanto, equipes que desenvolvem sistemas internos de pesquisa devem manter a identidade da fonte separada dos metadados de descoberta. Uma base de conhecimento com IA pesquisável permanece útil apenas quando suas citações levam a documentos duráveis.

A pressão imediata recai sobre intermediários de dados de busca. O risco subsequente alcança qualquer produto que trate sua saída como infraestrutura confiável de fontes.

A disputa real é entre resultados abertos e resolução controlada

O Google ainda publica uma página de resultados legível, mas controla cada vez mais as ações necessárias para transformar essa página em dados reutilizáveis.

Isso não é simplesmente Google contra uma empresa de scraping. A disputa principal ocorre entre dois modelos técnicos de acesso a resultados de busca voltados ao público.

O primeiro modelo trata uma página de resultados como um documento. Um cliente a baixa, lê os links incorporados ao HTML e decide o que fazer em seguida. Grande parte da web inicial funcionava por meio desse padrão simples.

O segundo modelo trata os resultados como um serviço interativo. O que o usuário vê permanece acessível, mas valores importantes se tornam disponíveis apenas por solicitações adicionais regidas pela plataforma.

A implementação de /goto aproxima o Google Search do segundo modelo. Isso ocorre sem remover resultados orgânicos ou obrigar usuários comuns a adotar um novo fluxo de trabalho.

Essa sutileza é importante. Chamar a atualização de proibição de scraping exagera seu efeito. Os links continuam resolvíveis, e testes independentes mostram que os desenvolvedores ainda podem recuperar seus destinos.

A ScrapingBee testou /goto em navegadores, sessões automatizadas e configurações de rede. Seus experimentos de redirecionamento concluíram que o token podia ser decodificado estruturalmente, mas não convertido localmente na URL original.

A empresa relatou que uma solicitação HTTP GET com redirecionamentos automáticos desativados retornava uma resposta 302 e um cabeçalho Location. Esse cabeçalho continha o endereço de destino.

Seus testes também concluíram que solicitações HEAD se comportavam de modo diferente. Elas retornavam respostas 200 sem o cabeçalho de localização necessário, obrigando os coletores a usar GET para uma resolução confiável.

Essa constatação entra em conflito com a recomendação inicial da Autom de ler a localização usando HEAD. A diferença pode refletir comportamento em mudança, condições de teste ou múltiplas variantes da implementação.

Os desenvolvedores não devem tratar nenhum dos métodos como um contrato permanente. Uma implementação defensiva pode testar o comportamento das respostas, oferecer suporte a mais de um wrapper e registrar falhas sem corromper as URLs armazenadas.

A ScrapingBee mediu 50 resoluções com uma mediana de cerca de 3,27 segundos quando processadas sequencialmente. Cinco workers reduziram a mediana para cerca de 1,23 segundos em seu ambiente.

Esses números vêm dos testes de um fornecedor, não de uma referência universal. Localização de rede, reutilização de conexões, respostas do Google e limitação de tráfego podem produzir resultados diferentes.

Ainda assim, o experimento esclarece a contrapartida. A atualização adiciona atrito, mas uma concorrência moderada pode absorver parte dele. Isso torna a medida mais propensa a remodelar custos do que a eliminar o scraping.

A interação com o servidor também dá ao Google opções que links estáticos não ofereciam. Ele pode ajustar respostas, alterar formatos de token, aplicar controles de taxa ou diferenciar tipos de clientes.

O Google já controla a própria página de resultados de busca. No entanto, URLs de saída diretas limitavam o envolvimento da empresa depois que um cliente recebia o HTML. /goto estende esse envolvimento à resolução do destino.

A mudança segue outros esforços que complicaram a coleta em larga escala. O Google reforçou as defesas contra tráfego automatizado e alterou parâmetros de páginas de resultados que os coletores usavam anteriormente para conjuntos maiores de resultados.

Cada ajuste individual pode ser contornado por engenharia. Juntos, eles tornam o acesso não oficial menos previsível e aumentam o valor de uma infraestrutura de coleta mantida.

Essa mudança também expõe uma simetria incômoda. O Google constrói seu índice ao rastrear outros sites, enquanto restringe sistemas automatizados que coletam a apresentação desse índice feita pelo Google.

As atividades não são idênticas. O Googlebot segue controles dos editores, constrói um produto de busca e opera sob sistemas de rastreamento documentados. Scrapers de SERP coletam páginas de classificação geradas pelo Google, frequentemente fora de uma relação com uma API compatível.

Ainda assim, editores e desenvolvedores percebem o desequilíbrio. O Google espera que a web aberta permaneça tecnicamente acessível enquanto torna sua própria camada de agregação progressivamente mais difícil de reutilizar.

Uma discussão na comunidade muito comentada refletiu essa disputa. Ela atraiu 472 pontos e 369 comentários no recorte fornecido para esta reportagem.

Alguns participantes consideraram a atualização uma proteção razoável do serviço. Outros a descreveram como mais um cercamento em torno de informações derivadas de sites públicos. Vários se concentraram no desafio prático de engenharia em vez do argumento de política.

A interpretação mais sólida fica entre essas posições. O Google não fechou seus resultados de busca, mas tornou a reutilização em alto volume mais dependente de interações controladas pelo Google.

A Atualização Cria Atrito, Não um Bloqueio Completo de Scraping

A maior incerteza é se `/goto` continuará sendo um formato de redirecionamento administrável ou se se tornará uma camada em um sistema de aplicação mais rígido.

O mecanismo atual tem limites visíveis. Um scraper pode solicitar cada redirecionamento e ler seu destino. Algumas cópias da URL subjacente também podem permanecer em outras partes da página renderizada.

O Google precisa de informações de destino para exibir domínios, favicons, breadcrumbs e atribuição. Dependendo do formato do resultado, os coletores podem reconstruir parte da identidade sem resolver todos os links.

Isso nem sempre produz a página de destino exata. Um domínio exibido não consegue distinguir uma página de produto de um artigo de suporte no mesmo site. O texto do breadcrumb também pode omitir parâmetros ou componentes do caminho.

A implementação tampouco é uniforme. A ScrapingBee relatou /goto no Chrome, Edge, Playwright e em seu próprio ambiente de coleta. Brave e LibreWolf retornaram links diretos durante o mesmo esforço de teste.

O Safari retornou outro wrapper do Google, em vez do mesmo formato /goto. Alterar a localização do proxy não removeu o redirecionamento de forma confiável.

Esses resultados sugerem variação por cliente, mas não revelam as regras de seleção do Google. O tipo de navegador pode se correlacionar com o resultado sem causá-lo diretamente.

Os tokens também pareceram portáveis nos testes da ScrapingBee. Tokens coletados por uma conexão podiam ser resolvidos posteriormente por outro cliente, sem os cookies ou proxy originais.

Eles permaneceram utilizáveis por mais de 24 horas nesses experimentos. Sua vida útil máxima continua desconhecida, e o Google pode alterar as regras de portabilidade ou expiração sem aviso.

Essa incerteza deve orientar decisões de engenharia. Um coletor de produção não deve armazenar tokens opacos como se fossem identificadores permanentes. Ele deve resolver e validar destinos perto do momento da coleta.

Também deve preservar o wrapper original para fins de diagnóstico. Manter ambos os valores ajuda as equipes a distinguir uma mudança de classificação de uma falha no resolvedor ou de uma nova variante de resposta do Google.

As tentativas precisam de limites cuidadosos. Uma resolução agressiva pode amplificar o padrão de solicitações que a mudança aparentemente busca expor. Tentativas ilimitadas também podem gerar custos maiores durante interrupções parciais.

Os sistemas de coleta devem eliminar duplicatas de tokens idênticos antes de resolvê-los. A ScrapingBee encontrou tokens repetidos em algumas páginas de resultados, tornando evitáveis solicitações duplicadas desnecessárias.

Os provedores também precisam de monitoramento em vários limites. Eles devem acompanhar a proporção de resultados que usam cada wrapper, taxas de sucesso de resolução, códigos de resposta e distribuições de latência.

Um aumento repentino de URLs do Google na saída do cliente é um incidente de parsing, não evidência de que os editores desapareceram da busca. Separar essas condições evita falsos alarmes de classificação.

As equipes de analytics têm uma pergunta diferente. Elas querem saber se o redirecionamento altera a atribuição de referência quando uma pessoa chega ao site de um editor.

Um redirecionamento no servidor ainda pode levar ao destino esperado preservando sinais de referência utilizáveis. A atribuição real depende do comportamento do navegador, dos cabeçalhos, da configuração de analytics e da implementação do Google.

Não há base verificada para afirmar que a implementação destrói amplamente a atribuição orgânica. Operadores de sites devem inspecionar suas próprias solicitações de landing page e classificações de analytics antes de tirar essa conclusão.

A orientação geral do Google sobre redirecionamentos explica como seu crawler interpreta tipos comuns de redirecionamento. Ela não documenta /goto como uma superfície pública de integração para coletores de terceiros.

Essa diferença importa. A documentação do Google Search Central informa aos editores como redirecionar suas próprias páginas. Ela não promete comportamento estável para os wrappers de saída da busca do Google.

Os usuários enfrentam uma contrapartida menor, mas real. Passar o cursor sobre um resultado pode revelar um endereço do Google em vez do destino completo. O domínio exibido ainda fornece contexto, mas a prévia de status do navegador se torna menos informativa.

Isso pode enfraquecer uma verificação de segurança conhecida. Um usuário cauteloso pode querer inspecionar o destino exato antes de abri-lo, especialmente quando várias páginas compartilham títulos semelhantes.

O Google pode argumentar que seus rótulos de domínio visíveis e proteções contra abuso continuam eficazes. Os críticos podem responder, de forma razoável, que um rótulo controlado pela plataforma não é idêntico a inspecionar o link real.

Nenhuma das preocupações prova que a implementação prejudica a maioria dos usuários. Ela mostra que medidas anti-automação podem alterar a transparência mesmo quando a experiência de clique parece inalterada.

As evidências atuais sustentam uma conclusão restrita. /goto aumenta os custos de coleta, quebra parsers simplistas e amplia o controle do Google sobre a resolução de destinos.

Elas não sustentam a afirmação mais forte de que o Google tornou o scraping de busca impossível. Os provedores já demonstraram caminhos de resolução funcionais, embora esses caminhos tragam novos riscos operacionais.

O Que a Atualização Anti-Scraping do Google Obriga as Equipes a Monitorar em Seguida

Três sinais determinarão se isso se torna uma atualização rotineira de parser ou uma mudança duradoura na economia dos dados de busca.

O primeiro sinal é a cobertura do formato de links. Os provedores devem medir com que frequência URLs diretas, wrappers /url e tokens /goto aparecem em navegadores, regiões e estados de sessão.

Uma combinação estável reforçaria a visão de que o Google opera um sistema de controle segmentado. Um movimento rápido rumo a links /goto universais reforçaria a interpretação anti-scraping.

Uma reversão para links diretos enfraqueceria a conclusão mais ampla. Ela sugeriria que problemas de compatibilidade, preocupações dos usuários ou resultados experimentais superaram o controle adicional.

O segundo sinal é o comportamento do resolvedor. As equipes devem acompanhar se uma simples solicitação GET continua retornando um cabeçalho 302 Location utilizável sem uma sessão de navegador.

Se essa rota continuar disponível, provedores experientes poderão tratar a atualização como um custo adicional de infraestrutura. Scrapers básicos deixarão de funcionar, mas sistemas mantidos poderão continuar operando.

Novos requisitos de autenticação, curta duração de tokens, limites rígidos de taxa ou tokens vinculados ao cliente aumentariam materialmente a barreira. Eles indicariam que o Google está reforçando o ponto de controle, em vez de apenas reescrever links.

Mudanças no comportamento de HEAD e GET também merecem atenção. Os relatos iniciais conflitantes mostram por que os provedores precisam de testes diretos, em vez de depender de uma única receita de implementação.

O terceiro sinal é a qualidade dos dados em produtos de SEO e IA. Os clientes devem observar páginas de destino ausentes, URLs do Google duplicadas, volatilidade inexplicada de classificação ou citações que param em wrappers de redirecionamento.

Esses sintomas mostrariam que alguns provedores não se adaptaram completamente. Uma saída estável sugeriria que os fornecedores absorveram a mudança sem transferir grande parte do ônus aos clientes.

Compradores de dados de busca devem fazer perguntas concretas aos fornecedores. O serviço retorna o destino final? Preserva parâmetros canônicos? Como rotula resultados não resolvidos?

Eles também devem perguntar se as posições reportadas mudaram por causa do formato dos links. Uma ferramenta de classificação deve separar erros de coleta de movimentos reais na ordenação do Google.

As equipes de produtos de IA precisam de verificações semelhantes em torno de citações. Cada afirmação recuperada deve se conectar à URL final do editor, com falhas de coleta visíveis aos operadores.

A próxima declaração pública do Google também importa, embora a empresa possa oferecer poucos detalhes adicionais. Uma explicação formal sobre proteção do usuário ou categorias de abuso reduziria o debate sobre a intenção.

A declaração atual confirma que /goto é uma medida de proteção. Ela não diz se crawlers de IA, ferramentas de SEO, medição de cliques ou outra classe de abuso motivaram o design.

Conflitos legais podem fornecer mais contexto. O Google contestou algumas empresas que coletam e revendem resultados de busca, mostrando que controles técnicos coexistem com pressão legal.

No entanto, /goto afeta uma gama mais ampla de clientes do que qualquer réu isolado. Pesquisadores, ferramentas de acessibilidade, extensões de navegador e sistemas internos de monitoramento podem encontrar os mesmos wrappers.

Os próximos meses revelarão se o Google distingue esses usos. Restrições uniformes favoreceriam provedores centralizados de dados capazes de manter grandes sistemas de resolução.

O acesso seletivo poderia produzir um mercado diferente. Parceiros compatíveis e interfaces aprovadas ganhariam importância, enquanto a coleta não oficial se tornaria menos confiável.

Para desenvolvedores, a resposta imediata é direta. Tratem links de resultados de busca como dados variáveis, validem destinos, preservem o contexto de diagnóstico e monitorem falhas de resolução separadamente das mudanças de classificação.

Para compradores, a tarefa é verificar. Perguntem se seu provedor de SEO, monitoramento ou pesquisa se adaptou antes de confiar em uma mudança inesperada em seus relatórios.

Para trabalhadores do conhecimento, inspecionem as citações quando um sistema automatizado de pesquisa retornar um wrapper do Google. Uma resposta utilizável deve levar à fonte subjacente, não parar na camada de roteamento do mecanismo de busca.

Google.com/goto: a atualização anti-scraping do Google, portanto, não é nem um bloqueio total nem um redirecionamento cosmético. É uma praça de pedágio arquitetural posicionada em um ponto valioso do pipeline de dados de busca.

Observe se esse pedágio permanece como uma solicitação barata. Se ganhar verificações de identidade mais rigorosas, tokens de vida mais curta ou limites mais restritos, o reparo de parser de hoje se tornará uma disputa maior por acesso.