As atualizações recentes do Google transformam documentação técnica em decisões sobre indexação, canonical, imagens, AMP e IA.
O Google atualizou várias partes da documentação para desenvolvedores em 2026. Não surgiu uma nova fórmula capaz de colocar qualquer site no topo, mas algumas mudanças alteram prioridades técnicas, removem recursos que deixaram de gerar resultados visuais e esclarecem práticas cercadas por promessas exageradas.
Para quem desenvolve sites, a leitura mais útil não é procurar um truque novo. É identificar o que precisa ser mantido, o que pode ser removido e quais sinais continuam ajudando o Google a rastrear, interpretar e apresentar uma página.
AMP continua existindo, mas a entrega mudou
Em julho, o Google simplificou a documentação de AMP e retirou referências antigas ao AMP Viewer, AMP Cache e signed exchanges. A partir dessa mudança, o usuário passa a ser conectado diretamente à versão AMP hospedada pelo próprio publisher. O conteúdo AMP continua sujeito aos mesmos critérios de classificação das demais páginas.
No dia a dia, não faz sentido tratar AMP como um atalho de ranqueamento. Quem mantém uma versão pareada precisa preservar a relação entre rel="amphtml" e canonical, validar o conteúdo e garantir que a página hospedada no próprio domínio entregue boa experiência. A atualização está registrada no histórico oficial da documentação do Google Search.
Alterações de canonical podem levar tempo para ser reavaliadas
Outra atualização de julho esclarece que mudanças de canonical não são necessariamente refletidas assim que o código é publicado. O Google precisa rastrear novamente as URLs envolvidas e reprocessar os sinais antes de escolher a página representativa.
Isso muda a forma de validar migrações, duplicações e correções de URL. O desenvolvedor deve conferir códigos de resposta, links internos, sitemap, redirecionamentos e canonical em conjunto, evitando sinais contraditórios. Depois, é preciso acompanhar o Search Console e permitir tempo para reavaliação, como explica o guia de solução de problemas de canonicalização.
O arquivo llms.txt não melhora a visibilidade no Google
Em junho, o Google acrescentou uma nota direta à documentação sobre otimização para recursos generativos: o arquivo llms.txt não Você precisa para a Pesquisa Google e não produz efeito positivo ou negativo em visibilidade ou posições. Isso não impede que o arquivo seja mantido para outros sistemas que decidam utilizá-lo. A consequência prática é não vender sua implementação como “SEO para IA” no Google. Para Search, continuam importantes o acesso ao conteúdo, a indexabilidade, os links, os dados estruturados adequados e a qualidade da informação.
SEO tradicional continua sendo a base para AI Overviews e AI Mode
O novo guia do Google sobre recursos generativos reforça que não existe uma marcação especial para entrar em AI Overviews ou AI Mode. As práticas que permitem rastreamento, indexação e compreensão do conteúdo continuam válidas.
O documento também recomenda conteúdo não comoditizado: informação que ofereça experiência, análise, dados ou utilidade além de um resumo genérico. Imagens e vídeos próprios, presença local consistente e informações de produtos bem estruturadas podem ampliar as formas pelas quais um conteúdo é encontrado. O Google detalha essas orientações no recurso oficial sobre otimização para recursos de IA na Pesquisa.
Para a Base de Ártemis, isso confirma uma decisão editorial importante: usar IA para apoiar o processo não substitui contexto, revisão e posicionamento. Essa relação também aparece na análise sobre até onde confiar na IA para gerenciar campanhas.
FAQ rich results deixaram de aparecer
O Google descontinuou em maio a exibição de FAQ rich results e removeu a documentação correspondente em junho. Isso não torna perguntas frequentes inúteis para leitores. Elas ainda podem organizar dúvidas reais e melhorar a compreensão da página, mas não devem ser mantidas apenas pela expectativa de ocupar mais espaço visual no resultado.
Desenvolvedores podem remover implementações mantidas exclusivamente para esse recurso, especialmente quando aumentam complexidade ou geram marcação desconectada do conteúdo visível. O princípio permanece: dados estruturados devem representar com precisão aquilo que a pessoa encontra na página.
og:image ganhou mais importância como indicação de imagem preferida
Em março, o Google esclareceu que pode usar tanto dados estruturados quanto a meta tag og:image para escolher miniaturas em resultados e no Discover. Para equipes de desenvolvimento, isso pede consistência entre imagem destacada, Open Graph e marcação estruturada.
A imagem precisa estar acessível ao rastreador, ter boa resolução e representar o conteúdo. Não basta preencher a tag com um arquivo genérico repetido em todo o site. A referência está nas boas práticas oficiais de SEO para imagens.
Ferramentas de SEO precisam ser avaliadas, não obedecidas
O Google também publicou orientações para avaliar ferramentas, serviços e recomendações de terceiros. Pontuações internas podem ajudar a priorizar problemas, mas não representam o funcionamento exato dos sistemas de classificação.
Antes de implementar uma sugestão automática, o desenvolvedor deve perguntar qual problema ela resolve, qual documentação sustenta a mudança e como o resultado será medido. Esse cuidado evita alterações extensas motivadas por alertas que não têm impacto real para usuários ou rastreadores.
Checklist técnico depois das atualizações
- Manter páginas importantes acessíveis, indexáveis e com resposta HTTP correta.
- Alinhar canonical, redirecionamentos, sitemap e links internos.
- Tratar AMP como tecnologia de entrega, não como fator de ranqueamento.
- Não atribuir ao
llms.txtbenefícios que o Google afirma não utilizar. - Revisar dados estruturados e remover marcações obsoletas.
- Definir imagens relevantes em Open Graph e dados estruturados.
- Produzir conteúdo original, útil e apoiado por fontes identificáveis.
- Validar recomendações de ferramentas antes de alterar o site.
Conclusão
As novas orientações reduzem espaço para atalhos e reforçam fundamentos. O trabalho técnico continua sendo facilitar acesso, interpretação e confiança, enquanto o trabalho editorial precisa entregar algo que não seja apenas uma reformulação do que já existe.
Para acompanhar mudanças sem transformar cada atualização em alarme, visite o Radar de Ártemis. A proposta é separar o que exige ação daquilo que apenas ganhou uma nova página na documentação.
