Website Caching Explained: What to Cache and Exclude

Website caching is one of those settings that every host and speed plugin switches on for you, and almost none of them explain. For an agency, that is a problem waiting to happen. A client rings to say the price on the product page does not match the basket, or their paid landing page is quick for you and slow for everyone clicking an ad, and the answer is usually buried in a cache rule nobody chose on purpose. This guide covers what website caching actually does, which pages on a client site to cache and which to exclude, and how to prove it works before the client notices anything.

Quick answer: website caching stores a ready-made copy of a page or file so the server does not rebuild it for every visitor. Cache public pages that look the same for everyone, such as the homepage, blog posts and standard product pages. Never serve cart, checkout, My Account or logged-in pages from a shared cache. Treat ad tracking tags and product filters differently, because one changes nothing on the page and the other changes everything.

Why website caching matters on client sites

Most of the sites agencies sell and maintain run on WordPress. W3Techs puts it at 39.5% of all websites (checked 28 October 2026). Without a page cache, WordPress rebuilds every page from PHP and database queries on every single visit.

Google’s web.dev guidance calls a Time to First Byte of 0.8 seconds or less “good”. Serving a stored copy is one of the most direct ways to get there, and it is usually cheaper than a hosting upgrade.

There is a catch that matters to any agency running paid media. With auto-tagging on, Google Ads adds a unique gclid to every landing page URL. Many caches treat each tag as a new page, and Cloudflare’s cache key documentation confirms its default key includes the full query string. Put those together and the visitors your client is paying for can be the only ones who never get the fast version of the site.

What HIT, MISS and BYPASS mean

Caching means doing the work once instead of every time. On an uncached request WordPress loads, runs the theme and plugins, queries the database and assembles the HTML. A full-page cache skips all of that and sends a stored copy. Every request ends in one of three ways:

• HIT: a stored copy existed and went straight back. This is the fast answer.
• MISS: there was no suitable copy, so WordPress built the page and may keep one for next time. Normal on a first visit.
• BYPASS: the cache was told to skip this request, usually because of a login, a basket or an excluded URL.

A MISS is not an error and a BYPASS is not a failure. On a checkout page, BYPASS is exactly what you want to see in the report you send the client.

The six types of website caching

Caching happens in more than one place, which is why “clear cache” in one plugin does not always change what customers see. When you inherit a client site, list every layer before you touch a setting.

Cache layer	What it stores	Most useful for
Browser	Images, CSS and JavaScript on the visitor’s device	Returning visitors
CDN or edge	Static files, and HTML only if set up to	Visitors far from the server
Full-page	The finished HTML of public pages	Blogs, service pages, catalogue pages
Fragment	Reusable parts of a page	Pages that mix shared and personal content
Object	Database query results, in Redis or Memcached	Busy WooCommerce shops
PHP OPcache	Compiled PHP code	Every WordPress site, usually on by default

For most small business sites, the full-page cache makes the biggest difference for logged-out visitors. Object caching earns its place on busy shops, where pages that cannot be fully cached still run heavy product queries.

Which pages to cache, and which never to cache

Cache a page when every anonymous visitor should see the same thing. Exclude it when the content belongs to one person, or changes with the request. The middle column is where most client shops get caught out.

WooCommerce’s own caching guidance says Cart, My Account and Checkout must stay dynamic because they show customer-specific basket information. It also lists the cookies a cache can use to spot a shopper, including woocommerce_items_in_cart and wp_woocommerce_session_. SiteGround’s Dynamic Cache already excludes cart, checkout and my-account, and skips the cache when a shopper or login cookie is present.

Excluding a page from the full-page cache does not mean giving up on speed. Browser caching, object caching and OPcache still help a checkout load quickly.

Why ad tracking tags and product filters need different rules

This is the part that matters most if you or your client run Google Ads or Meta ads to a WordPress site. Some parameters only record where a visitor came from. Others change what is on the page.

Google Ads adds a gclid to every click and Meta adds an fbclid. If the cache keys on the full query string, every ad click looks like a brand new page. Say a client sends 500 Google Ads clicks a week to one landing page. If gclid is part of the cache key, that could mean up to 500 separate cache entries, so nearly every paying visitor gets the slow MISS while blog readers get the fast HIT. (That is illustrative arithmetic, not a measured figure.)

Parameter	What it does	Cache rule
gclid, gbraid, wbraid, fbclid, msclkid	Identifies an ad click	Ignore in the cache key, after testing
utm_source, utm_medium, utm_campaign	Labels the campaign	Usually safe to ignore, after testing
filter_…, orderby, per_page	Changes the products shown	Keep as separate versions, or bypass
add-to-cart, preview, checkout tokens	Triggers an action or private view	Always bypass

Do not strip tracking tags from the URL to make caching work. Google says the GCLID has to reach the final landing page for conversion tracking, and your client’s reporting depends on it. The aim is for the cache to ignore those tags when choosing which copy to serve, while they stay in the URL for analytics. One exception: if the site changes a banner or offer based on a campaign tag, that tag does change the page and needs its own version.

