Title: Caching of query parameters
Author: WordPress VIP Documentation
Published: December 9, 2022
Last modified: April 9, 2026

---

 1. [Caching](https://docs.wpvip.com/caching/)
 2. [Page cache](https://docs.wpvip.com/caching/page-cache/)
 3. Caching of query parameters

#  Caching of query parameters

When receiving a request for a URL, the [page cache](https://docs.wpvip.com/caching/page-cache/)
considers the entirety of the URL, including `GET` parameters. As a result, the 
page cache will identify `example.com/?a=1&b=1` as different from `example.com?b
=1&a=1` and cache each variant separately. This caching behavior provides a more
scalable method for serving variations of a page to specific user groups.

Because each variant of a URL’s `GET` parameters are cached separately, an increase
in the number of variants for a URL can have performance implications for a site,
particularly during a high traffic event. The first request for each variant will
bypass cache and will result in SQL queries on the [origin server](https://docs.wpvip.com/origin-servers/).
A large volume of direct SQL queries can overload the primary database and lead 
to an increase in responses with a `503` HTTP status code.

 * Avoid using very explicit times (e.g., specifying minutes or seconds) in query
   parameters. Instead, round the dates and times up to the closest day, hour, or
   minute.
 * Avoid creating email campaigns that generate a wide variety of query parameter
   variants. Reduce the number of variants wherever possible.

## Filtered query parameter values

The values of a specific set of `GET` parameters in a request URL are filtered and
are therefore not cached as variants. This is a default behavior of VIP infrastructure
and cannot be customized per application.

Values for these query parameters are filtered by the page cache: 
`_`, `_ga`, `
__lsa`, `affiliate`, `dclid`, `eref`, `fb_ref`, `fb_source`, `fb_xd_bust`, `fb_xd_fragment`,`
fbclid`, `fbid`, `gclid`, `gref`, `hootPostID`, `hpt`, `ia_share_url`, `icid`, `
iid`, `iref`, `linkId`, `migAgencyId`, `migRandom`, `migSource, migTrackDataExt`,`
migTrackFmtExt`, `mod`, `ncid`, `npt`, `omcamp`, `pretty`, `snapid`, `srsltid`, `
ttclid`, `wsrlui`,`ScCid`

If any of the query parameters listed above are included in a request for a URL,
the query parameters will be cached but their values will be ignored. The page cache
will check all other query parameters and values in the URL before potentially passing
the request to the origin server.

For example:

 * The page cache receives an incoming request for `www.example.com/?fbclid=100`.
   If there is no cached response for `www.example.com/?fbclid`, then the full request
   is passed to the [origin web server](https://docs.wpvip.com/infrastructure/origin-servers/).
   The response from origin is then cached at the edge with the key `www.example.
   com/?fbclid`, and will be served to later requests for `www.example.com/?fbclid
   =123` and `www.example.com/?fbclid=456`.
 * `www.example.com/?hpt=foo&bar=baz` is rewritten as `www.example.com/?hpt&bar=
   baz`.
 * Query strings with a value and no name, such as `www.example.com/?=foo` are also
   filtered to reflect `www.example.com/`.

## Purging a URL from the page cache

When [purging a URL from the page cache](https://docs.wpvip.com/caching/page-cache/purge-urls/),
all variants of the URL’s `GET` parameters will also be purged.

Last updated: April 09, 2026