Overview
Cloudflare Cache Rules are evaluated for every incoming request. The rules are grouped into two categories: rules that make content eligible for edge caching, and rules that force a cache bypass for content that must always be served fresh from the origin.
Rules 1 and 2 enable caching, one for HTML on all incoming requests and one for static assets.
Rules 3 through 7 bypass the cache for dynamic, authenticated, transactional, admin, and API traffic.
There are 7 rules in total, all marked as Active. Two of the rules reference the store's public domain and the admin host; these host values must be provided for the target environment (shown as <store-domain> and <admin-host> below).
In addition to the cache rules, the integration requires two configuration steps in the application itself:
- The Cloudflare settings must be enabled in the Admin.
- The Cloudflare connection details must be provided in the environment configuration.
These details allow the Webstore to authenticate to the Cloudflare API and purge the edge cache when publish events occur.
1. Cloudflare Cache Rules
1.1 HTML
- Order: 1
- Match Type: All incoming requests
- Match Against: All incoming requests
- Cache Eligibility: Eligible for cache
- Edge TTL: Ignore cache-control header and use this TTL – 2 hours
- Browser TTL: Set (confirm exact value in the dashboard as it is not shown in the captured screen)
- Respect Strong ETags: On
- Serve Stale Content While Revalidating: On
- Status: Active
Why the Rule is Needed
Establishes the baseline caching behavior for page (HTML) responses. It marks requests as eligible for cache, ignores the origin cache-control header, and caches content at the edge for 2 hours.
The rule respects strong ETags for validation and serves stale content while revalidating, ensuring visitors are not blocked while content refresh occurs in the background.
Bypass rules configured later override this rule for any request that must not be cached.
Note: This rule applies to all incoming requests by default, excluding the URLs covered by the Admin bypass rule (Rule 6). If caching is required only for specific domains, filters can be added to this rule to restrict its scope accordingly.
1.2 cache-static-content
- Order: 2
- Match Type: Custom filter expression
- Match Against:URI Full contains <store-domain> AND File extension is in js, css, png, jpg, svg, webp, gif, ico, jpeg
- Cache Eligibility: Eligible for cache
- Edge TTL: Ignore cache-control header and use this TTL – 1 hour
- Status Code TTL: Single code, 200 (OK) – 1 hour
- Browser TTL: Not set
- Status: Active
Expression Preview
(http.request.full_uri contains "<store-domain>" and
http.request.uri.path.extension in {"js" "css" "png" "jpg" "svg" "webp" "gif" "ico" "jpeg"})Why the Rule is Needed
Makes static assets such as scripts, stylesheets, images, and icons explicitly cacheable at the edge for one hour, independent of the origin cache-control header.
These files change infrequently and benefit significantly from edge caching, reducing origin traffic and improving page load performance.
1.3 Bypass Dynamic / User Pages
- Order: 3
- Match Type: Custom filter expression
- Match Against:URI Path starts with /cart, /checkout, /my-account, or /account
- Cache Eligibility: Bypass cache
- Placement: Custom order — fire after cache-static-content
- Status: Active
Expression Preview
(starts_with(http.request.uri.path, "/cart")) or (starts_with(http.request.uri.path, "/checkout")) or (starts_with(http.request.uri.path, "/account"))
Why the Rule is Needed
Cart, checkout, and account pages are user-specific and must always be rendered with real-time data from the origin.
Bypassing the cache for these paths ensures that one visitor never sees another visitor's personalized content, cart details, or account information.
1.4 Bypass on Login / Cart Cookies
- Order: 4
- Match Type: Custom filter expression
- Match Against:Cookie contains next-auth.session-token, _Secure-next-auth.session-token, CartId, or CartNumber; OR URI Path contains login
- Cache Eligibility: Bypass cache
- Placement: Custom order — fire after Bypass Dynamic / User Pages
- Status: Active
Expression Preview
(http.cookie contains "next-auth.session-token") or (http.cookie contains "_Secure-next-auth.session-token") or (http.cookie contains "CartId") or (http.cookie contains "CartNumber") or (http.request.uri.path contains "login")
Why the Rule is Needed
Any request carrying a session cookie or cart cookie belongs to an authenticated or active shopping user.
These responses are personalized and should never be cached. This rule bypasses the cache whenever authentication or cart-related cookies are detected.
Including paths that contain login ensures authentication-related pages are always served directly from the origin, preventing cached responses from being delivered to authenticated users.
1.5 Bypass Cache for Non-GET Methods
- Order: 5
- Match Type: Custom filter expression
- Match Against:Request Method does not equal GET
- Cache Eligibility: Bypass cache
- Status: Active
Why the Rule is Needed
Only GET requests are safe to cache. Requests using methods such as POST, PUT, PATCH, DELETE, and other non-GET methods either modify application data or return non-idempotent responses that should always be processed directly by the origin server.
Bypassing the cache for all non-GET requests ensures transactional accuracy, prevents stale responses, and maintains the integrity of write operations across the application.
1.6 bypass Admin
- Order: 6
- Match Type: Custom filter expression
- Match Against: URI Full contains https://<admin-host>/
- Cache Eligibility: Bypass cache
- Status: Active
Expression Preview
(http.request.full_uri contains "https://<admin-host>/")
Why the Rule is Needed
The Admin application contains highly dynamic, user-specific, and security-sensitive content that must never be cached at the edge.
Bypassing the cache for all requests targeting the Admin host ensures administrators always receive the most current data and eliminates the risk of cached responses being shared across users.
This rule protects privileged administrative functionality, improves data consistency, and ensures all Admin operations are executed directly against the origin server.
Note: Provide the appropriate <admin-host> value for the target environment when configuring this rule.
1.7 Bypass auth + API
- Order: 7
- Match Type: Custom filter expression
- Match Against: URI Path starts with /api/auth, or URI Path equals /login, or URI Path equals /signin
- Cache Eligibility: Bypass cache
- Placement: Custom order — fire after bypass Admin
- Status: Active
Expression Preview
(starts_with(http.request.uri.path, "/api/auth")) or (http.request.uri.path eq "/login") or (http.request.uri.path eq "/signin")
Why the Rule is Needed
Authentication endpoints and API authentication routes process user credentials, create sessions, and generate authentication tokens.
Because these responses are request-specific and security-sensitive, they must never be stored or served from cache.
Bypassing the cache for authentication-related pages and API endpoints ensures that every login request, token validation, and authentication flow is processed directly by the origin server, maintaining security, session integrity, and accurate authentication behavior.
2. Admin — Cloudflare Setting
In the Admin, navigate to Store → Additional Attributes → Cloudflare Setting to configure the Cloudflare integration. The integration must be enabled and associated with the correct Cloudflare zone for the target environment.
The following settings must be configured:
| Setting | Required Value | Notes |
|---|---|---|
| Enable Cloudflare | Yes | Required field. Defaults to No and must be switched to Yes to activate the integration. |
| Zone ID | (zone-specific) | The Cloudflare Zone ID for the environment's domain. Copy the value from the Cloudflare dashboard on the Zone Overview page. |
Important: Enable Cloudflare must be set to Yes and a valid Zone ID must be provided before the application can communicate with Cloudflare.
The Cloudflare Setting screen is available under: Store → Additional Attributes → Cloudflare Setting.
3. Cloudflare Connection Details
For the Webstore to communicate with the Cloudflare API and perform cache purge operations, the following connection details must be configured for the target environment. All values are required.
| Detail to Provide | Purpose | Where to Obtain It |
|---|---|---|
| Cloudflare API Key / Token | Authenticates Webstore requests to the Cloudflare API and enables cache purge operations. | Cloudflare Dashboard → My Profile → API Tokens. |
| Cloudflare Account Email | Account identity used together with the API key or token for Cloudflare authentication. | The email address associated with the Cloudflare account that owns the zone. |
| Cloudflare API Base URL | The Cloudflare API endpoint used by the Webstore when making API requests. | Use the standard Cloudflare API base URL. |
| Zone ID | Identifies the Cloudflare zone that should receive cache purge requests. | Cloudflare Dashboard → Zone Overview page. |
These configuration values must be available before the Webstore can successfully authenticate and communicate with Cloudflare.
Without valid connection details, the Webstore will not be able to execute Cloudflare cache purge operations, and the publishing-related cache refresh behavior described in Section 5 will not function correctly.
4. Cache Purge Behavior
Using the API credentials configured in Section 4, the Webstore automatically performs a full Cloudflare cache purge (full zone flush) when specific publishing events occur. Administrators can also trigger a cache purge manually from the Admin Console.
The following events trigger an automatic full Cloudflare cache purge:
- Catalog Publish – Publishing a catalog triggers a full Cloudflare cache purge.
- Product Publish – Publishing an individual product triggers a full Cloudflare cache purge.
- Store Publish – Publishing store configuration changes triggers a full Cloudflare cache purge.
- Manual Purge – Administrators can manually purge the Cloudflare cache from Global Settings → Cache Management.
Operational Note
Each of the events listed above performs a purge of the entire Cloudflare cache for the configured zone rather than selectively clearing only the changed content.
Immediately after a purge operation, the edge cache becomes cold. The first requests for pages, assets, and resources must be served directly from the origin server until Cloudflare rebuilds and repopulates the cache.
To minimize the impact on application performance and user experience, publish operations should be planned carefully, especially during periods of high traffic or peak business activity.
Because purge operations affect the entire Cloudflare zone, the configured Zone ID (Section 3) and Cloudflare API credentials (Section 4) must be validated carefully for each environment.
An incorrect Zone ID may result in one of the following outcomes:
- The cache purge operation fails and the environment continues serving outdated cached content.
- The cache purge operation targets and clears the cache for the wrong Cloudflare zone.
5. Configuration Notes
Rule Order Matters
Cloudflare evaluates cache rules from top to bottom. When multiple rules apply to a request, the last matching rule takes precedence for a given setting.
The bypass rules (Rules 3 through 7) are intentionally positioned after the caching rules (Rules 1 and 2) so they can override cache eligibility for personalized, transactional, administrative, and API requests.
When recreating the configuration, maintain the exact rule order documented in this guide.
Host Values
Rules 2 and 6 reference environment-specific host values:
- <store-domain>
- <admin-host>
These values must be identified and supplied for the target environment before the rules are created.
Cookie List Validation
Rule 4 evaluates requests based on the following cookie names:
- next-auth.session-token
- _Secure-next-auth.session-token
- CartId
- CartNumber
The rule also evaluates any request path containing the term login.
Before enabling the rule, verify that the cookie names match the values currently used by the application.
TTL Values
- Rule 1 (HTML): Edge TTL is configured for 2 hours and ignores the origin cache-control header.
- Rule 2 (Static Content): Edge TTL is configured for 1 hour and ignores the origin cache-control header.
- Rule 2 Status Code TTL: HTTP 200 (OK) responses are cached for 1 hour.
The Browser TTL configured for Rule 1 should be verified directly in the Cloudflare dashboard.
Placement and Rule Chain
Several rules use a custom execution order configured through the fire after setting:
- Bypass Dynamic / User Pages fires after cache-static-content.
- Bypass on Login / Cart Cookies fires after Bypass Dynamic / User Pages.
- Bypass auth + API fires after bypass Admin.
Recreate this sequence exactly so the final rule order remains consistent from Rule 1 through Rule 7.
All Rules Must Remain Active
After configuration and validation are complete, all seven cache rules should remain enabled and display a status of Active.
6. Summary of Cache Rules
| # | Name | Match Against | Action |
|---|---|---|---|
| 1 | HTML | All incoming requests | Eligible for cache; Edge TTL 2 hours (ignore cache-control); Browser TTL; Respect strong ETags; Serve stale while revalidating. |
| 2 | cache-static-content | URI Full contains <store-domain> AND file extension is one of js, css, png, jpg, svg, webp, gif, ico, jpeg. | Eligible for cache; Edge TTL 1 hour; Status Code TTL 200 = 1 hour. |
| 3 | Bypass Dynamic / User Pages | URI Path starts with /cart, /checkout, /my-account, or /account. | Bypass cache. |
| 4 | Bypass on Login / Cart Cookies | Cookie contains next-auth.session-token, _Secure-next-auth.session-token, CartId, or CartNumber; OR URI Path contains login. | Bypass cache. |
| 5 | Bypass Cache for Non-GET Methods | Request Method does not equal GET. | Bypass cache. |
| 6 | bypass Admin | URI Full contains https://<admin-host>/. | Bypass cache. |
| 7 | Bypass auth + API | URI Path starts with /api/auth; URI Path equals /login; URI Path equals /signin. | Bypass cache. |