A rotina de quem cuida de SEO ganhou novidades diretamente do Google nesta semana. Entre os temas mais comentados está o uso do código 503 durante manutenções rápidas por conta de patches de PHP, além de esclarecimentos sobre o que o robots.txt realmente controla quando o assunto é crawler e agente de inteligência artificial. Também entraram na pauta a forma como o Google trata URLs com colchetes e o suporte (ou melhor, a falta dele) para imagens em JPEG XL. Reunimos tudo que importa pra quem trabalha com sites e busca orgânica.
Google orienta usar 503 ao tirar o site do ar para corrigir falhas no PHP
Em uma publicação no LinkedIn no dia 21 de outubro, o Google Search Central reforçou uma recomendação simples, mas importante: quem precisar derrubar servidores para aplicar patches de PHP deve retornar o código de status 503. O aviso saiu justamente no mesmo dia em que o PHP lançou correções emergenciais para duas falhas classificadas como críticas.
Segundo o próprio comunicado, o 503 “garante que URLs já indexadas sejam preservadas na Busca enquanto você trabalha” — e por isso a orientação é evitar páginas de erro 404 ou, pior ainda, retornar um 200 genérico durante a instabilidade. John Mueller, do Google, reforçou o recado no Bluesky, lembrando que o 503 não precisa necessariamente ser servido via PHP. Vale destacar ainda que, segundo a documentação de taxa de rastreamento do Google, o uso do 503 deve ficar limitado a no máximo 1 ou 2 dias, já que páginas que insistem em retornar esse código por muito tempo correm o risco de sair do índice.
Na prática, isso significa que, se o seu site cair justamente por causa do patch do PHP, o 503 precisa ser disparado por algo que continue funcionando mesmo com o PHP fora do ar — por exemplo, uma regra de roteamento na CDN ou um servidor temporário apontado pelo DNS. E atenção: de acordo com o guia do Google sobre pausar um site, se o 503 for disparado também nas respostas do robots.txt, todo o rastreamento acaba sendo bloqueado.
Illyes esclarece: robots.txt controla rastreamento, não o uso posterior do conteúdo
Gary Illyes, do Google, trouxe um ponto que gera bastante confusão no mercado. Em vídeo do Search Central publicado em 21 de outubro, ele explicou que, conforme a RFC 9309, as regras padrão do robots.txt servem apenas para dizer o que crawlers compatíveis podem ou não rastrear. Ou seja, essas diretivas não dizem nada sobre como o conteúdo é usado depois de coletado.
Illyes chamou o robots.txt de “um protocolo de preferência de acesso” e explicou que, para bloquear um crawler de IA específico enquanto libera outros, é preciso mirar no token do user-agent daquele robô em particular. A lista de crawlers comuns do Google documenta o Google-Extended como o token responsável por controlar se o conteúdo rastreado pelo Google pode ser usado no treinamento de futuros modelos Gemini e no embasamento de respostas no Gemini Apps e na Vertex AI — mas, segundo o próprio Google, esse token não interfere na presença do site na Busca. Vale lembrar que o Google-Extended não é um crawler separado e nem possui sua própria string de user-agent HTTP. Há ainda uma proposta de rascunho, coescrita por Illyes para o IETF, que criaria uma regra chamada Content-Usage no robots.txt justamente para declarar preferências de uso — mas, por enquanto, segue apenas como documento de grupo de trabalho, sem aprovação.
Na prática, uma regra Disallow sob o token de um crawler ajuda a mantê-lo longe dos caminhos listados. Para limitar o uso do conteúdo rastreado pelo Google em treinamentos do Gemini, o Google-Extended é o caminho. Já uma forma padronizada de expressar preferência de treinamento separada do acesso de rastreamento, por enquanto, só existe como rascunho.
Cloudflare e OpenAI apontam novas páginas encontradas para a busca do ChatGPT
Cloudflare e OpenAI divulgaram que um projeto-piloto de pesquisa ajudou a OpenAI a descobrir e indexar centenas de milhões de novas páginas na web, ampliando a base de informações disponível para o ChatGPT.
- O piloto envolveu cerca de 1% da rede da Cloudflare, usando sinais que ajudam o crawler da OpenAI a identificar páginas, ignorar páginas inexistentes e perceber quando um conteúdo foi atualizado.
- A publicação, de 15 de outubro, foi coescrita por dois funcionários da OpenAI e afirma que a descoberta de novas páginas “pode inicialmente aumentar o rastreamento”.
- O texto não informa com que frequência essas páginas recém-identificadas estão sendo citadas, nem traz dados sobre volume de visitas gerado a partir delas.
Um trecho chama atenção: “um sinal sobre uma página não concede permissão para acessá-la”. Isso é relevante porque a documentação de crawlers da OpenAI separa claramente busca e treinamento. Um site pode, por exemplo, usar no robots.txt um Allow para o OAI-SearchBot e, ao mesmo tempo, um Disallow para o GPTBot, deixando claro que aquele conteúdo não deve ser usado para treinar modelos. Além disso, como a própria OpenAI faz seu próprio ranqueamento de páginas, ter sido encontrado pelo piloto não garante, de forma alguma, que o site vai aparecer como citação.
Colchetes brutos e codificados geram URLs diferentes, confirma Mueller
Outro esclarecimento importante veio de John Mueller no Bluesky, em 19 de outubro: colchetes usados diretamente em uma URL e suas versões codificadas em percentual (%5B e %5D) criam, na prática, URLs distintas para o Google. Ele até admitiu ter achado, no passado, que eram equivalentes, e reconheceu: “provavelmente dei a resposta errada sobre isso antes”.
Mueller citou a RFC 3986 — o padrão de sintaxe de URI, que reserva colchetes e sinais de mais — e explicou que, quando um site retorna o mesmo conteúdo para as duas versões da URL, o Google acaba rastreando ambas, eliminando as duplicatas e escolhendo uma delas para manter. A recomendação prática dele é direta: “escolha uma” forma e use-a de maneira consistente em todo o site, incluindo links, tags canônicas, entradas de sitemap e dados estruturados. Isso está alinhado, aliás, com a documentação do Google sobre estrutura de URL, que já determinava que caracteres reservados precisam ser codificados em percentual.
O risco de misturar as duas formas é que, quando links e tags canônicas combinam colchetes brutos e codificados, o Google pode ter que decidir sozinho qual versão manter. Se o seu site já usa colchetes brutos em todo lugar, Mueller disse esperar que isso continue funcionando — ainda que ele mesmo tenha ressalvado que “não montaria um site novo assim”.
JPEG XL ainda não é compatível com Google Imagens nem com prévias do Discover
Imagens em formato JPEG XL continuam sem suporte no Google Imagens e também nas prévias exibidas no Discover, segundo confirmou John Mueller no Bluesky em 15 de outubro.
O comentário veio pouco depois do JPEG XL ganhar suporte no Chrome 155 — distribuição ampla iniciada em 6 de outubro — e no Firefox 158, em 13 de outubro. Apesar disso, a documentação de SEO para imagens do Google lista como formatos suportados em um atributo src de elemento img apenas BMP, GIF, JPEG, PNG, WebP, SVG e AVIF; até 22 de outubro, o JPEG XL não constava na lista. Questionado sobre o uso de formatos alternativos dentro de um elemento picture, Mueller respondeu que o elemento inclui um img, “então isso funcionaria para qualquer mecanismo de busca”.
Na prática, a solução é usar o JPEG XL como fonte dentro do picture, mas manter um arquivo em JPEG, WebP ou AVIF no elemento img — assim o formato lido pela Busca continua sendo um dos suportados. O guia do Discover do Google também aponta og:image e marcação schema.org como responsáveis pelas imagens de prévia, então vale garantir que elas apontem para um dos formatos já aceitos.
Pichai projeta agentes de IA acessando sites por navegação e por protocolos
Em entrevista a Alex Heath no podcast Sources, o CEO do Google, Sundar Pichai, afirmou esperar que agentes de inteligência artificial acessem sites de duas formas: navegando pelas páginas como uma pessoa faria e também por meio de protocolos criados especificamente para agentes.
“Acho que você tem os dois caminhos, e eles vão se desenvolver”, disse Pichai.
Ele destacou o avanço de protocolos de agentes e pagamentos, incluindo o Universal Commerce Protocol, que tem apoio do próprio Google. Pichai classificou os protocolos como “uma abordagem muito mais escalável”, mas ponderou que devem levar mais tempo para amadurecer. Mais adiante na conversa, ele disse esperar que os agentes ofereçam uma experiência unificada entre a Busca e o Gemini.
Pelo relato de Pichai, agentes que navegam pelas páginas como humanos continuam relevantes enquanto os protocolos evoluem. Vale lembrar que os próprios agentes hospedados pelo Google navegam como Google-Agent, um dos buscadores acionados por usuários que, segundo o próprio Google, costumam ignorar as regras do robots.txt.
Com informações de searchenginejournal.com.
