Alterações de SEO em junho de 2026

#Introdução

Junho de 2026 concentrou em quatro semanas mais notícias de pesquisa com peso do que a maioria dos trimestres consegue reunir. A Google concluiu uma Core Update que decorreu durante quase doze dias, adicionou um relatório de desempenho de IA e um interruptor de exclusão ao Search Console, publicou orientações que, discretamente, disseram à indústria do AEO e do GEO que as suas táticas preferidas não têm importância, e lançou uma Spam Update. Em pano de fundo, a Cloudflare confirmou que as máquinas fazem agora mais pedidos à web do que as pessoas, e uma vaga de desindexação inexplicada manteve os fóruns de SEO ocupados.

Esta é a perspetiva de construção WordPress sobre tudo isto. Não um resumo de quem publicou o quê, mas o que cada alteração significa para as equipas que lançam e mantêm sites WordPress, e quais destes desenvolvimentos exigem realmente ação.

#Core Update de maio de 2026 e sites afetados

A Google confirmou que a Core Update de maio de 2026 terminou a implementação a 2 de junho de 2026. A implementação demorou 11 dias e 21 horas, de 21 de maio a 2 de junho, ligeiramente menos do que as duas semanas que a Google previu. A leitura da comunidade de SEO foi direta: março foi fraco, maio foi significativo. Os sites de jogos de azar, as categorias YMYL como saúde e finanças, e os sites de comércio eletrónico registaram as maiores perdas.

O padrão é o que importa para as equipas WordPress. Os analistas descreveram esta atualização como semelhante às clássicas core updates anteriores aos AI Overviews: o conteúdo genuíno de especialistas ganhou, o conteúdo genérico e superficial perdeu. Não é uma instrução nova, mas é uma confirmação útil. Os sites que caíram raramente estavam avariados do lado técnico. Eram catálogos WooCommerce com descrições de categoria duplicadas, arquivos de blog inchados com enchimento gerado por IA, e páginas de serviço que repetiam as mesmas três frases ao longo de quarenta variantes de cidade.

O próprio conselho da Google é aguardar uma semana completa após o fim de uma implementação antes de analisar o Search Console, o que, para esta atualização, significa por volta de 9 de junho. Esse período de espera não é cautela burocrática. Os dados de ranking mantêm-se voláteis durante dias depois de a Google marcar uma implementação como concluída, e reagir aos dados do segundo dia significa normalmente perseguir ruído. Anote as datas no Search Console com uma anotação, aguarde e depois compare uma semana estável com uma semana estável.

A conclusão prática é antiga e correta: consolide páginas superficiais em menos páginas fortes, elimine arquivos duplicados de categoria e de tag, e certifique-se de que cada página que posiciona responde a uma pergunta feita por uma pessoa real. O WordPress torna trivial publicar mil páginas. As core updates continuam a punir os sites que o fazem.

#Como funciona o relatório de IA e a exclusão no Search Console

A 3 de junho de 2026 a Google anunciou duas novidades para o Search Console: um relatório de desempenho dedicado às superfícies de IA generativa (AI Overviews, AI Mode e funcionalidades de IA generativa do Discover) e o teste de um controlo que permite aos proprietários de sites excluir o seu conteúdo dessas funcionalidades. Segundo a página de ajuda da Google sobre o controlo, este não é usado como sinal de ranking nem de inclusão noutras partes da Pesquisa, pelo que os resultados orgânicos clássicos não são afetados.

A publicação da Google no The Keyword do mesmo dia diz que a Google está a ouvir os editores e a dialogar com reguladores como a Competition and Markets Authority do Reino Unido sobre estas ferramentas. Nem essa publicação nem o anúncio no blog do Search Central apresentam o controlo como uma obrigação legal, por isso também não o fazemos. O relatório começou com um subconjunto de sites, e o controlo como teste.

Leia as letras miudinhas antes de celebrar. O relatório de IA mostra apenas impressões, sem cliques e sem CTR, discriminadas por página, país, dispositivo e data. As páginas de ajuda da Google não dizem até quando recua o histórico, por isso leia a data mais antiga no seu próprio gráfico. O controlo está no Search Console em Settings > Search generative AI (na interface em inglês). Esteve em teste desde 3 de junho e, segundo a página de ajuda, ficou disponível para todos os sites do mundo a 31 de agosto de 2026.

