Create cloudflare-cache-woocommerce.md via n8n
This commit is contained in:
parent
88ec9480c0
commit
4cef7be28d
72
PBS/Tech/cloudflare-cache-woocommerce.md
Normal file
72
PBS/Tech/cloudflare-cache-woocommerce.md
Normal file
@ -0,0 +1,72 @@
|
||||
---
|
||||
project: cloudflare-cache-woocommerce
|
||||
type: tech-setup
|
||||
status: completed
|
||||
tags:
|
||||
- pbs
|
||||
- cloudflare
|
||||
- woocommerce
|
||||
- cache
|
||||
- production
|
||||
created: 2026-03-24
|
||||
updated: 2026-03-24
|
||||
path: PBS/Tech/
|
||||
---
|
||||
|
||||
# Cloudflare Cache Rules - WooCommerce Setup
|
||||
|
||||
## Background
|
||||
|
||||
After launching the WooCommerce store, a "coming soon" page was sticking around for visitors due to Cloudflare serving a cached version. The root cause was an aggressive "cache all" rule with no WooCommerce exceptions.
|
||||
|
||||
## What Was Already in Place
|
||||
|
||||
A cache rule set to **All incoming requests → Eligible for cache** was in place to improve cache hit rate (previously 87% of traffic was uncached).
|
||||
|
||||
## Problem
|
||||
|
||||
With a whole-site cache rule and no exceptions, Cloudflare was caching WooCommerce dynamic pages including:
|
||||
- Cart
|
||||
- Checkout
|
||||
- My Account
|
||||
- Pages tied to active shopping sessions
|
||||
|
||||
This caused stale content to be served to visitors, including the "coming soon" page after the store launched.
|
||||
|
||||
## Solution
|
||||
|
||||
Created a **new cache rule placed above the existing "cache all" rule** with the following configuration:
|
||||
|
||||
### Rule: WooCommerce Bypass
|
||||
**Order:** First (runs before the cache all rule)
|
||||
**Filter:** Custom expression
|
||||
|
||||
```
|
||||
(http.request.uri.path contains "/cart") or
|
||||
(http.request.uri.path contains "/checkout") or
|
||||
(http.request.uri.path contains "/my-account") or
|
||||
(http.cookie contains "woocommerce")
|
||||
```
|
||||
|
||||
**Cache eligibility:** Bypass cache
|
||||
**TTL settings:** None needed (bypass ignores TTL)
|
||||
|
||||
## How It Works
|
||||
|
||||
Cloudflare cache rules use **first match wins** logic:
|
||||
- Rule 1 catches all WooCommerce pages and active shopping sessions → bypass cache
|
||||
- Rule 2 catches everything else → cache it
|
||||
|
||||
This means static content (recipes, homepage, product images) still gets cached for performance, while dynamic shopping pages always serve fresh content.
|
||||
|
||||
## Key Decisions
|
||||
|
||||
- Used `http.cookie contains "woocommerce"` instead of listing individual cookie names — broader match covers all current and future WooCommerce cookies
|
||||
- No browser TTL needed on the bypass rule — nothing is being stored
|
||||
- Left the existing "cache all" rule unchanged — exceptions-first approach is cleaner than listing every page to cache
|
||||
|
||||
## Result
|
||||
|
||||
- WooCommerce cart, checkout, and account pages now always serve fresh content
|
||||
- Rest of the site continues to benefit from Cloudflare caching
|
||||
- No stale page issues for customers during active shopping sessions
|
||||
Loading…
Reference in New Issue
Block a user