O que aconteceu e o que é o formato /goto

Em artigo publicado em 27 de agosto de 2026, a Autom relatou uma alteração observada no Google Search: links de resultados orgânicos passaram a apontar para um caminho no domínio do próprio Google, como google.com/goto, em vez de revelar diretamente no atributo href o endereço de destino. A mudança foi observada de forma mais consistente em buscas feitas com o usuário desconectado ou em uma janela privada. A própria análise ressalta que o comportamento ainda pode ser um experimento, embora já não pareça restrito a uma parcela pequena das páginas de resultados.

O parâmetro url associado ao novo caminho não é uma versão simples em Base64 do endereço final. Trata-se de uma referência codificada de forma específica pelo Google, que não pode ser convertida de maneira confiável apenas com um decodificador local. Para descobrir o destino, o cliente precisa fazer uma nova requisição ao endereço /goto e observar o cabeçalho HTTP Location sem seguir automaticamente o redirecionamento.

Está notícia é importante para quem constrói indexadores, ferramentas de análise de resultados, coletores de dados ou pipelines de observabilidade. Para a pessoa que apenas clica em um resultado, a experiência tende a continuar parecida. Para um sistema automatizado, cada link passa a exigir uma etapa adicional, com mais tráfego, mais latência e novas decisões de segurança. O formato também não deve ser confundido com uma vulnerabilidade ou com uma prova de invasão. O que mudou, segundo a fonte consultada, é o mecanismo de intermediação do link e o custo operacional de obter o endereço real.

Como funciona o redirecionamento

Em um fluxo tradicional, o coletor lê o HTML da página de resultados, encontra um atributo href com a URL final e grava esse valor. No formato relatado pela Autom, o HTML apresenta o caminho /goto e um parâmetro que funciona como uma referência opaca. O coletor precisa preservar o contexto da sessão, montar uma requisição para esse endereço e pedir ao cliente HTTP que não siga redirecionamentos durante essa primeira etapa.

A resposta contém o destino no cabeçalho Location. Em uma biblioteca HTTP, isso normalmente significa configurar o modo de redirecionamento automático como desativado, ler os cabeçalhos recebidos e só então decidir se o valor é aceitável. A recomendação técnica da fonte é usar uma requisição HEAD para ler o Location sem baixar o conteúdo da página de destino. Mesmo assim, a equipe deve confirmar como o servidor responde a HEAD, porque alguns sites tratam HEAD de maneira diferente de GET.

A sequência segura é: coletar o link apresentado no resultado, reconhecer o padrão /goto, consultar o redirecionador com limite de tempo, capturar o Location, validar o esquema e o host do destino e só depois armazenar o endereço. Seguir o destino final é uma operação separada e não deve ocorrer por padrão. Essa separação evita downloads desnecessários, reduz o impacto sobre sites de terceiros e mantém a etapa de resolução observável.

O cuidado é ainda mais importante quando o resolver recebe dados externos. Um valor no cabeçalho Location é uma entrada fornecida por uma rede remota. Se o código aceitar qualquer endereço e fizer uma segunda requisição sem validação, ele pode criar um problema de SSRF na própria infraestrutura do coletor. A novidade do Google não cria esse risco sozinha; ela apenas acrescenta uma etapa em que uma implementação frágil pode tomar uma decisão perigosa.

Quem foi afetado e para que serve a mudança

O grupo mais diretamente afetado é formado por aplicações que extraem URLs de páginas de resultados do Google Search. Isso inclui ferramentas de pesquisa de palavras-chave, indexadores internos, plataformas de SEO, sistemas de comparação de resultados e crawlers que precisam organizar referências públicas. A Autom também relaciona a alteração ao aumento do custo de harvesting automatizado por crawlers de IA e scrapers de SEO que tentam transformar páginas de resultados em índices próprios.

A explicação apresentada pela fonte é coerente com o mecanismo observado: quando o endereço final aparece em texto no HTML, um coletor pode extrair milhares de URLs em uma única leitura. Quando o resultado aponta para /goto, o coletor precisa voltar ao Google para resolver cada referência. Isso torna o processo mais lento e mais ruidoso e permite que o Google observe um cliente que resolve centenas de links em sequência. A Autom cita também mudanças anteriores, como a remoção do parâmetro num=100 e o endurecimento de camadas chamadas BotGuard e SearchGuard, mas esses pontos devem ser tratados como contexto reportado pela fonte, não como uma especificação oficial para todas as contas.

