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 either:
- You should use a persistent object cache
- Your hosting provider can tell you if a persistent object cache can be enabled on your site. Your host appears to support the following object caching services: Redis.
WordPress thinks we have redis available, but we do not. One of the main reasons we don't use it is because the data it stores in memory can be a security risk when run on shared servers. We can, and will, assist with Redis configuration only on your own Virtual Private Server.
Between 2024 and 2025 we pre-installed an object cache plugin called Docket Cache. However we no longer do this.
At the start of 2026 we applied new optimizations to our default database and PHP configuration across all servers. These, among other optimizations, make having redis totally unnecessary. The most additional advantage our tests have shown that Redis provides is about 2-5ms in loading time, and in some cases the time it takes to communicate with the redis server locally is actually a few ms slower than when utilizing our database server cache.
However if you really wish to keep WordPress's alert quiet, you could use either:
W3 Total Cache (has a object cache built in), or
Docket Cache
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.