Para as equipas WordPress, a limitação de apenas impressões é o ponto central. Consegue ver que os AI Overviews mostraram a sua página, mas não se alguém clicou. Isto torna-o um sinal de visibilidade, não um sinal de tráfego, e deve ser tratado como tal nos relatórios. Não deixe um cliente ler as impressões de IA como sessões.

O controlo merece um aviso firme. Funciona por propriedade do Search Console, não por página. Uma propriedade de prefixo de URL herda o valor da propriedade principal, a menos que um proprietário o configure à parte, pelo que uma secção inteira pode ser tratada separadamente do resto do domínio, mas um URL isolado não. A Google indica que a exclusão produz efeito em um a dois dias, por vezes mais devido à cache. Para um site WordPress comercial que já obtém referências qualificadas das superfícies de IA, a exclusão remove uma visibilidade que não conseguirá recuperar de forma seletiva. O único caso claro para a exclusão é um site cujo conteúdo esteja a ser resumido de forma tão completa que as respostas de IA canibalizem o clique sem nunca o enviarem. Isso é um cálculo de negócio, não uma definição por defeito.

#Como o tráfego de bots afeta a cache e a análise no WordPress

A 5 de junho de 2026 a Cloudflare confirmou que os bots geraram mais de metade de todos os pedidos HTTP a páginas HTML pela primeira vez na história da web. O tráfego automatizado atingiu 57,3 por cento dos pedidos a conteúdo HTML, contra 42,7 por cento humano. O CEO da Cloudflare, Matthew Prince, observou que tinha previsto este ponto de viragem para o final de 2027, depois para o início de 2027, mas o tráfego agêntico cresceu depressa o suficiente para ultrapassar os 50 por cento bastante antes do previsto.

A discriminação dentro do tráfego de bots é a parte que os operadores WordPress devem interiorizar. Os bots de treino de IA representam 50,6 por cento dos pedidos automatizados. Os bots de pesquisa são apenas 10,7 por cento. As máquinas que leem o seu site estão agora, na sua maioria, ali para treinar modelos, e não para indexar para uma página de resultados.

Isto tem duas consequências concretas para o WordPress.

Primeiro, os pressupostos de caching quebram. Os plugins de cache de página estão afinados para o padrão humano: um conjunto quente de URLs populares servidos repetidamente a partir da cache. Os agentes de IA rastreiam de forma sequencial e exaustiva, alcançando páginas raramente visitadas que nunca ficam numa cache aquecida. Uma loja WooCommerce com 12.000 produtos pode registar uma carga na origem que nunca planeou, porque os agentes estão a puxar todos os URLs de produto, e não os 200 principais. Se o seu alojamento fatura por pedidos à origem ou se corre templates com muito PHP sem caching de página completa, essa fatura é agora um custo real.

Segundo, a analítica torna-se menos fiável. As métricas de tráfego, sessões e envolvimento sem uma filtragem agressiva de bots afastam-se mais da realidade a cada mês. Se a sua analítica WordPress ainda conta tudo o que pede uma página, os seus números são cada vez mais ficção. A filtragem do lado do servidor por user agents de bots verificados, ou uma camada de analítica que filtre o tráfego automatizado, deixou de ser uma higiene opcional.

#O que diz a Google sobre AEO, GEO e llms.txt

A 5 de junho de 2026 a Google publicou uma nova página de documentação, as orientações da Google Search sobre a utilização de ferramentas, serviços e conselhos de SEO de terceiros, e acrescentou ao guia “Precisa de um SEO?” uma secção sobre a avaliação de recomendações, como regista o histórico de alterações da documentação do Search Central. A nova página inclui as ferramentas que prometem melhorias nas experiências de IA e nos formatos de pesquisa, conhecidas como ferramentas de AEO ou GEO, entre os serviços a avaliar com espírito crítico.

A mensagem foi direta. As ferramentas de terceiros não têm acesso aos dados internos de ranking da Google e não podem garantir resultados. A Google não avalia serviços de terceiros, por isso aconselha desconfiança perante quem sugira que o seu trabalho é aceite ou aprovado pela Pesquisa Google. Isto visa diretamente o mercado em rápido crescimento de agências e ferramentas que vendem otimização autorizada para os AI Overviews.

