Use this guide to troubleshoot cache issues in Pressidium EDGE.

Caching improves performance by serving eligible content from cache instead of requiring WordPress, PHP, and the database to generate the same response for every request. If cache is not working as expected, pages may load slowly, origin load may increase, or visitors may receive stale or unexpected content.

When to use

Use this guide when:

  • Pages are slower than expected
  • Requests appear to bypass cache
  • Cache hit rate is lower than expected
  • Cached content does not update after changes
  • Static assets or pages are not being cached
  • Cache exclusions may be too broad
  • WordPress caching plugins may be conflicting with EDGE cache
  • You need to check whether a page is being served from cache

Symptoms

Common signs of cache issues include:

  • Slow page loads: Pages take longer to load than expected.
  • High origin load: More requests than expected reach the origin server.
  • High server response time: Dynamic requests take longer because they are not served from cache.
  • Low cache hit rate: A large number of eligible requests are not being served from cache.
  • Repeated cache misses: The same public page continues to miss cache after repeated requests.
  • Missing or unexpected cache headers: Response headers do not show the expected cache behavior.
  • Stale content: Old content appears after updates.
  • Dynamic content cached incorrectly: Visitor-specific content appears where it should not.

Common causes

Cache is not enabled or not active

Issue: The relevant cache type is not enabled, has been cleared, or is not yet serving cached responses.

What to check:

  • Open the site in the Pressidium Dashboard.
  • Go to Performance -> Cache.
  • Review the available cache sections for the site.
  • Check whether the relevant cache type is active.
  • Confirm whether cache was recently cleared or purged.

See The Cache Management screen for cache management options.

Cache exclusions are matching the request

Issue: A URL path, cookie, or request pattern is excluded from Page Cache.

Cache exclusions are useful for dynamic or visitor-specific pages, but broad exclusions can cause more requests to bypass cache than expected.

What to check:

  • URL path exclusions
  • Cookie-based exclusions
  • Rules that match large sections of the site
  • Exclusions added for testing but not removed
  • Dynamic pages that should remain excluded, such as cart, checkout, account, LMS, membership, or logged-in areas

See Cache Exclusions screen for URL path and cookie-based exclusions.

The request is not eligible for Page Cache

Issue: The request is dynamic, personalized, authenticated, or uses a method that should not be cached.

Some requests should bypass cache by design.

Common examples include:

  • Logged-in WordPress admin requests
  • Logged-in customer, LMS, membership, or account requests
  • WooCommerce cart and checkout pages
  • HTTP POST requests
  • Requests with an Authorization header
  • Password-protected content
  • Requests that depend on visitor-specific cookies
  • Pages that return private or user-specific data

In these cases, bypassing cache is expected and helps prevent personalized content from being served to the wrong visitor.

WordPress cache plugin conflict

Issue: A WordPress caching, optimization, CDN, minification, or security plugin is changing cache headers, rewriting URLs, serving stale files, or clearing cache independently of EDGE.

What to check:

  • Page caching plugins
  • CDN plugins
  • Minification or optimization plugins
  • Image optimization plugins
  • Security plugins that modify headers or block requests
  • Plugins that set Cache-Control: no-cache, private, or similar headers
  • Plugins that serve cached HTML from WordPress before EDGE can handle the request correctly

If you use EDGE cache, avoid running multiple full-page caching layers unless they are intentionally configured to work together.

See WordPress Plugin Conflicts for plugin conflict troubleshooting.

Origin headers prevent caching

Issue: The origin response includes headers that tell caches not to store the response.

What to check:

  • Cache-Control
  • Pragma
  • Expires
  • Set-Cookie
  • Vary
  • Authorization
  • HTTP status code
  • Redirect behavior

For example, pages with Cache-Control: private, no-store, or no-cache may not be cached as expected. Responses that set cookies may also be treated as dynamic, depending on the request and configuration.

Cache was purged recently

Issue: Cache was cleared, so initial requests after the purge may be cache misses until cache is rebuilt.

