Cloudflare Command Center: Domains, DNS, Zero Trust, and Tunnels from Beginner to Expert Part 18: Cloudflare for WordPress, Static Sites, SaaS Apps, and APIs

Part 17 built out the Zero Trust foundation: Access policies, identity providers, device posture checks, and the logic that decides what gets through before a request ever reaches your origin. That section covered the infrastructure layer. This one covers the application layer. Specifically, it covers what happens when you take everything you've learned about DNS proxying, SSL modes, Cache Rules, and WAF configuration and apply it to four environments that each have their own failure modes, their own caching logic, and their own security surface.

WordPress behaves differently than a static site deployed to Vercel. A SaaS app with wildcard subdomains needs a different DNS strategy than a single-tenant API. Treating all four the same way is how you end up with cache poisoning on your admin panel, SSL mismatches on your checkout flow, or a staging environment that's accidentally indexed by Google. The patterns in this part exist because the generic setup leaves real performance and security on the table.

This is Part 18 of 23. By this point, you've earned the technical vocabulary to move fast through the configurations below. The explanations assume you're comfortable with proxied records, Full (Strict) SSL, and the difference between a Page Rule and a Cache Rule. What you're building here isn't a checklist. It's a set of composable blueprints you can adapt to any stack you're managing.

Why Environment-Specific Patterns Matter

The cost of a generic Cloudflare setup

Most people add their domain to Cloudflare, proxy their A records, flip on "Auto" SSL, and call it done. That configuration works in the same way a car with four tires and a full tank technically works. It moves. But it doesn't perform, and it doesn't protect.

A generic Cloudflare setup serves HTML and images with the same cache TTL, which means your WordPress admin panel might serve a cached response to the wrong session. It applies WAF rules globally without accounting for the difference between a public marketing page and a REST API endpoint that needs to pass JSON bodies without being blocked by an overzealous managed rule. It leaves staging environments publicly accessible because nobody configured Access. The cost isn't always visible immediately. It shows up as a mysterious 526 error at 2am, a WooCommerce cart that won't update, or a security audit that flags your xmlrpc.php as wide open.

The four environments this part covers are WordPress, static sites, SaaS apps, and APIs. Each one has a documented failure pattern when treated generically, and each one has a configuration blueprint that eliminates those failures.

How pattern thinking accelerates deployment

A pattern isn't a rigid procedure. It's a tested starting point with known trade-offs. When you internalize the WordPress pattern, you don't spend forty minutes debugging why your logged-in users are seeing cached pages. You already know to write the cache bypass rule before you launch. When you know the static site pattern, you don't accidentally proxy a Vercel CNAME in a way that creates a certificate conflict. The decision tree is already solved.

Each blueprint in this part is composable. You can run a WordPress site and a static marketing subdomain on the same zone. You can layer Access on top of a SaaS staging environment. The patterns stack because they're built around Cloudflare's actual rule evaluation order, not around a simplified mental model of how the proxy works. Frame these as starting points. Adapt them to your stack. Document what you change and why.

The WordPress Pattern: DNS, SSL, and Cache Done Right

DNS configuration for WordPress on Cloudflare

The DNS setup for a WordPress site on Cloudflare is straightforward but the details matter. Your root domain and www subdomain both need proxied A or AAAA records pointing to your origin server's IP address. The orange cloud has to be on. DNS-only records bypass Cloudflare entirely, which means no WAF, no caching, and no DDoS protection.

Here's what a clean DNS table looks like for a WordPress site that also handles its own email:

The mail records stay DNS-only. Proxying your mail subdomain through Cloudflare breaks SMTP. The DKIM TXT record goes on the selector subdomain your mail provider specifies, not on the root. Get this wrong and your outbound email fails SPF/DKIM checks.

Choosing the correct SSL mode for WordPress

Full (Strict) is the only correct SSL mode for a WordPress site. Not Flexible. Not Full without Strict. Flexible SSL terminates HTTPS at Cloudflare's edge and then sends the request to your origin over plain HTTP. That means your login credentials, session cookies, and form submissions travel unencrypted between Cloudflare and your server. It's a false sense of security.

