Google Search plans to support the new HTTP QUERY method, but that does not make QUERY an SEO implementation option today. In an August 2026 LinkedIn post, Google Search Relations analyst Gary Illyes said Google Search would support the method “eventually as the ecosystem catches up”. He pointed to faceted navigation and complex filters as useful cases, while also warning that servers, CDNs, reverse proxies, browsers, HTML and other parts of the web stack still need broader support.
For technical SEO teams, the useful question is not whether QUERY sounds cleaner than long parameter URLs. It is whether a search engine can discover a query state, request it reliably and associate the result with a resource that can participate in indexing. Google has not yet published that implementation model. Until it does, existing URL discovery, crawling and indexing practices remain the basis for search visibility.
- RFC 10008, published in June 2026, defines QUERY as a safe, idempotent HTTP method that carries request content and supports caching.
- Gary Illyes said Google Search intends to support QUERY in the future, but Google has announced neither a rollout date nor a current site-owner implementation requirement.
- QUERY can be associated with GET-accessible URIs through HTTP response fields, but assigning those URIs is optional. The method therefore does not automatically create crawlable or indexable URLs.
- Google’s current faceted-navigation guidance still focuses on controlling URL spaces and deciding which filtered URLs should be available for crawling.
- For now, important search landing pages should retain stable URLs, crawlable links and consistent canonical and indexing signals.
Google’s announcement is about future crawler capability, not a new SEO rule
Illyes described HTTP QUERY as a possible answer to a technical compromise that becomes obvious on sites with complex filtering. GET gives a request a URL and works naturally with web caching, but large numbers of filter values can produce long and combinatorial query strings. POST can carry structured request content, but it has different semantics and is not normally the model search engines use to discover ordinary indexable web resources.
QUERY is designed for a server-side query whose request content does not change server state. Illyes highlighted faceted navigation and heavy filters as examples where those properties could be useful. His more important SEO message, however, was about timing: Google Search support comes later, after the wider infrastructure can handle the method reliably.
That distinction prevents a standards announcement from turning into premature implementation advice. There is no Google Search documentation telling site owners to replace GET-based filtered URLs with QUERY, no migration recommendation, and no published crawler behaviour explaining how QUERY resources should be exposed for indexing.
What RFC 10008 actually gives QUERY
RFC 10008, published in June 2026, defines QUERY as an HTTP method that asks a target resource to perform a query using content contained in the request. It is defined as both safe and idempotent. A QUERY response is also cacheable, although caching is more complicated than GET because the request content and related metadata form part of the cache key.
| Property | GET | QUERY | Why it matters |
|---|---|---|---|
| Safe | Yes | Yes | The operation is intended for retrieval rather than changing server state. |
| Idempotent | Yes | Yes | Repeating the same request is expected to have the same operational effect. |
| Structured request content | Not the normal GET model | Yes | Complex filters do not have to be encoded entirely in the request URL. |
| Cacheable response | Yes | Yes | QUERY was designed to support caching, although the request body affects the cache key. |
| URI for the query | Built into the GET request | Optional | This is the important distinction for crawling and indexing. |
The final row deserves more attention than it usually gets in SEO discussions.
QUERY does not automatically solve URL discovery
The web standard and a search engine have different jobs. RFC 10008 defines how clients and servers can communicate. It does not define which application states Google should discover, crawl, canonicalise or index.
The RFC allows a QUERY response to provide a Location header identifying an equivalent resource. That resource can then be requested with GET without sending the original QUERY body again. A Content-Location can similarly identify a resource corresponding to the result that was returned.
But these mappings are optional. A server can process a QUERY request without assigning a durable GET-accessible URI to either the query or its result.
That creates the central SEO question. Search engines work with discoverable resources and URLs. Google explains that it normally discovers pages by following links and other URL sources, then sends requests to those URLs during crawling. If a useful filtered state exists only as request content and has no discoverable URI, current SEO assumptions about linking, canonicalisation, sitemap inclusion and indexing cannot simply be transferred to it.
Google still needs to explain how its planned QUERY support will bridge that gap.
Why faceted navigation makes QUERY interesting
Faceted navigation is the clearest SEO use case because it exposes the cost of representing every application state as a URL.
A catalogue might allow users to combine brand, colour, size, price, availability, material and sort order. When those selections are encoded as URL parameters, the number of possible URLs can grow rapidly. MOCOBIN’s guide to URL parameters and SEO covers the current problem: useful filters and low-value permutations can exist in the same URL space, so teams need to decide which variations deserve search visibility.
Google’s current faceted-navigation documentation makes the same distinction. If filtered URLs do not need to appear in search, Google recommends preventing unnecessary crawling. If those pages do have potential search value, their URLs need to follow crawler-friendly practices. Google specifically warns that large faceted URL spaces can lead to overcrawling and slower discovery of more useful pages.
QUERY could eventually reduce the need to encode every interactive combination into an ever-growing query string. That is an application architecture benefit.
It is not yet an indexing strategy.
A filtered interface and an indexable landing page may still be different resources
Even after Google Search supports QUERY, teams should not assume that every user-selected filter should become a search landing page.
Consider a retailer with hundreds of possible colour, size, price and availability combinations. Most combinations may exist only to help shoppers narrow the catalogue. A smaller subset may correspond to durable search demand and deserve a dedicated search presence.
Those are two different requirements:
- Application filtering: let the user ask the catalogue for a specific combination of data.
- Search discovery: provide a stable resource that crawlers can discover, revisit, understand and potentially index.
QUERY may become useful for the first requirement without eliminating the second.
RFC 10008’s optional Location mechanism is particularly relevant here because a server can associate a QUERY operation with an equivalent URI that later works through GET. Whether Google will use such mappings for discovery or indexing has not been documented. Until it is, treating those protocol features as SEO instructions would go beyond the evidence.
What should technical SEO teams do now?
The answer is mostly to avoid changing a working architecture merely because a new HTTP method exists.
Keep important landing pages addressable
If a category, product variation or filtered collection deserves organic search visibility, keep it available through a stable URL that your site can link to consistently. Use the same preferred URL across internal links, canonical signals and other discovery systems where appropriate.
Control faceted URL spaces deliberately
Do not wait for QUERY to solve an existing parameter problem. Classify filters according to whether they create genuine search value. Low-value sorting and combinatorial states usually need a different crawl strategy from stable landing pages that answer identifiable demand.
Use crawl-budget work where scale justifies it
On large sites, uncontrolled filter combinations can consume substantial crawler and server resources. MOCOBIN’s crawl budget guide covers that problem. Smaller sites should not turn QUERY into a crawl-budget project simply because the protocol is new.
Let development testing stay development testing
Teams experimenting with QUERY should test servers, frameworks, proxies, CDNs, caches and clients across the complete request path. RFC support at the protocol level does not guarantee that every part of a production stack handles the method correctly.
The RFC also notes that QUERY is not a CORS-safelisted method. Cross-origin browser use therefore requires a preflight request under current Fetch rules. That is another reason broad browser and platform support matters before QUERY becomes routine application infrastructure.
What would actually change the SEO recommendation?
A second Gary Illyes comment confirming intent would add little. The meaningful milestone is implementation documentation.
For this page, the signals worth watching are much more specific:
- Google documenting that Googlebot sends QUERY requests in Search crawling;
- guidance explaining how Google discovers resources that require QUERY request content;
- documentation covering whether
Location,Content-Locationor another URI mapping participates in discovery and indexing; - canonicalisation guidance for a QUERY operation and any GET-accessible equivalent resource;
- updated faceted-navigation documentation that explicitly incorporates QUERY;
- broader production support across browsers, servers, CDNs and web frameworks.
As of 18 September 2026, Google’s current Search Central and crawling-documentation update logs do not announce such an implementation. The status therefore remains straightforward: Google Search intends to support HTTP QUERY, but site owners should continue designing important search resources around the crawlable URL model Google documents today.
For the wider technical foundation, MOCOBIN’s technical SEO guide explains how crawl access, indexability, canonical signals and site structure fit together. HTTP QUERY may eventually change part of the request layer. It does not currently change that decision order.