What to check:

  • Whether cache was recently purged from the Dashboard
  • Whether WordPress content updates triggered cache clearing
  • Whether a deployment, plugin update, theme change, or file update cleared cache
  • Whether the page has received enough repeat traffic to warm cache again

A cache miss immediately after clearing cache is normal. Repeated requests to eligible public pages should begin showing cached behavior after cache has been rebuilt.

Query strings or URL variations create separate cache entries

Issue: Requests with different query strings, URL parameters, or URL variants may not use the same cached response.

What to check:

  • Tracking parameters such as utm_source, utm_campaign, or fbclid
  • Search or filter parameters
  • Session or preview parameters
  • Different trailing slash behavior
  • HTTP and HTTPS differences
  • Root domain and www differences

Normalize URLs where possible and avoid unnecessary query parameters on cacheable landing pages.

Diagnostic steps

Step 1: Check cache status in the Dashboard

  1. Log in to the Pressidium Dashboard.
  2. Select the website you want to check.
  3. Go to Performance -> Cache.
  4. Review the available cache sections.
  5. Check whether the relevant cache type is active.
  6. Check whether cache was recently cleared or purged.

If the site has cache exclusions configured, open the Cache Exclusions tab and review whether the affected URL or request is being excluded.

Step 2: Check Performance Analytics

Use Performance Analytics to understand whether requests are reaching the origin and whether response times changed.

  1. Open the site in the Pressidium Dashboard.
  2. Go to Performance -> Performance Analytics.
  3. Review request volume and response timing.
  4. Check whether slow paths are concentrated on specific URLs.
  5. Compare the current period with previous activity.
  6. Look for traffic spikes, high-impact paths, or unusually slow response times.

See The Performance Analytics screen for request volume and response timing data.

Step 3: Verify cache headers

Use browser developer tools or curl to inspect the response headers for the affected page.

Run:

curl -I https://example.com/

Then repeat the request:

curl -I https://example.com/

Compare the first and second response.

Check:

  • HTTP status code
  • Cache-Control
  • Age, if present
  • ETag, if present
  • Expires, if present
  • Vary, if present
  • Set-Cookie, if present
  • Any EDGE-specific cache status headers, if present
  • Whether headers change between the first and second request

A public page that is eligible for cache should not repeatedly behave like a fully dynamic request.

Step 4: Test in a clean browser session

Browser cache and logged-in sessions can make cache testing confusing.

Test with:

  • A private or incognito browser window
  • A logged-out visitor session
  • A different browser
  • A different device or network
  • Browser developer tools with “Disable cache” enabled only when testing browser cache behavior

Do not test cache behavior while logged in to WordPress unless you are specifically checking logged-in behavior. Logged-in WordPress requests often bypass Page Cache by design.

Step 5: Check whether the page should be cached

Some pages should bypass cache.

Check whether the affected URL is:

  • A cart page
  • A checkout page
  • An account page
  • A login page
  • A WordPress admin page
  • A membership page
  • An LMS student page
  • A personalized dashboard
  • A page that depends on visitor cookies
  • A page that handles form submissions
  • A page that uses POST requests

If the page is dynamic or visitor-specific, cache bypass may be correct.

Step 6: Review cache exclusions

Open the Cache Exclusions area and review:

  • Excluded URL paths
  • Excluded cookie names
  • Broad wildcard-like patterns
  • Old testing exclusions
  • Exclusions added for plugins or dynamic features
  • Exclusions that match more pages than intended

If an exclusion is too broad, narrow it so only the required dynamic paths or cookie-based requests bypass cache.

Step 7: Check WordPress plugins and themes

Review recently added or changed plugins and theme settings.

Pay special attention to:

  • Full-page cache plugins
  • CDN plugins
  • Optimization plugins
  • Security plugins
  • Membership plugins
  • LMS plugins
  • WooCommerce or ecommerce plugins
  • Plugins that set cookies for all visitors
  • Plugins that change response headers
  • Plugins that perform redirects

Temporarily disable only suspected conflicting features and test again. Avoid disabling production-critical plugins without a rollback plan.

