Méthode HTTP QUERY : Google Search la prendra en charge « à terme », selon Gary Illyes

L’essentiel

• Gary Illyes (Google) écrit sur LinkedIn que Google Search prendra en charge la méthode HTTP QUERY « à terme ».
• Aucun calendrier : serveurs web, CDN, reverse proxies et navigateurs doivent d’abord évoluer, tout comme HTML et CORS.
• QUERY est normalisée par l’IETF depuis juin 2026 (RFC 10008, statut Proposed Standard).
• En attendant, la consigne est de garder des URL classiques propres, facettes comprises.

Gary Illyes : un support annoncé, sans date

Gary Illyes, analyste de l’équipe Search de Google, a expliqué dans un post LinkedIn, relayé le 18 août 2026 par Search Engine Roundtable, pourquoi on le sollicitait sur des méthodes HTTP peu courantes. La raison tient en une phrase : « HTTP dispose d’une nouvelle méthode appelée QUERY » (traduction).

Google Search la prendra en charge « à terme, à mesure que l’écosystème suivra » (traduction). Pas de date. Gary Illyes prévient que l’adoption prendra du temps : « les serveurs web, les CDN, les reverse proxies et les navigateurs doivent d’abord mettre à jour leur pile réseau, d’ici deux ans environ. Même HTML doit être mis à jour avant, sans parler de CORS » (traduction). Pour la période intermédiaire, il se contente d’un conseil : « D’ici là, gardez des URL classiques bien tenues » (traduction).

C’est la déclaration d’un Googler, pas une annonce documentée. Rien n’a été publié sur Search Central. On ignore donc quels robots seraient concernés (Googlebot seul ou l’ensemble des crawlers de Google) et comment une réponse obtenue par QUERY serait traitée à l’indexation.

QUERY : une requête sûre qui transporte un corps

La méthode est définie par la RFC 10008, « The HTTP QUERY Method », publiée en juin 2026 par le groupe de travail httpbis de l’IETF. Elle est signée Julian Reschke (greenbytes), James Snell (Cloudflare) et Mike Bishop (Akamai), et succède au brouillon draft-ietf-httpbis-safe-method-w-body.

QUERY se place entre les deux méthodes les plus utilisées. GET est sûre et se met en cache, mais tous ses paramètres passent par l’URL. POST accepte un corps de requête, n’est pas mise en cache par défaut et peut modifier l’état du serveur. QUERY transporte un corps comme POST, tout en restant sûre et idempotente comme GET, et sa réponse peut être mise en cache. Un client peut donc la relancer sans risque, par exemple après une coupure réseau.

Le texte impose que la clé de cache d’une requête QUERY intègre le contenu envoyé et les métadonnées qui l’accompagnent : deux requêtes aux corps différents ne doivent pas recevoir la même réponse en cache. Un serveur annonce qu’il accepte QUERY, et les formats de requête qu’il comprend, avec l’en-tête Accept-Query. Il peut aussi renvoyer un en-tête Location vers une URI que le client interrogera ensuite en GET pour répéter la requête sans renvoyer le corps. La RFC précise que cette URI peut n’être que temporaire.

Navigation à facettes : l’usage visé

Gary Illyes cite lui-même la navigation à facettes et les recherches chargées de filtres. Sur un site e-commerce, chaque combinaison de couleur, de taille, de prix et de tri produit aujourd’hui une URL à paramètres. Ces URL se multiplient vite et consomment une partie du crawl. Passer les filtres en POST règle ce problème, mais la réponse perd alors le cache et l’adresse stable.

Avec QUERY, les filtres voyageraient dans le corps de la requête, sans allonger l’URL et sans renoncer au cache des CDN. La suite relève de l’interprétation : l’en-tête Location pourrait servir de passerelle vers une URL indexable. Google n’a rien dit de la façon dont il traiterait ces réponses.

Pour rappel, le post que Gary Illyes repartage à cette occasion indiquait que les crawlers de Google envoient déjà d’autres méthodes que GET et POST (HEAD, OPTIONS, PUT, PATCH, DELETE), déclenchées par le JavaScript au moment du rendu. Elles pèsent moins de 1,5 % de leurs requêtes (voir mon article).

Ce que j’en retiens

Je n’y vois aucun chantier pour 2026. Basculer ses filtres vers QUERY aujourd’hui n’apporterait rien en référencement : Google Search ne la prend pas encore en charge et les formulaires HTML ne savent émettre que GET et POST. Le conseil utile est la dernière phrase de Gary Illyes. Sur les facettes existantes, cela veut dire limiter les combinaisons explorables, garder un ordre de paramètres constant et n’ouvrir à l’indexation que les combinaisons qui correspondent à une vraie recherche des internautes. Le reste peut être bloqué au crawl ou rattaché par la balise canonical à une page de référence.

Un contrôle rapide : dans le rapport Statistiques sur l’exploration de la Search Console, regardez quelle part des requêtes de Googlebot part vers des URL à paramètres. Côté infrastructure, je surveillerais surtout les notes de version de votre CDN et de votre serveur web. Le signal d’adoption viendra de là, bien avant une page de documentation chez Google.