Google Search plans to support the new HTTP QUERY method, but there is no rollout date and no implementation change for site owners yet. In an August 17, 2026 LinkedIn post, Google Search Relations analyst Gary Illyes said Google Search would support QUERY “eventually as the ecosystem catches up”. He also warned that adoption across web servers, CDNs, reverse proxies, browsers, HTML, and other parts of the web stack will take time.
- Google has not announced that QUERY support is live. Illyes described it as future support that depends on wider ecosystem adoption.
- RFC 10008, published in June 2026, defines QUERY as a safe and idempotent HTTP method that carries request content for a server-side query.
- Faceted navigation and complex search filters are potential use cases, but Google has not published Search documentation explaining how QUERY-driven resources will be discovered, crawled, indexed, or canonicalised.
- Sites do not need to migrate for SEO purposes. Existing URL, crawl, canonical, and indexing practices remain the practical basis for search visibility.
What Gary Illyes Said About HTTP QUERY
Illyes presented QUERY as a way to address a familiar trade-off between GET and POST. In his LinkedIn post, he pointed to faceted navigation and heavy search filters as cases where a request body could carry complex filter data while the method remains safe and idempotent.
The important part for SEO is the status. Illyes did not announce a current Googlebot capability, migration requirement, or rollout schedule. He said Google Search would support QUERY in the future as the surrounding ecosystem catches up, adding that site owners should keep their regular URLs tidy in the meantime. Search Engine Roundtable reported the statement on August 18, 2026 as future support rather than a live Search feature.
What RFC 10008 Defines
RFC 10008 is an IETF Standards Track document published in June 2026. It defines QUERY as a method for asking a target resource to perform a query using enclosed request content. QUERY requests are safe and idempotent, and QUERY responses are cacheable under the rules set out in the specification.
This differs from GET and POST in a specific way. HTTP does not define general semantics for content in a GET request. POST can carry request content, but a POST operation is not inherently safe or idempotent. QUERY provides a dedicated method for a server-side query that expects request content while preserving those read-oriented semantics.
The RFC also allows a server to identify an equivalent resource or query result with a URI through response fields such as Location or Content-Location. That is useful protocol behaviour, but it does not tell search engines which QUERY-driven states should be indexed. Google still needs to document how its crawler and indexing systems will handle those resources before there is a defined SEO implementation model.
Why Faceted Navigation Is the Main SEO Use Case
Faceted navigation can generate large numbers of URL combinations for attributes such as brand, colour, size, price, availability, and sort order. On large ecommerce and directory sites, those combinations can create unnecessary crawl paths and many URLs with little independent search value. MOCOBIN’s guide to URL parameters and SEO explains how those patterns affect URL management.
QUERY could eventually let an application send richer filter instructions in request content instead of encoding every input in the URL. That is the architectural benefit Illyes highlighted. It should not be treated as an automatic fix for faceted navigation, duplicate URLs, or index bloat.
Google’s current faceted navigation guidance still focuses on controlling crawlable URL patterns and making deliberate decisions about which filtered states should be available to crawlers. Google has not yet published equivalent Search guidance for QUERY.
What SEO and Development Teams Should Do Now
No SEO migration is required. Important search landing pages should continue to use stable, crawlable URLs, and teams should keep internal links, canonical signals, indexing directives, and sitemap choices aligned with the URLs they actually want search engines to process.
On larger sites, review whether parameter-generated combinations are creating unnecessary crawl demand before changing application architecture. The crawl budget guide is relevant when site scale, rapid URL generation, or frequent updates make crawl efficiency a genuine operational concern.
Development teams interested in QUERY should test support across the full request path rather than assuming the RFC alone guarantees production compatibility. The RFC also states that QUERY is not a CORS-safelisted method, so cross-origin browser requests require a preflight under current Fetch rules.
From an SEO perspective, the next meaningful signal will be Google Search documentation that explains how Googlebot sends QUERY requests, how QUERY-driven resources become discoverable, and how indexing and canonicalisation should work. Until then, the safer approach is to maintain established technical SEO practices and treat QUERY as a web standard with planned Google Search support, not as a live optimisation tactic.
