Websites
Site Caching
Caching is the biggest single speed win available to a WordPress site: full-page caching serves finished HTML without running PHP at all, and object caching keeps database results in memory. This guide covers both, what bypasses the cache automatically, and how to purge and warm it.
Where Caching Lives in KPanel
- Sign in to KPanel.
- Click Websites in the left sidebar, then click the site.
- In the site's tab strip, open WordPress, then Caching.
The direct address is /websites/<site-id>/cache.
The WordPress group only appears for WordPress and WooCommerce sites. Caching here is a plan entitlement: full-page caching and the object cache are included with Managed WordPress. On other plans the page shows an upgrade panel describing what is available rather than the controls.
Full-Page Cache
Full-page caching stores the finished HTML of a page and serves it straight to the next visitor. For an anonymous visitor, that means no PHP execution and no database queries at all: the request is answered before WordPress is ever loaded.
The card shows an On or Off pill, and when it is on, the date it was enabled, whether routing has been confirmed, and the cache lifetime.
To enable it, click Enable full-page cache. To turn it off again, click Disable.
The cache is cleared automatically when you publish or update a post, so your changes appear immediately rather than waiting for the lifetime to expire.
If your site is mostly read by anonymous visitors, this is the highest-value switch on the page. It is common for the difference to be an order of magnitude on time to first byte, because the slow part of a WordPress request is the part that no longer happens.
Purging and Warming
Two actions appear once full-page caching is on.
Purge cache empties the cache immediately. Use it after a change that WordPress does not treat as a post update: editing a theme file, changing a widget, updating a menu, or altering a plugin setting that affects output. The next visitor to each page gets a fresh copy.
Warm cache pre-fetches your pages so they are already cached before a visitor asks. After warming, a banner tells you how many pages of the total were pre-cached and lists the first few URLs.
The natural sequence after a design change is: purge, then warm. That way nobody has to be the unlucky visitor who pays for the first uncached render.
For the edge cache in front of your site, which is a separate layer, see Purging the CDN Cache.
What Never Gets Cached
Some URLs must always run PHP, because their output differs per visitor or has side effects. These paths are bypassed automatically and you do not need to configure anything:
| Path | Why |
|---|---|
/wp-admin/ | WordPress admin is always dynamic |
/wp-login.php | The login page is never cached |
/cart/ | WooCommerce cart is per visitor |
/checkout/ | WooCommerce checkout is per visitor |
/my-account/ | WooCommerce account pages are per visitor |
/wp-cron.php | Scheduled tasks must actually run |
/?wc-ajax=* | WooCommerce AJAX endpoints |
On top of the path rules, cookies matter. A logged-in WordPress user, or a visitor with an active WooCommerce session cookie, is always served a dynamic response, even on a page that is cached for everyone else. That is why a store owner browsing their own site often sees none of the benefit while anonymous visitors do.
Because you are usually logged in, testing cache behaviour in your normal browser will mislead you. Test in a private window, or a browser you are not signed in to.
Object Cache
The object cache is a different layer. Instead of storing finished pages, it keeps the results of database queries and WordPress transients in memory, so repeat work is not repeated.
The card shows an On or Off pill, and when it is on, the date it was enabled. Use Turn on and Turn off to change it.
Object caching helps exactly where full-page caching cannot: logged-in users, admin screens, and per-visitor pages such as cart and checkout. That makes it especially valuable for busy stores and membership sites, where much of the traffic is authenticated and therefore never page-cached.
Running both together is the normal configuration. Full-page caching handles anonymous traffic, and the object cache speeds up everything that must run PHP anyway.
Choosing What to Enable
- Content site, mostly anonymous readers. Full-page caching is the priority. Object caching adds a smaller improvement on top.
- WooCommerce store. Enable both. Full-page caching still covers your product and category pages for browsing visitors, while the object cache carries the cart, checkout, and account pages that can never be cached.
- Membership or community site where nearly everyone is logged in. Object caching does the heavy lifting, because most requests will bypass the page cache by design.
Troubleshooting
I updated the site but visitors still see the old version. Purge the cache, then warm it. If it is still stale, remember there may be an edge cache too: see Purging the CDN Cache.
Caching does nothing for me. You are almost certainly logged in. Check in a private window.
The cart or a form behaves oddly for anonymous visitors. The standard commerce paths are bypassed automatically, but a custom or plugin-provided dynamic page on a non-standard URL is not. If a page must never be cached and is not on the bypass list, that is worth raising with support so we can look at the rule.
The card says caching is included with Managed WordPress. Your current plan does not include it. The banner links to the plans page.
Routing check pending. The cache is enabled and the routing confirmation has not completed yet. Give it a moment and refresh.
A page shows the wrong personalised content. Anything personalised must be excluded from the page cache or rendered client-side. If a plugin personalises output on an otherwise cacheable URL without setting a session cookie, the page cache cannot know that. Test in a private window and raise it with support if you find one.
Related Pages
- Site Performance and APM to measure whether caching actually helped.
- Site Traffic Analytics for the edge cache hit ratio.
- Enabling the CDN to add an edge cache in front of all of this.
- Taking a Backup before making larger changes to a live site.