A cache is a temporary copy of a resource, kept closer to whoever requests it so that it does not have to be generated or downloaded from scratch on every visit.
A website does not have just one. At least three that matter live side by side: the one in the visitor's browser, the one on the server hosting the site, and the one on the CDN's nodes. When someone says "I changed the text but I still see the old version online", the job is to work out which of the three is holding the stale copy. Each is cleared in a different way, and if you clear them in the wrong order nothing happens.
The cache layers you find on a site
Anyone working on a WordPress site usually runs into four or five, stacked one on top of the other. Each has a different owner, which explains why the plugin's "clear cache" button is sometimes not enough.
| Layer | Where it lives | What it stores | Who clears it |
|---|---|---|---|
| Browser cache | On the visitor's device | CSS, JavaScript, images, fonts | The visitor, or the headers the site sends |
| Page cache | On the site's server | The already assembled HTML | The caching plugin or the hosting control panel |
| Object cache | On the server (Redis, Memcached) | Database query results | The plugin or service that manages it |
| Opcode cache | In memory, inside PHP (OPcache) | Already compiled PHP code | Restarting PHP-FPM |
| CDN cache | On edge nodes (Cloudflare, Fastly, Varnish) | Complete HTTP responses | A purge from the CDN dashboard |
| bfcache | In the browser's RAM | The whole page, JavaScript included | The browser, on its own |
Of the six, only two are really under the site's control: the page cache and the object cache. For the other four the site can only send instructions and hope they are followed.
Who decides how long a copy lasts
The rules are not written by Google but by the HTTP standard. The reference document is RFC 9111 "HTTP Caching", published by the IETF in 2022, which replaced the earlier RFC 7234 and became a standard as STD 98. It defines three headers: Cache-Control, Expires and Age. The first is the one in use; the other two are historical leftovers.
If the server says nothing, the cache does not give up: it guesses. The specification calls this heuristic freshness and suggests estimating the lifetime as a fraction of the time since the file was last modified, "typically 10%". A file modified ten days ago therefore stays valid for about a day, without anyone having decided so. That is why a site with no cache headers behaves differently from one browser to the next.
| Directive | What it instructs | When to use it |
|---|---|---|
max-age=31536000 | Keep for a year without requesting anything | Files with a hash in the name, which change name with every deploy |
s-maxage | Applies only to shared caches (CDN, proxy) | HTML you want to keep on the CDN but not in the browser |
no-cache | Keep the copy, but revalidate it before using it | Pages that change often and must stay up to date |
no-store | Store nothing, anywhere | Basket, checkout, account area |
private | The browser may store it, the CDN may not | Pages personalised for the logged-in user |
must-revalidate | Once the copy has expired, it must not be served anyway | Prices, availability, data that cannot tolerate delays |
Alongside lifetime there is validation. With ETag the server attaches a fingerprint of the content to every response; the browser sends it back in If-None-Match on the next request and, if the fingerprint matches, receives a 304 Not Modified with no body. Last-Modified and If-Modified-Since work the same way, but on a date rather than a fingerprint.
Googlebot uses caching too, and hardly anyone lets it
On 9 December 2024 Gary Illyes published a post on the Google Search Central blog called Crawling December: HTTP caching, with a figure nobody expected to be so low: ten years ago about 0.026% of Googlebot's total fetches could be served from cache, and today that has fallen to 0.017%. In practice, almost no site tells Google that a resource has not changed.
Google's crawling infrastructure supports conditional requests exactly as RFC 9111 describes them, with both ETag and Last-Modified. Illyes writes that he prefers ETag, because the value is a free-form string and is less error-prone than a hand-formatted date, and recommends setting both where possible. When the crawler receives a 304, the server does not generate the page or send the response body: it saves bandwidth and CPU cycles, and in return Google has more headroom to crawl the pages that really have changed.
On a small site the difference is barely noticeable. On a catalogue with tens of thousands of URLs that rarely change, handling conditional requests properly is one of the technical SEO fixes with the best ratio of effort to return, and it affects how Google allocates crawling far more than many of the ranking factors people argue about endlessly.
Google's cached copy no longer exists
Plenty of articles about caching still explain how to open a page's "cached copy" from the SERP. That link disappeared in January 2024 and the feature was retired. Danny Sullivan, Google's Search Liaison, confirmed it to Search Engine Land on 1 February 2024, adding that the cache: operator would also go soon. Today that search returns nothing.
Two things survived. The noarchive meta tag is still respected, as Sullivan specified in the same statement, because other search engines read it too. And access to historical versions has moved elsewhere: since 11 September 2024, as the Internet Archive announced on its blog, clicking the three dots next to a result to open the About this result panel and then "More about this page" shows a link to the Wayback Machine.
For what SEOs used it for, checking what Google saw on the page, the replacement is the URL Inspection tool in Google Search Console, which shows the crawled HTML and the date of the last crawl. It is more accurate than the old cached copy, which returned a rendered page and was often misleading.
bfcache, the one almost nobody talks about
The back/forward cache is a different thing from the HTTP cache: it does not store individual responses, it stores the whole page frozen in memory, JavaScript heap included. When the visitor presses the back button, the page reappears without touching the network.
How much it matters is set out in Chrome's documentation on web.dev: Chrome usage data shows that 1 in 10 navigations on desktop and 1 in 5 on mobile are back or forward. Chrome has it from version 96, as do Firefox and Safari, and since version 10.0 Lighthouse has a dedicated audit.
The most common way to break it is to put Cache-Control: no-store on the HTML of the whole site "for safety". That directive has historically excluded the page from the bfcache. If the content only needs to stay current and is not private, the right choice is no-cache or max-age=0, which force revalidation without losing the instant back navigation. The other classic cause is a listener on the unload event, which Chrome is deprecating for exactly this reason. The gain goes straight into page speed metrics and into how fast the site feels.
When the cache becomes the problem
A published change that does not show up is almost always a question of order. You start from the innermost layer and work outwards: first the page cache on the server, then the object cache if the site uses Redis or Memcached, then the CDN purge, and only at the end a hard reload in the browser. Purging the CDN before the server just copies the old version back onto the edge nodes.
With static files you avoid the problem before it starts by giving every build a different name: style.a3f9c1.css instead of style.css. A file that changes name with every release can be cached for a year with no risk, because the new version is a new resource. The same reasoning applies to optimised images, which once published hardly ever change.
The basket, the checkout, account areas and any screen showing one person's data stay out of the page cache. On WordPress the most popular plugins, from WP Rocket to LiteSpeed Cache, already have these exclusions preset for WooCommerce, but hand-built pages with a form or a dynamic quote have to be excluded manually. A second point to watch is pages served in different versions depending on a cookie or the language: without a correct Vary header, a shared cache can hand one visitor another visitor's page.
The most expensive caching mistake
It is not an old page served for two hours. It is a wrong 301 redirect. The HTTP standard classes the 301 as heuristically cacheable, so if the server does not attach an explicit Cache-Control the browser is free to keep it for a long time. Once the rule is removed from the server, anyone who had already hit it keeps being redirected by their own browser, and the problem is invisible to whoever looks for it from a clean machine. It works the other way too: a 404 error returned by mistake during a migration can stay in circulation after the site has been fixed.
If you publish redirects often, during a site rebuild for example, it pays to send each 301 with a Cache-Control: max-age of a few hours until the map is stable, and raise it only afterwards. It is a detail that almost never appears in migration checklists, and in SEO projects it explains quite a few cases of traffic that does not come back when it should.
Frequently asked questions about website caching
No. A purge only removes the temporary copies of pages and files. The content stays in the database and the site rebuilds itself on the first request. The only visible effect is that the first load after the purge is slower than usual, because the copies have to be regenerated.
Google does not assess whether a caching system is in place. It does, however, affect two things that count: the response times the visitor experiences and the number of requests Googlebot can close with a 304 Not Modified instead of downloading the page again.
Not on a schedule. Caching plugins invalidate the affected pages on their own when content is updated. A manual purge is needed after changes that touch the whole site: a theme change, CSS work, a plugin update, a new build of the static files.
No. Two plugins writing rules into the same server configuration file overwrite each other and produce half-served pages. If your hosting already provides server-side caching, the choice is between that and the plugin, not both.
For any page, use the Internet Archive's Wayback Machine, which you can also reach from the three dots next to a search result, under More about this page. For a page on your own site, the URL Inspection tool in Search Console is the better option: it shows the HTML actually crawled and the date of the last crawl.