Full (Strict) requires a valid certificate on your origin server. The easiest way to get one is through Cloudflare's Origin CA. In the Cloudflare dashboard, go to SSL/TLS, then Origin Server, and generate a certificate. Install it on your server using your hosting control panel or by dropping the cert and key files into your Nginx or Apache configuration. Cloudflare's Origin CA certificates are valid for 15 years and are trusted by Cloudflare's edge. They're not trusted by browsers directly, which is fine, because the browser never talks to your origin. Cloudflare does.

Cache rules that won't break your admin panel

This is where most WordPress configurations break. Cloudflare doesn't know the difference between a public blog post and your wp-admin dashboard unless you tell it. If you cache everything, your admin panel serves stale responses. If you cache nothing, you lose the performance benefits entirely.

The correct approach uses two Cache Rules in the Cloudflare dashboard under Caching. Cache Rules replace the older Page Rules for caching logic and give you more precise control.

Rule 1: Bypass cache for admin and authenticated sessions

Match condition: URI path contains /wp-admin OR URI path contains /wp-login.php OR cookie contains wordpress_logged_in.

Action: Bypass cache.

Rule 2: Cache static assets aggressively

Match condition: file extension matches jpg, jpeg, png, gif, webp, svg, css, js, woff2.

Action: Cache everything. Edge TTL: 30 days. Browser TTL: 7 days.

The wp-json REST API endpoint is a judgment call. If your theme or plugins use it for dynamic data, bypass cache. If you're using it for read-only content like a headless frontend, you can cache it with a short TTL of 60 to 300 seconds. The safer default is bypass.

Page Rules still work but Cloudflare is phasing them toward deprecation. Write new rules in Cache Rules. If you have existing Page Rules, migrate them. The behavior is equivalent and Cache Rules give you compound match conditions that Page Rules can't express.

WordPress Security Layer: WAF, Bot Fight, and Rate Limiting

Enabling the Cloudflare WAF for WordPress

The Cloudflare WAF ships with a WordPress managed ruleset that you enable under Security, then WAF, then Managed Rules. The ruleset blocks known WordPress exploit patterns: malformed login requests, PHP injection attempts, path traversal on theme and plugin files, and a rotating set of CVE-based signatures that Cloudflare updates without requiring any action on your end. Enable it. The false positive rate on a standard WordPress install is low enough that you should turn it on before you customize anything else.

The managed ruleset doesn't cover everything. Custom rules fill the gaps.

Custom rule: Block xmlrpc.php

xmlrpc.php is a legacy WordPress endpoint that enables XML-based remote procedure calls. Almost no modern WordPress setup needs it, and it's been a reliable attack vector for credential stuffing and DDoS amplification for years. Create a custom WAF rule with this logic:

Match: URI path equals /xmlrpc.php

Action: Block.

Done. If you're running a plugin that genuinely requires xmlrpc.php, replace Block with Managed Challenge. But audit that plugin first.

Bot Fight Mode and xmlrpc.php

Bot Fight Mode challenges requests that Cloudflare's bot scoring identifies as automated. For most WordPress sites, turn it on. The trade-off shows up with WooCommerce. Checkout flows that rely on third-party payment processors, affiliate tracking scripts, or inventory sync APIs can get caught by Bot Fight Mode because those services send automated requests that score as bot traffic.

If you're running WooCommerce, enable Super Bot Fight Mode instead of the standard version, and add bypass rules for the specific user agents or IP ranges your payment processor uses. Stripe, PayPal, and most major processors publish their IP ranges. Allowlist them explicitly in a custom rule placed above the Bot Fight Mode evaluation order.

Hotlink protection is worth enabling for media-heavy WordPress sites. Under Scrape Shield, turn on Hotlink Protection. This blocks external sites from embedding your images directly, which reduces bandwidth theft and keeps your CDN costs from spiking when a Reddit post links directly to a 4MB image in your media library.

Rate limiting wp-login.php

Rate limiting on /wp-login.php is non-negotiable for any WordPress site exposed to the public internet. Brute force attacks against WordPress login pages are automated, constant, and cheap to run. Without rate limiting, your login page absorbs thousands of requests per hour from botnets that rotate IPs and user agents.

Configure a rate limiting rule under Security, then Rate Limiting Rules:

Match: URI path equals /wp-login.php AND request method equals POST.

