That red WordPress warning is not a site-wide grade
The colors in Tools > Site Health are easy to misread. WordPress is not grading your website there. It is running separate checks for PHP, HTTPS, REST API access, scheduled tasks, updates, and other parts of the installation.
A customer once asked me, “My Site Health score is 82 percent. Is Google going to penalize us?” I was working on a hosting support team at the time. The answer was no: Site Health is not an SEO score, and it cannot tell you by itself whether hosting performance is good.
Let me put it this way: I treat the screen as an incident board. It points to things worth checking. I still compare every warning with the way the site actually behaves.
What WordPress shows in Site Health
WordPress separates the report into two main tabs:
- Status: automatic checks, critical issues, and recommended improvements.
- Info: technical details about the server, WordPress, themes, plugins, database, and filesystem.
The Status tab is useful during routine administration. The Info tab saves time when I open a support ticket, prepare a migration, or work with a developer. You can copy the relevant sections, but inspect them first for domain names, paths, hostnames, and email addresses that should not be shared publicly.
Critical issues
A red check often concerns security, updates, HTTPS, or a basic site function. It does not always mean the site is already broken. I ask three questions: does this increase the attack surface, prevent updates, or stop visitors from completing an important action?
An outdated WordPress version, an unsupported PHP version, or broken HTTPS deserves prompt attention. A plugin failing to contact its update server may be less serious if the failure is temporary. Context matters.
Recommended improvements
Orange or yellow notices usually do not take the site offline immediately. WordPress may recommend persistent object caching, limited automatic updates, or a configuration choice that is not considered ideal.
Making a notice disappear is not the same as fixing a problem. If WordPress recommends persistent object caching, do not install a random cache plugin just to turn the indicator green. First check whether the server provides Redis or Memcached, whether it conflicts with the existing page cache, and how it could affect WooCommerce sessions.
Green does not mean perfect
Green checks are useful, but they do not prove that every part of the website works well. WordPress may confirm HTTPS, update connectivity, and several basic settings while visitors wait for a slow database query.
TTFB may be high. A product query may take several seconds. Checkout may fail because of a JavaScript error. Site Health does not measure all of that, so I use web server logs, browser developer tools, real-user measurements, and tools such as mtr when the network path is part of the suspicion.
Do not install a plugin the moment you see red
Not every notice has the same urgency. I classify an alert with four questions:
- Does it prevent visitors from using the site?
- Does it create a security or data-loss risk?
- Does it affect updates, backups, or scheduled tasks?
- Is it persistent, or could it be a temporary connection failure?
“The REST API returned an unexpected response” is a good example. The block editor, some blocks, WooCommerce operations, and external integrations may depend on the REST API. One failed Site Health test does not prove that every REST request is broken.
Start by checking the request’s HTTP status in your browser’s developer tools. Then inspect security-plugin records, web server logs, and any CDN or WAF rules. A plugin that merely hides the warning has not repaired the request.
Checks you will see often
WordPress, themes, and plugins
When Site Health identifies outdated components, I begin with a backup. On production, I do not press “update everything” before checking the PHP version, theme compatibility, custom code, and WooCommerce version.
Before an update, I take at least a database export. On a server with WP-CLI, my basic check looks like this:
wp core version
wp plugin list --update=available
wp theme list --update=available
wp db export /var/backups/site-before-update.sqlThe first three commands show installed versions and available updates. The last exports the database to an SQL file. I check that the file exists and that it can actually be restored. A dump on the same disk, never tested, is not enough for me.
I learned that during a migration. A customer showed me a folder and said, “We have a backup.” The files were there, but no usable database dump was inside. When rollback became necessary, the folder was not empty; it was simply useless. That mistake was not mine, but I have made the related mistake of trusting a backup job without performing a restore test. Since then, I treat a backup as a restorable copy.
For related database checks, see WordPress Error Establishing a Database Connection: Fixes. I use the same habit here: inspect application and database evidence before changing settings.
PHP version and memory limits
The PHP version affects security and application compatibility. Before moving to a newer version, check the support status of your theme and plugins. A site working on PHP 8.3 does not guarantee that an old plugin will fail loudly when it becomes incompatible. Sometimes it fails quietly.
If you see a WP_MEMORY_LIMIT or memory_limit warning, do not raise the value at random. More memory does not explain a bad query or an unnecessary loop.
A support ticket once requested only a higher memory_limit. The actual cause was a reporting plugin scanning a large table without a WHERE condition. Increasing memory might have postponed the failure, but it would not have fixed it. The requested change was small; the underlying query was not.
HTTPS and secure connections
For an HTTPS warning, check that the certificate is valid, that the domain resolves to the intended certificate, and that HTTP-to-HTTPS redirection works correctly. If you use a CDN, reverse proxy, or load balancer, confirm that WordPress sees the original request as HTTPS.
An old hard-coded siteurl or home value in wp-config.php can cause redirect loops. Take a database backup before changing URL values. To inspect the current WordPress options:
wp option get home
wp option get siteurlSeeing https:// in the output is not enough. If the page source or browser Network tab still shows HTTP resources, mixed content remains.
REST API and loopback requests
A loopback request checks whether the site can reach itself over HTTP. WordPress and plugins use this for background work, scheduled tasks, maintenance operations, and some asynchronous calls.
Common causes include a security plugin blocking requests from the server itself, incorrect DNS, SSL verification problems, PHP fatal errors, low timeouts, and reverse-proxy settings. On the server, I usually start with PHP-FPM and web server logs. A basic request looks like this:
curl -I https://example.com/wp-json/A 200, or a 3xx in some configurations, does not prove that every REST route is healthy. It narrows the investigation. A 403, 404, 500, or 502 gives you a more useful direction. Replace the example domain with your own, and do not send repeated heavy tests against production.
If the REST request eventually fails while reaching the database, the troubleshooting steps in WordPress Error Establishing a Database Connection: Fixes are also relevant. A network-looking error may have an application or database cause underneath it.
Scheduled tasks and WP-Cron
WP-Cron is not a system service that runs at fixed intervals. It is normally triggered by a site request. Low-traffic sites can accumulate delayed tasks, while busy sites may generate more cron requests than necessary.
List scheduled events with WP-CLI:
wp cron event list --fields=hook,time_gmt,intervalThis shows the hook name, its next scheduled time, and the interval when one exists. For the complete output, remove the field filter:
wp cron event listIf the same hook appears many times, the task may be failing, or a plugin may be creating events repeatedly. Find which plugin owns it before deleting anything. Blind cron cleanup can interfere with WooCommerce emails and order processing.
Persistent object caching
Site Health may recommend persistent object caching when none is detected. Redis can keep frequently accessed options and query results in memory instead of fetching them from the database repeatedly. It does not do the same job as a page cache.
A site without persistent object caching is not automatically slow. On a small, low-traffic site, the bottleneck may be a large image, a poorly written plugin, or a slow external API. WooCommerce cart and user-session rules need particular care when caching is introduced.
The Info tab makes support tickets shorter
Instead of writing only “There is an error in Site Health,” share the relevant section from the Info tab. It includes the WordPress version, PHP version, server software, database version, active theme, plugins, and filesystem details.
Passwords, API keys, and database credentials should not normally appear there in plain text, but review anything you export before sending it. Sharing only the sections related to the problem is safer than forwarding every available detail.
You can check the WordPress and command-line PHP versions from a terminal:
wp core version
php -vThese commands show versions only. If the server has multiple PHP versions, the PHP used by php -v may differ from the PHP used by the website. Shared hosting makes this particularly easy to miss.
A Site Health report is not a performance report
Site Health gives signals about configuration, security, and WordPress’s basic operating conditions. It does not fully measure page-load time, the connection quality of real visitors, or organic search traffic.
A site can look healthy and still be slow. If a product query on the homepage takes four seconds, successful HTTPS, REST API, and update checks do not make visitors wait any less.
For search visibility, read How to Read the Google Search Console Performance Report and compare clicks, impressions, queries, and pages. A green Site Health indicator does not say that organic traffic is healthy; the two screens answer different questions.
If you suspect the hosting layer, inspect CPU, RAM, disk I/O, PHP-FPM activity, and web server logs separately. Even in my own Proxmox lab, I do not label a site “slow” before checking mtr, the web server access log, and database query time as separate pieces of evidence. Blaming the infrastructure based on one colored notice usually extends the diagnosis.
A safe order of operations
- Read the complete message. The explanation and suggested action matter as much as the red heading.
- Back up before changing anything. If you touch PHP, a theme, a plugin, or HTTPS configuration, keep a way back.
- Verify in staging. Do not experiment by repeatedly disabling and enabling plugins on production.
- Check the logs. A
500error, REST problem, or loopback failure is often clearer in the logs. - Change one thing at a time. If you disable five plugins together, you will not know which change helped.
- Run the test again. Refresh Site Health after the change, then test the real user workflow as well.
The rollback plan matters. I have seen an empty or unusable backup folder described as “the backup” during a migration. The folder existed, but there was no database that could actually be restored. These days I plan a file and database export before an update, then perform a small restore test when the change deserves it.
When should you take the report seriously?
Do not wait if security updates cannot run, the PHP version is unsupported, HTTPS is incorrect, REST API or loopback failures affect real workflows, or cron tasks are accumulating. These deserve priority because the site’s operating conditions may be deteriorating, not simply because the indicator changed color.
If the only notice is a persistent object-cache recommendation or an automatic-update preference, consider the site’s actual needs first. You do not have to apply every recommendation. You should know why you are leaving it unchanged.
My routine is simple: open Site Health, order the red items by impact, collect the technical context from Info, and compare it with logs and real user flows. I do not consider the job finished when the screen turns green. Can visitors add a product to the cart, send the contact form, log in, and receive email? That is where the useful answer usually is.
Frequently asked questions
Can a red warning take a site offline?
Not every red warning means that the site will immediately go offline. Security, HTTPS, PHP compatibility, REST API, and update problems can affect core workflows, so read the explanation and inspect the logs without unnecessary delay.
Does Site Health affect SEO rankings?
The color or general status shown by Site Health is not a direct Google ranking score. Broken HTTPS, a slow server, inaccessible pages, or failed user workflows can still affect SEO and conversions indirectly.
How do I fix a REST API error?
Start with the HTTP status for /wp-json/, security-plugin records, web server logs, and SSL configuration. Do not keep disabling and enabling plugins without first identifying the source of a 403, 500, or 502.
How often should I check Site Health?
Check it after updates, PHP changes, migrations, and security-configuration changes. For a normal site, a monthly review is practical, with critical notices followed through email or a monitoring system.