Filters are the opposite. On a URL like /pool-heat-pumps/?filter_fan-direction=horizontal, ignoring the filter would show the full list to someone who asked for horizontal-fan models. Caching every combination creates a huge number of copies, and bypassing them all puts the load back on the database. Depending on the shop, cache a few popular combinations, add an object cache for the product query, or bypass and make the query faster.

Setting cache rules on SiteGround and Cloudflare

Plenty of agency clients sit on SiteGround. Its Speed Optimizer has two custom filters that do opposite jobs. sgo_ignored_query_params tells the cache to ignore a parameter when it creates and serves copies. sgo_bypass_query_params tells it to skip the cache whenever that parameter appears. Mix them up and you get the reverse of what you wanted.

Here is an example for a small site-specific plugin, following the pattern in SiteGround’s documentation. Try it on staging first, and check nothing on the site changes the page based on these tags.

add_filter( 'sgo_ignored_query_params', 'svai_ignore_tracking_params' );

function svai_ignore_tracking_params( $ignored_query_params ) {
    $tracking = array(
        'gclid', 'gbraid', 'wbraid', 'fbclid',
        'utm_source', 'utm_medium', 'utm_campaign',
    );
    return array_unique( array_merge( $ignored_query_params, $tracking ) );
}

It leaves filter, orderby, per_page and add-to-cart alone on purpose. It also does not guarantee a HIT for every ad click, because cookies, CDN rules and security checks can still get in the way.

On Cloudflare, the controls depend on the plan. Choosing exactly which query string parameters go into the cache key is an Enterprise feature, while the blunter “ignore query string” setting is available on every plan.

How to check the cache is working

Run these checks on every client site you take on, and again after any plugin, theme or hosting change. Each one has a clear “done” so it fits neatly into a maintenance report.

1. List every cache layer. Host, plugin, CDN, object cache and browser headers. Done when you know which one serves the HTML.
2. Request a public page twice, logged out. Done when the second response shows a HIT.
3. Repeat with ?gclid=test on the end. Done when you know whether ad clicks get a HIT, a MISS or a BYPASS.
4. Open a filtered category URL. Done when the products shown match the filter, every time.
5. Add something to the basket, then visit cart and checkout. Done when both show BYPASS and your own basket.
6. Change a price, purge, and reload logged out. Done when the new price appears straight away.

On SiteGround, read the x-proxy-cache header. A 202 response with SG-Captcha is SiteGround’s anti-bot check, not the cache, so look at it separately and do not switch protection off to make a test pass. Check in a real browser as well as cURL, because unusual tools are often treated differently from real visitors. When content changes, purge only what changed where you can: on SiteGround that is Speed Optimizer, Site Tools or wp sg purge.

UK GDPR and caching personal data

A badly set cache is not only a speed problem. If a shared cache stores an account or order page and serves it to the next visitor, one customer’s details have been shown to another, and your client is the data controller who has to deal with it.

• It counts as a breach. The ICO treats unauthorised disclosure of personal data, including sending it to the wrong person, as a personal data breach.
• The deadline is 72 hours. Unless the breach is unlikely to put people’s rights and freedoms at risk, it must be reported to the ICO within 72 hours of becoming aware of it.
• Record it either way. Keep a note of the breach and the reasoning, even if it does not need reporting.
• Test before you switch. Whenever a new cache plugin, CDN or host goes in, check cart, checkout and account pages before go-live.

Frequently asked questions

What is website caching in simple terms?

Keeping a ready copy of a page, file or database result so the site does not rebuild it for every visitor. Done well, pages load faster and the server copes with more traffic. Done badly, visitors see outdated or private content.

Should I cache every page on a WordPress site?

No. Pages that look the same for every visitor, such as the homepage, blog posts and standard product pages, are good candidates. Cart, checkout, My Account, logged-in admin pages and form or payment endpoints should never come from a shared page cache.

Does gclid stop a page from being cached?

It depends on the cache. Some include the full query string in the cache key, some bypass any URL with a query string, and some let you ignore chosen parameters. Check the settings and response headers, and keep gclid in the URL for tracking.

What is the difference between page caching and object caching?

Page caching stores a page’s finished HTML and sends it as it is. Object caching stores database query results, so even a page that must be built fresh, like a filtered category, runs faster. Busy WooCommerce shops often benefit from both.

Will caching improve my client’s Google rankings?

Not on its own. Faster responses support a better experience and better Core Web Vitals, but rankings also depend on relevant content, sound indexing and links. Treat speed as one part of the picture.

Hand the caching work to us

Caching is one of the jobs we untangle most often on agency client sites, and we do it under your brand. If a client’s landing pages keep missing the cache or shoppers see old prices, we can find which layer is responsible and fix it quietly.

• See our white-label performance optimisation service.
• Add caching checks to every client with white-label website maintenance.
• Running shops for clients? Look at our WooCommerce development work.
• Or send us a brief and tell us what you are seeing.