Themeisle Docs

Appearance

Cloudflare Cache Rules with Multiple Subdomains on a Single WordPress Site ​

Super Page Cache automatically creates and manages Cloudflare Cache Rules when you enable Cloudflare CDN & Caching. If your single WordPress installation is reachable through multiple hostnames (for example, example.com, www.example.com, and blog.example.com), you will notice that the plugin only maintains cache rules for the configured primary hostname. This article explains why this happens and how to handle both www/non-www and true multi-subdomain setups.

📝 Note: This article covers a single WordPress installation serving multiple subdomains — for example, via URL rewriting or a reverse proxy. If you are running a WordPress Multisite network, see WordPress Multisite (Subdomain Mode) Setup with Cloudflare instead.

Why Cache Rules Are Overwritten ​

When you save the plugin settings or re-run the Cloudflare configuration wizard, Super Page Cache automatically updates the Cloudflare Cache Rule for your site to match the currently configured hostname. The plugin is designed to manage a single primary hostname per WordPress installation.

This means:

  • The plugin creates or updates one Cache Rule scoped to the current site's hostname.
  • If you reconfigure the plugin with a different hostname, the existing Cache Rule is overwritten to match the new hostname only.
  • Any subdomains that were previously covered by the rule are no longer included.

As a result, only the most recently configured hostname benefits from Cloudflare edge caching through the plugin's managed rule.

⚠️ Important: This is by design. Super Page Cache does not support managing cache rules for multiple hostnames from a single WordPress install. The workaround below requires manual steps inside the Cloudflare dashboard.

If your issue is www vs non-www ​

example.com and www.example.com are different hostnames in Cloudflare Cache Rules.

If the plugin-managed rule is set to:

  • Field: Hostname
  • Operator: equals
  • Value: example.com

...then requests to www.example.com do not match that rule.

This is why you can see cache hits on one hostname and misses on the other, even though both load the same WordPress site.

If both www and non-www URLs serve the same site content, use one canonical hostname and redirect the other hostname to it.

  1. Decide whether your canonical hostname is example.com or www.example.com.
  2. Make sure your WordPress site URLs use that same canonical hostname.
  3. Add a redirect at Cloudflare or your server so the non-canonical hostname always redirects to the canonical hostname.
  4. Retest your pages and confirm requests are only served from the canonical hostname.

This keeps caching predictable and avoids split cache behavior across duplicate hostnames.

Do not rely on editing the plugin-managed rule ​

Avoid changing the plugin-created Cache Rule from Hostname equals to broader matching such as contains.

  • Super Page Cache synchronizes its managed rule and can overwrite manual edits during plugin configuration updates.
  • Broad hostname matching can cache unintended hostnames or requests.
  • For www vs non-www duplicates of the same site, canonical redirects are the preferred long-term setup.

Workaround: Manually Duplicate Cache Rules in Cloudflare ​

To ensure all your subdomains are covered by Cloudflare caching, you can manually create additional Cache Rules in the Cloudflare dashboard — one for each subdomain that is not covered by the plugin-managed rule.

Use this when separate hostnames must remain directly accessible (for example, blog.example.com and shop.example.com), rather than for simple www/non-www duplicates of the same site.

Step 1 — Identify the Plugin-Created Cache Rule ​

  1. Log in to your Cloudflare dashboard.
  2. Select your domain zone (e.g., example.com).
  3. Go to Caching → Cache Rules.
  4. Look for the rule created by Super Page Cache. It is typically named after the plugin and targets your primary hostname (e.g., www.example.com).

[Screenshot: Cloudflare Cache Rules list showing the plugin-created rule for the primary hostname]

Step 2 — Create a Duplicate Rule for Each Additional Subdomain ​

For each subdomain not covered by the plugin-managed rule:

  1. On the Cache Rules page, click Create rule.
  2. Give the rule a descriptive name (e.g., SPC – blog.example.com).
  3. Under When incoming requests match…, set the condition:
    • Field: Hostname
    • Operator: equals
    • Value: your subdomain (e.g., blog.example.com)
  4. Under Then the settings are…, configure the cache behavior to match the plugin-created rule:
    • Eligible for cache: Enabled
    • Set any additional cache settings (e.g., Edge TTL, Browser TTL) to mirror the values in the plugin-managed rule.
  5. Click Deploy.
  6. Repeat for each additional subdomain.

