What Is Cloudflare (and How Enterprise WordPress Uses It)

Cloudflare is a global edge network that sits between your readers and your origin servers. For enterprise WordPress it is usually the layer that decides whether a traffic spike is a non-event or an outage, and whether an attack reaches PHP at all. We put Cloudflare in front of most of the enterprise properties we run at Seahawk VIP; this guide covers the four products that matter for WordPress and the configuration details that make them work.

The four products that matter for WordPress

Cloudflare sells dozens of services. For a WordPress estate, four do most of the work:

1. CDN and caching. Serves copies of your pages and assets from data centers near the reader so the origin is rarely touched.
2. Web Application Firewall (WAF). Inspects requests and blocks known attack patterns, bad bots, and abusive clients before they reach WordPress.
3. Workers. JavaScript that runs at the edge on each request. Used for redirects, header manipulation, A/B routing, and small API transformations without a deploy to origin.
4. Zero Trust. Identity-aware access control for the WordPress admin and other internal surfaces, so /wp-admin is reachable only by authenticated staff on approved devices.

CDN and cache rules for WordPress

Out of the box, Cloudflare caches static assets (images, CSS, JavaScript) and passes HTML through to origin. The real gain for a content site is caching HTML, which requires rules so you do not cache logged-in or personalized responses.

The rule set we deploy on most sites:

• Cache everything for anonymous HTML. Apply a Cache Rule to all paths with an Edge TTL of an hour or more, and set the origin to send Cache-Control: public, s-maxage=3600, stale-while-revalidate=86400 on front-end pages.
• Bypass cache when a WordPress cookie is present. Exclude requests carrying wordpress_logged_in_*, wp-postpass_*, comment_author_*, or woocommerce_* cookies. Logged-in editors must see live content.
• Bypass admin and API paths. /wp-admin/*, /wp-login.php, /wp-json/* (unless you intentionally cache public REST responses), /graphql, /xmlrpc.php, /preview*, and /wp-cron.php.
• Normalize query strings. Ignore marketing parameters such as utm_*, fbclid, and gclid in the cache key so campaigns do not fragment your cache.
• Cache assets aggressively. Long TTLs on /wp-content/uploads/* and versioned theme assets; invalidate by changing the filename, not by purging.

Then wire purge on publish. Install a Cloudflare integration plugin or use the API from a small mu-plugin to purge the post URL, its archives, and the home page when content changes. On Enterprise plans, use cache tags: emit Cache-Tag headers naming post IDs and taxonomies, and purge by tag so one update clears only the pages that reference it.

Measure cache hit ratio in the Cloudflare dashboard. For a publishing site, HTML hit ratio above 90 percent is the target; below that, find what is busting cache.

WAF: start with managed rules, then tune

Enable the Cloudflare Managed Ruleset and the OWASP Core Ruleset. Both include WordPress-specific signatures. Then add custom rules the managed sets will not know about:

• Rate-limit /wp-login.php and /xmlrpc.php. Block xmlrpc.php entirely unless a specific integration needs it.
• Challenge or block requests to /wp-admin/* from countries where you have no staff, or restrict to Zero Trust (next section) and skip geography altogether.
• Block user enumeration via ?author=N and /wp-json/wp/v2/users.
• Enable Bot Fight Mode or, on Enterprise, Bot Management, so scrapers do not consume origin capacity.

Run new rules in log mode for a week before switching to block. False positives on upload endpoints and editor autosaves are common; the admin cookie exclusions used for caching are a good basis for WAF skip rules too.

Workers: edge logic without touching origin

Workers are where Cloudflare moves from defense to engineering tool. Patterns we use on WordPress properties:

• Redirect maps. Thousands of legacy URLs stored in Workers KV and resolved at the edge, which keeps the redirect plugin out of PHP and off the origin.
• Header hardening. Inject Content-Security-Policy, Strict-Transport-Security, and Permissions-Policy consistently across every response, including ones your host cannot easily configure.
• Geo and language routing. Route readers to regional editions by country without a round trip to WordPress.
• Headless glue. For Astro or Next.js front ends, Workers can cache WPGraphQL responses, strip sensitive fields, or stitch multiple origins under one domain.
• Maintenance pages and failover. Serve a static page or a stale cached copy when origin health checks fail.

Keep Workers in version control with the rest of the site and deploy them through CI, not the dashboard.

Zero Trust: protect the admin without a VPN

Most WordPress compromises start at the login page. Cloudflare Access, part of the Zero Trust suite, puts an identity check in front of /wp-admin and /wp-login.php:

• Connect your identity provider (Okta, Entra ID, Google Workspace).
• Create an Access application for the admin paths that requires a valid session from an approved group.
• Add device posture checks if your security team requires managed devices.
• Keep WordPress’s own login in place as a second factor behind Access.

Unauthenticated bots never see the login form, which removes brute-force noise and most credential-stuffing risk. For headless builds, protect the GraphQL endpoint the same way, with a service token for your build pipeline.

How this fits with enterprise hosts

Enterprise WordPress platforms such as WordPress VIP ship with their own edge network. Cloudflare can still sit in front, and it often does when an organization standardizes on Cloudflare across every property. When you stack them:

• Let the host’s layer handle origin caching and purge; use Cloudflare for WAF, Workers, Zero Trust, and DNS.
• Avoid double caching HTML with conflicting TTLs; pick one layer to own page cache and set the other to respect its headers.
• Pass real client IPs through so WordPress and the host’s logs are accurate.
• Confirm your host supports Cloudflare proxied DNS and authenticated origin pulls before cutting over.

Next step

Cloudflare is only as good as its rules, and WordPress has enough edge cases that a default setup usually leaks cache misses and admin exposure. Seahawk VIP configures and operates Cloudflare for enterprise WordPress properties, including the cache rules, WAF tuning, Workers, and Zero Trust policies described here. If you already have a Cloudflare account, we can audit the current configuration against this guide before changing anything.