Page Caching

How it works

When a visitor requests a page for the first time, the plugin generates the full HTML output, saves it as a static file, and serves that file to the visitor. On subsequent requests, the cached file is served directly — WordPress, your theme, and your plugins never run. This reduces server response time from hundreds of milliseconds to single-digit milliseconds.

Key settings

Enable Caching

Master on/off switch for page caching. Enabled by default on activation.

Cache Lifespan

How long cached pages are kept before being automatically regenerated. Default: 10 hours. Shorter lifespans ensure fresher content at the cost of more frequent regeneration. Longer lifespans reduce server load but may serve slightly stale content.

Separate Mobile Cache

Creates a separate cache file for mobile visitors. Enable this if your theme serves different HTML to mobile devices (responsive themes that use CSS media queries typically do not need this). If your theme uses a separate mobile version or serves different content by device, enable this setting.

Logged-in Users

Logged-in users always bypass the page cache. The cached copy is served only to anonymous visitors, which prevents private content from ever being served to the wrong user. This is a fixed safety rule and is not configurable.

Never Cache URLs

List specific pages or URL patterns that should never be cached. Enter one per line. Common exclusions:

• /cart/
• /checkout/
• /my-account/
• /wp-json/

Cart, checkout, and account pages for WooCommerce and Easy Digital Downloads are excluded automatically.

Never Cache Cookies

Pages are not cached when the visitor has any of these cookies set. Useful for membership sites or custom session handling.

Never Cache User Agents

Pages are not cached for visitors with these user agent strings. Useful for excluding specific bots or devices.

Cache Query Strings

By default, pages with query strings (e.g., ?utm_source=google) are not cached. Add specific query parameters here to allow caching when they are present.

What is on from the start

Page caching is switched on the moment the free plugin is activated: the drop-in is installed, the browser-caching rules are written and the fast defaults apply, with no licence and no configuration. The Caching Out Pro add-on is the part that waits for a licence: installed but not yet validated, it scans and audits without changing anything for your visitors. See Switching Pro on.

Cache clearing

The cache is automatically cleared when:

• A post or page is published, updated, or deleted
• A comment is approved, edited, or deleted
• A theme is switched
• A plugin is activated or deactivated
• Widgets or customizer settings are saved
• WooCommerce product stock or price changes

You can also clear the cache manually from the Cache tab or, with Pro, via WP-CLI:

wp cachingout purge
wp cachingout purge --post_id=42

Debugging

Enable CACHINGOUT_DEBUG in your wp-config.php to see the X-CachingOut-Cache header on every response:

• HIT — Served from cache
• MISS — Generated fresh and cached
• BYPASS:reason — Not cached, with the specific reason. Common reasons: logged-in, cookie:<name> (a cookie from your "Never cache when these cookies are present" list), session-cookie:PHPSESSID (the visitor has a PHP session, see below), variation-cookie:<name> (a language or currency cookie that changes what the same URL shows, see below), query-string, woocommerce-cart.

Kill switch

Add this to wp-config.php to disable all cache reading and writing:

define( 'CACHINGOUT_DISABLE_CACHE', true );

Troubleshooting

My changes aren't showing up. Clear the cache manually. If you're logged in, you're seeing uncached pages by default — log out to see what visitors see.

Some pages are not being cached. Check the X-CachingOut-Cache header. If it says BYPASS, the reason will tell you which rule is preventing caching.

Every page says BYPASS:session-cookie:PHPSESSID. A plugin or theme on your site starts a PHP session for every visitor. A session ties a page to one visitor, so Caching Out never shares it: a request carrying the PHPSESSID cookie is served live, and a page that starts a session is never stored. This is built in and cannot be switched off. Find the plugin that calls session_start() on the front end (deactivate plugins one at a time, or use the Page Audit) and ask its author for a setting that limits the session to the pages that need it; caching resumes as soon as visitors stop receiving the cookie.

My own browser never gets a cached page, but curl or PageSpeed Insights does; the header says BYPASS:variation-cookie:pll_language (or wp-wpml_current_language, _icl_current_language). Polylang and WPML give every visitor a language cookie the first time WordPress renders a page for them, and keep it for a year. What Caching Out does with it depends on how your languages are addressed:

• Each language has its own URL (Polylang "directory name", "subdomain" or "different domains"; WPML "directories" or "domains"): from 1.21.2 the cookie is ignored, because the URL already says which language to serve. If you still see the bypass after updating, save any setting once (or deactivate and reactivate the plugin) so the runtime settings are refreshed, and check the plugin's language URL setting is not the same-URL mode.
• Every language at the same URL (Polylang "set from content", WPML ?lang=): the cookie is the only thing that says which language the page is in, so a request carrying it is served live and never cached. This is deliberate: a cached copy could be the wrong language. Give each language its own URL to cache these visitors.

Currency cookies from multi-currency plugins (wmc_current_currency, woocs_current_currency) always bypass for the same reason.

First-time visitors from another country land on the wrong language, although my theme (or a plugin) redirects by browser language. A cached page is served before WordPress runs, so a redirect written in PHP (a theme reading Accept-Language and sending Polish browsers from / to /pl/, for example) never runs for a cached URL: whichever language the page was cached in is what every later visitor gets, and any cookie that redirect would have set is never set. This is how page caching works, not a fault in the redirect. Move the decision to the browser: a few lines of JavaScript on the page that read navigator.language (and a cookie remembering the choice) and navigate once, or the multilingual plugin's own browser-language detection where it runs client-side. Do not exclude the home page from caching to keep a PHP redirect: that gives up the cache on the most-visited page for every visitor.

My site broke after enabling caching. Add define( 'CACHINGOUT_DISABLE_CACHE', true ); to wp-config.php to immediately disable caching while you investigate.