WordPress Site Health Warnings: Which Ones Are Actually Your Job?

Most of what WordPress Site Health warns you about is not your job to fix. The one warning that most certainly is your job sits in the lower of its two warning groups, under a heading that reads like a polite suggestion.

That is the trouble with the little Site Health box on your dashboard. It is a useful tool, built by careful people, and it ranks every problem the way a developer would rank it: security exposure first, server configuration next. Business consequences are not part of its scoring at all. So an owner who logs in, sees "Should be improved" in orange, and works down the list from the top can spend an evening on things their host should be handling, and never reach the item that is quietly costing them customers.

I run operations for a hosting platform, so I read these reports far more often than most people would choose to. I sort them into three piles: yours, your host's, and the ones that need a conversation between the two.

What the Site Health Box Is Actually Saying

The full report lives under Tools, then Site Health. The dashboard widget is only a summary. According to the WordPress developer reference ^[2], the widget shows one of a small set of messages. "Great job! Your site currently passes all site health checks" is the one hardly anybody sees. The common ones are "Your site's health is looking good, but there are still some things you can do to improve its performance and security", and the more alarming "Your site has critical issues that should be addressed as soon as possible to improve its performance and security."

Behind the widget, the Status tab sorts every result into three bands: critical issues, recommended improvements and passed tests. WordPress's own documentation ^[1] describes critical issues as parts of your website that "can be potential security vulnerabilities or serious performance issues". Recommended improvements are items that are "not critical for your website but should be modified for better security and performance."

There is also an Info tab. It changes nothing. Think of it as a long, read-only description of your setup, and its most useful feature is a button that copies the whole lot to your clipboard. Remember that button. It matters later.

The Colours Rank Developer Risk, Not Business Risk

Consider two results WordPress can show you:

• "You have plugins waiting to be updated" is marked critical. Fair enough. Outdated plugins are a well-worn way into WordPress sites, and WordPress is right to shout about them.
• "Search engines are discouraged from indexing this site" is marked recommended. The description underneath is blunt: "Your site is hidden from search engines. Consider enabling indexing if this is a public site." That check only arrived in WordPress 6.9, late last year. Before then, Site Health did not mention it at all.

Now weigh what each one means for a business. A pending plugin update is a risk that might become a problem. A hidden site is already a problem, every single day, for every person who searches for what you sell.

Take a hypothetical Kildare tack shop that moved its website onto a new theme over the summer. Whoever did the rebuild ticked "Discourage search engines from indexing this site" under Settings, then Reading, so Google would not pick up a half-finished site. Nobody unticked it at launch. Autumn arrives, the season when riders buy winter rugs, and the phone is quieter than last year. The owner opens Site Health, sees one critical item about a plugin update, fixes it and feels better. The real problem sits three lines further down in a calmer colour, and it stays there until a customer mentions they could only find the shop on Facebook.

That is not a failure of the tool. It is a failure of reading the tool top to bottom as if its order were your priority list.

Sorting the List Into Three Piles

The common warnings divide up like this. The first column uses WordPress's own wording, so you can match it against your screen.

Warning, as WordPress words it	WordPress group	Whose job
Search engines are discouraged from indexing this site	Recommended	Yours
You have plugins waiting to be updated	Critical	Yours, with a safety net
You should remove inactive plugins	Recommended	Yours
Your site is running on an older or outdated version of PHP	Recommended or critical	Your host's
You should use a persistent object cache	Recommended	Your host's
Page cache is not detected and the server response time is slow	Varies with response time	Your host's
Your site could not complete a loopback request	Critical	A conversation
Autoloaded options could affect performance	Critical	A conversation

Every row gets its own explanation below, in the same order.

Pile One: Warnings Only You Can Clear

Search engines are discouraged

This is a single tick box. Go to Settings, then Reading, untick "Discourage search engines from indexing this site", and save. Nobody at your host should be changing that setting for you, because there are legitimate reasons to have it on, and a staging environment is exactly where it belongs.

One honest limitation. Unticking the box does not put you back in Google overnight. Search engines have to come back, recrawl the site and notice the change, and that can take days or a few weeks depending on how often they visit you. The sooner it is fixed, the sooner that clock starts. Verify the result afterwards in Google Search Console rather than assuming.

Plugins waiting to be updated

WordPress is right to mark this critical. Plugins have deep access to your site, and an outdated one with a published vulnerability is an open door. So update them. What deserves thought is how.