Threshold: 5 requests per 60 seconds per IP.

Action: Block for 10 minutes.

Five POST requests per minute is generous enough to accommodate a user who mistyped their password three times and tried again. It's tight enough to stop any automated attack that's running at the speeds credential stuffing tools operate at. Log blocked requests for the first week so you can confirm the threshold isn't catching legitimate users on shared IPs.

The Static Site Pattern: Vercel, Netlify, and Cloudflare Pages

DNS setup for Vercel and Netlify deployments

Static sites deployed to Vercel or Netlify need a CNAME record pointing to the platform's edge network. The complication is that standard DNS doesn't allow a CNAME at the zone apex, meaning your root domain can't technically be a CNAME. Cloudflare solves this with CNAME flattening, which resolves the CNAME chain at the DNS level and returns an A record to the client. You get root domain support without the RFC violation.

For a Vercel deployment, your DNS records look like this:

The proxied vs. DNS-only decision matters here. Proxied records route traffic through Cloudflare's edge, which means you get Cloudflare's WAF, caching, and analytics in front of Vercel or Netlify. DNS-only records send traffic directly to the platform, bypassing Cloudflare entirely. For production traffic, use proxied. For preview deployments, DNS-only is usually the right call.

SSL and redirect handling for static sites

When you proxy a CNAME through Cloudflare, the SSL certificate at the browser-to-Cloudflare layer is Cloudflare's edge certificate, provisioned automatically. The Vercel or Netlify certificate handles the Cloudflare-to-origin leg. Both need to be valid. Vercel and Netlify both provision Let's Encrypt certificates automatically for custom domains, so this usually works without intervention. The failure case is when you add the domain to Cloudflare before adding it to Vercel or Netlify, and the certificate provisioning on the platform side fails because the DNS is already proxied and the ACME challenge can't resolve correctly. Add the domain to your deployment platform first, confirm the certificate is issued, then proxy the record in Cloudflare.

Enable Always Use HTTPS under SSL/TLS and configure HSTS with a max-age of at least 31536000 seconds (one year) once you're confident the site will stay on HTTPS. HSTS tells browsers to refuse HTTP connections to your domain entirely, which eliminates redirect chains for returning visitors.

Use Transform Rules for www-to-root or root-to-www redirects. Under Rules, then Transform Rules, then Redirects. A single rule matching http.host eq "www.example.com" with a redirect to https://example.com${http.request.uri.path} handles the canonical redirect cleanly without a Page Rule.

Cache strategy: edge-first for static, bypass for preview URLs

Static assets on a Netlify or Vercel deployment don't change between deploys. Cache them aggressively at Cloudflare's edge with a 30-day TTL. HTML files are a different story. If you're deploying updates frequently, short HTML cache TTLs of 5 to 15 minutes prevent stale content from serving after a deploy. Alternatively, use a Cache Rule that bypasses HTML entirely and lets the platform's own CDN handle it.

Preview deployment URLs like deploy-preview-42--yoursite.netlify.app should stay DNS-only or be protected with Cloudflare Access. Proxying preview URLs through production Cloudflare configuration causes rule conflicts and can serve cached preview content to users who shouldn't see it. Keep preview URLs either off Cloudflare entirely or gated behind an Access policy scoped to your team.

Cloudflare Pages sidesteps most of these trade-offs. It's Cloudflare's own static hosting platform with built-in CI/CD triggered by Git pushes, global edge deployment, and native integration

The SaaS Pattern: Wildcard Subdomains, Custom Hostnames, and Tenant Isolation

A multi-tenant SaaS app has a different shape from everything above. One application serves many customers, each customer expects their own address, and some of them will want to put their own domain on top of it. The Cloudflare setup has to handle all three without anyone creating a DNS record by hand every time a customer signs up.

Wildcard DNS and SSL for tenant subdomains

If each tenant gets a subdomain like acme.company.com, add a single proxied wildcard record: an A or CNAME record for * pointing at your application. Every tenant subdomain now resolves and passes through Cloudflare with no per-tenant DNS work. Confirm that your plan supports proxying wildcard records before you build around it.

The certificate is where people get caught. Universal SSL covers your apex domain and one level of subdomains, so company.com and *.company.com. It does not cover a second level such as *.app.company.com.