[Screenshot: Cloudflare Cache Rule creation form with Hostname equals blog.example.com and cache enabled]

💡 Tip: Open the plugin-managed rule and the new rule side by side in your Cloudflare dashboard to make sure all settings match. This ensures consistent caching behavior across all subdomains.

Step 3 — Verify the Rules Are Active ​

After creating the rules, confirm they are enabled:

  1. On the Cache Rules page, make sure each new rule shows a green Active status.
  2. Check that the rules are ordered correctly — more specific hostname rules should not be overridden by broader rules earlier in the list.

Static asset and Cloudflare R2 subdomains ​

If you serve images or other static files from a Cloudflare R2 bucket through a custom subdomain (for example, cdn.example.com or media.example.com), that asset subdomain is entirely outside Super Page Cache's scope. The plugin-managed Cache Rule only targets the primary WordPress hostname — it does not create or update rules for external asset hosts, R2 custom domains, or CDN subdomains.

As a result, requests to an R2 asset subdomain will typically return CF-Cache-Status: DYNAMIC, meaning Cloudflare is not caching the assets at the edge, even when Super Page Cache is active and working correctly for your WordPress pages.

To cache assets served from an R2 custom subdomain, you need to:

  1. Create a dedicated Cloudflare Cache Rule for the asset hostname.
  2. Make sure the R2 objects include cacheable Cache-Control headers.

📝 Note: Both conditions are required. A Cache Rule alone is not enough — if the R2 objects do not send cacheable headers, Cloudflare will still return CF-Cache-Status: DYNAMIC for those requests even when a matching rule exists.

Create a Cache Rule for the R2 asset hostname ​

  1. Log in to your Cloudflare dashboard.
  2. Select the zone that contains your asset subdomain (e.g., example.com).
  3. Go to Caching → Cache Rules.
  4. Click Create rule.
  5. Give the rule a descriptive name (e.g., R2 assets – cdn.example.com).
  6. Under When incoming requests match…, set the condition:
    • Field: Hostname
    • Operator: equals
    • Value: your asset subdomain (e.g., cdn.example.com)
  7. Under Then the settings are…, set Eligible for cache to Enabled.
  8. Click Deploy.

[Screenshot: Cloudflare Cache Rule creation form with Hostname equals cdn.example.com and Eligible for cache enabled]

💡 Tip: Make sure your R2 custom domain is proxied through Cloudflare (orange cloud icon in DNS → Records). If the record is set to DNS-only (grey cloud), Cloudflare cannot apply Cache Rules or return CF-Cache-Status headers for that hostname.

Set cacheable Cache-Control headers on R2 objects ​

Cloudflare respects the Cache-Control headers returned by R2. If objects do not include cacheable headers, Cloudflare treats the response as uncacheable and returns CF-Cache-Status: DYNAMIC, even when a matching Cache Rule exists.

For static, versioned assets (images, fonts, scripts) that do not change at the same URL, use:

Cache-Control: public, max-age=31536000, immutable

For assets that may be replaced at the same URL (for example, non-versioned images), use a shorter TTL to avoid serving stale files:

Cache-Control: public, max-age=86400

You can set Cache-Control metadata on R2 objects in the Cloudflare dashboard under R2 → your bucket → select object → Edit HTTP metadata, or via the R2 API at upload time.

⚠️ Important: If you replace an R2 object at the same URL without changing the filename, Cloudflare and browsers will continue serving the cached version until the TTL expires. Use versioned filenames (e.g., image-v2.jpg) or a short max-age for assets that may be updated in place.

Verify an R2 image is cached ​