Solutions

Enable or review cache settings

  1. Open the site in the Pressidium Dashboard.
  2. Go to Performance -> Cache.
  3. Review the cache sections for the site.
  4. Confirm that the relevant cache type is active.
  5. Save any required changes.
  6. Retest the affected URL as a logged-out visitor.

Fix cache exclusions

  1. Open the site in the Pressidium Dashboard.
  2. Go to Performance -> Cache.
  3. Open the Cache Exclusions tab.
  4. Review URL path exclusions and cookie-based exclusions.
  5. Remove exclusions that are no longer needed.
  6. Narrow broad exclusions so they only match the required dynamic paths or cookies.
  7. Save changes.
  8. Purge affected cache if needed.
  9. Retest the affected URL.

Do not remove exclusions for pages that must remain dynamic, such as checkout, cart, account, membership, LMS, or logged-in areas.

Resolve WordPress cache conflicts

  1. Identify any WordPress caching, optimization, or CDN plugins.
  2. Disable duplicate full-page caching features unless they are intentionally required.
  3. Check whether plugins are setting no-cache headers.
  4. Check whether plugins are setting cookies for all visitors.
  5. Review minification, asset optimization, and CDN rewriting features.
  6. Change one setting at a time.
  7. Purge cache after each relevant change.
  8. Retest the affected page as a logged-out visitor.

If the problem started after installing or updating a plugin, test by disabling that plugin’s caching or optimization features first.

Fix origin headers that prevent caching

  1. Inspect the response headers for the affected page.
  2. Look for headers that make the response private or uncacheable.
  3. Check whether a plugin, theme, custom code, or origin server rule is setting those headers.
  4. Adjust the origin configuration only if the page is safe to cache.
  5. Purge cache.
  6. Retest the page.

Do not force caching for pages that contain private, personalized, user-specific, or transactional data.

Purge and rebuild cache

Use this when old content is being served or after changing cache-related settings.

  1. Open the site in the Pressidium Dashboard.
  2. Go to Performance -> Cache.
  3. Use the available cache clear or purge option.
  4. If only specific URLs are affected, purge those URL paths instead of clearing all cache.
  5. Open the affected page as a logged-out visitor.
  6. Reload the page and inspect the response headers.
  7. Repeat the request to confirm whether cache behavior changes.

See The Cache Management screen for cache clearing options.

Fix stale content

If old content is still appearing:

  1. Confirm the content was updated at the origin or in WordPress.
  2. Purge the affected URL path from EDGE cache.
  3. Clear any WordPress plugin cache.
  4. Clear browser cache or test in a private window.
  5. Check whether another cache layer exists at the origin or in a plugin.
  6. Retest the affected page.

If the old content appears only in one browser, it may be local browser cache.

Cache types

Page Cache

Page Cache stores eligible full-page responses so they can be served faster without regenerating the page through WordPress for every visitor.

Check Page Cache when:

  • Public pages are slow
  • Server response time is high
  • Repeat requests do not become faster
  • Too many requests appear to reach the origin
  • Cached pages show stale content

Common Page Cache bypass reasons include:

  • Logged-in users
  • POST requests
  • Authorization headers
  • Cart, checkout, account, LMS, or membership pages
  • Cookie-based exclusions
  • URL path exclusions
  • Origin headers that prevent caching
  • Pages that set visitor-specific cookies

Static Assets Cache

Static Assets Cache helps serve static files such as images, CSS, JavaScript, fonts, and other assets more efficiently.

Check Static Assets Cache when:

  • CSS or JavaScript files are slow
  • Images or fonts are slow to load
  • Static files appear to reload from origin too often
  • Asset URLs include cache-busting query strings
  • Old CSS, JavaScript, or image files are still appearing

If only images are affected, see Images Not Loading.

Browser Cache

Browser cache is controlled by response headers that tell the visitor’s browser how long it can reuse a local copy of a resource.

Check browser cache when:

  • A page looks correct in a private window but wrong in a normal browser window
  • One user sees old content while others see updated content
  • CSS or JavaScript changes are not visible
  • Hard refresh fixes the issue locally

