Cache Control: Patterns and Rules

Beyond basic cache TTL settings, you have fine-grained control over what gets cached through regex patterns and cookie bypass rules. These advanced features let you handle complex scenarios where simple path matching isn't enough.

Understanding Cache Exclusion Patterns

Cache exclusion patterns tell the edge server which URLs should never be cached, regardless of your TTL settings. When a request matches an exclusion pattern, it bypasses the cache entirely and always fetches fresh content from your backend. This is essential for dynamic content like user dashboards, shopping carts, and API endpoints that return personalized data.

The system uses regular expressions to match URLs, giving you powerful pattern matching capabilities. If you're not familiar with regex, don't worry—most common use cases can be handled with simple patterns. A pattern like /admin/ matches any URL containing "/admin/" anywhere in the path. For more precision, you can anchor the pattern with ^/admin/ to match only URLs that start with "/admin/".

Common patterns include excluding entire directory trees with patterns like ^/wp-admin/ for WordPress admin areas or ^/cart/ for e-commerce checkout flows. You can also exclude specific file types that should never be cached, like \.php$ to exclude all PHP files or \.json$ for JSON API responses.

The wildcard pattern .* matches any character, so /api/.* matches anything under the /api/ path. Question marks and special characters need to be escaped with a backslash if you want to match them literally. For example, to exclude a specific query parameter pattern, you might use /search\?q=.

Practical Exclusion Examples

For a typical WordPress site, you'll want to exclude the admin interface and login pages. A pattern like ^/(wp-admin|wp-login) excludes both paths with a single rule. The pipe character | acts as an "or" operator, matching either pattern on either side.

E-commerce platforms need to exclude checkout and cart pages where prices, inventory, and user selections change constantly. Something like ^/(cart|checkout|account|order) covers the main dynamic sections. You can extend this pattern as your site grows by adding more path segments separated by pipes.

API endpoints often return personalized data and should rarely be cached. If all your API routes are under a /api/ prefix, the pattern ^/api/ excludes them all with one rule. For APIs that return public data you do want to cache, you can create more specific patterns like ^/api/private/ to exclude only the authenticated endpoints.

Session-dependent content like user profiles or personalized recommendations should always be excluded. Patterns like ^/user/ or ^/profile/ ensure these pages always reflect the current user's data. Combined with cookie bypass rules, this approach handles logged-in user experiences correctly.

Cookie Bypass Rules Explained

Cookie bypass rules work differently from exclusion patterns. Instead of matching URLs, they examine the request's cookies. If a request contains any of the specified cookies, the entire request bypasses the cache, regardless of the URL. This approach is perfect for maintaining separate experiences for logged-in versus anonymous users.

The cookie bypass system supports exact matches and wildcard patterns. An exact match like PHPSESSID only bypasses cache when that specific cookie is present. A wildcard pattern like wordpress_logged_in_* matches any cookie whose name starts with "wordpress_logged_in_", regardless of what comes after the asterisk.

When a request arrives with bypass cookies, the edge server skips cache lookup entirely and forwards the request directly to your backend. The response isn't cached either, ensuring logged-in users always see fresh, personalized content. Anonymous users without these cookies still benefit from full caching.

This cookie-based approach is more efficient than path-based exclusion for user authentication. Instead of excluding every possible page a logged-in user might visit, you exclude based on the session cookie that indicates they're logged in. The entire site remains cacheable for anonymous visitors while dynamically handling authenticated users.

WordPress Cookie Patterns

WordPress uses several cookies to track logged-in users and their settings. The most important is wordpress_logged_in_*, which appears when someone logs into the WordPress admin panel. This cookie should always trigger cache bypass to ensure administrators see current content and can access the admin interface without cache interference.

Additional WordPress cookies include wp-settings-* for user preferences and wordpress_sec_* for security tokens. Comment authors get comment_author_* cookies to pre-fill their information on subsequent visits. For a complete WordPress setup, you typically want to bypass on all of these: wordpress_logged_in_*, wordpress_sec_*, wp-settings-*, and comment_author_*.

The PHP session cookie PHPSESSID is another common bypass candidate. Many WordPress plugins use PHP sessions for functionality like shopping carts or multi-step forms. Bypassing cache when this cookie is present ensures these features work correctly.

E-commerce and Session Cookies

Shopping cart implementations typically use cookies to track what items a customer has added. Cookie names vary by platform—WooCommerce uses woocommerce_items_in_cart, Shopify uses cart, and custom implementations might use anything. Identify which cookies your platform uses and add them to your bypass rules.

