Skip to main content
WP Bulk Publishing

Platforms → Cloudflare

Cloudflare standards

Cloudflare is the most common CDN/proxy for WordPress sites, and its presence changes how requests reach WordPress — cache layer, security headers, IP visibility. WBP is engineered so Cloudflare accelerates the site instead of fighting it: cache is auto-purged selectively on publish, real visitor IPs are restored from CF-Connecting-IP, and dual-layer WAF is treated as complementary, not overlapping.
TL;DR: WBP auto-purges the Cloudflare cache surgically on every publish (selective, with retry on failure), restores real client IPs from CF-Connecting-IP, and runs dual WAF: Cloudflare handles edge + DDoS, WBP Security handles app-level (malware, scraping). No WBP core feature requires Cloudflare.

1. Cache management

Problem: the wrong URL cached at the edge is worse than no cache — stale prices, stale stock, stale personalised blocks.

Solution: WBP auto-purges the Cloudflare cache on every publish, selectively (per URL for a single post; bulk API for a batch), with retry on failure. On the origin: hashed static asset URLs, HTML with s-maxage=300, stale-while-revalidate=86400, wp-admin and wp-login marked private, no-store. Cloudflare's default logged-in cookie bypass handles authenticated sessions without configuration.

2. Dual WAF security

Cloudflare and WBP Security do not overlap — they layer.

  • Cloudflare WAF handles edge threats: DDoS, HTTP flood, TLS abuse, bot signatures, geo rules.
  • WBP Security handles app-level threats: malware scans, scraping detection, brute-force on wp-login, plugin CVE monitoring.

Recommended Cloudflare config: WAF managed ruleset on Sensitive; Bot Fight Mode on; Rate Limiting on /wp-login.php and /xmlrpc.php; Zero Trust access on /wp-admin for staff-only sites.

3. Analytics behind Cloudflare

Behind Cloudflare, WordPress sees Cloudflare's IP on every request instead of the real visitor. That breaks analytics, geo-personalisation, rate limiting and audit logs.

Solution: WBP restores the real IP from the CF-Connecting-IP header on every request, before any WBP plugin runs. Analytics, security, and personalisation all see the true client IP — no per-plugin configuration required.

4. Dynamic features and caching

A/B testing, personalised CTAs, geo-varied prices — all of these need to bypass full-page cache. WBP marks dynamic-content responses with Cache-Control: private, no-store so Cloudflare skips them, or (on Cloudflare Workers) uses a Workers-based split serving so both variants stay cached but different users see different HTML.

5. What we don't do

  • We do not require Cloudflare for any WBP core feature — it's an accelerator, not a dependency.
  • We do not do reflexive full-cache purges. Every purge is surgical (per URL) or scoped (per template tag).
  • We do not overlap with the Cloudflare WAF. Edge is Cloudflare's job; app-level is ours.
  • We do not cache authenticated responses. wp-admin, REST writes and cart pages stay uncached.

Related standards