Fix “Page caching is disabled because your site uses the ‘Set-Cookie’ header” in WP Rocket

If you’re wondering what’s broken: your page isn’t being cached at all. Something is sending a Set-Cookie header with the response, so your cache (and WP Rocket) treat it as dynamic and skip page caching.

Why this notice shows up

The Set-Cookie header tells the browser “store this cookie.” That’s great for logins, carts, and personalization—but shared caches (NGINX, Varnish, CDNs, edge caches) see it and assume the page is user-specific.

Most caching layers play it safe: if a response includes Set-Cookie, they don’t cache the page at all. WP Rocket or your host then surfaces a notice like “Page caching is disabled because your site uses the ‘Set-Cookie’ header.”

Your job is to answer two questions:

1. Where is Set-Cookie being sent?
2. Does this page really need to be personalized for every visitor?

Step 1 — Confirm where the Set-Cookie header appears

First, make sure you’re testing as a normal visitor.

• Open an incognito/private window.
• Visit the page where you saw the notice.
• Make sure you’re logged out of WordPress.

Check the response headers in your browser

1. Open DevTools (F12 or Right-click → Inspect).
2. Go to the Network tab and reload the page.
3. Click the main HTML request (usually the first row).
4. Under Headers → Response Headers, look for set-cookie:.

If you see one or more set-cookie lines on a public page while logged out, that’s what’s disabling page caching.

Optional: double-check with cURL

If you like the command line, you can verify the same thing with curl:

curl -I https://example.com/ | grep -i set-cookie

No output = no Set-Cookie header. One or more lines = something on the server is setting cookies for that page.

Note on “legit” dynamic pages

Don’t panic if you see Set-Cookie on:

• wp-login.php and the admin area
• Cart / Checkout / My Account pages in WooCommerce
• Membership dashboards, account areas, etc.

Those pages are supposed to be dynamic and are often excluded from caching on purpose. The problem is when your public pages (home, posts, landing pages) send Set-Cookie for anonymous visitors.

Step 2 — Find who’s sending Set-Cookie on public pages

Once you’ve confirmed Set-Cookie is present, you need to find what sets it.

Look at the cookie names

In DevTools, under the same response, check the Cookies / Application → Cookies panel. You’ll usually see names like:

• PHPSESSID (generic PHP sessions)
• wp_woocommerce_session_... or woocommerce_items_in_cart
• _ga, _fbp, marketing tags (usually set by JS, not headers)
• Plugin-specific names (geo/currency, A/B testing, wishlist, recently viewed, etc.)

Those names are your biggest clue. Search your plugins list for anything that matches the purpose (e.g. “recently viewed products”, “currency switcher”, “popup”, “newsletter bar”).

Quick way to narrow it down

1. In your incognito window, keep DevTools open on the affected page.
2. In another window, go to Plugins → Installed Plugins.
3. Temporarily deactivate a small batch of plugins (start with tracking, marketing, popups, geo/currency, wishlist, “helper” plugins).
4. Reload the page and check if set-cookie disappears from the response headers.

When the header disappears, you’ve found the plugin or combination of plugins that’s setting it.

Step 3 — Fix it based on what you found

Scenario A — A non-essential plugin sets cookies on every page

This is very common with:

• “Recently viewed products” widgets
• Some chat widgets or marketing plugins
• Plugins that call session_start() for no good reason

Best fix: stop setting global cookies

• Check the plugin’s settings for options like “Use PHP sessions”, “Track all visitors”, or “Enable cookie” and turn them off where possible.
• If there’s an option to use AJAX instead of PHP for dynamic pieces, enable it so the main page can be cached.
• If the plugin only needs the cookie once, ask the developer (or your dev) to set it only when it doesn’t already exist, instead of on every request.

If the plugin must set a cookie for every visitor and cannot be changed, you have two choices:

• Replace it with a more cache-friendly alternative.
• Accept that full page caching won’t apply to the affected pages.

Scenario B — Cookies that are only needed on specific pages

Typical examples:

• Cart / checkout cookies
• Account / membership area cookies
• Geo / currency cookies for pricing

What to do:

• Make sure only the pages that truly need the cookie are affected. For example, a cart cookie should not be set on the homepage before a product is added.
• Check WP Rocket’s built-in exclusions—WooCommerce cart, checkout, and My Account are automatically excluded from caching. You don’t need to “fix” those.
• For custom pages, use WP Rocket → Settings → Advanced Rules → Never Cache URLs to exclude only the dynamic pages that rely on those cookies.

This way, your public content (blog posts, landing pages, category pages) can still be cached, while high-risk dynamic pages stay uncached on purpose.

Scenario C — You need both cookies and caching (geo, currency, A/B tests)

Some plugins store user-specific info (like country or currency) in a cookie but you still want cached pages for each variant. WP Rocket can handle this in some cases.

What to do:

• Check if your plugin is on WP Rocket’s list of compatible geo / currency plugins that use dedicated cookies and separate cache files.
• If it is, follow their integration guide so WP Rocket can create different cache files per cookie value instead of disabling caching.
• If it isn’t, talk to the plugin developer or your host about:
  • Using AJAX to inject the dynamic bits (e.g. currency label) on top of a cached page.
  • Or matching WP Rocket’s “dynamic / mandatory cookies” pattern so the cache can be split safely.

Step 4 — Advanced: host-level changes (only if you know what you’re doing)

On some stacks (NGINX FastCGI, Varnish, custom edge cache), your host can choose to ignore Set-Cookie for specific pages or cookies so the page can still be cached.

For example, NGINX can be configured to ignore certain headers when caching. But this is dangerous if the cookies include login or session data—you could end up caching personalized content for everyone.

If you’re not 100% sure which cookies are being set and why, don’t try to hack around them at the server level. Ask your host’s support to review the headers and suggest a safe configuration.

Verification checklist

Once you’ve made changes, verify that things are actually fixed:

• As a logged-out visitor, your key public pages no longer send a Set-Cookie header (or only send it after an action like adding to cart).
• WP Rocket’s cache footprint shows a timestamp at the bottom of the HTML source for those pages.
• Your CDN / host now shows cache HIT / non-zero Age headers for those URLs.
• Logins, carts, and account pages still behave normally.

Still stuck?

For AI help

Scroll down and hit Continue Chat. Tell me which cookie names you’re seeing in the headers, which plugins you suspect, and whether the problem is on all pages or just a few. I’ll help you narrow it down.

For expert human help

Scroll down to the contact form below. Enter your name, email, and WordPress needs. Atiba will get back to you as soon as possible.