As orientações também reforçaram o documento da Google de 15 de maio sobre otimização para IA generativa, que enumerou táticas que considera desnecessárias para a Pesquisa: ficheiros llms.txt, schema especial para IA e content chunking.

Aqui separamo-nos de uma leitura generalizada. A Google dizer que o llms.txt não ajuda o crawler da Google é verdade e não surpreende: o Googlebot não lê o llms.txt. Mas a Pesquisa já não é o único sistema de recuperação na web, como os números da Cloudflare acabaram de estabelecer. O llms.txt, os ficheiros irmãos em Markdown e a negociação de conteúdo destinam-se aos agentes de recuperação de IA, não ao Googlebot, e a Google não tem qualquer incentivo para endossar mecanismos que contornam os seus próprios produtos. Mantemos esses sinais no nosso próprio stack precisamente por essa razão. A conclusão correta é mais restrita do que “o GEO é banha da cobra”: não compre um ficheiro llms.txt como alavanca de ranking, porque não o é, e trate qualquer pessoa que venda otimização de IA aprovada pela Google como um sinal de alerta. A disciplina subjacente de escrever conteúdo citável e bem fundamentado não é folclore.

#Porque é que a Google desindexa páginas WordPress

Ao longo de junho, os fóruns de SEO encheram-se de relatos de desindexação silenciosa. Começou quando o antigo engenheiro da Google, Pedro Dias, perguntou a 30 de abril se outros estavam a ver uma taxa mais alta de desindexação aleatória de URLs desde o início de abril. A resposta foi enorme. Profissionais de muitos países descreveram o mesmo padrão: páginas indexadas durante anos a desaparecer sem uma ação manual, sem erros de rastreio, aterrando discretamente em “Rastreada - atualmente não indexada”.

John Mueller abordou o assunto no Bluesky com um encolher de ombros: alguns sites crescem, outros caem, nada de invulgar. A indústria não ficou satisfeita. Glenn Gabe documentou um estudo de caso de um site que perdeu quase todo o seu índice. O Search Engine Journal cobriu o tema em detalhe, notando que alguns relatos confundem perda de ranking com desindexação, mas alguns são remoções genuínas e inexplicadas. A Google confirmou não ter havido qualquer alteração aos seus mecanismos de indexação.

Para o WordPress em concreto, “Rastreada - atualmente não indexada” tem um conjunto familiar de causas que vale a pena descartar antes de culpar um algoritmo. O conteúdo superficial ou quase duplicado é o gatilho clássico, e o WordPress gera-o por defeito através de arquivos de tags, páginas de comentários paginadas, páginas de anexos e arquivos de autor. Antes de assumir que foi apanhado numa varredura misteriosa, verifique se o seu sitemap XML lista apenas URLs canónicos e dignos de indexação, se o Yoast ou o Rank Math não está a deixar escapar arquivos de baixo valor para o índice, e se a sua ligação interna alcança de facto as páginas que lhe interessam. A Google pode ser opaca e, ainda assim, estar a reagir a um sinal de qualidade genuíno. Descarte primeiro as explicações aborrecidas.

#O que é a política da Google contra o sequestro do botão retroceder

A 15 de junho de 2026 entrou em vigor a política da Google sobre o sequestro do botão retroceder. A Google anunciou-a a 13 de abril e deu aos proprietários de sites dois meses para se conformarem.

O sequestro do botão retroceder manipula o histórico do navegador para que clicar em Retroceder não devolva o utilizador ao local de onde veio, mas o empurre para outras páginas do site ou para anúncios. A partir de 15 de junho, os sites que utilizam a técnica podem enfrentar ações manuais de spam e despromoções algorítmicas. A Google foi explícita ao afirmar que a responsabilidade recai sobre o proprietário do site, mesmo quando a manipulação vem de código de bibliotecas de terceiros ou de redes de anúncios.

Esta é uma preocupação direta para o WordPress. A técnica raramente vem de um tema que um programador escreveu. Chega através de plugins de arbitragem de anúncios, widgets agressivos de retenção e scripts de monetização que os editores instalam sem ler o que fazem. Se corre anúncios de display num site WordPress através de uma rede de terceiros, a manipulação pode ser injetada a jusante do seu próprio código, e a Google continuará a responsabilizar o seu domínio. Audite o que os seus plugins de anúncios e de popups fazem ao histórico do navegador. “Foi o plugin” não é uma defesa que a Google aceite.

