Skip to main content

Caching Plugin Configuration

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 payments.

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

If you use an external membership plugin (MemberPress, WooCommerce Subscriptions, Paid Memberships Pro, Restrict Content Pro), check its own documentation for cache exclusions too — most have a similar list of account and checkout pages that need the same treatment.

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.

The same applies to any other Benecaster page that renders a Stripe payment form. The client secret is generated fresh on every render in every case, so a cached snapshot always carries a stale one and the payment always fails at the Stripe step. If you add a page that takes a payment through Benecaster, exclude it.

Pages That Are Already Protected

Private Subscriber Feed URLs

Benecaster’s private feed URLs automatically include a Cache-Control: no-store HTTP response header, and every token-bearing feed response also defines WordPress’s own DONOTCACHEPAGE constant — the signal WP Super Cache, W3 Total Cache and WP Rocket check directly, so those plugins skip caching these URLs entirely with no exclusion rule needed from you.

Reverse proxy setups (Nginx FastCGI cache, Varnish) and Cloudflare cache based on URL patterns rather than reading either signal, so they may still cache a feed response. If subscribers report stale feeds or access problems, add a manual exclusion for your feed URL path or paths — see the Cloudflare and Nginx sections below for specifics; for other reverse proxies, exclude /podcast-feed/ (and, if you’ve turned on Use pretty feed URLs at Settings → Permalinks, /podcast/ as well) in that layer’s configuration.

Configuring Your Caching Plugin

WP Rocket

  1. Go to Settings → WP Rocket → Cache
  2. Scroll to Never Cache URL(s)
  3. Add one URL per line: 
    /your-account-page-slug/
/your-donation-page-slug/
  4. Save changes and clear the cache

WP Rocket already respects DONOTCACHEPAGE, so feed URLs are skipped automatically — no entry needed here for them. If you’ve turned on Use pretty feed URLs (Settings → Permalinks) and still see stale feeds, add /podcast-feed/ and /podcast/ to the same list as a manual fallback.

LiteSpeed Cache

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

W3 Total Cache

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

WP Super Cache

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

SiteGround SG Optimizer

  1. Go to SG Optimizer → Caching → Dynamic Cache
  2. Click Exclude URL from cache
  3. Add your account and donation page URLs
  4. 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 for your account and donation pages.

Feed URLs and Cloudflare: Benecaster’s private feed URLs send Cache-Control: no-store, but Cloudflare’s proxy layer can cache based on URL patterns and may not honour this header. If subscribers are reporting stale feeds or access problems, add a Cache Rule to bypass the feed path:

  1. In the Cloudflare dashboard, go to Caching → Cache Rules
  2. Create a new rule with condition: URI Path starts with /podcast-feed/
  3. Set the action: Cache → Bypass
  4. Save
  5. If you’ve turned on Use pretty feed URLs (Settings → Permalinks), repeat for URI Path starts with /podcast/

If you have Cloudflare APO (Automatic Platform Optimization) enabled, APO caches HTML at Cloudflare’s edge. Add Bypass rules for your account page, donation pages, and feed path(s):

  1. Go to Caching → Cache Rules and create a rule
  2. For the account page: URI Path equals /your-account-page-slug/ → Bypass
  3. For each donation page: URI Path equals /your-donation-page-slug/ → Bypass
  4. For the feed: URI Path starts with /podcast-feed/ → Bypass
  5. If pretty feed URLs are on: URI Path starts with /podcast/ → 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;
}
if ($request_uri ~* "^/podcast/") {
    set $skip_cache 1;
}

Apply $skip_cache to both fastcgi_cache_bypass and fastcgi_no_cache directives. The /podcast/ rule only matters if you’ve turned on Use pretty feed URLs (Settings → Permalinks) — include it either way, since it’s harmless if unused.

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:

  1. Open an incognito or private browsing window — this starts a clean session without any cookies
  2. Visit your subscriber account page — you should see a generic or empty state, not a specific subscriber’s data
  3. Visit a donation page — start a payment and confirm it reaches the Stripe payment step without an error
  4. 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

See Also

Need this built rather than just documented? See our services →

Powered by