Google vai suportar o método HTTP QUERY, mas ainda não agora

Gary Illyes, da equipe de busca do Google, publicou no LinkedIn que o Google Search vai suportar o novo método HTTP QUERY, mas com uma ressalva importante: só quando "o ecossistema alcançar" o padrão. A informação foi reportada pelo Search Engine Roundtable e vale menos pelo anúncio em si (que é sobre um futuro difuso) e mais pelo problema técnico que o QUERY promete resolver: o velho impasse entre GET e POST em navegação facetada e filtros de busca pesados.

O impasse que o QUERY resolve

Hoje, quem constrói uma página com filtros complexos (e-commerce↳E-commerce21 conteúdosECBR Club: novo espaço para devs se conectarem ao ecossistema de e-commerceDev (Back & Front) · mai 2025TOTVS anuncia joint venture com VTEXMarketing Tech · mai 2019Jovens da Brasilândia recebem formação gratuita em tecnologiaGestão Dev & TI · jul 2025Ver tudo em Marketing Tech → com dezenas de facetas de cor, tamanho, marca, faixa de preço) escolhe entre dois caminhos, ambos com defeitos.

O GET empacota todos os parâmetros na URL. É seguro (não altera estado no servidor) e cacheável por CDNs e proxies, o que é ótimo para performance e para rastreabilidade. O problema aparece quando os filtros crescem: a URL vira uma string quilométrica cheia de ?cor=azul&tamanho=42&marca=x&preco_min=100..., difícil de gerenciar e sujeita a limites de tamanho de URL.

O POST aceita um corpo de requisição de qualquer tamanho, o que resolve o problema de payload grande. Mas, como o próprio Illyes resume, intermediários não fazem cache de POST por padrão. Resultado: você quebra o cache de edge/CDN e, em muitos casos, a própria capacidade do Googlebot de rastrear aquele conteúdo, já que o crawler prioriza GET.

O QUERY combina as peças que faltavam. Ele é seguro e idempotente como o GET (pode ser repetido ou reiniciado sem risco de efeito colateral no servidor), é cacheável como o GET, mas transporta um corpo estruturado como o POST. Na prática, um servidor poderia receber um payload rico de filtros (um JSON com toda a seleção de facetas) de forma limpa, sem gerar URLs grotescas nem recorrer a rotas POST que estragam cache e crawlability.

Vale registrar a honestidade de Illyes ao explicar o termo idempotente: ele disse que aprendeu a palavra "com o Martin, mas não faço ideia do que significa". Para o registro: idempotente quer dizer que executar a operação uma ou várias vezes produz o mesmo resultado, sem acumular mudanças, exatamente o que torna seguro repetir uma requisição.

O que diz a especificação

O QUERY está definido em rascunho pelo IETF e, conforme a citação do RFC trazida pela fonte, descreve um método que "solicita que o alvo processe o conteúdo incluído de maneira segura e idempotente e responda com o resultado desse processamento". É semanticamente parecido com o POST no formato (tem corpo), mas com as garantias de segurança e idempotência do GET. Essa combinação é justamente o que permite o cache: um intermediário sabe que pode guardar e reusar a resposta sem risco.

Por que "eventualmente" é a palavra-chave

O anúncio é deliberadamente cauteloso, e com razão. Illyes foi explícito: "a adoção ampla vai levar tempo". Ele listou o que precisa ser atualizado antes de o método ser útil de verdade:

• Servidores web, CDNs e proxies reversos precisam entender o método nas suas pilhas de rede;
• Navegadores precisam suportá-lo nativamente;
• O próprio HTML↳HTML45 conteúdosA importância do HTML e CSS para quem trabalha com UI Design e Design SystemProduto & UX · dez 2024Como hostear seu site HTML gratuitamente com GitHub PagesDev (Back & Front) · jun 2025SQL Server – Como criar um versionamento de código das suas Stored Procedures em HTML e com comentários da alteraçãoData · nov 2020Ver tudo em Dev (Back & Front) → precisa de atualização para permitir formulários que disparem QUERY;
• CORS também entra na conta, já que requisições com corpo estruturado e método não convencional caem nas regras de preflight.

São "os próximos dois anos", nas palavras dele. Ou seja: mesmo que o Google esteja disposto a suportar, não adianta o crawler entender QUERY se o navegador do usuário, o CDN na frente do site e o servidor de origem ainda não falam essa língua. É uma mudança de infraestrutura de camadas, não uma feature que se liga num painel.

O que o dev brasileiro deve fazer hoje

A resposta prática é curta e o próprio Illyes a entregou: "Até lá, mantenha suas URLs organizadas." Nada muda no curto prazo, e cair na tentação de gambiarras para antecipar o QUERY seria contraprodutivo.

O que faz sentido agora, para quem opera e-commerce ou qualquer site com navegação facetada no Brasil:

• Não migre nada para POST achando que resolve rastreabilidade. Continua sendo verdade que POST prejudica cache e crawl. Se o conteúdo por trás de um filtro precisa ser indexado, ele tem que estar acessível via GET com URL limpa.
• Revise a estrutura de URLs de facetas. Defina quais combinações de filtro merecem ser indexadas (as de real valor de busca) e quais devem ser bloqueadas por robots.txt ou marcadas com noindex/canonical. Isso já é boa prática e vai continuar sendo mesmo depois do QUERY.
• Meça o desperdício de crawl budget. Vale abrir os relatórios de cobertura e as estatísticas de rastreamento no Google Search Console para identificar quantas URLs de filtro estão consumindo rastreamento sem gerar valor. Esse é o número que o QUERY promete melhorar lá na frente, então saber o baseline agora ajuda a medir o ganho quando ele chegar.

O trade-off que fica em aberto

O ponto delicado do QUERY é o SEO em si. URLs são a espinha dorsal da indexação: cada URL única é um endereço que o buscador pode listar, compartilhar e ranquear. Uma requisição QUERY com o estado dos filtros num corpo estruturado, em vez de na URL, levanta a pergunta de como esse conteúdo seria referenciado e indexado. A fonte não detalha como o Google pretende reconciliar isso, e essa é a maior incógnita técnica.

Provavelmente o QUERY fará mais sentido para respostas dinâmicas que não precisam de indexação individual (o resultado de um filtro muito específico, por exemplo), enquanto as páginas de faceta com valor de busca continuarão dependendo de URLs canônicas bem definidas. Ou seja, o método tende a ser uma ferramenta a mais, não um substituto do GET limpo para o que importa em ranqueamento.

Em resumo: o QUERY é uma boa notícia de engenharia, resolve uma dor real de arquitetura web e o Google sinalizou que vai acompanhar. Mas é um movimento de médio prazo que depende de toda a cadeia (navegador, CDN, servidor, HTML, CORS) evoluir junto. Por ora, a recomendação técnica não mudou: URLs enxutas, facetas bem controladas e crawl budget monitorado.

Fonte: Search Engine Roundtable