Publishing Failed. You Are Probably Offline: Every Variant

The block editor saved through the REST API and the API did not answer with a success. What the notice says depends on the WordPress version. On older versions — 6.3 and earlier, at least — it was "Publishing failed." or "Updating failed." followed by a second sentence that named the cause — most often "You are probably offline." or "The response is not a valid JSON response." Current versions, including 7.2, show only "Publishing failed. Keep this page open and try publishing again." — or "Updating failed." and "Scheduling failed." in the same form — and drop the reason; only a browser that reports itself offline gets a different notice. Either way the facts are in the browser's network panel, where the response to the save request sits with a status code and a body that names the problem.

Which message you are seeing

"Updating failed." on a published post and "Scheduling failed." on a future one are the same failures with a different verb. The JSON variant is common enough to have its own guide. On a current version, the network panel is the only place the reason appears.

Look at the actual request

Open the browser's developer tools, switch to the Network panel, and click Publish again. Find the request to /wp-json/wp/v2/posts/<id> (or /index.php?rest_route= on sites with plain permalinks). Its status and response body are the facts:

• 200 with HTML — the API route returned a page. Permalinks are broken or a plugin printed something before the JSON.
• 301 or 302 — the request was redirected, usually from http to https or between www and the apex. The site URL and the address bar disagree.
• 401 or 403 with JSON — WordPress refused: rest_cookie_invalid_nonce ("Cookie check failed") survives the editor's own nonce refresh only when the login cookie never arrived — the request went to another host or scheme — or the refresh request itself was blocked; rest_cannot_edit or rest_forbidden means capabilities or a security plugin.
• 403 with HTML — a web application firewall or mod_security blocked the request body before WordPress saw it.
• 500 — PHP failed on the save; the error log has the trace.
• No status, "failed" — the browser could not complete the request: a certificate the browser rejects, a blocked port, a timeout.

Permalinks and the REST route

The API lives at /wp-json/, which is a rewrite rule. If the rewrite rules are stale — after a migration, a server change, or a .htaccess that was replaced — the route 404s or returns the home page. Settings › Permalinks › Save Changes rewrites the rules and is the first thing to try. Sites on nginx need the try_files rule pointing at index.php; sites on Apache need mod_rewrite and a writable .htaccess, both covered in permalinks not working.

URL mismatch

The editor sends requests to the API URL WordPress printed into the page, which is built from home_url(). If the site is open at https://www.example.com and home says http://example.com, the request goes cross-origin or through a redirect, and the browser either blocks it or follows the redirect to something that is not JSON. Make the stored URLs match the served address, including scheme — WP_HOME and WP_SITEURL force it when the admin is hard to reach.

Security plugins and firewalls

Plugins that disable the REST API for logged-out users are fine; those that disable it entirely, or restrict it to specific routes, break the editor for everyone. Check the plugin's REST settings before disabling it. A firewall rule triggered by the post content — a block containing something that looks like SQL or a script, an embedded form — returns a 403 before PHP runs, and shows up as a 403 with an HTML body from the firewall rather than from WordPress. Whitelisting the wp-json path for authenticated users is the usual rule.

Server and proxy setups that block the save

The 403-with-HTML and no-response cases come from layers in front of WordPress, and each has its own switch:

• cPanel hosting. ModSecurity rules match post content that looks like code or SQL. Where the host enables it, cPanel has a ModSecurity screen under Security that can disable it per domain for a test; if saving then works, ask the host to whitelist the rule ID from its log rather than leaving it off.
• Plesk. The equivalent is the Web Application Firewall (ModSecurity) setting, available per domain or only server-wide depending on the host, with a detection-only mode that logs instead of blocking — useful for finding the rule.
• Nginx on a VPS. A missing try_files $uri $uri/ /index.php?$args; makes /wp-json/ a 404, and a too-small client_max_body_size returns 413 on long posts.
• Cloudflare or another proxy. A WAF rule or bot challenge on /wp-json/ returns a challenge page instead of JSON. Skip those rules for the REST path for logged-in traffic; see Cloudflare and WordPress.
• Managed hosts. Some cache the REST API or strip cookies on it. Purge the host cache and confirm /wp-json/ is excluded from page caching.

Certificates and loopback

A save with no status — "You are probably offline" on older versions, the plain "Keep this page open" notice on current ones — on an HTTPS site often means the browser trusts the certificate for the page but a redirect sent the API request to a host the certificate does not cover. Site Health reports both the REST API check and the loopback request, and a failure there usually matches the editor's.

Verify

Fix the cause the network panel pointed to, then publish again without reloading — the content is still in the editor. The request should return 200 with a JSON body containing the post. Then run Tools › Site Health: "The REST API encountered an error" should be gone from the list. If the editor still fails but the API check passes, the failure is specific to this post's content, and the firewall rule is the next thing to read.