Custom hostnames for customers who bring their own domain

When a customer wants portal.theirbrand.com to serve your app, that domain isn't in your Cloudflare account and you can't issue its certificate by hand. Cloudflare for SaaS, which Cloudflare calls custom hostnames, exists for exactly this.

The flow has four moving parts. You set a fallback origin, the origin that receives traffic for any custom hostname. The customer creates a CNAME that points their hostname at a target you give them. You register the hostname through the dashboard or API, and Cloudflare validates ownership, issues the certificate, and renews it. Your application reads the Host header to work out which tenant the request belongs to. Plan details and included quantities change, so check Cloudflare's current pricing before you promise this to customers.

Protecting the admin interface

Your tenant-facing app and your own admin interface should never share a hostname. Put the admin interface on its own subdomain, such as admin.company.com, and place a Cloudflare Access application in front of it. That keeps internal tooling off the public internet while the tenant subdomains stay open to customers, and it means a rule written for tenant traffic can't accidentally block your own staff.

The API Protection Pattern: Subdomain, Rate Limiting, and mTLS

APIs are not just another page on your site. They're a separate attack surface, a separate performance concern, and a separate trust boundary. Treating them as an afterthought inside your main zone is how you end up with a WordPress WAF ruleset accidentally blocking your mobile app's JSON requests. Give your API its own subdomain, its own rules, and its own identity.

Setting up api.example.com as a dedicated subdomain

Start in the Cloudflare DNS dashboard. Add an A record pointing api.example.com to your API server's IP, or a CNAME pointing to your load balancer or origin hostname. Enable the proxy. That single toggle puts Cloudflare between every API consumer and your origin, which is where you want the enforcement to live.

With the subdomain proxied, you can write zone-level rules that apply only to api.example.com without touching your marketing site or WordPress admin. That isolation is the point. A WAF rule change for your API won't accidentally break your blog's comment form.

Rate limiting strategies for public and authenticated API endpoints

