{"id":5157,"date":"2026-09-09T13:59:33","date_gmt":"2026-09-09T10:59:33","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/?p=5157"},"modified":"2026-09-09T06:26:22","modified_gmt":"2026-09-09T03:26:22","slug":"how-to-read-and-fix-wordpress-site-health-report","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/how-to-read-and-fix-wordpress-site-health-report\/","title":{"rendered":"WordPress Site Health: How to Read and Fix the Report"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><div id=\"toc_container\" role=\"navigation\" aria-label=\"Table of Contents\" data-nosnippet class=\"toc_transparent no_bullets toc_numbered toc_title_center\"><p class=\"toc_title\">\u0130\u00e7indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#That_red_WordPress_warning_is_not_a_site-wide_grade\"><span class=\"toc_number toc_depth_1\">1.<\/span> That red WordPress warning is not a site-wide grade<\/a><\/li><li><a href=\"#What_WordPress_shows_in_Site_Health\"><span class=\"toc_number toc_depth_1\">2.<\/span> What WordPress shows in Site Health<\/a><ul><li><a href=\"#Critical_issues\"><span class=\"toc_number toc_depth_2\">2.1.<\/span> Critical issues<\/a><\/li><li><a href=\"#Recommended_improvements\"><span class=\"toc_number toc_depth_2\">2.2.<\/span> Recommended improvements<\/a><\/li><li><a href=\"#Green_does_not_mean_perfect\"><span class=\"toc_number toc_depth_2\">2.3.<\/span> Green does not mean perfect<\/a><\/li><\/ul><\/li><li><a href=\"#Do_not_install_a_plugin_the_moment_you_see_red\"><span class=\"toc_number toc_depth_1\">3.<\/span> Do not install a plugin the moment you see red<\/a><\/li><li><a href=\"#Checks_you_will_see_often\"><span class=\"toc_number toc_depth_1\">4.<\/span> Checks you will see often<\/a><ul><li><a href=\"#WordPress_themes_and_plugins\"><span class=\"toc_number toc_depth_2\">4.1.<\/span> WordPress, themes, and plugins<\/a><\/li><li><a href=\"#PHP_version_and_memory_limits\"><span class=\"toc_number toc_depth_2\">4.2.<\/span> PHP version and memory limits<\/a><\/li><li><a href=\"#HTTPS_and_secure_connections\"><span class=\"toc_number toc_depth_2\">4.3.<\/span> HTTPS and secure connections<\/a><\/li><li><a href=\"#REST_API_and_loopback_requests\"><span class=\"toc_number toc_depth_2\">4.4.<\/span> REST API and loopback requests<\/a><\/li><li><a href=\"#Scheduled_tasks_and_WP-Cron\"><span class=\"toc_number toc_depth_2\">4.5.<\/span> Scheduled tasks and WP-Cron<\/a><\/li><li><a href=\"#Persistent_object_caching\"><span class=\"toc_number toc_depth_2\">4.6.<\/span> Persistent object caching<\/a><\/li><\/ul><\/li><li><a href=\"#The_Info_tab_makes_support_tickets_shorter\"><span class=\"toc_number toc_depth_1\">5.<\/span> The Info tab makes support tickets shorter<\/a><\/li><li><a href=\"#A_Site_Health_report_is_not_a_performance_report\"><span class=\"toc_number toc_depth_1\">6.<\/span> A Site Health report is not a performance report<\/a><\/li><li><a href=\"#A_safe_order_of_operations\"><span class=\"toc_number toc_depth_1\">7.<\/span> A safe order of operations<\/a><\/li><li><a href=\"#When_should_you_take_the_report_seriously\"><span class=\"toc_number toc_depth_1\">8.<\/span> When should you take the report seriously?<\/a><\/li><li><a href=\"#Frequently_asked_questions\"><span class=\"toc_number toc_depth_1\">9.<\/span> Frequently asked questions<\/a><ul><li><a href=\"#Can_a_red_warning_take_a_site_offline\"><span class=\"toc_number toc_depth_2\">9.1.<\/span> Can a red warning take a site offline?<\/a><\/li><li><a href=\"#Does_Site_Health_affect_SEO_rankings\"><span class=\"toc_number toc_depth_2\">9.2.<\/span> Does Site Health affect SEO rankings?<\/a><\/li><li><a href=\"#How_do_I_fix_a_REST_API_error\"><span class=\"toc_number toc_depth_2\">9.3.<\/span> How do I fix a REST API error?<\/a><\/li><li><a href=\"#How_often_should_I_check_Site_Health\"><span class=\"toc_number toc_depth_2\">9.4.<\/span> How often should I check Site Health?<\/a><\/li><\/ul><\/li><\/ul><\/div>\n<h2><span id=\"That_red_WordPress_warning_is_not_a_site-wide_grade\">That red WordPress warning is not a site-wide grade<\/span><\/h2>\n<p>The colors in <strong>Tools &gt; Site Health<\/strong> 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.<\/p>\n<p>A customer once asked me, &#8220;My Site Health score is 82 percent. Is Google going to penalize us?&#8221; 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.<\/p>\n<p>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.<\/p>\n<h2><span id=\"What_WordPress_shows_in_Site_Health\">What WordPress shows in Site Health<\/span><\/h2>\n<p>WordPress separates the report into two main tabs:<\/p>\n<ul>\n<li><strong>Status:<\/strong> automatic checks, critical issues, and recommended improvements.<\/li>\n<li><strong>Info:<\/strong> technical details about the server, WordPress, themes, plugins, database, and filesystem.<\/li>\n<\/ul>\n<p>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.<\/p>\n<h3><span id=\"Critical_issues\">Critical issues<\/span><\/h3>\n<p>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?<\/p>\n<p>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.<\/p>\n<h3><span id=\"Recommended_improvements\">Recommended improvements<\/span><\/h3>\n<p>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.<\/p>\n<p>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.<\/p>\n<h3><span id=\"Green_does_not_mean_perfect\">Green does not mean perfect<\/span><\/h3>\n<p>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.<\/p>\n<p>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 <code>mtr<\/code> when the network path is part of the suspicion.<\/p>\n<h2><span id=\"Do_not_install_a_plugin_the_moment_you_see_red\">Do not install a plugin the moment you see red<\/span><\/h2>\n<p>Not every notice has the same urgency. I classify an alert with four questions:<\/p>\n<ol>\n<li>Does it prevent visitors from using the site?<\/li>\n<li>Does it create a security or data-loss risk?<\/li>\n<li>Does it affect updates, backups, or scheduled tasks?<\/li>\n<li>Is it persistent, or could it be a temporary connection failure?<\/li>\n<\/ol>\n<p>&#8220;The REST API returned an unexpected response&#8221; 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.<\/p>\n<p>Start by checking the request&#8217;s HTTP status in your browser&#8217;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.<\/p>\n<h2><span id=\"Checks_you_will_see_often\">Checks you will see often<\/span><\/h2>\n<h3><span id=\"WordPress_themes_and_plugins\">WordPress, themes, and plugins<\/span><\/h3>\n<p>When Site Health identifies outdated components, I begin with a backup. On production, I do not press &#8220;update everything&#8221; before checking the PHP version, theme compatibility, custom code, and WooCommerce version.<\/p>\n<p>Before an update, I take at least a database export. On a server with WP-CLI, my basic check looks like this:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">wp core version\nwp plugin list --update=available\nwp theme list --update=available\nwp db export \/var\/backups\/site-before-update.sql<\/code><\/pre>\n<p>The 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.<\/p>\n<p>I learned that during a migration. A customer showed me a folder and said, &#8220;We have a backup.&#8221; 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.<\/p>\n<p>For related database checks, see <em><a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-database-connection-error-fixes\/\">WordPress Error Establishing a Database Connection: Fixes<\/a><\/em>. I use the same habit here: inspect application and database evidence before changing settings.<\/p>\n<h3><span id=\"PHP_version_and_memory_limits\">PHP version and memory limits<\/span><\/h3>\n<p>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.<\/p>\n<p>If you see a <code>WP_MEMORY_LIMIT<\/code> or <code>memory_limit<\/code> warning, do not raise the value at random. More memory does not explain a bad query or an unnecessary loop.<\/p>\n<p>A support ticket once requested only a higher <code>memory_limit<\/code>. The actual cause was a reporting plugin scanning a large table without a <code>WHERE<\/code> 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.<\/p>\n<h3><span id=\"HTTPS_and_secure_connections\">HTTPS and secure connections<\/span><\/h3>\n<p>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.<\/p>\n<p>An old hard-coded <code>siteurl<\/code> or <code>home<\/code> value in <code>wp-config.php<\/code> can cause redirect loops. Take a database backup before changing URL values. To inspect the current WordPress options:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">wp option get home\nwp option get siteurl<\/code><\/pre>\n<p>Seeing <code>https:\/\/<\/code> in the output is not enough. If the page source or browser Network tab still shows HTTP resources, mixed content remains.<\/p>\n<h3><span id=\"REST_API_and_loopback_requests\">REST API and loopback requests<\/span><\/h3>\n<p>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.<\/p>\n<p>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:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">curl -I https:\/\/example.com\/wp-json\/<\/code><\/pre>\n<p>A <code>200<\/code>, or a <code>3xx<\/code> in some configurations, does not prove that every REST route is healthy. It narrows the investigation. A <code>403<\/code>, <code>404<\/code>, <code>500<\/code>, or <code>502<\/code> gives you a more useful direction. Replace the example domain with your own, and do not send repeated heavy tests against production.<\/p>\n<p>If the REST request eventually fails while reaching the database, the troubleshooting steps in <em>WordPress Error Establishing a Database Connection: Fixes<\/em> are also relevant. A network-looking error may have an application or database cause underneath it.<\/p>\n<h3><span id=\"Scheduled_tasks_and_WP-Cron\">Scheduled tasks and WP-Cron<\/span><\/h3>\n<p>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.<\/p>\n<p>List scheduled events with WP-CLI:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">wp cron event list --fields=hook,time_gmt,interval<\/code><\/pre>\n<p>This shows the hook name, its next scheduled time, and the interval when one exists. For the complete output, remove the field filter:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">wp cron event list<\/code><\/pre>\n<p>If 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.<\/p>\n<h3><span id=\"Persistent_object_caching\">Persistent object caching<\/span><\/h3>\n<p>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.<\/p>\n<p>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.<\/p>\n<h2><span id=\"The_Info_tab_makes_support_tickets_shorter\">The Info tab makes support tickets shorter<\/span><\/h2>\n<p>Instead of writing only &#8220;There is an error in Site Health,&#8221; 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.<\/p>\n<p>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.<\/p>\n<p>You can check the WordPress and command-line PHP versions from a terminal:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">wp core version\nphp -v<\/code><\/pre>\n<p>These commands show versions only. If the server has multiple PHP versions, the PHP used by <code>php -v<\/code> may differ from the PHP used by the website. Shared hosting makes this particularly easy to miss.<\/p>\n<h2><span id=\"A_Site_Health_report_is_not_a_performance_report\">A Site Health report is not a performance report<\/span><\/h2>\n<p>Site Health gives signals about configuration, security, and WordPress&#8217;s basic operating conditions. It does not fully measure page-load time, the connection quality of real visitors, or organic search traffic.<\/p>\n<p>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.<\/p>\n<p>For search visibility, read <em><a href=\"https:\/\/www.dchost.com\/blog\/en\/how-to-read-google-search-console-performance-report\/\">How to Read the Google Search Console Performance Report<\/a><\/em> 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.<\/p>\n<p>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 &#8220;slow&#8221; before checking <code>mtr<\/code>, 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.<\/p>\n<h2><span id=\"A_safe_order_of_operations\">A safe order of operations<\/span><\/h2>\n<ol>\n<li><strong>Read the complete message.<\/strong> The explanation and suggested action matter as much as the red heading.<\/li>\n<li><strong>Back up before changing anything.<\/strong> If you touch PHP, a theme, a plugin, or HTTPS configuration, keep a way back.<\/li>\n<li><strong>Verify in staging.<\/strong> Do not experiment by repeatedly disabling and enabling plugins on production.<\/li>\n<li><strong>Check the logs.<\/strong> A <code>500<\/code> error, REST problem, or loopback failure is often clearer in the logs.<\/li>\n<li><strong>Change one thing at a time.<\/strong> If you disable five plugins together, you will not know which change helped.<\/li>\n<li><strong>Run the test again.<\/strong> Refresh Site Health after the change, then test the real user workflow as well.<\/li>\n<\/ol>\n<p>The rollback plan matters. I have seen an empty or unusable backup folder described as &#8220;the backup&#8221; 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.<\/p>\n<h2><span id=\"When_should_you_take_the_report_seriously\">When should you take the report seriously?<\/span><\/h2>\n<p>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&#8217;s operating conditions may be deteriorating, not simply because the indicator changed color.<\/p>\n<p>If the only notice is a persistent object-cache recommendation or an automatic-update preference, consider the site&#8217;s actual needs first. You do not have to apply every recommendation. You should know why you are leaving it unchanged.<\/p>\n<p>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.<\/p>\n<h2><span id=\"Frequently_asked_questions\">Frequently asked questions<\/span><\/h2>\n<h3><span id=\"Can_a_red_warning_take_a_site_offline\">Can a red warning take a site offline?<\/span><\/h3>\n<p>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.<\/p>\n<h3><span id=\"Does_Site_Health_affect_SEO_rankings\">Does Site Health affect SEO rankings?<\/span><\/h3>\n<p>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.<\/p>\n<h3><span id=\"How_do_I_fix_a_REST_API_error\">How do I fix a REST API error?<\/span><\/h3>\n<p>Start with the HTTP status for <code>\/wp-json\/<\/code>, security-plugin records, web server logs, and SSL configuration. Do not keep disabling and enabling plugins without first identifying the source of a <code>403<\/code>, <code>500<\/code>, or <code>502<\/code>.<\/p>\n<h3><span id=\"How_often_should_I_check_Site_Health\">How often should I check Site Health?<\/span><\/h3>\n<p>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.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>A WordPress Site Health report is a troubleshooting dashboard, not an SEO score. Learn how to interpret warnings and verify real site functions safely.<\/p>\n","protected":false},"author":4,"featured_media":5154,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[183],"tags":[243,479,116,478,404,402],"class_list":["post-5157","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wordpress","tag-website-performance","tag-website-security","tag-wordpress","tag-wordpress-site-health","tag-wordpress-troubleshooting","tag-wp-cli"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/5157","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=5157"}],"version-history":[{"count":1,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/5157\/revisions"}],"predecessor-version":[{"id":5159,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/5157\/revisions\/5159"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/5154"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=5157"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=5157"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=5157"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}