Browser cache is separate from EDGE cache. Purging EDGE cache does not always clear a visitor’s browser cache.

WordPress-specific cache issues

WordPress cache plugins

WordPress cache plugins can conflict with EDGE cache if they also perform full-page caching, CDN rewriting, asset optimization, or cache header changes.

Common issues include:

  • Duplicate caching layers
  • Stale HTML served by a plugin
  • Cache clearing not synchronized with EDGE
  • Conflicting Cache-Control headers
  • Asset optimization breaking CSS or JavaScript
  • Plugin cache clearing one layer but not another

Recommended approach:

  1. Use EDGE cache as the primary full-page cache.
  2. Avoid duplicate full-page caching unless there is a specific reason.
  3. Keep only the plugin features you need.
  4. Coordinate cache clearing after content, plugin, or theme changes.
  5. Test after changing plugin caching or optimization settings.

Dynamic WordPress content

Dynamic WordPress content should usually bypass Page Cache.

Examples include:

  • Cart and checkout pages
  • Account pages
  • Login and registration pages
  • LMS student dashboards
  • Membership content
  • Personalized recommendations
  • Form submission pages
  • Search or filtered results that depend on visitor input
  • Pages that set visitor-specific cookies

Use cache exclusions for dynamic content when needed. Keep exclusions as narrow as possible so they do not bypass cache for unrelated public pages.

Best practices

Cache management

  • Monitor cache behavior after setup and after major changes.
  • Review cache exclusions regularly.
  • Keep exclusions narrow and intentional.
  • Purge only the affected URLs when possible.
  • Clear all cache only when a broader change requires it.
  • Test cache behavior as a logged-out visitor.
  • Avoid testing Page Cache from a logged-in WordPress session.
  • Record cache-related changes so you can trace issues later.

Cache optimization

  • Cache public, anonymous pages where possible.
  • Do not cache private, user-specific, or transactional pages.
  • Use appropriate TTL values for the type of content.
  • Use longer cache lifetimes for stable static assets.
  • Use shorter cache lifetimes or targeted purges for frequently updated pages.
  • Avoid unnecessary query strings on cacheable pages.
  • Review high-traffic pages in Performance Analytics.
  • Monitor cache hit behavior after deployments or content changes.

Troubleshooting checklist

  • Checked cache status in the Dashboard
  • Reviewed Performance -> Cache
  • Checked whether cache was recently purged
  • Tested the page as a logged-out visitor
  • Tested in a private browser window
  • Checked response headers with browser developer tools or curl -I
  • Repeated the request to compare first and second responses
  • Checked whether the page is eligible for cache
  • Reviewed URL path exclusions
  • Reviewed cookie-based exclusions
  • Checked for WordPress caching or optimization plugin conflicts
  • Checked origin headers such as Cache-Control, Set-Cookie, and Vary
  • Checked whether query strings or URL variants are causing separate cache behavior
  • Purged affected URLs if stale content was served
  • Reviewed Performance Analytics for slow or high-impact paths
  • Contacted Support if the issue persists

When to contact Support

Contact Pressidium Support when:

  • Cache issues persist after troubleshooting
  • You cannot identify why a page is bypassing cache
  • A cacheable public page repeatedly misses cache
  • Cache exclusions do not behave as expected
  • Old content remains after purging the affected URLs
  • Cache behavior differs by browser, region, or network
  • A plugin or origin header appears to interfere with EDGE cache
  • You need advanced cache diagnostics

When contacting Support, include:

  • Site name
  • Affected URL or URL pattern
  • Whether the issue affects Page Cache, Static Assets Cache, or browser cache
  • Screenshot of relevant cache settings
  • Relevant cache exclusions
  • Response headers from curl -I or browser developer tools
  • Whether the request was tested logged in or logged out
  • Whether the issue affects all users or only specific users, regions, or browsers
  • Any recent plugin, theme, deployment, DNS, cache, or configuration changes
  • Steps already taken

Where to go next