Two rate limit rules cover most API deployments. The first targets all traffic on /v1/*: 100 requests per minute per IP is a reasonable public ceiling that stops casual scrapers without punishing legitimate integrations.

The second rule targets /v1/auth/* specifically. Authentication endpoints are the highest-value targets for credential stuffing. Drop the ceiling to 10 requests per minute per IP and add a block action rather than a challenge. Legitimate users don't attempt login 11 times in 60 seconds.

mTLS for machine-to-machine API authentication

Mutual TLS means both sides of the connection present a certificate. Your server presents its certificate as usual. Your client, whether that's a partner's backend system or an internal microservice, presents its own certificate signed by a CA you control. Cloudflare verifies that certificate at the edge before the request ever reaches your origin.

For B2B API consumers, mTLS is the right answer. API keys get leaked. Client certificates tied to a specific CA don't have the same exposure profile.

To enable it: navigate to SSL/TLS, then Client Certificates, and upload your client CA certificate. Enable mTLS for api.example.com. Then write a WAF custom rule that blocks any request to /v1/* that doesn't present a valid client certificate. Requests missing the expected Authorization header format can get a separate WAF rule returning a 401 before they hit rate limiting at all.

For caching, the rule is simple. GET requests returning public, non-user-specific data are safe to cache. POST requests, anything touching user sessions, and anything returning personalized data should bypass cache unconditionally. Write a Cache Rule that sets cache to bypass for POST, PUT, PATCH, and DELETE methods on api.example.com. For public GET endpoints like a product catalog or pricing list, a 60-second edge TTL meaningfully reduces origin load without serving stale data to clients who need fresh state.

Cloudflare Workers sit above all of this as an optional API gateway layer. Request validation, header transformation, routing logic, and response shaping all happen at the edge before your origin sees the request. If your API needs to normalize inconsistent client headers or enforce a request schema, a Worker is the right place to do it.

Cache Strategy Deep Dive: TTLs, Purging, and Cache Keys

Caching is not a single setting. It's a hierarchy of decisions, and if you don't make those decisions explicitly, Cloudflare will make them for you based on defaults that may not match your content model at all.

Understanding Cloudflare cache tiers and TTL hierarchy

Three TTL values compete for authority on every cacheable response. The browser cache TTL controls how long the visitor's browser holds the asset locally. The edge cache TTL controls how long Cloudflare's network holds it. The origin Cache-Control header is what your server sends and what Cloudflare respects by default.

Cache Rules let you set edge TTLs by path pattern, independent of origin headers. A rule matching /wp-content/uploads/* can set a 30-day edge TTL even if your WordPress server sends a 24-hour Cache-Control. A rule matching /api/v1/* can force bypass regardless of what your origin claims.

Custom cache keys for personalized or localized content

The default cache key is the URL. That works for fully public content. It breaks immediately when the same URL returns different content for different users.

Cache key customization lets you include or exclude query strings, cookies, and headers from the key. For static assets, strip all query strings from the cache key so /logo.png?v=4 and /logo.png?v=5 don't create separate cache entries for the same file. For search results pages, include the query string so /search?q=pricing and /search?q=support cache independently.

For WordPress, vary the cache key by the wordpress_logged_in_* cookie. Logged-in users should never receive a cached version of a page that was generated for an anonymous visitor. Write a Cache Rule that bypasses cache entirely when that cookie is present, and caches aggressively when it isn't.

Cache Reserve extends this further. It's Cloudflare's persistent cache layer, backed by R2 storage, that keeps assets alive beyond the standard edge cache TTL. For high-traffic sites with large static asset libraries, it meaningfully reduces origin egress costs.

Programmatic cache purging for deployments

Manual cache purging doesn't scale. Every deployment that changes a file should trigger a purge of the affected URLs or cache tags. Cloudflare's purge API accepts single URLs, lists of URLs, or cache tags if you've set Cache-Tag headers on your origin responses.

A CI/CD integration looks like this: after your deploy step completes, call the Cloudflare API with a POST to /zones/{zone_id}/purge_cache, passing the list of changed URLs or the relevant cache tags. Your build pipeline handles it. No one logs into the dashboard.

Tiered Cache reduces how often purge events actually matter. By routing cache misses through a higher-tier Cloudflare data center before hitting your origin, it concentrates cache fills and reduces the number of simultaneous origin requests during a cold cache event after a purge.

DNS Strategy Across All Four Environments

DNS is the foundation every other Cloudflare feature sits on. Get the zone structure wrong and you'll spend the rest of your configuration fighting against it.

Zone structure: one zone vs. multiple zones

One zone is fine for simple deployments. A personal site, a small business with one app, a blog with a staging subdomain. Everything lives under example.com and you manage it in one place.

Multiple zones make sense when different teams own different subdomains, when you need independent WAF rulesets, or when your API has compliance requirements that shouldn't share policy space with your marketing site. Separate zones for example.com, app.example.com, and api.example.com give each environment its own DNS, SSL, WAF, and cache configuration with no cross-contamination.

Subdomain delegation and NS record strategy

When you need a subdomain managed outside Cloudflare, use NS records to delegate it. Add NS records for internal.example.com pointing to your internal DNS server and Cloudflare will forward resolution for that subdomain without proxying it. The parent zone stays on Cloudflare. The delegated subdomain goes wherever you need it.

A reference DNS table for all four environments should include: example.com as a proxied A record pointing to your WordPress origin; www.example.com as a CNAME to your Netlify or Vercel deployment with CNAME flattening enabled at the root; staging.example.com as a proxied A record pointing to your staging server; and api.example.com as a proxied A record or CNAME pointing to your API origin.

TTL tuning for deployments and failovers

During a migration or DNS cutover, drop TTLs to 60 seconds at least 24 hours before the change. That minimizes propagation lag when you flip the record. After the migration stabilizes, raise TTLs back to 3600 seconds for most records. MX and TXT records that rarely change can go to 86400.

DNSSEC should be enabled on every production zone. It cryptographically signs your DNS responses, preventing spoofing attacks against your domain. For enterprise and SaaS environments where your domain is a trust anchor for customers, DNSSEC isn't optional. Enable it in the DNS dashboard with two clicks and let Cloudflare handle the key management.

Access Strategy: Zero Trust Across All Environments

The staging site is not protected by obscurity. The admin panel is not protected by a long URL. If it's on the internet and it's not behind an identity check, it's exposed.

Mapping Access applications to your environment inventory

Start with an inventory. List every hostname or path that isn't meant for public access: staging.example.com, example.com/wp-admin, app.example.com/admin, api.example.com/management, internal dashboards, monitoring UIs. Each of those becomes an Access application in your Zero Trust dashboard. One application per hostname or path prefix, each with its own policy.

Policy layering: identity, device posture, and geo

A basic Access policy requires a corporate email domain. That's the floor. Layer device posture checks on top for admin applications: the request must come from a managed device with disk encryption enabled and an endpoint agent reporting a clean status. Both conditions must be true before the session is allowed.

Geo-restriction adds a third layer for compliance-sensitive environments. If your admin panel should only be accessible from within a specific country, add a geo policy that blocks all other origins. It's not a substitute for identity verification, but it meaningfully reduces the attack surface for credential stuffing against your Access login page.

Service tokens and machine access

CI/CD pipelines, monitoring agents, and internal microservices can't complete an identity provider login flow. They use service tokens: a client ID and secret pair that Cloudflare Access validates at the edge. Scope each token to the specific application it needs to reach. A deploy pipeline token should only have access to the staging environment, not the production admin panel.

The Access JWT that Cloudflare issues after a successful authentication can be forwarded to your downstream application. Your app validates the JWT signature using Cloudflare's public key and extracts the identity claims for its own authorization logic. That gives you a second authorization layer without building a separate identity system.

Access groups let you define a reusable set of conditions, a specific email domain plus a device posture requirement, and apply that group to multiple applications at once. When the policy needs to change, you update the group and every application that references it updates automatically.

The Access audit log records every authentication attempt, success, failure, and policy evaluation. For compliance environments, that log is an artifact. Export it to your SIEM and treat it the same way you treat firewall logs.

Putting It All Together: Reference Architecture

Four environments. One Cloudflare account. The patterns you've built across this article aren't separate projects. They're composable layers that share infrastructure and reinforce each other.

A complete example: company.com across all four patterns

www.company.com runs the WordPress pattern: Full (Strict) SSL, cache bypass rules for logged-in users and admin paths, the WordPress managed WAF ruleset, and a rate limit on wp-login.php. marketing.company.com runs the static site pattern: CNAME to Vercel, CNAME flattening at the root, long-TTL cache rules for versioned assets, and no origin server to protect. app.company.com runs the SaaS pattern: wildcard CNAME and SSL for tenant subdomains, custom hostname provisioning, and Access protecting the admin interface. api.company.com runs the API pattern: dedicated rate limits on /v1/* and /v1/auth/*, mTLS for B2B clients, WAF rules enforcing Authorization header format, and cache bypass for all non-GET methods.

All four environments share one Zero Trust organization. Staging Access applications cover every environment. The audit log is centralized. Account-level API tokens manage all four zones from a single CI/CD pipeline.

Decision tree: which pattern applies to your environment

The decision is usually obvious once you ask the right question.

"Is the content fully static and deployed from a build pipeline?" Use the static site pattern. "Does the content come from a CMS with a database and an admin panel?" Use the WordPress pattern. "Does the application serve multiple tenants under their own subdomains?" Use the SaaS pattern. "Does the surface accept programmatic requests from non-browser clients?" Use the API pattern.

That composability is the point. You're not choosing one pattern for your entire infrastructure. You're identifying which pattern applies to each surface and stacking them inside the same account. The staging Access protection from Part 17 applies to every staging subdomain across all four environments, not just the one you configured it for first.

Your Part 18 Action Checklist

WordPress environment checklist

Static site environment checklist

SaaS and API environment checklist

That's the full pattern library: WordPress, static sites, SaaS apps, and APIs, each with its own DNS, SSL, cache, and access rules, and all four sharing one account and one Zero Trust organization. Start with the environment that carries the most risk or revenue, work through its checklist, then move to the next. Don't try to retrofit all four in a weekend. Order and verification matter more than speed.

Part 19 zooms back out. It takes everything from the last several parts and assembles it into a complete Cloudflare Infrastructure Blueprint for Small Businesses, one layer at a time: domain registration and ownership hygiene, DNS architecture and naming, email DNS, website protection, and tunnels for internal services.