Caching Plugin Configuration

Page caching plugins store HTML snapshots of your pages so they load faster. For most pages on your site this is fine — but two types of Benecaster pages generate different output for different visitors, or include single-use tokens that expire after the page is rendered. Caching these pages causes broken subscriber accounts and failed donation payments.

This page lists which pages must be excluded from page caching and shows how to configure the most common caching plugins.

Pages to Exclude

The Subscriber Account Page — Always Required

The page containing the [benecaster_account] shortcode shows each subscriber their private feed URL and account details. The content is specific to the subscriber viewing the page. If this page is cached, everyone who visits it receives the same cached snapshot — typically either a blank state or another subscriber’s data.

Finding this page: It is the WordPress page you designated as your subscriber account page during setup. It contains [benecaster_account] in its content. Its URL is typically something like https://yoursite.com/podcast/ or https://yoursite.com/my-account/.

Exclude this page’s exact URL path from your caching plugin.

Listener Support Donation Pages — Required If Using Listener Support

Any page containing [benecaster_listener_support] (including the style="button" and style="icon" variants) renders a Stripe payment form. Stripe’s Payment Element requires a freshly generated one-time client secret that Benecaster creates server-side each time the page is rendered. When the page is cached, visitors receive a stale client secret and the payment will fail at the Stripe step.

Finding these pages: Search your WordPress pages and posts for benecaster_listener_support. Exclude the URL of every page where this shortcode appears.

Pages That Are Already Protected

Private Subscriber Feed URLs

Benecaster’s private feed URLs automatically include a Cache-Control: no-store HTTP response header. Most page caching plugins respect this header and skip caching these URLs entirely.

Reverse proxy setups (Nginx FastCGI cache, Varnish) and some Cloudflare configurations cache based on URL patterns and may not honour the header. If your feeds or subscribers report stale content, add a manual exclusion for the feed URL path as well.

Feed URL path: /podcast-feed/ by default — configurable under Settings → Feeds. Exclude this path and everything under it.

Configuring Your Caching Plugin

WP Rocket

Go to Settings → WP Rocket → Cache
Scroll to Never Cache URL(s)

Add one URL per line:

/your-account-page-slug/
/your-donation-page-slug/

Save changes and clear the cache

If you have changed the feed URL path from the default, add /podcast-feed/ (or your custom path) to the same list.

LiteSpeed Cache

Go to LiteSpeed Cache → Cache → Excludes
Under Cache URI(s) Excludes, add your URLs — one per line:
```
/your-account-page-slug/
/your-donation-page-slug/
```
Save and purge all caches

W3 Total Cache

Go to Performance → Page Cache → Advanced
Under Never cache the following pages, add your URLs one per line
Save settings and flush all caches

WP Super Cache

Go to Settings → WP Super Cache → Advanced
Scroll to Accepted Filenames & Rejected URIs
Add your page slugs to the Rejected URIs list
Save and clear the cache

SiteGround SG Optimizer

Go to SG Optimizer → Caching → Dynamic Cache
Click Exclude URL from cache
Add your account and donation page URLs
Clear the cache from the SiteGround control panel or the SG Optimizer dashboard

Cloudflare

Cloudflare does not cache HTML pages in its default configuration — if you are using standard Cloudflare proxying only, no action is required.

If you have Cloudflare APO (Automatic Platform Optimization) enabled, APO caches HTML at Cloudflare’s edge. You need a Cache Rule to bypass it:

In the Cloudflare dashboard, go to Caching → Cache Rules
Create a new rule
Set the condition: URI Path equals /your-account-page-slug/
Set the action: Cache → Bypass
Save and repeat for each URL that must not be cached

For the feed path with APO enabled, add a rule using URI Path starts with /podcast-feed/ set to Bypass.

Nginx FastCGI Cache

If your hosting runs Nginx with a FastCGI page cache — common on VPS and cloud hosting, and on managed hosts that offer Nginx-level caching — add exclusions to your server configuration. Contact your host if you do not have direct Nginx access.

set $skip_cache 0;

if ($request_uri ~* "^/your-account-page-slug/") {
    set $skip_cache 1;
}
if ($request_uri ~* "^/your-donation-page-slug/") {
    set $skip_cache 1;
}
if ($request_uri ~* "^/podcast-feed/") {
    set $skip_cache 1;
}

Apply $skip_cache to both fastcgi_cache_bypass and fastcgi_no_cache directives. Replace /podcast-feed/ with your actual feed path if you have changed it.

WP Engine, Kinsta, Flywheel, and Other Managed Hosts

Managed WordPress hosts run their own server-level page caches. Most provide a URL exclusion option in their hosting control panel or a caching plugin specific to their platform.

Look for a “Page Cache” or “Exclusion Rules” section in your host’s dashboard. If you cannot find it, contact their support team and ask how to exclude specific URLs from their server cache.

Testing That Exclusions Are Working

After adding exclusions, confirm that the pages are being served fresh:

Open an incognito or private browsing window — this starts a clean session without any cookies
Visit your subscriber account page — you should see a generic or empty state, not a specific subscriber’s data
Visit a donation page — start a payment and confirm it reaches the Stripe payment step without an error
Check response headers — open your browser’s developer tools (Network tab), reload the page, and look for the response headers on the document request. A correctly excluded page will typically show Cache-Control: no-store or X-Cache: MISS rather than X-Cache: HIT

If a Page Is Still Showing Stale Content

If exclusion rules are in place but content still appears cached:

Clear the cache manually — most caching plugins have a “Purge All” or “Clear All Caches” button on their main dashboard
Check for a CDN layer — if you have a CDN between visitors and your server, the CDN may be caching independently of your WordPress caching plugin. Add the same URL exclusions in your CDN configuration
Check for host-level caching — some managed hosts cache at the server level separately from any WordPress plugin. Log in to your hosting control panel and look for a cache management option
Try a query string — append ?v=1 to the page URL in your browser. Caching plugins typically skip query string URLs, so if the page displays correctly with the query string but not without it, your exclusion rule is not taking effect yet