Pressing "Update all" on the production environment during your busiest hour is the classic way to turn a security task into an outage. A booking plugin updates, conflicts with the theme, and the enquiry form stops submitting while you are serving customers and not looking at the website. You find out from the silence.

Take a backup before you update, or better, rehearse major updates in a staging environment first. On Web60, a pre-update safety snapshot is taken automatically, so a bad update means a rollback to the snapshot, not an afternoon of rebuilding.

Inactive plugins and themes

WordPress's wording here is worth reading in full: "Inactive plugins are tempting targets for attackers. If you are not going to use a plugin, you should consider removing it." A deactivated plugin still sits on the server, and if its code has a vulnerability it can still be reached. Switching it off is not the same as taking it away.

Two cautions before you start deleting. Some plugins remove their saved settings and data when you delete them, so export anything you might want back, such as form entries. And Site Health also checks that a default WordPress theme is available, so keep one installed as a fallback even if you never use it.

Pile Two: Warnings That Belong to Your Host

An older or outdated version of PHP

PHP is the programming language your server uses to run WordPress. Every PHP version gets a fixed support period, and when it ends, newly discovered security holes in that version stop being patched. WordPress currently recommends "version 8.3 or greater" on its requirements page ^[3].

This one has a date attached. The PHP project's supported versions page ^[4] shows PHP 8.2 receiving security fixes only until 31 December 2026. A site on 8.2 that shows the milder "older version" message today is about eleven weeks from that line. Once it passes, expect the critical version instead, the one that reads "does not receive security updates. It should be updated."

Some hosting panels offer a PHP version switcher, where your hosting provider supports it. Use it with care. Older plugins can break on a newer PHP version, so the change belongs in a staging environment first. On managed hosting, the server software is the host's responsibility, and an outdated PHP warning is something to raise with them rather than fix yourself.

The two cache warnings

"You should use a persistent object cache" and the page cache check both arrived in WordPress 6.1, added by the WordPress performance team ^[5]. They measure two different things.

• An object cache keeps the answers to common database questions in memory, so WordPress does not ask the database the same thing on every page view.
• A page cache keeps finished copies of your pages, so a visitor gets a ready-made page instead of one assembled from scratch.

In practice, these two are the difference between a page that appears as soon as a customer taps your link and one that makes them wonder whether your site is working. WordPress's own wording on the object cache tells you whose job it is: "Your hosting provider can tell you if a persistent object cache can be enabled on your site." It needs a service like Redis running on the server. No plugin can conjure that on hosting that does not provide it.

The page cache check also times how fast your server responds. The WordPress 6.1 announcement ^[5] puts the acceptable threshold at 600 milliseconds, and both checks only run in a production environment, so a staging copy will not show them. One practical warning as well: if your host caches at server level, ask before installing a caching plugin on top. Two caches fighting over the same page is a conflict that is tedious to untangle.

This is the gap in the tool, and it is a real one. Site Health measures the response from the server to itself. It does not see your customer on a phone with two bars of signal, a heavy homepage image or a slow third-party script. A pass on these checks means the server end is in good order. It does not mean your site is fast for visitors, which is a wider question covered in our complete guide to WordPress performance.

Pile Three: Warnings That Need a Conversation

Your site could not complete a loopback request

A loopback is WordPress calling itself. It uses these calls to run scheduled jobs, such as background updates, and to check code stability in the built-in theme and plugin editors. WordPress's documentation lists a failed loopback among its critical issues.

When it fails, the cause is usually one of three things: a security plugin or firewall blocking the request, a conflict between plugins, or a server setting. You cannot see the server side. Your host cannot see which plugin you installed last Tuesday. That is why it needs both of you. Left alone, scheduled jobs quietly stop running, and you only notice when something that should have happened by itself did not.

Autoloaded options could affect performance

Added in WordPress 6.6, this check is marked critical when the settings WordPress loads on every single page view grow past a default limit of around 800 KB. The usual cause is leftover data from plugins, including ones deleted years ago. It is the kind of database clutter that slowly drags a site down, and fixing it means editing the database directly.

Do not start deleting rows in a database manager on the strength of a forum post. Take a backup, then ask your host to look at it with you.

What to send, and where

For both of these, open the Info tab, click the button to copy the site info to your clipboard, and paste it into a support ticket with a short note on what changed recently. That report lists your server paths, plugins and their versions, which is exactly what a support engineer needs and exactly what you should not paste into a public forum.

