CF GarageThe cache boundary problem of a store
WooCommerce pages fall into three strict categories: catalog pages (product, category) that are identical for everyone and can be cached; customer pages (cart, checkout, my-account) that must never be cached; and machine endpoints (payment webhooks, order APIs) that must reach the origin unmodified, every time. One imprecise rule in either direction causes either empty carts or a slow store.
Setting it up step by step
Step 1: strict SSL/TLS and protected cookies. Same base as any WordPress: Full (strict) mode to avoid loops, then a Cache Rule that bypasses caching whenever a WooCommerce session cookie (woocommerce_items_in_cart, wp_woocommerce_session) is present, or on /cart, /checkout and /my-account paths.
Step 2: cache the catalog deliberately. Product and category pages are your cache candidates: long TTLs for /wp-content/ assets, and edge caching of catalog HTML when the store serves the same content to anonymous visitors. Verify with curl that cf-cache-status flips from DYNAMIC to HIT on product pages.
Step 3: exempt payment webhooks explicitly. Payment gateways (Stripe, PayPal and bank PSPs) call your site server-to-server during checkout. A maintenance rule, a WAF rule or a rate limit that touches those routes breaks real orders silently. List the webhook paths in a top-priority skip rule, the same way described in our guide on WAF false positives on signups and checkouts.
Step 4: control automated abuse. Price scraping, inventory hoarding bots and card testing all show up first as request patterns. Rate limiting on /?add-to-cart= bursts, on checkout POSTs and on failed payment attempts protects both your stock data and your PSP fees.
Step 5: measure what matters. Track cache hit ratio on catalog pages, checkout response times, and the false-positive count in Security Events. An e-commerce change is only done when these three stop moving in the wrong direction.
Common mistakes that cost orders
- Caching the checkout page. The classic catastrophe: one customer sees another's checkout. When in doubt, bypass; product pages alone carry most of the speed win.
- Rate limiting the checkout POST path. A shared limit catches multi-step checkouts and real buyers retrying with a corrected card. Rate limit with generous, path-specific thresholds and challenge rather than block.
- Blocking payment gateway IPs. Gateways publish IP ranges that change; a static blocklist kills webhooks one day without notice. Use verified-bot and explicit hostname exemptions instead.
- Ignoring the mobile checkout path. Most traffic is mobile; test the full order flow on a real phone after every rule change.
- Forgetting cron and AJAX endpoints.
admin-ajax.phpand WP-Cron calls need consistent treatment across rules, or you will see random add-to-cart failures.
Frequently asked questions
Can I cache WooCommerce product pages safely?
Yes, when the page carries no user-specific content and no session cookie is present, which the bypass rule guarantees. Product pages with dynamic stock badges can still be cached with a short TTL and cache-stripped for session-bearing requests.
Why do payments fail since I enabled Cloudflare rules?
Usually a WAF or rate limiting rule touching the webhook or return-URL routes. Check Security Events for blocked requests coming from your PSP's ASN, then add those routes to a skip rule. The diagnosis path is the same as the one in our WAF false positive guide.
Do I need a paid Cloudflare plan for a WooCommerce store?
Free covers caching rules, redirect rules and basic bot fighting. Pro adds the WAF managed rulesets and image optimization, useful at higher traffic. Most stores start on Free and upgrade for managed WAF rules when abuse grows.
How do I stop competitors scraping my prices?
Perfect prevention is impossible, but rate limiting by IP and ASN, verified-bot-only exemptions and aggressive challenge thresholds on catalog pages raise the cost sharply. Measure the trade-off: too tight, and search engine crawlers get caught too.