#O que mudou com o Spam Update da Google de junho de 2026

Entre 24 e 26 de junho, a Google implementou a Spam Update de junho de 2026, a segunda atualização antispam oficial do ano. Decorreu durante 2 dias e 1 hora, de 24 de junho às 09:00 PT a 26 de junho às 10:00 PT. A Google descreveu-a em termos padrão: uma atualização de spam normal que abrange todas as línguas e localizações.

Não foram anunciadas novas categorias de violação. Foi o SpamBrain a aplicar as regras existentes de forma mais eficaz. Barry Schwartz confirmou que não visava spam de links nem a política de Site Reputation Abuse. Os observadores do WebmasterWorld consideraram-na mais forte do que a de março, com comentários a apontar para sites de localização produzidos em massa e à escala, e para sites de comparação.

O contexto importa. Nove dias antes, a política de sequestro do botão retroceder entrou em vigor e, três semanas antes disso, a Google estendeu as suas políticas de spam aos AI Overviews e ao AI Mode. A Google confirmou não haver ligação direta entre estes acontecimentos, mas a direção é consistente. O conteúdo à escala, baseado em templates e com pouca diferenciação está sob pressão sustentada, e o WordPress é a plataforma mais capaz de o produzir em volume. Se corre páginas WordPress programáticas, grelhas de cidade-vezes-serviço, ou conteúdo de comparação gerado automaticamente, esta atualização é um tiro de aviso. A diferenciação por página é agora o preço da sobrevivência, e não pode ser fingida com um parágrafo reciclado.

#Atualizações da Google depois de junho de 2026

A pesquisa não parou em junho. Quatro alterações posteriores vêm diretamente dos canais da própria Google, o Search Status Dashboard e o blog Search Central:

O anúncio de 3 de junho de Hillel Maoz e Moshe Samet descreve um relatório que começou com um subconjunto de sites e conta impressões nos AI Overviews, no AI Mode e nas funcionalidades de IA generativa do Discover. Discrimina-as por página, país, dispositivo (apenas na Pesquisa) e data, com granularidade horária, diária, semanal e mensal. Uma nota acrescentada à publicação indica que os relatórios chegaram a todos os sites do mundo a partir de 31 de agosto de 2026. Um site WordPress fora do primeiro grupo de teste já tem os dados, e a ressalva anterior mantém-se: são impressões, não visitas.

A publicação de 28 de agosto sobre a política de reputação do site surgiu depois de conversas com a Comissão Europeia. A partir de 30 de agosto, uma ação manual ao abrigo dessa política afeta os resultados para utilizadores fora do Espaço Económico Europeu. Dentro do EEE não se aplica, e a secção afetada pode ser separada nos sistemas da Google para que, com o tempo, se posicione de forma independente do resto do site. Para um editor em WordPress que aloja secções de parceiros, o efeito de uma ação manual depende agora de onde está quem pesquisa, e a notificação continua a chegar ao Search Console.

Segundo o Search Status Dashboard, junho não foi a última passagem antispam do ano. A Google anunciou a atualização de setembro como uma implementação que podia demorar até duas semanas, e concluiu-a a 8 de outubro. Se o seu tráfego mudou no final de setembro, verifique as duas janelas antispam antes de culpar uma alteração de conteúdo, e mantenha a mesma semana de espera antes de ler o Search Console.

#O que fazer após as atualizações da Google de junho

A maior parte das notícias de junho é contexto, não uma lista de tarefas. Três itens justificam ação para as equipas WordPress.

• Audite os plugins de anúncios e de monetização quanto à manipulação do histórico do navegador antes que a política do botão retroceder apanhe o seu domínio pelo código de outra pessoa.
• Corrija a filtragem de bots na analítica, porque mais de metade do seu tráfego é agora automatizado e os seus relatórios estão a afastar-se da realidade.
• Consolide o conteúdo superficial e baseado em templates, porque tanto a Core Update como a Spam Update continuaram a recompensar a diferenciação e a punir o volume.

O resto vale a pena acompanhar e não vale a pena entrar em pânico. Leia o Search Console uma semana após qualquer implementação, trate as impressões de IA como visibilidade e não como tráfego, e ignore quem venda um atalho aprovado pela Google para os AI Overviews. A Google acabou de lhe dizer por escrito que tal coisa não existe.