DevelopWhale

How to Purge Cloudflare Cache from n8n After WordPress Publishing

Automation flow purging selected Cloudflare cache entries after a WordPress publish

Written by

DevelopWhale Automation

in

If your WordPress publishing workflow runs through n8n and your site uses Cloudflare caching, publishing the post is only half the job. The new article can exist correctly in WordPress while visitors still receive an older cached copy from Cloudflare.

The safest fix is not to purge the entire zone every time. Cloudflare recommends targeted single-file purging, and its API lets you invalidate one or more exact URLs with a single request. That makes it a good fit for an n8n workflow that already knows the final WordPress URL after publishing.

When this pattern is actually useful

Cloudflare does not cache HTML by default. This workflow matters when you have deliberately made HTML cacheable, for example with a Cache Rule, Automatic Platform Optimization, or another configuration that can return cached page HTML. It is also useful for static assets whose URLs stay the same after deployment.

Before adding any purge step, check the response headers for the page you are trying to invalidate. If Cloudflare is not caching that resource, a purge request may succeed but change nothing. Cloudflare explicitly notes that an HTTP 200 response only means the purge request was accepted; it does not prove that the target was cached.

The architecture

WordPress publish/update
        ↓
final public URL available
        ↓
n8n HTTP Request
        ↓
POST /zones/{zone_id}/purge_cache
        ↓
purge exact URLs
        ↓
verify public response

The important design choice is that the purge happens only after WordPress has successfully returned the final URL. Do not invalidate the cache first and then hope the publish succeeds.

1. Create a least-privilege Cloudflare API token

Use a Cloudflare API token rather than a Global API key. The purge endpoint accepts API token authentication and requires the Cache Purge permission. Scope the token to the smallest set of zones that your automation needs.

Store the token in n8n credentials or another secret store. Do not hard-code it into a Function node, Code node, expression, exported workflow JSON, or Google Sheet.

2. Get the Cloudflare zone ID

The purge endpoint needs the zone ID:

POST https://api.cloudflare.com/client/v4/zones/{ZONE_ID}/purge_cache

The zone ID identifies the Cloudflare zone that owns the URL you are purging. Keep it as a workflow variable or credential-side configuration rather than repeating it throughout the workflow.

3. Use purge-by-URL instead of purge-everything

Cloudflare supports several purge modes. For a publishing workflow, exact URL purging is usually the smallest and safest blast radius.

{
  "files": [
    "https://www.example.com/my-new-post/",
    "https://www.example.com/"
  ]
}

Cloudflare documents purge-by-URL for all tiers. By contrast, a purge-everything request removes every cached object in the zone and forces subsequent requests back to the origin until the cache is repopulated. That can create an unnecessary origin spike.

For most WordPress publishing workflows, invalidate the final article URL and, only when your homepage or archive page is also cached and changed by the publication, invalidate that page too.

4. Configure the n8n HTTP Request node

Add an HTTP Request node after the successful WordPress publish or update step.

Setting Value
Method POST
URL https://api.cloudflare.com/client/v4/zones/{ZONE_ID}/purge_cache
Authentication Bearer token / Header Auth
Content-Type application/json
Body JSON

The request header should send the API token as a Bearer token:

Authorization: Bearer YOUR_CLOUDFLARE_API_TOKEN

A minimal JSON body is:

{
  "files": [
    "{{$json.url}}"
  ]
}

The exact expression depends on the output of your WordPress node. The rule is simple: pass the final canonical public URL returned by the successful publish step, not a draft URL, preview URL, REST endpoint, or internal post ID.

5. Purge the homepage only when it really changed

Many WordPress homepages show recent posts. If that page is cached at Cloudflare and publishing a new article changes its HTML, you may want to purge both the article and the homepage:

{
  "files": [
    "{{$json.url}}",
    "https://www.example.com/"
  ]
}

Do not blindly add category pages, tag pages, feeds, sitemaps, and every navigation page. Each additional URL should have a reason to be invalidated. A targeted list keeps the cache warm and the workflow easy to reason about.

6. Do not confuse Cloudflare edge cache with browser cache

A Cloudflare purge removes the edge-cached object. It does not clear a visitor’s browser cache. If a repeat visitor still sees an older static asset, inspect the browser cache headers separately. Cloudflare’s Browser Cache TTL documentation explicitly notes that purging Cloudflare cache does not remove assets already stored in the visitor’s browser.

7. Verify the purge instead of trusting HTTP 200

Cloudflare states that a successful purge API call returns HTTP 200, but that status only confirms the request was received. It does not prove that Cloudflare previously cached the resource or that a specific cache entry existed.

For a page that should be cached, request it again after the purge and inspect the CF-Cache-Status response header. A targeted purge should cause the next request to stop being a cache HIT; depending on the cache configuration, you may see a status such as MISS or EXPIRED.

curl -I https://www.example.com/my-new-post/

Do not build your workflow around the assumption that every HTML response must return MISS. Cloudflare does not cache HTML by default, and different cache products and rules can produce different status values.

8. Handle failure without breaking the WordPress publish

A cache purge failure and a WordPress publish failure are different operational events. Once WordPress has successfully published the article, rolling the post back because a cache invalidation request failed is usually the wrong recovery model.

A more robust workflow is:

Publish WordPress post
        ↓
Store post ID + final URL
        ↓
Try Cloudflare purge
        ↓
Success → continue
Failure → retry / alert / reconciliation queue

This keeps the content state authoritative in WordPress while treating cache invalidation as a recoverable post-publish step.

9. Watch for custom cache keys

If your Cloudflare cache key includes request headers or other custom properties, a simple URL-only purge may not identify every cached variant. Cloudflare’s API documentation explains that custom cache-key inputs such as device type, country, or language may need to be included in the purge request.

If you do not use custom cache keys, keep the request simple. If you do, document the key inputs before automating invalidation.

10. Why this is better than adding another WordPress plugin

If n8n already owns the publishing workflow, moving cache invalidation into the same automation keeps the responsibility in one place. The workflow already knows whether publishing succeeded, which URL changed, and whether a retry is needed.

That does not mean every site should remove its cache plugin. The point is architectural: when Cloudflare edge invalidation is the only missing step, you can call the official API directly instead of installing a plugin solely to issue a purge request.

Related DevelopWhale guides

Production checklist

  • Confirm the target resource is actually cacheable at Cloudflare.
  • Create a scoped API token with Cache Purge permission.
  • Keep the token out of workflow source and logs.
  • Run the purge only after WordPress returns success.
  • Use the final canonical public URL.
  • Prefer exact URL purging over purge-everything.
  • Purge the homepage only if it is cached and changed.
  • Verify the result with response headers.
  • Treat purge failures as retryable post-publish failures.
  • Account for custom cache keys if you use them.

Official references

The practical rule is straightforward: let WordPress publish first, invalidate only the URLs that changed, and verify the public result. That gives you fast cache freshness without turning every deploy or article update into a full-zone cache reset.

More posts