A Ten-Minute Site Health Routine

1. Verify search visibility. Confirm the "Discourage search engines" box in Settings, then Reading, is unticked on your production site.
2. Snapshot, then update. Take a backup or confirm your host takes one, then update plugins, ideally rehearsing big ones in staging first.
3. Remove what you do not use. Export any data you want to keep, then delete inactive plugins and spare themes, keeping one default theme.
4. Copy the report and hand over the rest. Send the Info tab report to your host for anything about PHP, caching, loopback requests or autoloaded options.
5. Re-run the checks. Reload the Status tab after each change so you can see straight away which warnings have cleared.

Once a month is plenty, plus once after any big change to the site.

What a Managed Host Should Take Off Your List

A host worth paying for should own pile two outright. That means server software kept in order by the host rather than by you, object and page caching built into the server rather than bolted on as plugins, and support staff who read a pasted Site Health report and reply with an answer, not a link to a knowledge base article.

Web60 is managed WordPress hosting, so the stack underneath is ours to run. Every Web60 site sits on the WordOps stack with Nginx, PHP-FPM, Redis object caching and FastCGI page caching, on Irish-hosted infrastructure built for exactly this kind of workload, with server-level hardening, fail2ban intrusion prevention and automatic malware scanning as standard. When you paste a Site Health report into a ticket, it goes to an Irish-based support team, real people, not an outsourced queue.

Where managed hosting is the wrong fit

In fairness, this kind of hands-off arrangement does not suit everyone. If your business has a developer on staff who wants to choose the PHP version, tune the cache configuration and control every server setting personally, an unmanaged server or a premium enterprise managed host with deep configuration options will suit that arrangement better. Every pile becomes your developer's, which is sensible when you are paying for one. Most local firms are not, and they should not have to learn what a loopback request is.

WordPress runs roughly four in ten websites, according to W3Techs ^[6], and the barrier for owners was always the setup and the server, never the editing. If you are starting fresh rather than inheriting an old site, Web60's AI builder puts a WordPress site on that stack in under a minute for €60 a year, with hosting, SSL, backups and support included.

Reading the Box the Right Way

Site Health is a good tool with a ranking system built for a different reader. The colour tells you how worried a developer would be. It does not tell you what is costing you enquiries, and it does not tell you whose job the fix is.

Sort it by ownership instead. Clear your own pile in ten minutes, starting with search visibility. Hand the host's pile to your host with the copied report attached. Bring the awkward ones to a conversation rather than a forum. The next time that box turns orange, you will know within a minute whether it is a job for you, a job for your host, or nothing to lose sleep over.

Frequently Asked Questions

Is 'Should be improved' in Site Health something to worry about?

Not on its own. It means at least one test landed in the recommended group, and nearly every WordPress site has something there. Open Tools, then Site Health, and read the actual items. The one to act on straight away is 'Search engines are discouraged from indexing this site', because it hides the site from Google whatever colour it is shown in.

Does WordPress Site Health affect my Google ranking?

No. Site Health is a private report inside your dashboard and Google never sees it. Some of the things it reports do affect search, though. A site set to discourage search engines can drop out of results entirely, and a slow server response makes pages slower for real visitors, which Google does measure.

How do I fix 'You should use a persistent object cache'?

On most hosting you cannot fix it properly yourself, because it needs a caching service such as Redis running on the server. WordPress's own wording says your hosting provider can tell you whether one can be enabled, so ask them. On Web60, Redis object caching is part of the standard hosting stack.

Why does Site Health say my PHP version is outdated?

WordPress compares the PHP version your server runs against the versions that still receive security fixes. PHP 8.2, for example, stops receiving security fixes on 31 December 2026, according to php.net. If your hosting panel offers a version switcher, test the change in a staging environment first. On managed hosting, raise it with your host.

Should I delete every inactive plugin Site Health lists?

Delete the ones you are sure you will not use again, after taking a backup. Some plugins remove their saved settings and data when they are deleted, so export anything you need first. Keep one default WordPress theme installed as a fallback, which Site Health also checks for.

Can I switch Site Health off?

It can be hidden with custom code or a plugin, but there is little reason to. The checks cost you nothing to read and they flag things no other screen in WordPress will. A better habit is a ten-minute look once a month and after any big change to the site.

Sources