Cloudflare Enterprise for WordPress: cache less, correctly.

Cloudflare Enterprise is often sold as a performance upgrade. It is really a control plane: more granular cache rules, a stronger WAF, bot management, log export, and a support relationship. The performance gain comes from using those controls well. Misconfigured, the same features can cache a customer's cart, block a payment webhook, or make the admin unusable.

This guide assumes WordPress on a conventional origin, with WooCommerce on the same domain. It is deliberately conservative: cache only what is safe, observe before enforcing, and keep a rollback for every change.

What Enterprise actually adds

Plan features change, so verify the current contract before buying. In general, the enterprise tier adds more sophisticated WAF managed rules, bot management, custom cache rules and cache keys, tiered cache, Argo smart routing, image optimization at scale, logpush, and a named support path. Some of these are available in lower tiers in limited form; the enterprise value is in the controls, limits, and support, not a single magic feature.

For a WordPress site, the useful capabilities are usually: precise cache bypass, cache tags or purge-by-URL, WAF tuning with logs, bot control that does not block legitimate crawlers, and the ability to export security events to your own monitoring. Image resizing and tiered cache are nice; they are not worth a broken checkout.

1. DNS and TLS first

Move the authoritative DNS to Cloudflare and confirm the records before changing nameservers. Keep the TTL low during the transition. Once DNS is stable, set SSL/TLS to Full (strict) and install a valid origin certificate. If the origin has a self-signed certificate, Full (strict) will fail; use an origin CA certificate or a publicly trusted certificate instead.

Enable Always Use HTTPS and HSTS only after you have verified that every subdomain and internal integration supports HTTPS. HSTS is difficult to undo quickly; roll it out with a short max-age first, then increase it.

# Verify the origin certificate and redirect behavior before tightening TLS
curl -I https://origin.example.com
openssl s_client -connect origin.example.com:443 -servername origin.example.com

# Check the apex and www after the DNS switch
curl -I https://example.com
curl -I https://www.example.com

2. Cache rules that respect sessions

Start by listing the paths that must never be cached: WordPress admin and login, REST routes used by integrations, WooCommerce cart, checkout, and account pages, previews, feeds if they are personalized, and any path with a session cookie. Then build a bypass rule that is explicit rather than clever.

# Cloudflare cache-rule expression (not a drop-in config)
(
  http.request.uri.path contains "/wp-admin" or
  http.request.uri.path contains "/wp-login.php" or
  http.request.uri.path contains "/wp-json" or
  http.request.uri.path contains "/cart" or
  http.request.uri.path contains "/checkout" or
  http.request.uri.path contains "/my-account" or
  http.request.uri.path contains "/preview" or
  http.cookie contains "wordpress_logged_in" or
  http.cookie contains "woocommerce_items_in_cart" or
  http.cookie contains "wp_woocommerce_session_"
)

Apply "Bypass cache" to that expression. For everything else, a conservative HTML cache rule can be: method is GET, the path is not the bypass set, and there is no session cookie. Set an edge TTL that matches your publishing cadence and a browser TTL of zero or a short value so a purge takes effect quickly.

Do not use a broad “Cache Everything” page rule on a WooCommerce site. It is the fastest route to a cart leaking between customers. If you inherited one, audit it before changing anything else.

3. Purge strategy

Purging everything is easy and expensive: it creates a cold cache and a stampede at the origin. Prefer targeted purges by URL or cache tag. WordPress can emit cache tags on publish, but that requires a plugin or custom code; if you do not have tags, purge the specific URLs that changed and keep a small TTL on the rest.

For a product import, purge the affected product and category URLs, then warm the most important pages before the traffic arrives. For a theme deploy, purge the whole HTML cache only after the new assets are live and the origin is healthy.

4. WAF: observe, then enforce

Enable managed rules in log mode first. Review the events for a week, especially on admin, REST, and checkout paths. False positives on a payment callback or a legitimate customer are more expensive than the attack you are trying to stop. Once the baseline is clean, move to block mode in stages.

Create scoped skip rules for integrations that need them. A payment webhook should be allowed by exact path and method, not by disabling the WAF for the whole site. If the provider publishes IP ranges, restrict to those as an additional layer. Log the exceptions and review them quarterly; an old skip rule is a permanent hole.

5. Bot management without blocking Google

Verified bots should generally be allowed. Configure the bot policy to allow known search engines and monitoring services, challenge unverified automation on sensitive paths, and leave checkout to human traffic. Do not challenge the payment provider's callback or your own uptime monitor.

If you use Cloudflare's bot score, start with a high threshold and log the results. A score that is too aggressive will block real customers on mobile networks or privacy tools. The goal is to reduce credential stuffing and scraping, not to win a purity contest.

6. Image optimization and tiered cache

Image resizing, Polish, and WebP/AVIF conversion can reduce LCP, but they are not free: each transformation adds compute and can change the visual result. Test on a subset of pages, compare LCP and visual quality, and keep the originals. Do not enable aggressive conversion on product images without checking that the catalog still looks correct.

Tiered cache and Argo can reduce origin load and improve latency for distributed audiences. They are most useful when the origin is far from the edge and the cache hit ratio is already high. They cannot fix a low hit ratio or a slow dynamic path. Measure TTFB and origin requests before and after; if the hit ratio does not move, the feature is not doing much.

The safe rollout order

How to verify it is working

• Cache status: check the `cf-cache-status` header on a catalog page and a cart page. The first should be HIT after warm-up; the second should be BYPASS or DYNAMIC.
• Session isolation: log in as customer A, add an item, then open a private window as customer B. Carts must not mix.
• Checkout: place a real test order with a test card and confirm the webhook and email.
• WAF: review 403s for legitimate paths and confirm the payment callback succeeds.
• Origin load: compare origin requests per minute before and after; a good edge rollout reduces them without reducing checkout success.

The commercial reality

Enterprise pricing is a custom quote and typically starts in the four figures per month, depending on traffic, features, and contract length. That can be rational for a store with significant revenue at risk or a publisher with a global audience. It is hard to justify for a brochure site that would benefit more from a better origin and a simpler cache plugin.

Ask what the contract includes: log retention, support response targets, bot management limits, image transformation volume, and overage pricing. The feature list is less important than the operating model you are buying into.

The pre-flight checklist

The edge is a multiplier. It multiplies a correct cache policy and it multiplies a wrong one.

If you are still choosing a host, remember that Cloudflare does not replace origin capacity. A managed platform with its own edge may be simpler than assembling an origin plus Enterprise. If you need the controls and have the operator, the rollout above is the safe path.