Session cookies like PHPSESSID, JSESSIONID, or framework-specific variants indicate that the application is maintaining server-side state for the user. These almost always warrant cache bypass since the content is inherently personalized to that session. Without bypassing on session cookies, users might see cached content from other users' sessions or experience broken functionality.

Authentication tokens in cookies, whether JWT tokens or proprietary formats, signal that the user is authenticated and should receive personalized content. If your application stores auth tokens in cookies rather than using built-in session mechanisms, add those cookie names to your bypass rules.

Combining Patterns and Rules

Exclusion patterns and cookie bypass rules work together to give you complete control. A common strategy is to use cookie bypass for user authentication states while using exclusion patterns for specific dynamic endpoints. This combination handles both "who is asking" (cookies) and "what they're asking for" (patterns).

For example, you might exclude /api/ paths with a pattern while also bypassing on auth_token cookies. API requests from authenticated users bypass cache due to the cookie, while API requests from anonymous users bypass due to the pattern. Both approaches reach the same outcome through different mechanisms.

Some sites use exclusion patterns for administrative areas and cookie bypass for the public site. Administrative paths like ^/admin/ are excluded completely, ensuring no admin content ever enters the cache. Meanwhile, regular users with shopping cart cookies bypass cache for their personalized shopping experience while anonymous browsers get fully cached pages.

Testing Your Configuration

After setting up patterns and rules, test thoroughly from different user states. Browse your site in an incognito window to verify that anonymous users get cached content. Then log in and verify that your personalized areas show current data and aren't being cached. Check the cache statistics to confirm that logged-in requests are bypassing as expected.

Use your browser's developer tools to inspect which cookies are being set during different user flows. This helps identify which cookies need to be added to bypass rules. Watch for cookies that appear during checkout, login, or when using specific features—these are candidates for bypass rules.

Test edge cases like users who clear cookies mid-session or users who log out. Verify that the absence of bypass cookies allows them to immediately benefit from caching. Check that excluded paths work correctly regardless of cookie state, since pattern exclusions apply universally.

Performance Considerations

Remember that exclusion patterns and bypass rules reduce cache effectiveness. Every request that bypasses cache puts load on your backend server. The goal is to bypass only when necessary for correctness, not preemptively "just in case."

Be as specific as possible with your patterns. Excluding ^/ would bypass everything, defeating the purpose of using a cache. Instead, identify the specific paths that genuinely need fresh data and exclude only those. The more you can safely cache, the better your performance and the lower your backend load.

Cookie bypass rules should target cookies that definitively indicate personalization is needed. Avoid bypassing on tracking or analytics cookies that don't affect content. The distinction is whether the cookie influences what content the server returns—if it does, bypass; if it doesn't, cache normally.

Common Mistakes to Avoid

One frequent error is making patterns too broad. A pattern like admin without anchors or delimiters would match URLs containing "admin" anywhere, including "/administrator/", "/admins/", or even "/badministry/". Use anchors like ^/admin/ and word boundaries to match precisely what you intend.

Another mistake is forgetting to escape special regex characters. If you want to match a literal period in a file extension, use \. not just . because an unescaped period matches any character. Similarly, question marks, asterisks, and brackets have special meanings in regex and need escaping for literal matches.

Overlooking cookie wildcards is also common. Setting a bypass rule for wordpress_logged_in as an exact match won't work because the actual cookie is wordpress_logged_in_username_hash. You need the wildcard pattern wordpress_logged_in_* to match all variations.

When to Use Which Approach

Use exclusion patterns when specific URLs or paths should never be cached regardless of who requests them. Admin panels, API endpoints that return real-time data, and dynamic form processors are good candidates for pattern-based exclusion.

Use cookie bypass rules when the same URLs should be cached for some users but not others. Public blog posts should be cached for anonymous visitors but might need to be fresh for logged-in editors who are making changes. The cookie indicates which treatment is appropriate.

Use both approaches when you have layered requirements. A site might exclude checkout URLs with patterns while also bypassing on session cookies. This "belt and suspenders" approach ensures dynamic content is never inadvertently cached through either path.

The right configuration depends on your specific application architecture and user flows. Start with conservative rules that err on the side of not caching, then gradually expand caching as you verify correct behavior. It's better to miss some caching opportunities initially than to serve stale personalized content.