If saving or updating a post in the WordPress block editor throws "Updating failed: The response is not a valid JSON response," and this happens consistently (not just once), your Cloudflare-proxied domain is very likely intercepting the editor's save request with a security challenge page before it reaches WordPress. The editor sends a request to the REST API or admin-ajax.php expecting JSON back, but instead receives an HTML challenge or block page from Cloudflare — and since that HTML isn't valid JSON, Gutenberg shows this exact error instead of a useful one. The fix is identifying which Cloudflare rule is intercepting the request, then excluding the specific WordPress endpoints it needs from that check.

Symptoms

  • Clicking "Update" or "Save draft" in the block editor shows "Updating failed: The response is not a valid JSON response."
  • The error appears consistently for the same user, post type, or action — not randomly on one save out of many.
  • Autosave also fails silently, or you see repeated autosave failure notices in the editor.
  • Opening the browser's developer tools (Network tab) on the failed save request shows the response body is an HTML page (often containing Cloudflare branding or a challenge message) instead of JSON.

Likely causes, in order of how often they actually happen

  1. A Cloudflare WAF managed rule or custom rule is challenging or blocking requests to /wp-json/* or /wp-admin/admin-ajax.php, treating the editor's background save request the same as any other suspicious request pattern, since these endpoints accept POST data and can resemble attack traffic to generic rulesets.
  2. Cloudflare's bot management or Managed Challenge is triggering on the specific user session making the save request, especially if that user is on a flagged IP, VPN, or the request pattern (rapid repeated POSTs from autosave) resembles automated traffic.
  3. A rate-limiting rule is counting editor autosave requests toward a threshold meant for abuse prevention, and once exceeded, subsequent save requests get blocked with a challenge or error page instead of reaching WordPress.
  4. An overly aggressive "Browser Integrity Check" or similar heuristic setting is rejecting the request's headers because the editor's background fetch doesn't look like a normal full-page browser navigation.

Fix it: lowest-risk steps first

Step 1 — Confirm it's Cloudflare by checking the actual response

Before changing anything, open your browser's developer tools (F12), go to the Network tab, trigger the failing save, and click on the request that failed (it will typically go to wp-json/wp/v2/posts/... or admin-ajax.php). Look at the Response tab for that request.

  • If you see HTML mentioning Cloudflare, "Attention Required," "Checking your browser," or a challenge/CAPTCHA page — this confirms Cloudflare is intercepting it, and you should continue to Step 2.
  • If the response is HTML from your own theme or a PHP error instead, the problem isn't Cloudflare — it's more likely a plugin conflict or a PHP error on the server, and the fix here won't apply.

Step 2 — Check Cloudflare's Security Events log to identify the exact rule

In the Cloudflare dashboard, go to Security → Events. Filter by your domain and look for entries around the timestamp of your failed save attempt, filtering by the path /wp-json or /admin-ajax.php if the log allows it. Each blocked or challenged event shows which rule triggered it — this might be a specific Managed Ruleset rule (with an ID), a custom WAF rule you created earlier, or a rate-limiting rule. Note the exact rule name/ID before moving on; you'll need it to build a precise exception rather than a broad one.

Step 3 — Create a scoped WAF exception for the WordPress editor endpoints

Once you know which rule is firing, go to Security → WAF → Custom rules and create a new rule:

  1. Set the match condition to URI Path contains /wp-json/ or URI Path contains /wp-admin/admin-ajax.php.
  2. For extra precision, add an AND condition narrowing it to authenticated requests if your setup allows it (for example, matching on a WordPress logged-in cookie name if Cloudflare's rule builder supports cookie matching) — this keeps the exception limited to logged-in editor traffic rather than all public REST API requests.
  3. Set the action to Skip, and choose only the specific rule or ruleset you identified in Step 2 — not "Skip all remaining rules." If the offending rule was a managed ruleset rule, Cloudflare's rule builder lets you skip a specific managed rule by ID rather than the whole ruleset.
  4. Deploy the rule and retest saving a post in the editor.

Step 4 — If it's a rate limit, raise the threshold instead of removing it

If Step 2 showed the trigger was a rate-limiting rule rather than a managed WAF rule, go to Security → WAF → Rate limiting rules, open the rule, and either raise its request threshold or add the same path-based exclusion as Step 3 so editor autosave traffic doesn't count against the limit meant for public-facing abuse.

Step 5 — Confirm no broader bypass is left in place

Review the rule you created and make sure it's scoped only to the two paths above, not a wildcard that excludes larger portions of /wp-admin/ or the whole REST API from security checks. A narrow exception here is safe; a blanket bypass of /wp-json/* for all requests (not just logged-in editor sessions) removes meaningful protection from a commonly targeted attack surface.

Verify the fix

  1. Open the block editor, make an edit, and click Update — confirm it saves without the JSON error.
  2. Let the editor sit idle long enough to trigger an autosave and confirm no failure notice appears.
  3. Recheck Security → Events afterward to confirm the specific rule is now showing "Skipped" (not blocked/challenged) for requests to /wp-json/ and /admin-ajax.php from your logged-in session, while unrelated traffic to those same paths from unauthenticated visitors is still being evaluated normally.

If you need to roll back

If the new custom rule causes unexpected issues (for example, spam or abuse suddenly hitting the REST API without being challenged), disable or delete it under Security → WAF → Custom rules — the original managed rule or rate limit will resume protecting those endpoints immediately, and you'll be back to the JSON error until you refine the exception further.

Related fixes

FAQ

Why does Cloudflare block requests to my own REST API when I'm logged in?

Cloudflare's edge rules generally evaluate every request to your domain the same way regardless of WordPress login state, unless you specifically configure a rule to account for it (as in Step 3). Managed rulesets are tuned for generic threat patterns across many sites, so legitimate editor traffic can occasionally match a rule meant for attacks.

Is excluding /wp-json/* from all security checks a bad idea?

Yes, if done as a blanket exclusion — the REST API is a common target for scanning and abuse, so removing all Cloudflare protection from it sitewide is not advisable. Scope the exception as narrowly as your rule builder allows (specific rule IDs, logged-in sessions, or specific REST routes) rather than disabling checks on the entire path for everyone.

Could a caching or optimization plugin cause this same error without Cloudflare?

Yes — the identical error message can appear if a caching plugin, security plugin, or a PHP fatal error on the server returns non-JSON output for the same request. That's why Step 1 (checking the actual response body) matters before assuming Cloudflare is the cause; the fix here only applies once you've confirmed the response is a Cloudflare challenge or block page.