Yoast SEO error parsing the response to JSON, and other Yoast errors

What error parsing the response to JSON means

Yoast keeps a table of indexables, a compact record of every post, term and archive with its title, description, canonical and links. It builds that table through a series of background requests to REST API addresses under /wp-json/yoast/v1/, and it reads and saves other data the same way when you use the editor panel.

Each request expects a reply that is pure JSON, something like {"objects":[...],"next_url":"..."}. The error appears when the reply cannot be parsed as JSON. That happens when:

• the JSON is there, but something printed text before or after it, such as a PHP notice or a stray blank line;
• the reply is an HTML page instead, such as a 403 block page from a firewall, a login page, a challenge page or a 500 error page;
• the request was redirected to another address and the browser got the wrong document;
• the reply was empty because PHP ran out of memory or time and stopped.

So the message is a symptom. The fix is to find out what came back instead of JSON. The same family of faults causes the block editor's The response is not a valid JSON response message, Yoast's panel failing to load, and the optimisation stopping partway through.

Common causes and where to look

A recent change is the best clue. If the error started after installing a security plugin, moving to a new host, adding Cloudflare or switching on HTTPS, start with that row.

How to see what actually came back

Open the page where the error appears, such as Yoast SEO, Tools. Open Chrome DevTools, choose the Network panel, filter by yoast, and start the optimisation again. Click the request that fails and look at three things: the status code, the response headers, and the Response tab. A 403 with an HTML body names the blocker; a 200 with Warning: before the JSON points to PHP; a 301 shows an address problem.

From a terminal you can test whether the REST API answers with JSON at all. The namespace index is public, so it needs no login:

curl -s -o /dev/null -w '%{http_code} %{content_type}\n' https://example.com/wp-json/
curl -s -o /dev/null -w '%{http_code} %{content_type}\n' https://example.com/wp-json/yoast/v1
curl -s https://example.com/wp-json/yoast/v1 | head -c 300

Both lines should print 200 application/json, and the last should start with {. If you see text/html, a 403, or a redirect, something in front of WordPress is changing the reply.

Turn on logging without showing errors

In wp-config.php, above the line that says to stop editing, log errors to a file instead of printing them into responses:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Run the optimisation again and read wp-content/debug.log. Any fatal error or warning listed during the run names the file and plugin responsible. Also check Tools, Site Health, which runs its own REST API test and reports The REST API encountered an error or an unexpected result when it fails.

Fixes on Plesk, Apache, nginx and Cloudflare

Plesk and ModSecurity

On Plesk, read the domain's error logs first. They live under the vhost system folder:

sudo tail -n 50 /var/www/vhosts/system/example.com/logs/error_log
sudo tail -n 50 /var/www/vhosts/system/example.com/logs/proxy_error_log
sudo grep -i 'wp-json' /var/log/modsec_audit.log | tail -n 20

If ModSecurity is blocking /wp-json/ requests, the audit log shows the rule ID. In Plesk, open the domain's Web Application Firewall settings and switch off that specific rule ID rather than the whole firewall, then test again.

Apache and nginx

Look for rules that deny wp-json in .htaccess or in the nginx server block. Hardening guides sometimes add them to hide the REST API, which breaks the editor and Yoast. Also make sure permalink rules are present: on Apache the standard WordPress block in .htaccess, on nginx a try_files $uri $uri/ /index.php?$args; line in the main location.

Cloudflare

In Security, Events, filter by the path /wp-json/ and see which rule acted. Add a skip or allow rule for requests to /wp-json/ from logged-in sessions, or relax the specific managed rule, rather than turning protection off. Exclude /wp-json/* and /wp-admin/* from any cache everything rule.

If the server returns 500 errors on these requests, the 500 errors guide and the guide to HTTP errors in WordPress cover the server side in more depth.

Other Yoast SEO errors and their usual fixes

• Sitemap shows a 404. Open Settings, Permalinks and click Save to rebuild the rewrite rules. Then check that /sitemap_index.xml is not excluded or blocked by your security or caching plugin. See sitemap index problems in WordPress.
• Sitemap shows an XML declaration error. A message that the XML declaration is allowed only at the start of the document means something printed whitespace before the sitemap. The cause is the same as the JSON error: a blank line before <?php or after a closing ?> in a theme or plugin file.
• The Yoast panel in the editor is blank or spins. Usually a JavaScript conflict or a blocked REST request. Check the browser console for errors, then deactivate other plugins one at a time on a staging copy.
• Updating failed, the response is not a valid JSON response. The block editor's version of the same problem. Follow the diagnosis above.
• Titles or descriptions not showing on the page. Not an error but a common complaint. The theme may be overwriting the title, or caching is serving an old copy. See Yoast or Rank Math meta description not working.
• Duplicate tags after installing Yoast. Another SEO plugin or the theme is still writing tags. See the WordPress SEO plugin guide.

A worked example: blocked after a security change

Example Bakery added a security plugin and, the same week, Yoast's SEO data optimisation began failing at 4 per cent with error parsing the response to JSON. The Network panel showed the request to an indexing address returning status 403 with an HTML body titled Access denied.

The curl test on /wp-json/ returned 200 application/json, so the REST API itself was working. The security plugin's log showed it had blocked the request because a rule limited REST requests per minute, and the optimisation sends many requests quickly. Raising that limit for logged-in administrators fixed it. The optimisation then completed, and running wp yoast index on the server confirmed every object was indexed.

The lesson is to read the response before changing anything. The plugin that showed the error was not the plugin that caused it.

The fix, step by step

Edge cases worth knowing

• Very large sites. Optimising tens of thousands of posts in the browser can hit time limits. Run wp yoast index on the server instead, which processes everything without browser requests.
• Plain permalinks. The REST API then uses ?rest_route= addresses. It still works, but rules written for /wp-json/ will not match, so check both forms when testing firewalls.
• Staging copies behind password protection. HTTP basic authentication on a staging site can block background requests. Allow the site's own requests or test with the protection lifted briefly.
• Corrupt indexables. If the REST API works and errors persist, rebuild the table with wp yoast index --reindex, or use the reset option for indexables in the Yoast Test Helper plugin, then run the optimisation again. Back up the database first.
• Object cache problems. A persistent object cache serving stale options can make Yoast think the optimisation is unfinished. Flush it with wp cache flush.

Keeping Yoast working

Once the REST API answers with clean JSON again, keep it that way:

1. Keep WP_DEBUG_DISPLAY set to false on live sites so notices go to the log, never into responses.
2. Exclude /wp-json/ and /wp-admin/ from page caching on every caching layer, from plugins to Cloudflare.
3. After adding a security plugin, firewall rule or CDN, run the curl test and open the Site Health status screen.
4. After large imports or migrations, run wp yoast index so the indexables match the content. The WordPress migration guide lists the other checks to make after a move.