Cloudflare Cache Rules for WordPress in 2026: Safe Defaults, Safe Exclusions, and the Mistakes That Break Sites

Cloudflare cache rules for WordPress sit at a dangerous intersection: configured correctly, they dramatically improve performance; configured incorrectly, they serve logged-in admin pages to anonymous visitors, leak private data, or break checkout flows. This guide covers the safe defaults that work for nearly every WordPress site, the exclusions you must get right, and the mistakes that cause real damage.

The safe default: cache everything, then exclude carefully

The most reliable pattern starts with a broad caching rule and adds specific exclusions. Cache all static responses by default—HTML, CSS, JavaScript, images, fonts. Then exclude paths and conditions where caching is unsafe: admin pages, login states, dynamic pages with user-specific content.

This “cache everything, exclude carefully” approach works better than selective caching because you start from maximum performance and carve out exceptions for functionality. The alternative—selectively enabling caching for specific pages—leaves performance gains on the table for any page you forget to include.

Cloudflare’s Cache Rules interface lets you set conditions based on URL path, cookie presence, HTTP headers, and other request characteristics. For WordPress, the key conditions are: URL path patterns for admin areas, cookie patterns for logged-in states, and specific paths for dynamic functionality.

Essential exclusions every WordPress site needs

The WordPress admin area (/wp-admin/) must never serve from cache. Cached admin pages cause severe problems: editors see stale content, settings don’t save correctly, and administrative functions fail silently. Exclude the entire /wp-admin/* path from all caching.

The login page (/wp-login.php) needs exclusion for obvious reasons. Cached login pages can expose session tokens or serve one user’s authenticated state to another. Always bypass cache for authentication-related paths.

WordPress AJAX endpoint (/wp-admin/admin-ajax.php) handles dynamic operations from both admin and front-end. Many plugins use AJAX for forms, live search, filtering, and other dynamic features. Caching AJAX responses produces incorrect results. Exclude this path.

The WordPress REST API (/wp-json/*) typically serves dynamic, often user-specific data. Caching API responses can return stale data or another user’s information. Exclude unless you specifically understand which API endpoints are safe to cache and have configured cache keys appropriately.

WooCommerce paths need careful exclusion: /cart/*, /checkout/*, /my-account/*, and any page with cart widget data. Caching these pages serves one customer’s cart or account to another—a serious privacy and functionality failure. Cart and checkout must always be dynamic.

Cookie-based bypass rules

WordPress sets specific cookies for logged-in users: wordpress_logged_in_*, wordpress_sec_*, and wp-settings-*. When any of these cookies exist in the request, the visitor is logged in and should see dynamic, uncached content.

Configure Cloudflare to bypass cache when these cookies are present. This ensures logged-in admins, editors, and subscribers always see current content while anonymous visitors benefit from cached pages.

WooCommerce adds its own cookies: woocommerce_cart_hash, woocommerce_items_in_cart, and wp_woocommerce_session_*. When these exist, the visitor has an active shopping session. Bypass cache to ensure cart contents display correctly.

Cookie-based bypass is the safest approach for handling logged-in states because it’s automatic. You don’t need to maintain lists of user-specific pages—any request from a logged-in user bypasses cache regardless of what page they’re visiting.

Cache duration settings

For static assets (images, CSS, JavaScript, fonts), aggressive caching is safe. Set long TTLs—weeks or months. These files have unique filenames or version parameters that change when content changes. Cached versions become irrelevant when the filename changes.

For HTML pages, moderate TTLs are more appropriate. Caching HTML for 1-4 hours balances performance with content freshness. Published changes become visible within the cache duration. Shorter TTLs mean fresher content but more origin hits. Longer TTLs mean better performance but delayed updates.

Consider implementing cache purging alongside TTLs. When you publish or update content, automatically purge the specific URL from Cloudflare cache. This combines long TTLs (good performance) with immediate updates (fresh content). Most WordPress caching plugins include Cloudflare purge integration.

The mistakes that cause real problems

Caching pages with Set-Cookie headers creates session leakage. If a cached response includes a session cookie, every subsequent visitor receiving that cached page gets the same session. This is a security vulnerability. Ensure Cloudflare doesn’t cache responses that set cookies, or strip cookies from cached responses.

Ignoring query string variations causes wrong-page bugs. WordPress uses query strings for pagination, search, and filtering. If cache rules ignore query strings, page 2 of search results might serve the same cached content as page 1. Configure cache keys to include relevant query parameters.

Caching POST request responses breaks forms. Contact forms, login attempts, and other POST submissions should never serve cached responses. Ensure cache rules only apply to GET requests. POST, PUT, and DELETE should always hit origin.

Caching redirect responses incorrectly can create redirect loops. If a redirect response is cached with the wrong cache key, visitors get stuck in loops. Be careful caching 301/302 responses, especially for mobile redirects or authentication redirects.

Not testing after configuration is the most common mistake. Deploy cache rules to a staging environment or test with a subset of traffic. Verify: anonymous visitors see cached pages, logged-in users see dynamic content, admin area works correctly, forms submit successfully, WooCommerce cart/checkout function properly.

Monitoring cache performance

Track cache hit ratio in Cloudflare analytics. A healthy WordPress configuration achieves 70-90% cache hit rate for anonymous traffic. Below 50% suggests exclusion rules are too broad or cache durations too short.

Monitor for cache-related errors through application logs. If users report seeing others’ content, admin dashboard issues, or form failures, cache misconfiguration is the likely cause. Quick rollback capability—disabling cache rules entirely—provides safety while investigating.

Review Cloudflare’s cache analytics to understand what’s cached and what bypasses. High bypass rates for specific URLs indicate exclusion rules catching more traffic than intended. Low hit rates for popular pages suggest cache isn’t warming effectively.

A practical starting configuration

Start with these rules in order: bypass cache for /wp-admin/*, bypass for /wp-login.php, bypass for wp-admin/admin-ajax.php, bypass when WordPress logged-in cookies are present, cache everything else with a 2-hour HTML TTL and long asset TTLs.

Test thoroughly, then refine. Add exclusions for WooCommerce paths if applicable. Adjust TTLs based on your content update frequency. Add purge automation for immediate updates when publishing.

This foundation provides substantial performance improvement with minimal risk. Refinements can follow once the basic configuration proves stable. For WordPress sites where caching configuration complexity exceeds your comfort level, our performance team can implement and validate cache rules as part of a broader optimisation engagement.