Caching Setup

Set up caching before you launch

One cookie, added to every caching layer. Ten minutes now saves leaked content and refunded members later.

Why This Matters

Page caching serves one saved copy of a page to many readers. That is exactly what you want for anonymous traffic, and exactly what you do not want once some readers are members seeing something different.

If caching is not configured for memberships, one of two things happens, and both cost you:

What goes wrongWhat it costs you
A cached anonymous page is served to a memberYour paying member hits a paywall on content they bought, and sees ads they paid to remove. Refunds and support tickets.
A cached member page is served to anonymous readersWorse. Your gated content is handed to everyone free, and ads are suppressed for readers who were never going to pay. Direct lost revenue on both sides.

This is a ten-minute setup task. Do it before you publish your membership, not after.

When a reader has a membership session, Allspice sets a cookie:

allspice_member_session

Every caching layer on your site needs to skip the cache when a request carries that cookie. That is the whole task. Anonymous readers do not have it, so they keep getting fast cached pages exactly as before.

Allspice already signals this from WordPress: it sets DONOTCACHEPAGE and sends no-cache headers whenever the cookie is present. Most WordPress cache plugins honour that natively. But plugins with their own cookie rules, and every CDN or host-level cache, sit above that and must be told separately.

TIP:

The rule keys on the cookie being present, not on it being valid. That is deliberate: an expired cookie must never be able to poison a shared cache with a member's version of a page.

WordPress Cache Plugins

Find your plugin below and add allspice_member_session to the listed setting. Wording varies slightly by version; you are looking for the option about cookies that should never be cached.

PluginWhere to add it
WP RocketSettings → WP Rocket → Advanced Rules → Never Cache Cookies
LiteSpeed CacheLiteSpeed Cache → Cache → Excludes → Do Not Cache Cookies
W3 Total CachePerformance → Page Cache → Advanced → Rejected Cookies
WP Super CacheSettings → WP Super Cache → Advanced → Rejected Cookies
WP Fastest CacheExclude tab → Add New Rule → choose Cookie

Add the cookie name on its own line, with no quotes and no leading dollar sign. Clear the cache afterwards.

Cloudflare and Other CDNs

A CDN caches in front of WordPress, so it never sees the plugin's instruction. It must be configured on its own.

Cloudflare

  1. In your Cloudflare dashboard, open Rules → Cache Rules
  2. Create a rule that matches when the request Cookie header contains allspice_member_session
  3. Set the action to Bypass cache
  4. Deploy, then purge the existing cache

If you use Automatic Platform Optimization (APO), this rule is not optional. APO caches full HTML pages at the edge, which is precisely the thing that will serve a member page to the public.

Other CDNs and server caches

The same principle applies to Fastly, KeyCDN, Varnish, and Nginx FastCGI caching: add a cache-bypass condition when the request cookie contains allspice_member_session. If you are not sure how, your host's support team will know the exact syntax for their stack.

Managed WordPress Hosts

Managed hosts run their own server-level cache that you often cannot see from the WordPress admin. This includes BigScoots, Kinsta, WP Engine, SiteGround, Cloudways, and Rocket.net.

Open a support ticket and ask for exactly this:

"Please add allspice_member_session to the cache-bypass cookie list for my site, at every caching layer including any edge or CDN cache. Requests carrying this cookie must not be served from, or written to, a shared cache."

Hosts do this routinely for membership and ecommerce plugins. It is a standard request.

Verifying It Works

Do not assume it is right because you changed a setting. Test it, in this order:

  1. Signed out, in a private window: open a gated page. You should see the gate, and your ads.
  2. Sign in as a member in a normal window and open the same page. You should see the full content, and no ads if the membership includes ad-free.
  3. Reload the member view several times. It must stay unlocked every time. If the gate reappears, a cache is serving the anonymous copy.
  4. Go back to the private window and hard-refresh. This is the important one. It must still show the gate and your ads. If the content is now unlocked there, a member page has leaked into the shared cache. Stop and fix it before launching.

Checking response headers

For a definitive answer, open your browser's developer tools, go to the Network tab, and look at the response headers for the page itself while signed in as a member. Depending on your stack you will see one of:

  • cf-cache-status - should read BYPASS or DYNAMIC, not HIT
  • x-litespeed-cache - should not read hit
  • x-cache - should not read HIT

A HIT on a signed-in member request means that layer is still caching, and the configuration has not taken effect.

Troubleshooting

Members intermittently see the paywall

Classic symptom of a cache still serving anonymous pages. Work down the layers: cache plugin first, then CDN, then ask your host about server-level caching. "Intermittent" usually means one layer is configured and another is not.

Members see ads even though the membership is ad-free

Same root cause. The ad-free markup is written into the page HTML at render time, so a cached anonymous page will not carry it. Check the page source for allspice-ad-free-member in the body classes: if it is missing while signed in as a member, you are being served a cached copy.

Signed-out readers can see gated content

Treat this as urgent. A member render has been written to a shared cache. Purge every cache immediately, then fix the bypass rule before restoring traffic.

Everything works for me but not for readers

You are probably logged into WordPress, and most cache plugins skip caching for logged-in administrators entirely. Always test in a private window with a real member account, never as an admin.