Skip to content

Query parameter filtering

By default, any query parameter on a request makes it uncacheable — a ?utm_source=newsletter link and the bare URL would otherwise create distinct cache entries, blowing up the cache size and forcing a MISS for every tracking link in your marketing.

The Ignored Query Parameters setting fixes this by listing parameters the cache should strip from the URL before computing the cache key.

Configured under Settings → Speed Boost → Dashboard → Query Parameter Filtering → Ignored Query Parameters.

The input is a tag-style field — type a parameter name, press Enter, repeat. The plugin ships with a sensible default list that covers the common tracking parameters.

Common entries to add:

  • utm_source, utm_medium, utm_campaign, utm_term, utm_content
  • gclid (Google Ads)
  • fbclid (Facebook)
  • msclkid (Microsoft Ads)
  • mc_cid, mc_eid (Mailchimp)
  • _ga, _gid (Google Analytics)
  • Any internal tracking parameter your team adds

When the request comes in:

  1. Each query parameter is compared against the Ignored Query Parameters list.
  2. Parameters in the list are removed from the cache key, so the cached entry is shared with the bare URL.
  3. The parameters are still visible to your storefront / JavaScript — Shopware receives the full request, which means analytics scripts still see the UTM values.

So the visitor benefits from a cached HIT and your tracking continues to work.

A query parameter not in the list disqualifies the request from caching:

  • The response is generated as normal
  • It’s not stored under any cache key
  • Subsequent requests with the same parameter rebuild the page

If you find an internal parameter is silently bypassing the cache, add it to the list.

Some parameters genuinely change the response — don’t ignore those:

  • Pagination (p, page) — different page = different content
  • Sort (order) — different order = different content
  • Filter (min-price, max-price, properties) — these belong to the listing AJAX flow which has its own caching
  • Search (search) — different search = different content

The plugin already handles these correctly via the AJAX listing routes — you don’t need to add them yourself.

The list can be overridden per sales channel. In most stores you keep one global list.

Open a product page twice:

Terminal window
curl -sI 'https://example.com/p/foo' | grep -i p2lab
curl -sI 'https://example.com/p/foo?utm_source=newsletter' | grep -i p2lab

Both should return HIT (assuming utm_source is in the list and the entry is already cached).