Usuários desconectados e pessoas que navegam em modo privado podem perceber o comportamento com mais facilidade, mas a observação não prova que todas as sessões ou todos os países recebem exatamente a mesma resposta. Testes de automação precisam registrar o estado de autenticação, os cookies, o idioma, o agente de usuário e o momento da consulta. Sem esse contexto, duas equipes podem interpretar respostas diferentes como uma falha do parser, quando na realidade estão recebendo variantes do rollout.

O Google ainda precisa mostrar informações sobre o resultado na página, como domínio, favicon e atribuição. Por isso, a análise da Autom observa que cópias do endereço continuam presentes em partes do HTML. Isso não significa que o parser possa depender de um único campo alternativo. A estrutura da página pode mudar, e o endereço apresentado visualmente não substitui a resolução controlada do Location.

Como identificar a mudança nos dados e nos logs

O primeiro indicador é encontrar /goto no valor do href de um resultado orgânico. O segundo é a presença do parâmetro url em uma URL do Google que não contém o destino legível. O terceiro aparece na resposta HTTP: em vez de um corpo útil, o resolver recebe uma resposta com Location apontando para o endereço real. Se o cliente estiver configurado para seguir redirecionamentos, esse sinal pode desaparecer da camada de coleta e só ficar visível na URL final.

Os logs devem registrar a URL solicitada, o código de status, a presença do cabeçalho Location, o host do destino, o tempo de resposta, a identificação da sessão de busca e um identificador de correlação. Não é necessário guardar o parâmetro opaco completo em todos os casos. Se ele puder conter dados de sessão ou representar uma consulta sensível, aplique mascaramento ou retenção reduzida. O objetivo é explicar por que um resultado foi resolvido sem transformar o log em uma nova fonte de exposição.

Um teste diagnóstico simples compara três comportamentos: baixar a página sem seguir links, consultar um endereço /goto com redirecionamento automático desligado e repetir a consulta em uma sessão privada. O resultado esperado é que o segundo teste revele o Location na resposta e que o terceiro possa apresentar a mesma estrutura com uma distribuição diferente. Se o parser registrar google.com como destino final para todos os resultados, ele provavelmente está salvando o intermediário ou seguindo o redirecionamento sem capturar a cadeia corretamente.

Não tente descobrir o destino fazendo força bruta sobre o parâmetro url ou assumindo que ele é Base64. A fonte afirma que a codificação é específica do Google e não pode ser decodificada offline de forma simples. O caminho confiável é usar o fluxo HTTP previsto para a resolução, dentro das regras e limites aplicáveis ao seu uso.

Como se proteger e mitigar riscos

A correção imediata para uma integração legítima é separar o parser de resultados do resolver de redirecionamentos. O parser identifica o padrão e coloca o item em uma fila controlada. O resolver faz uma única requisição ao host esperado, com timeout curto, limite de tamanho de cabeçalhos e redirecionamento automático desligado. O valor do Location passa por validação antes de ser persistido ou usado em outra chamada.

Valide pelo menos o esquema https ou http, rejeite credenciais embutidas na URL, normalize o host sem alterar o valor original para auditoria e defina limites de comprimento. Se a etapa seguinte for fazer uma requisição ao destino, aplique uma política de saída que bloqueie loopback, redes privadas, endereços reservados, serviços de metadados de nuvem e nomes internos. Reavalie o endereço depois de cada resolução DNS para reduzir o risco de DNS rebinding. Não envie cookies do Google, tokens ou cabeçalhos internos para o destino encontrado.

Use uma lista de permissões quando o objetivo for apenas resolver links de resultados para domínios conhecidos. Quando o caso de uso precisar aceitar qualquer domínio público, mantenha o fetcher em um ambiente isolado, com identidade de serviço sem privilégios, sem acesso à rede administrativa e sem credenciais disponíveis no processo. Essa arquitetura protege o restante da organização caso uma resposta remota tente redirecionar o coletor para um serviço interno.

Também é importante controlar ritmo, concorrência e cache. A mudança foi descrita como uma forma de tornar a coleta em massa mais lenta e visível. Aumentar agressivamente a quantidade de workers pode elevar o custo, gerar bloqueios e prejudicar a disponibilidade do seu próprio sistema. Use backoff, limite por sessão, métricas de erro e uma fila que possa ser pausada. Respeite os termos de uso e as políticas aplicáveis ao serviço consultado e prefira uma API autorizada quando ela atender ao objetivo.