After creating the Cache Rule and ensuring the R2 objects send cacheable headers:

  1. Open browser Developer Tools (F12) and go to the Network tab.
  2. Enter an image URL from your asset subdomain directly in the browser address bar (e.g., https://cdn.example.com/photo.jpg).
  3. Check the response headers for CF-Cache-Status:
    • MISS — Cloudflare received the request but had no cached copy; this is expected on the first request.
    • HIT — Cloudflare served the image from the edge cache ✅
    • DYNAMIC — The Cache Rule is not matching, the DNS record is not proxied through Cloudflare, or the R2 object is missing cacheable Cache-Control headers.
  4. Reload the same URL. After the first MISS, subsequent requests from the same Cloudflare edge location should return HIT.

If you continue to see DYNAMIC after creating the rule and setting headers, verify that:

  • The DNS record for the asset subdomain shows an orange cloud (proxied) in DNS → Records.
  • The Cache Rule is deployed and shows Active status on the Cache Rules page.
  • The R2 object's HTTP metadata includes a Cache-Control header with a public directive and a positive max-age.

Cache Purging Behavior ​

Super Page Cache's automatic cache purging is tied to the primary hostname configured in the plugin settings. This affects how purges work across your subdomains:

Purge typePrimary hostnameAdditional subdomains (manual rules)
Automatic URL purge (on content update)✅ Handled by the plugin❌ Not handled automatically
Purge All (from plugin dashboard)✅ Purges the entire zone✅ Purges the entire zone (same zone)
Manual URL purge (from Cloudflare dashboard)✅ Works if the rule matches✅ Works if the rule matches

Because automatic URL-specific purges only fire for the primary hostname, cached pages on additional subdomains will not be purged when you update content. You will need to purge those subdomains manually.

How to Manually Purge Cache for Additional Subdomains ​

  1. In the Cloudflare dashboard, go to Caching → Configuration.
  2. Under Purge Cache, choose Custom Purge.
  3. Enter the specific URLs on your additional subdomain that need to be purged (e.g., https://blog.example.com/my-updated-post/).
  4. Click Purge.

Alternatively, use Purge Everything to clear the cache for the entire zone, which includes all subdomains. Be aware this will also clear the cache for your primary hostname.

⚠️ Note: Purge Everything clears the Cloudflare cache for the entire zone and all subdomains at once. Use it only when you need to clear all cached content across all subdomains simultaneously.

Verifying Cache Is Working for Each Subdomain ​

After setting up the manual Cache Rules, test each subdomain individually:

  1. Open the subdomain in an Incognito/Private browser window (e.g., https://blog.example.com/).
  2. Press F12 to open Developer Tools and go to the Network tab.
  3. Reload the page and select the first request for your subdomain.
  4. Check the response headers for CF-Cache-Status:
    • HIT — Cloudflare is serving the cached page ✅
    • MISS — the page was not in cache (normal on first visit; reload to confirm it becomes HIT)
    • BYPASS — the cache rule is not matching or caching is bypassed for this request

Repeat this check for each subdomain to confirm all Cache Rules are working.

If you serve images or static files from an asset subdomain (for example, a Cloudflare R2 custom domain), test those URLs separately as well. HTML pages and static assets are served from different hostnames and require their own Cache Rules — confirming that your WordPress pages are cached does not guarantee that images on the asset subdomain are also cached. See Static asset and Cloudflare R2 subdomains for setup instructions and a dedicated verification checklist.

Best Practices and Alternatives ​

If managing manual Cache Rules becomes difficult to maintain, consider these alternatives:

  • Use a WordPress Multisite network — With Multisite in subdomain mode, each subsite can have its own plugin configuration, and cache rules, purging, and settings are managed independently per subsite. See WordPress Multisite (Subdomain Mode) Setup with Cloudflare for setup instructions.
  • Use separate WordPress installations per subdomain — Each install manages its own Cloudflare Cache Rules and purging independently, without any conflicts.
  • Use a Cloudflare wildcard Cache Rule — If all your subdomains need the same cache behavior, you can create a single Cache Rule in Cloudflare using a wildcard hostname match (e.g., *.example.com). This covers all subdomains at once, although the plugin will still manage its own rule separately.

📝 Note: A wildcard Cache Rule created manually in Cloudflare will not be overwritten by the plugin. Only the plugin-managed rule is updated when you reconfigure Super Page Cache.

Was this helpful?