O clique num resultado orgânico do Google já não leva diretamente ao seu site. Desde 26 de agosto de 2026, data em que o Google confirmou a implementação, cada ligação nos resultados passa por google.com/goto?url= com um token codificado, e só depois o servidor do Google reencaminha o navegador para o endereço correto. Para o utilizador nada muda, para os rankings também não. O que muda é aquilo que veem as ferramentas que leem os resultados a partir do HTML, e essa é a única área em que há algo a verificar. Este texto separa o que o Google confirmou daquilo que o setor acrescenta por conta própria, e diz o que verificar em concreto na analítica e no WordPress.
O que o Google confirmou e o que é suposição
A confirmação é uma só e curta. Na resposta ao Search Engine Land de 26 de agosto de 2026, o Google escreveu:
We have a long history of deploying technical measures against evolving forms of abuse, and we regularly take steps to protect our services and users.
(Tradução: temos um longo historial de implementação de medidas técnicas contra formas de abuso em evolução, e tomamos regularmente medidas para proteger os nossos serviços e utilizadores.)
É tudo. Não há documentação, não há descrição do formato do token, não há política de referrer, não há data de início. O resto vem de observações, e convém saber de quem.
| o que sabemos | fonte | estado |
|---|---|---|
a ligação tem a forma google.com/goto?url= com um token codificado | observações de SEO desde junho de 2026 | confirmado várias vezes |
| o servidor responde com um redirecionamento 302 para o endereço de destino | observações de ferramentas | confirmado |
| o token não pode ser descodificado localmente | Nozzle, SerpAPI | confirmado por tentativas |
| implementação próxima de 100 por cento em endereços residenciais | Derek Perkins, Nozzle | medição de uma única empresa |
| Search Console sem alterações | Search Engine Land | relato, não documento |
| política de referrer | ninguém | desconhecida |
Os primeiros relatos datam de 23 de junho (Alex Greenland) e de 2 de julho (Brodie Clark), pelo que, da primeira observação à confirmação, passaram dois meses. O Google chamou-lhe uma medida contra abusos, e o contexto é claro: a empresa tinha processado a SerpAPI por scraping e perdeu as reclamações principais ao abrigo da DMCA. Já que o tribunal não bloqueou a leitura dos resultados, a técnica tratou disso.
O mecanismo, em três passos
Até 26 de agosto, a ligação num resultado orgânico era um simples <a href="https://oseusite.pt/artigo/">. A ferramenta que descarregava o HTML dos resultados tinha de imediato a lista de endereços e posições.
Agora o href aponta para https://www.google.com/goto?url= seguido de uma sequência de caracteres que parece base64, mas que não o é em nenhuma forma publicamente conhecida. O navegador envia o pedido para esse endereço, o servidor do Google responde com o código 302 e um cabeçalho Location para a página correta, e o navegador segue-o. O utilizador vê um clique e uma página. Na barra de estado, antes do clique, vê no entanto um endereço do Google e não o seu, e essa é a única diferença visível para ele.
Não é uma ideia nova. O Google Ads encaminha há anos os cliques em anúncios através de um endereço intermédio próprio, e nos resultados orgânicos um redirecionamento semelhante, /url?q=, já aparecia para utilizadores com sessão iniciada por volta de 2009, só que com o endereço de destino escrito em texto aberto. A novidade não é o redirecionamento, mas sim o facto de o endereço de destino ter deixado de ser legível sem executar um pedido.
Referrer: porque o apocalipse não chegou em agosto, porque chegou em 2011
A maior parte dos textos alarmistas diz respeito ao referrer e à atribuição. Vale a pena arrefecer isso com dois factos.
Primeiro, o Google não publicou uma política de referrer para o goto. Qualquer artigo que afirme com certeza o que vai ver no Google Analytics está a descrever observações próprias, não uma regra.
Segundo, e mais importante: os dados que agora supostamente iria perder, perdeu-os há muito tempo. Em 2011, o Google deixou de passar a consulta no referrer para utilizadores com sessão iniciada (o famoso “not provided”) e, nos anos seguintes, alargou isso a todo o tráfego. Desde então, o navegador recebe do Google apenas a origin, ou seja, https://www.google.com/, sem caminho e sem parâmetros. O GA4, o Matomo, o Umami e o Plausible classificam há anos essa visita como google / organic exclusivamente com base no domínio. O redirecionamento por google.com/goto não altera o domínio.
Os nossos próprios dados não acrescentam nada aqui, e dizemo-lo sem rodeios: no Umami da wppoland.com não recolhemos referrer de todo, o campo source significa para nós o local na página de onde partiu o evento, não de onde veio o utilizador. Gerimos o tráfego do motor de pesquisa a partir do Search Console, e este, segundo o relato do Search Engine Land, não vê os redirecionamentos goto, porque conta os cliques a partir dos seus próprios registos, não do HTML.
O que verificar se usa o GA4 ou outra ferramenta com referrer: compare a quota de google / organic na semana de 8 a 17 de agosto com a semana de 22 a 31 de agosto. Se a quota caiu e, na mesma janela, os cliques no Search Console ficaram no sítio, isso significa que parte das visitas mudou de classificação, e aí vale a pena investigar mais. Se os dois gráficos andam juntos, não há nada para corrigir. No nosso caso, os cliques do Search Console nessas duas janelas são 223 e 226, portanto do lado do Google nada mexeu.
Ferramentas de posições: é aqui que está o custo real
Um rank tracker que até agora fazia um pedido por consulta e lia cem endereços do HTML recebe hoje cem tokens. Para saber quem está na sétima posição, tem de fazer um pedido a google.com/goto para o sétimo token e ler o cabeçalho Location. Para toda a primeira página e os blocos adicionais, a Nozzle estima isto em 500 a 1000 pedidos por consulta.
As consequências são três, e cada uma aparece nos seus relatórios de forma diferente.
A primeira é o custo, que as ferramentas vão passar para os preços ou para a frequência de leitura. Uma medição diária pode tornar-se uma medição de três em três dias sem qualquer aviso, e o gráfico de posições começa a parecer uma escada.
A segunda são as lacunas. O Google limita a frequência de pedidos em endereços residenciais, pelo que uma ferramenta que tem de fazer mil pedidos em vez de um vai bater com mais frequência num bloqueio a meio da leitura. No relatório vai ver resultados para as posições 1 a 4 e ausência de dados a partir daí, ou a posição “não encontrado” para uma página que no Search Console tem cliques nesse mesmo dia.
A terceira é a volatilidade que não é volatilidade dos rankings. Se a ferramenta amostra em vez de medir, duas leituras consecutivas da mesma frase podem diferir porque a amostra foi diferente, não a SERP. As ondas de “volatilidade não confirmada” de agosto, que Barry Schwartz descreveu a 1 a 3, 5 a 6 e 12 a 13 de agosto, coincidem exatamente com o período de testes do goto. Não afirmamos que seja a única causa. Afirmamos que uma ferramenta que nesse período mudou o método de leitura não é uma testemunha fiável da volatilidade do ranking.
Regra prática: desde 26 de agosto, o Search Console é a única fonte que não mudou de método. Se o rank tracker e o Search Console não coincidem, o Search Console tem razão e o tracker tem uma lacuna. Antes de comunicar a um cliente uma queda de posições, compare as impressões e a posição média da mesma página no Search Console para o mesmo dia.
O que isto muda no WordPress: nada, com duas exceções
Nenhum ficheiro do tema, nenhum plugin e nenhuma definição do servidor influencia a forma como o Google constrói a ligação nos seus resultados. Não é preciso reconstruir nada, não é preciso acrescentar cabeçalhos, não há nada para “otimizar para o goto”. Se alguém lhe vende esse serviço, está a vender ar.
As duas exceções dizem respeito a plugins que baseiam a lógica no referrer.
A primeira são os plugins antigos que mostram “a frase pela qual o utilizador chegou” e a realçam no conteúdo. Trabalham com o parâmetro q do referrer, que o Google não envia desde 2011. Estavam mortos antes do goto e continuam mortos depois. Se ainda tem um desses ativo, remova-o, porque pesa em cada pedido e não dá nada em troca.
A segunda são os plugins de A/B e de personalização que verificam se o referrer contém google. para mostrar outra variante da página. Esses continuam a receber a origin google.com, por isso a condição funciona, mas depois de 26 de agosto vale a pena verificá-la ao vivo: abra um resultado do Google em modo privado e veja nos registos do servidor ou nas ferramentas de programador que Referer chegou. Cinco minutos, e a resposta é sólida, não vinda de um artigo.
Há ainda uma coisa sobre a qual ninguém escreve: a cache e os redirecionamentos próprios. Se o seu servidor tem uma regra que trata pedidos com um referrer invulgar como suspeitos (algumas configurações de proteção contra hotlinking e parte das regras em firewalls de aplicações), verifique se google.com com goto no caminho do referrer não foi parar à lista de bloqueados. É raro, mas o resultado seria um erro 403 para os utilizadores vindos do motor de pesquisa, e o Search Console só mostra um erro desses com semanas de atraso.
O que não sabemos e como agir mesmo assim
Não conhecemos o formato do token nem sabemos se o Google tenciona documentá-lo algum dia. Não sabemos se o redirecionamento vai abranger todos os países e tipos de resultados ou apenas as ligações orgânicas principais. Não sabemos qual é o objetivo para lá do genérico “contra abusos”, embora a sequência de acontecimentos à volta da SerpAPI sugira a resposta. E não sabemos como os navegadores se vão comportar nas próximas versões, porque a política de referrer para redirecionamentos 302 depende deles, não do Google.
A decisão operacional não depende de nenhuma destas lacunas. Os rankings são os mesmos de antes de 26 de agosto. O Search Console mostra o mesmo que antes. O utilizador chega onde chegava. A única coisa que mudou foi a fiabilidade das ferramentas que leem os resultados a partir de fora, e é para lá que o ónus da prova tem de passar: do tracker para o Search Console.
Três ações que encerram o assunto:
- Compare no GA4, ou na sua ferramenta, a quota de tráfego orgânico do Google nas janelas antes e depois de 26 de agosto. Se caiu e os cliques no Search Console não, tem um problema de classificação para investigar. Se não caiu, assunto encerrado.
- Verifique as datas e as lacunas no rank tracker desde 20 de agosto. Qualquer relatório para cliente desse período deve ter uma coluna com a posição do Search Console ao lado da posição da ferramenta.
- Remova os plugins que dependem da frase do referrer e verifique ao vivo os que verificam o domínio do referrer.
O Google tirou às ferramentas o mapa dos resultados, não lhe tirou a si o tráfego. É essa a diferença entre uma mudança a que é preciso reagir e uma mudança que é preciso conhecer. Esta é a segunda.