Comparação com formatos anteriores e alternativas

O formato antigo citado na análise usava google.com/url?q= com o endereço de destino legível ou codificado na query string. Nesse modelo, o parser podia extrair o valor de q sem fazer uma nova consulta ao Google. A diferença para /goto é operacional: agora o endereço apresentado funciona como referência para uma etapa de resolução, e não como uma cópia simples do alvo final.

Há também a alternativa mais direta, em que o HTML expõe o destino sem intermediário. Ela reduz a latência do coletor, mas permite que grandes volumes de URLs sejam extraídos com poucas requisições. A análise da Autom coloca o novo comportamento nesse contexto de aumento do custo do harvesting automatizado. Nenhum desses formatos deve ser interpretado como criptografia para proteger o usuário. O Location precisa ser enviado ao cliente que está resolvendo o link, e a página ainda pode conter pistas sobre o domínio final.

Para equipes que precisam de dados de busca de forma recorrente, uma alternativa operacional é usar integrações autorizadas e fontes de dados que ofereçam contrato, limites e campos estáveis. Se a coleta de páginas continuar necessária, o parser deve tratar o formato /goto como uma variante normal do protocolo, com telemetria e controles de segurança. Tentar manter um decodificador particular baseado em amostras antigas cria dependência frágil e pode levar a decisões erradas quando o experimento mudar.

Em termos de privacidade, existe um trade-off. A resolução adicional pode gerar mais eventos associados ao cliente que está coletando os resultados. Isso não permite concluir, por si só, como os dados serão usados ou retidos pelo Google, mas recomenda que a equipe documente o fluxo, reduza consultas desnecessárias e não envie identificadores pessoais extras. A minimização de dados continua válida mesmo quando a informação é pública.

Análise técnica do fluxo HTTP

O ponto central da análise é o uso do cabeçalho Location como fonte do destino final. A primeira resposta deve ser tratada como uma resposta de redirecionamento, sem pressupor que o corpo contenha HTML útil. A aplicação deve guardar o status recebido, ler apenas os cabeçalhos necessários e validar o campo antes de transformá-lo em uma nova requisição. Se o status ou o cabeçalho não corresponderem ao esperado, o item deve ser marcado para revisão ou descartado com motivo explícito.

Uma implementação robusta pode seguir este fluxo técnico: primeiro, extrair o href e confirmar que o host é o esperado; segundo, abrir uma conexão com timeout e redirecionamentos desativados; terceiro, capturar o Location sem baixar a página final; quarto, analisar esquema, host, porta e comprimento; quinto, registrar o resultado sanitizado; sexto, decidir se o endereço será somente armazenado ou consultado por um componente isolado. Essa ordem impede que uma biblioteca faça trabalho implícito antes da validação.

Não há CVE ou pontuação CVSS atribuída ao comportamento descrito na fonte. Ele é uma mudança de roteamento e de proteção contra coleta automatizada, não um relatório de falha no Google. O risco de segurança está nas integrações que seguem qualquer redirecionamento, misturam cookies de origens diferentes, ignoram limites de rede ou deixam um usuário controlar a URL de partida. Essa distinção evita alarmismo e direciona a correção para o componente que realmente pode ser explorado.

Para testes, use respostas gravadas com dados sanitizados e cubra pelo menos quatro casos: resultado direto, resultado com /goto, ausência de Location e Location apontando para rede privada. Verifique que o cliente não baixa conteúdo no modo de resolução e que um erro não faz a fila repetir indefinidamente. Meça a latência extra e a taxa de falhas por sessão para detectar regressões após novas mudanças no Google Search.

Impacto e consequências

O impacto operacional mais evidente é o aumento do número de requisições necessárias para recuperar a URL final. Pipelines que calculavam custo e capacidade apenas pela página de resultados podem começar a exceder o orçamento, o tempo de execução ou o limite de concorrência. A latência adicional também afeta dashboards que esperam dados em tempo real e pode fazer um resultado parecer indisponível quando a etapa de resolução apenas expirou.

