Kinsta cache layers: purge the right copy and verify the result

Where edge caching adds value

Kinsta’s edge caching guide describes distributing eligible cached pages through Cloudflare. It does not serve the static files handled by the CDN.

Kinsta lists incompatibilities with password protection, narrow geolocation variations, advanced custom exclusions and Cloudflare APO. It also warns that an edge response can bypass origin-level geolocation blocking or redirects. Ask support to assess such rules before enabling it; a loading page does not prove a location restriction works.

For an ordinary public publication, the attraction is a simpler delivery setup. For a membership site or region-dependent application, document what must remain personalized first. Choosing the right exclusions is more valuable than maximizing a cache-hit number.

Inspect the response you are actually receiving

Open the browser’s developer tools and use Network while reloading. Select the document request for the HTML, then inspect individual asset requests separately. Chrome documents request selection, response headers and its Disable cache option in the Network reference. Disabling the browser cache during a diagnostic reload does not disable a managed CDN or origin cache.

For a document request served from Kinsta’s server, Kinsta’s testing guide describes x-kinsta-cache: a HIT indicates a stored response, while a MISS indicates it was not served from that cache. A first request after a purge can legitimately miss. Do not turn one MISS into a diagnosis of broken hosting.

For an image served through Kinsta’s CDN, the current CDN documentation identifies ki-cache-type: CDN together with ki-cf-cache-status: HIT as useful evidence. Inspect the response for the file you selected; a header on an image does not establish how the HTML was delivered. If headers are absent or unexpected, keep the response details and ask support about the actual route.

A HIT also does not mean the stored content is correct. Compare the returned article text or file with the revision you intended to publish. Correctness and reuse are separate checks.

Purge deliberately and verify afterwards

Kinsta’s cache-control guide places the combined purge at Sites → the relevant site → Caching → Clear all caches. It covers server, CDN and edge cache, plus the Redis object cache when that add-on is enabled. Verify the site name and environment first, especially in an account containing several client sites.

The same guide recommends clearing a theme or plugin’s own cache before the hosting caches. Its SSH procedure also documents wp kinsta cache purge when the Kinsta MU plugin is installed; the clearing endpoint must be reachable. Dashboard controls are the more accessible starting point for an owner who does not already work safely with SSH. Do not run a command against an unidentified environment.

Kinsta’s must-use plugin provides WordPress-side cache controls and automatic clearing associated with content updates. If the expected Kinsta Cache menu or toolbar control is missing, verify the MU plugin with support instead of installing another page-cache plugin as a substitute.

Check the provider’s current banned and incompatible plugin list before adding an optimization tool. Some caching plugins are blocked, while individual exceptions exist. A familiar plugin from another host is not automatically the right fit here.

After a deliberate purge, return to the original logged-out test. Confirm the specific changed sentence, the affected asset and one important interaction. Kinsta advises allowing two to five minutes for edge invalidation to complete across its locations. Do not promise that an immediate dashboard notice proves every remote response has already changed.

Handle a changed stylesheet or image differently

A fictional photographer replaces the banner image but keeps the same file URL. The article HTML may be current while a saved image remains reusable elsewhere. Inspect that image’s response and the actual file content. If the content-management workflow can publish a new versioned asset address, that gives the changed file a distinct identity; keep links and templates consistent rather than adding arbitrary query parameters everywhere.

If the theme generates optimized CSS or JavaScript, Kinsta’s troubleshooting guide recommends regenerating those generated files, then clearing that theme or plugin cache before the server cache. Purging a perfectly current copy of an old generated file does not regenerate the file itself.

Also check whether an older CDN hostname is hardcoded in the theme or plugin. Kinsta’s CDN uses the site’s own domain, and its migration instructions call for replacing previous CDN addresses. Avoid running two CDN services casually; the provider warns that asset purging can become problematic.

Keep private pages private

Test an account page as two distinct authorized test users and as a logged-out visitor before changing custom caching rules. Check that each sees only the intended information. Use a safe test environment and synthetic account details; do not put real customer data into a public troubleshooting screenshot.

If a custom login or account route needs fresh data, Kinsta’s server-caching documentation directs owners to support for specific bypass rules. That is a more focused request than disabling page caching for the whole site. Include the route, expected behavior and a reproducible example, without sending passwords or session cookies.

When caching is working but the page is still slow

A cache is not an image editor, a substitute for efficient code or a guarantee about every visitor’s connection. Compare repeat tests using the same page, tool and location, and distinguish an initial cold request from later cached requests. Kinsta’s testing documentation prohibits stress/load testing on the platform; ordinary diagnostic browsing is not permission to generate simulated traffic.

For an uncached operation, Kinsta’s APM tool can help locate PHP, database or external-request bottlenecks. It is included in its plans but adds monitoring overhead, so the provider recommends enabling it while actively investigating and avoiding simultaneous monitoring agents.

Redis persistent object caching is a separate paid add-on. Kinsta identifies highly dynamic sites as potential candidates and says an ordinary static publication may see little benefit when page caching already works well. Investigate an actual bottleneck before adding recurring cost. We have not measured a Redis improvement for this guide.

Is Kinsta’s caching approach a useful fit?

It is a strong workflow to shortlist when you want managed page caching, a documented CDN and hosting-level diagnostics under one operator. The practical benefit is having a place to inspect and resolve delivery problems without assembling every layer yourself. You still own publishing quality, compatibility decisions and verification.

Before choosing a plan, list the site’s public pages, private flows, asset sizes and custom location rules. Ask how those fit the documented setup, and compare the current plan allowances and support scope. This guide does not establish that a migration will be faster, that a speed score will rise or that a particular plan is sufficient.

Continue with our explanation of shared versus managed WordPress hosting and what hosting plans include. For recovery planning before larger changes, see how to prepare a WordPress backup you can restore.