Cache-control: no-store, no-cache despite setting up cache's rules

Hello Cloudflare Community,

We are encountering an issue with caching configuration on our website, and we would appreciate your opinion and suggestions to help us troubleshoot.

Our website homepage (https://yourdomain.com/) is showing cf-cache-status: DYNAMIC and cache-control: no-store, no-cache in the response headers when inspected using browser developer tools.

We are using a free plan on Cloudflare.

Page Rules Configuration:

Here are the Page Rules we have set up:

Rule 1: Eligible for Cache (wp-content and wp-includes)

starts_with(“/wp-content/”) or starts_with(/wp-includes/")

Cache Level: Cache Everything

Rule 2: Bypass Cache (specific URLs)

Login / Create Account / Cart / Checkout Pages

Cache Level: Bypass Cache

Rule 3: Eligible for Cache (All Other URLs)

( “domain.com/”)

Cache Level: Cache Everything

We aim to cache our homepage and other static content effectively to improve performance.

Our current understanding is that our website is not being cached at all by Cloudflare despite setting up Page Rules, as we keep getting these “cache-control: no-store, no-cache” in the response headers, is that correct and which options should be explored to fix this ?

R.

Can you share your domain?

You should update the order of your rules. Cache Rules operate on a last-match basis, so the settings from Rule 1 will be overruled by Rule 3. At least in theory, because it’s obviously not happening.

Can you share screenshots of your rules?
There is no starts_with() in Page Rules, only in Cache Rules. And in Cache Rules, there is no Cache Level: Cache Everything, so it looks like you are mixing things up here.

You should use Cache Rules, as Pages Rules are deprecated and will soon be removed.

Your URIs are wrong. Cloudflare gives examples for the values you need to enter:

http.request.uri
Represents the URI path and query string of the request.

Example value:
/articles/index?section=539061&expand=comments

Got it, thanks.

I re ordered and made the change below, apparently still not working.

cache-control: no-store, no-cache, must-revalidate
cf-cache-status: DYNAMIC

Your first rule references /*. The Wildcard operator is not supported in cache rules, so that won’t work.

If you want it to affect all requests, do something like hostname equals example.com.

Then the next step, what did you put in the Edge TTL section of the rule?

As your origin doesn’t set a TTL, you must overrule that in your rule.

Ok, I re do my answer as:

1- I modified the cache rule to “hostname equals example.com” and since that, I have
cache-control: no-store, no-cache, must-revalidate
cf-cache-status : BYPASS

so its not anymore DYNAMIC

2- up to now, I did not set the Edge TTL setting, no changed it to “Ignore cache-control header and use this TTL” for the two caching rules and the status is now:

cache-control: no-store, no-cache, must-revalidate
cf-cache-status: HIT

there is no more turtle besides the domain name, seems like it was fixed ? is the 2H setting for Edge TTL correct in your opinion ?

It looks like the rules are now working as intended. Whether or not two hours are a good setting for you is something you need to decide for yourself.

I would recommend that you spend some time checking that logged-out users don’t see the content of logged-in users.

Purge the cache, log in and visit a few pages, then use a private browser window and visit the same pages again.

Got it. Many thanks again for your patience in helping to resolve this matter step by step. I’ll review your last suggestion and come back only if further question arises.

1 Like

You were right. I quickly realized that whenever I logged in as Admin and logged out, any other customer account (I used a test one to verify) logging in right after would gain admin access.

I have come to the conclusion that using Cloudflare to cache pages on a WP / Woo website presents too many configuration problems. I will explore other solutions, keeping only firewall solutions for the moment.

It’s possible, but the setup is certainly a bit more complex.

Cloudflare offers a plugin for Wordpress that basically manages the cache settings automatically.

It’s included in the pro plan and also available at 5$ per month as a standalone I believe.

No, there is too little documentation and too few tutorials on this topic to justify investing in a paid Cloudflare solution. The $5 per month is not a significant amount, but I must assume at this stage that if things don’t work correctly, I won’t have the necessary resources to resolve the issues effectively. This would likely result in wasting hours without much progress. I am quite disappointed with Cloudflare as a company based on this experience. It’s understandable to need to search for solutions or ask for help, but the inability to set things up correctly despite putting in the effort, seemingly to promote a paid solution, is not what I expected from Cloudflare.

Thanks for the help and patience into this anyway, with your direction + the few web instruction I found and tried to apply, I can feel that i did try my best with this.

Cheers.