Há consequências para a qualidade dos dados. Se o coletor não reconhecer /goto, pode salvar o Google como domínio de todos os resultados, gerar duplicatas ou perder a relação entre palavra-chave, posição e destino. Se seguir os redirecionamentos sem registrar a cadeia, a equipe perde evidência para explicar de onde veio uma URL. A telemetria precisa distinguir resultado orgânico, intermediário do Google, destino final e erro de resolução.

Do ponto de vista de privacidade, cada consulta extra deve ser avaliada sob o princípio da necessidade. Guardar a URL final pode ser legítimo para uma análise de segurança ou pesquisa autorizada, mas não é justificativa para manter indefinidamente identificadores de sessão, parâmetros opacos ou páginas completas. Defina retenção, controle de acesso, mascaramento e um processo para apagar dados que não são mais necessários.

Existe ainda um risco reputacional e de disponibilidade. Uma automação que dispara muitas resoluções em pouco tempo pode ser interpretada como tráfego abusivo, sofrer bloqueio ou consumir recursos de terceiros. A equipe deve tratar a alteração como um sinal para revisar a taxa de coleta e a dependência de páginas de resultados, não como um convite para contornar mecanismos de defesa. O impacto financeiro depende do volume, da arquitetura e do fornecedor utilizado, então não é correto atribuir um número universal.

Dicas práticas e boas práticas

Use este checklist ao adaptar uma integração:

  • Detecte /goto antes de aplicar o parser usado para URLs diretas.
  • Desative o seguimento automático durante a resolução e leia o Location explicitamente.
  • Não tente decodificar o parâmetro url como se fosse Base64 comum.
  • Valide esquema, host, porta, tamanho e caracteres antes de armazenar o destino.
  • Bloqueie loopback, redes privadas, metadados de nuvem e nomes internos no componente que faz fetch.
  • Separe o resolver do worker que visita páginas e remova credenciais do ambiente de execução.
  • Registre status, latência, sessão e motivo do erro sem guardar dados sensíveis em excesso.
  • Use timeout, backoff, cache e limite de concorrência para evitar picos de tráfego.
  • Teste sessões conectadas, desconectadas e privadas e preserve o contexto de cada amostra.
  • Prefira APIs e integrações autorizadas quando a necessidade for recorrente e previsível.

Vale incluir esses casos no teste de contrato do seu coletor. O teste deve falhar quando uma biblioteca voltar a seguir o redirecionamento sem autorização, quando um cabeçalho ausente for tratado como URL válida ou quando uma resposta HTML de fallback for confundida com um destino resolvido. Também monitore a proporção de links diretos e links /goto ao longo do tempo. Uma mudança abrupta pode indicar alteração do rollout, problema de sessão ou regressão no parser.

Para segurança de sites, o aprendizado é mais amplo: qualquer redirecionamento externo deve ser tratado como dado não confiável. O mesmo cuidado vale para links enviados por usuários, encurtadores, parâmetros de retorno e integrações de login. A aplicação deve validar o destino, limitar a rede que pode ser acessada e evitar que uma URL externa controle o fluxo interno. O caso do Google torna essa regra visível porque um resultado que antes parecia simples agora passa por um intermediário explícito.

Conclusão: o que fazer agora

A alteração observada no Google Search transforma a extração de URLs em um fluxo de duas etapas para parte das sessões: primeiro o resultado aponta para /goto, depois uma requisição controlada revela o endereço no Location. A mudança foi relatada pela Autom no fim de agosto de 2026 e pode continuar evoluindo. Por isso, trate o comportamento como uma variante observável, não como um contrato permanente.

O próximo passo é auditar o parser, localizar pontos em que redirecionamentos são seguidos automaticamente e adicionar testes para respostas com /goto. Em seguida, isole o resolver, valide o destino contra uma política de saída, reduza a coleta ao necessário e atualize os painéis para distinguir intermediário, destino e erro. Registre a sessão usada no teste e compare os resultados ao longo dos dias.

Não há motivo para declarar uma vulnerabilidade no Google com base apenas nessa mudança. Há, porém, motivo suficiente para revisar SSRF, privacidade, rate limiting e observabilidade em qualquer pipeline que passe a seguir URLs obtidas de cabeçalhos remotos. Uma integração resiliente reconhece o formato, respeita limites e mantém o controle sobre cada requisição. Se o serviço de busca alterar novamente a estrutura, essa separação permitirá adaptar o parser sem ampliar a superfície de ataque.