Set up caching before you launch
Add one cookie to every caching layer on your site so members never get a cached public page, and the public never gets a member page.
On this page
Why this matters
Page caching saves one copy of a page and serves it to many readers. That's what you want for anonymous traffic, and what you don't want once members see something different from everyone else.
If caching isn't set up for memberships, one of two things goes wrong:
| What goes wrong | What happens |
|---|---|
| A cached anonymous page is served to a member | A paying member hits the paywall on content they paid for, and sees ads they paid to remove. |
| A cached member page is served to anonymous readers | Your gated content is shown to everyone for free, and ads are hidden for readers who never paid. |
Set this up before you publish your membership.
The one thing to configure
When a reader signs in as a member, the Allspice plugin sets this cookie on your domain:
Every caching layer on your site needs to skip the cache when a request carries that cookie. Anonymous readers don't have it, so they keep getting cached pages as before.
From WordPress, the plugin already sets DONOTCACHEPAGE and sends no-cache headers whenever the cookie is present, so WordPress cache plugins won't store a member's page. Many of them still serve their existing cached copy before WordPress runs, though, and CDNs and host-level caches never see those signals at all. Those layers need to be told about the cookie.
The rule keys on the cookie being present, not on it being valid. An expired cookie still skips the cache, so it can never write a member's version of a page into a shared cache.
WordPress cache plugins
WP Rocket is handled for you. The Allspice plugin adds allspice_member_session to WP Rocket's Never Cache Cookies list, regenerates WP Rocket's configuration once, and clears its cache. You don't need to change anything in WP Rocket. If WP Rocket is installed later, this happens the next time you open the WordPress admin.
For other plugins, add allspice_member_session to the setting below. Labels vary a little between versions; look for the option listing cookies that should never be cached.
| Plugin | Where to add it |
|---|---|
| WP Rocket | Automatic. Nothing to add. |
| LiteSpeed Cache | LiteSpeed Cache → Cache → Excludes → Do Not Cache Cookies |
| W3 Total Cache | Performance → Page Cache → Advanced → Rejected Cookies |
| WP Super Cache | Settings → WP Super Cache → Advanced → Rejected Cookies |
| WP Fastest Cache | Exclude tab → Add New Rule → choose Cookie |
Add the cookie name on its own line, with no quotes. Clear the cache afterwards.
Cloudflare and other CDNs
A CDN caches in front of WordPress and never sees the plugin's no-cache signals, so it has to be configured separately.
Cloudflare
- In your Cloudflare dashboard, open Rules → Cache Rules
- Create a rule that matches when the request Cookie header contains
allspice_member_session - Set the action to Bypass cache
- Deploy, then purge the existing cache
If you use Automatic Platform Optimization (APO), you must add this rule. APO caches full HTML pages at the edge, which is how a member page ends up served to the public.
Other CDNs and server caches
The same applies to Fastly, KeyCDN, Varnish, and Nginx FastCGI caching: add a cache-bypass condition for requests whose cookie contains allspice_member_session. Your host's support team can give you the exact syntax for their stack.
Managed WordPress hosts
Managed hosts run their own server-level cache, which you often can't see from the WordPress admin. This includes BigScoots, Kinsta, WP Engine, SiteGround, Cloudways, and Rocket.net.
Open a support ticket and ask for this:
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 make this change routinely for membership and ecommerce plugins.
Verifying it works
Test it after changing settings, in this order:
- Signed out, in a private window: open a gated page. You should see the gate and your ads.
- 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 reading.
- Reload the member view several times. It must stay unlocked every time. If the gate comes back, a cache is serving the anonymous copy.
- Go back to the private window and hard-refresh. It must still show the gate and your ads. If the content is unlocked there, a member page has made it into the shared cache. Fix that before you launch.
Checking response headers
For a definite answer, open your browser's developer tools, go to the Network tab, and check 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 readBYPASSorDYNAMIC, notHITx-litespeed-cache- should not readhitx-cache- should not readHIT
A HIT on a signed-in member request means that layer is still caching.
Troubleshooting
Members sometimes see the paywall
A cache is still serving anonymous pages to members. Work down the layers: cache plugin first, then CDN, then ask your host about server-level caching. When it happens only some of the time, one layer is usually configured and another isn't.
Members see ads even though the membership is ad-free
Same cause. The ad-free markup is written into the page HTML when it is rendered, so a cached anonymous page doesn't have it. While signed in as a member, check the page source for allspice-ad-free-member in the body classes. If it's missing, you are getting a cached copy.
Signed-out readers can see gated content
Treat this as urgent: a member's page has been written to a shared cache. Purge every cache now, then fix the bypass rule.
Everything works for me but not for readers
You are probably logged into WordPress, and most cache plugins skip caching for logged-in administrators. Test in a private window with a real member account, not as an admin.