This article describes how to fix/handle commonly found 'issues' reported in WordPress Site Health in the WordPress admin under Tools > Site Health. We exclude the ones about removing inactive plugins and themes and they are fairly self explanatory.
You should use a persistent object cache
WordPress Site Health says: You should use a persistent object cache
When WordPress is installed on our systems we pre-install an object caching solution called Docket Cache. However those that come from other hosts or who installed WordPress before 2024 would not have an object cache installed.
You'll find both our recommended object caching solution and other caching and performance solutions in our extensive how to speed up WordPress guide.
A scheduled event is late
WordPress Site Health says: A scheduled event is late
This may not be something that needs fixing - depending on what you're running on the site. If most of your site is static (ex: you don't use eCommerce or a user login system), then late scheduled events ultimately mean that most of your website visitors are being served a cached version of your site which is exactly what you want for optimal site speed. But that also means WordPress's PHP isn't running frequently enough to handle some of its backround tasks on their intended schedule.
See our dedicated article to late events in WordPress here for a solution.
Loopback Request Failed
WordPress Site Health says: The loopback request to your site failed, this means features relying on them are not currently working as expected. Error: cURL error 28: Connection timed out after 10000 milliseconds (http_request_failed)
There are a couple of potential reasons and solutions for this. Here they are, most common first:
- You have recently updated the name servers or DNS for the domain: Wait 48 hours after the DNS changes and the issue will disappear on its own.
- The server has an entry in its /etc/hosts file for this domain: Remove that entry or comment it out by preprending it with #.
The authorization header is missing
WordPress Site Health says: the authorization header is missing.
First, try clicking the Flush Permalinks link under that Site Health report to see if that resolves the issue.
If it flushing permalinks does not resolve it, the issue is probably with your .htaccess file. Use the Plesk File Manager or FTP to examine your .htaccess file. In the section for WordPress rewrites, look for this line:
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
If you do not see that line, you will need to add it in the same location where you see it in the WordPress documentation here. If your rewrites haven't been customized you can just replace the rewrites you have now with the entire set from that documentation. Customizing them is rare: it's most commonly done when you have WordPress in a subdirectory.
If you see two sets of rewrites and the last ones are missing the Authorization line, remove that duplicate set.
