Caching is one of the easiest ways to make a WordPress site dramatically faster. When Cloudflare caches your pages, visitors get served static copies from a server near them instead of waiting for your origin to rebuild the page every time. The catch is that not everything on a WordPress site should be cached. Admin screens, login flows, and personalized content all need to stay dynamic. The trick to a good cache rule is aggressively caching public pages while carefully excluding the parts that must remain live.
Below is a practical set of exclusions you can build into a Cloudflare cache rule for a typical WordPress blog.
Bypass caching on admin and backend paths
WordPress relies on several special URLs to run its dashboard, authentication, and background systems. Caching these would break functionality or serve stale data, so you’ll want your cache rule to bypass them entirely.
The /wp-admin path is the WordPress admin dashboard, and it should never be cached since administrators need live, up-to-date screens. The /wp-login page handles authentication, so bypassing it ensures credentials and sessions work correctly rather than being served a cached copy. The /wp-json endpoints power the WordPress REST API, which many themes, plugins, and integrations depend on for fresh, dynamic data. The /xmlrpc interface supports remote publishing and third-party tools, and it needs to hit your origin directly to work. Finally, /wp-cron triggers WordPress’s scheduled background tasks, so excluding it ensures those jobs actually fire on time.
Bypass caching when WordPress session cookies are present
Beyond specific URLs, you also want to skip caching whenever a request carries certain WordPress cookies. These cookies signal that a visitor is seeing personalized content, which should never be served from a shared cache.
When the wordpress_logged_in_ cookie is present, the visitor is logged in, so they should see their personalized content and admin toolbar rather than a generic cached page. The wp-postpass_ cookie appears when someone has entered the password for a password-protected post, and bypassing the cache ensures they actually get access. The comment_author_ cookie is set for visitors who have left a comment, and skipping the cache lets them see their saved details and any pending comments.
Putting it together
To actually access the Cache Rules page:
- Navigate to your domain in CloudFlare
- Then go to Caching > Cache Rules > Create Rule
The full cache rule expression (copy and modify)
Cloudflare cache rules use a filter expression to decide which requests the rule applies to. The expression below puts everything together: it matches all requests to your hostname except the admin paths and logged-in/session cookies we discussed. Copy it into the expression editor of your own cache rule and swap in your details where noted.
(http.host eq "YOUR-DOMAIN.com"
and not http.request.uri.path contains "/wp-admin"
and not http.request.uri.path contains "/wp-login"
and not http.request.uri.path contains "/wp-json"
and not http.request.uri.path contains "/xmlrpc"
and not http.request.uri.path contains "/wp-cron"
and not http.cookie contains "wordpress_logged_in_"
and not http.cookie contains "wp-postpass_"
and not http.cookie contains "comment_author_")To adapt it, replace YOUR-DOMAIN.com with your own hostname. If you have any pages that must always stay dynamic (for example a members area, a live search page, or a checkout), add another line in the same style, such as and not http.request.uri.path contains "/your-dynamic-page". You can build this visually with the rule builder’s dropdowns or paste it directly using the “Edit expression” option.
The cache settings to turn on
Matching the right requests is only half the job. The “Then…” section of the rule controls what actually happens to those requests. Here are the settings to enable so your public pages get served fast from Cloudflare’s edge.
Cache eligibility: set this to Eligible for cache. This tells Cloudflare that responses from your origin for matching requests are allowed to be stored in its cache rather than bypassed.
Edge TTL: choose Ignore cache-control header and use this TTL, then enter a time-to-live such as 12 hours (or however long you want. If you’re making blog updates every few hours, you may want to decrease this down to an hour but most sites update every couple of days or weeks).
Many WordPress origins send conservative or no-cache headers by default, so overriding them lets Cloudflare hold onto your pages for a set period regardless of what the origin says. A longer TTL means more cache hits and less load on your server; a shorter one means content refreshes sooner. Pick a value that fits how often your content changes, and remember you can purge the cache manually whenever you publish something new.
Browser TTL: leaving this on Respect origin TTL is a safe default. It lets your origin decide how long visitors’ browsers hold onto content locally, which avoids the risk of stale content getting stuck in someone’s browser where a Cloudflare purge can’t reach it.
With the expression excluding your dynamic paths and cookies, and these settings enabling edge caching with a sensible TTL, anonymous visitors will be served cached pages straight from Cloudflare while logged-in users, commenters, and your admin area continue to work exactly as expected.
Purge Cache
If you’re making updates to your website and need to see the changes faster, simply Purge Cache. You can do this by:
- Navigating to your domain in CloudFlare
- Select Caching on the left side bar
- Select Configuration
- You’ll see the text ‘Purge Cache’. Click it.
This will reset your cache.