APO Configuration
Cloudflare APO (Automatic Platform Optimization) caches WordPress HTML at the edge so visitors around the world see low-latency TTFB. The key is to cache public pages aggressively and bypass anything that is personalized (logged-in users, cart/checkout, account).
What APO Changes
- HTML can be served from the edge (not just static assets).
- Purge behavior is tied to WordPress updates when the Cloudflare WP plugin is connected.
Static vs Dynamic
- Static / Blog
- Woo / Membership
- APO ON
- Long TTL (purge on updates)
- Minimal bypass rules
- APO ON
- Strict bypass rules for cart/checkout/account
- Cookie bypass for logged-in sessions
- Validate checkout after every rule change
Setup Checklist
- Enable APO in the Cloudflare dashboard.
- Install and connect the Cloudflare WordPress plugin.
- Confirm APO is enabled in the plugin.
- Add bypass rules for dynamic routes and auth cookies.
- Verify with headers.
Bypass Rules (Typical)
Bypass caching for:
/wp-admin*/wp-login.php*/cart*,/checkout*,/my-account*- Requests with auth/session cookies (example:
wordpress_logged_in_)
Verification
Public page (should be HIT after warm):
curl-apo-hit.sh
curl -I https://example.com/
Example signals:
apo-hit-example.txt
cf-cache-status: HIT
cf-apo-via: cache
Checkout (should bypass):
curl-checkout-bypass.sh
curl -I https://example.com/checkout/
apo-bypass-example.txt
cf-cache-status: BYPASS
Common Mistakes
| Mistake | What Happens | Fix |
|---|---|---|
| No bypass rules for Woo routes | Broken carts/checkout | Add path bypass for cart/checkout/account |
| No cookie bypass for logged-in sessions | Cached HTML served to authenticated users | Bypass when auth cookies are present |
| Very short TTL | Low hit rate | Use longer TTL + purge on updates |