How to Fix WordPress Site Health Critical Issues: 7 Proven Step-by-Step Fixes That Worked for Me (2026)

TL;DR: Red WordPress Site Health critical issues warnings mean immediate action—start with PHP updates and plugin isolation. Based on my experience, most critical issues fall into five categories: outdated PHP, plugin conflicts, REST API/Loopback failures, database corruption, and security configuration gaps (HTTPS errors + disabled automatic updates). Follow the step-by-step fixes below, and you’ll clear those warnings in under an hour.

What Users Are Actually Looking For When They Search “WordPress Site Health Critical Issues”

If you’re staring at a bright red “Site Health detects critical issues” warning in your WordPress dashboard right now, you’re probably wondering: Is this serious? Will my site get hacked? Can I fix this without breaking anything?

Based on search behavior and the questions I’ve received from readers, there are three main types of users searching for how to fix WordPress Site Health critical issues:

1. Beginners who don’t understand the warning – they see red text, don’t know what it means, and are afraid to touch anything.
2. Users who know there’s a problem but don’t know how to fix it – they see specific errors like “REST API error” or “loopback request failed” and need step‑by‑step instructions they can follow safely.
3. Site owners dealing with recurring issues – they fix a problem, but the warnings come back weeks later, and they need a sustainable maintenance routine.

I’ve been in all three situations myself. In this post, I’ll give you exactly what I wish I’d had the first time I saw that WordPress Site Health critical issues warning: clear diagnosis steps, safe fixes, and a system to keep those warnings from coming back.

📑 Table of Contents

1. The first time I saw a red warning—and what I did wrong
2. Why Site Health warnings matter for your WordPress site
3. Critical issue #1: Is an outdated PHP version slowing down your site?
4. Critical issue #2: Plugin conflicts and white screens
5. Critical issue #3: Who’s blocking your REST API?
6. Critical issue #4: Loopback request failures—why can’t WordPress talk to itself?
7. Critical issue #5: Corrupted database tables
8. Critical issue #6: Security configuration gaps—HTTPS errors & disabled automatic updates
9. How to verify the fix actually worked
10. Common mistakes to avoid when fixing WordPress Site Health critical issues
11. Frequently asked questions about WordPress Site Health critical issues
12. A maintenance routine that keeps red warnings away
13. Closing thoughts

The first time I saw a red warning—and what I did wrong

Back in 2023, I took over a friend’s personal blog. The first thing I saw after logging in was a glaring red banner: “Site Health detects critical issues.” When I opened the Site Health screen, three critical warnings stared back at me: “Outdated PHP version,” “REST API error,” and “Automatic updates disabled.”

I made a mistake that, in hindsight, was embarrassingly naive. The site was still working. I could view posts on the front end, write new ones in the admin. So I figured the warnings were just noise and ignored them.

Three months later, the site was hacked. Attackers exploited a known vulnerability in the outdated PHP version to inject malicious code. The site dropped out of Google’s rankings, and it took me two full weeks to clean up. Traffic never fully recovered.

Since then, I’ve made it a habit: every month, I go to Tools → Site Health first. That habit has caught several potential disasters before they turned into actual downtime.

Below, I’ve documented the real cases I’ve handled and the steps I used to fix WordPress Site Health critical issues. Hopefully, this helps you avoid the mistakes I made.

Why Site Health warnings matter for your WordPress site

A lot of people—including past me—assume that if a site is up, it’s fine. But Site Health is like an annual physical: it flags issues that haven’t yet caused visible problems but could become serious if left alone.

Fix priority guide: Start with 🔴 Highest issues—these pose immediate security or stability risks. Then move to 🟠 High.

My rule now is simple: when Site Health shows a red warning, it’s time to act.

Critical issue #1: Is an outdated PHP version slowing down your site?

TL;DR: An outdated PHP version is one of the most common WordPress Site Health critical issues, putting your site at risk of hacks and slow performance. PHP 8.1 reached end-of-life in December 2023; PHP 8.2 ended active support in December 2024. Switching to PHP 8.3 or 8.4 in your hosting panel takes five minutes and will fix this warning instantly.

How to spot it

Site Health displays a warning like: “Your site is running an outdated version of PHP.”

In 2025, I helped a friend running an e‑commerce site with slow load times. When I checked Site Health, PHP 8.0 was still active. By then, WordPress recommended PHP 8.2 or higher, and his host already supported PHP 8.4—he just never switched.

The real impact

Before switching, the site’s TTFB (time to first byte) averaged 1.2 seconds. After switching to PHP 8.3, it dropped to 0.6 seconds. Here’s how the numbers changed:

These aren’t just numbers—they translate to faster page loads, better user experience, and improved Core Web Vitals for SEO.

The fix is simpler than it looks.

Before you start any of these steps, back up your full site (files + database). This lets you instantly restore your site if anything goes wrong.

Step 1: Back up everything. I can’t stress this enough. Switching PHP versions rarely breaks sites, but when it does, having a backup makes recovery instant.

Step 2: Switch the PHP version in your hosting control panel.

• cPanel: Look for “Select PHP Version”
• Plesk: Usually under “Domain Settings” or “PHP Settings”
• Cloud servers (AWS Lightsail, DigitalOcean, etc.): Check “Application Management” or “Server Configuration”

Step 3: Choose the right version. PHP 8.1 reached end-of-life in December 2023; PHP 8.2 ended active support in December 2024. Current recommendation: PHP 8.3 (supported until late 2026) or PHP 8.4 (stable as of 2024). I avoid the absolute latest if it was released less than 2–3 months ago, because some plugins need time to catch up.

Step 4: Test thoroughly. Log in to WordPress. Click through the admin area. Visit the front end in a private browsing window. Confirm everything works.

Step 5: Re-run Site Health. The warning should disappear after a fresh scan.

What I learned the hard way

Once, I switched a client’s PHP version and got a white screen immediately. I didn’t panic—I switched back to the old version, and the site came back up. The culprit turned out to be a three-year-old plugin that wasn’t compatible with PHP 8.3. Updating the plugin fixed it.

Key takeaway: If something breaks after a PHP upgrade, roll back first, then update your plugins and theme one by one.

Critical issue #2: Plugin conflicts and white screens

TL;DR: Plugin conflicts cause the “white screen of death” and are responsible for approximately 60% of Site Health critical issues. The fastest fix to this WordPress Site Health critical issues warning is to isolate the culprit using the Health Check & Troubleshooting plugin for safe troubleshooting, or by renaming the plugins folder via FTP.

How to spot it

This usually happens after you install a new plugin or run bulk updates. Suddenly, the site shows a white screen or the error message: “There has been a critical error on this website.” Sometimes the admin area still works; sometimes it’s locked out too.

The worst case I handled was a WooCommerce store. The owner clicked “Update All” on plugins, and the entire site went down.

Start with isolation—it’s faster than guessing.

Before you start any of these steps, back up your full site (files + database).

If the admin area is still accessible:

1. Install the Health Check & Troubleshooting plugin (officially maintained by the WordPress team) for safe troubleshooting.
2. Enable troubleshooting mode. This creates a clean session that only affects your logged-in view—visitors see the normal site.
3. In troubleshooting mode, reactivate plugins one by one. After each activation, refresh Site Health to see if the critical warning returns.
4. When you identify the problematic plugin, either update it (if an update exists) or replace it with a reliable alternative.

If the admin area is completely locked out:

This requires FTP or your hosting control panel’s file manager.

1. Navigate to /wp-content/.
2. Rename the plugins folder to something like plugins_deactivated.
3. WordPress will now see all plugins as disabled. The site should become accessible again.
4. Log in to the admin area. Go to the Plugins screen—everything will show as inactive.
5. Rename the folder back to plugins.
6. Back in the Plugins screen, activate plugins one at a time. After each activation, check the front end and Site Health.

I’ve used this method over a dozen times. It always pinpoints the exact plugin causing the problem.

A real example with code

A client’s Site Health showed two critical issues: REST API errors and loopback failures. I disabled all plugins via FTP, and both warnings disappeared. When I reactivated plugins one by one, the issues reappeared as soon as I enabled a specific theme that was calling session_start() incorrectly.

The problematic code in the theme’s functions.php was:

if(!session_id()) @session_start();

I replaced it with:

if(!session_id()) session_start(['read_and_close' => true]);

This change tells PHP to close the session immediately after starting it, preventing it from blocking other requests. The issue was solved in under 30 minutes.

Critical issue #3: Who’s blocking your REST API?

TL;DR: A blocked REST API usually means a security plugin, caching plugin, or server firewall is intercepting WordPress’s internal requests. Temporarily disable these tools one by one to fix this WordPress Site Health critical issues error.

How to spot it

Site Health shows: “The REST API encountered an unexpected result” or a similar error. You might also notice the block editor hanging on save, or the media library taking forever to load.

Why this matters

The REST API is how WordPress communicates with itself. Your editor autosaves, plugins fetch updates, and admin dashboards load data through it. If it’s blocked, critical features start breaking.

Common cURL errors you might see

Follow the chain—most blocks happen at one of these layers.

Before you start any of these steps, back up your full site (files + database).

Step 1: Check caching plugins.
Some caching plugins cache REST API responses to improve performance, which can cause unexpected results. Temporarily disable your caching plugin (or turn off REST API caching in its settings) and re-check Site Health.

Step 2: Check security plugins.
Plugins like Wordfence (the free tier is powerful enough for most sites) and Sucuri (excellent for enterprise-level protection) sometimes mistake REST API requests for malicious activity. Disable the security plugin temporarily. If the warning disappears, look for a setting like “Disable REST API” and make sure it’s not enabled.

Step 3: Regenerate permalinks.
If you’ve manually edited .htaccess or Nginx rules, they might be blocking /wp-json/ (the REST API endpoint). A quick fix: go to Settings → Permalinks and click “Save Changes” without changing anything. WordPress rewrites the rules for you.

Step 4: Contact your hosting provider.
Some hosts apply server‑level firewall rules that block REST API requests. If the first three steps didn’t help, ask your host: “Are you blocking loopback or REST API requests?” I’ve had cases where ModSecurity rules were the culprit, and support resolved it in minutes.

Critical issue #4: Loopback request failures—why can’t WordPress talk to itself?

TL;DR: Loopback failures mean WordPress can’t talk to itself, breaking scheduled posts, automatic updates, and background tasks. The fix mirrors REST API troubleshooting: check security plugins, regenerate permalinks, and increase PHP memory.

How to spot it

Site Health warns: “Your site could not complete a loopback request.”

Why this matters

Loopback requests are WordPress’s way of talking to itself. Scheduled posts, automatic updates, and theme previews all depend on them. If loopbacks fail, those background tasks stop working.

The same troubleshooting logic applies—start simple.

Before you start any of these steps, back up your full site (files + database).

Step 1: Clear all caches.
Disable caching plugins, clear any CDN cache, and if your host offers server‑level caching, clear that too.

Step 2: Temporarily disable security plugins.
Security plugins often block loopbacks as a precaution. Disable them and re-run Site Health to see if the warning clears.

Step 3: Regenerate permalinks.
Same as with REST API: go to Settings → Permalinks and click “Save Changes.” This often resolves accidentally broken rewrite rules.

Step 4: Increase PHP memory.
Sometimes loopbacks time out because the site is low on memory. Add this line to wp-config.php:

define('WP_MEMORY_LIMIT', '256M');

Step 5: Ask your host.
Some shared hosting providers disable loopback requests by default. If nothing else works, support can confirm whether loopbacks are allowed and enable them if needed.

Special case: Docker and containerized environments (advanced users)

In Docker deployments, loopback requests often fail because the container cannot resolve its own external domain. (This step is only for advanced users; most shared hosting users don’t need to worry about it.) The fix requires adding extra_hosts to your docker-compose.yml:

extra_hosts:
  - "yourdomain.com:host-gateway"

Or explicitly define the internal IP in /etc/hosts within the container.

Critical issue #5: Corrupted database tables

TL;DR: Database corruption usually happens after a server crash or when disk space fills up. Use phpMyAdmin’s repair tool or WordPress’s built-in repair tool to fix it—but remove the repair code immediately afterward.

How to spot it

You might see “Error establishing a database connection” or notice that some pages return 404 errors, while others work fine. Occasionally, admin functions behave erratically.

Why it happens

The most common causes: sudden server power loss, disk space filling up, or a heavy query that corrupted a table.

Repair is straightforward if you know where to look.

Before you start any of these steps, back up your full site (files + database).

Step 1: Repair via phpMyAdmin.

1. Log into your hosting control panel and open phpMyAdmin.
2. Select your WordPress database.
3. Check all tables, then choose “Check table” from the dropdown.
4. If any tables show as “corrupted,” select them and choose “Repair table.”

Step 2: Use WordPress’s built-in repair tool.

Add this line to wp-config.php:

define('WP_ALLOW_REPAIR', true);

Then visit http://yourdomain.com/wp-admin/maint/repair.php (replace yourdomain.com with your actual domain name). Click “Repair database.”

Step 3: Check disk space.

A full disk can corrupt database tables. Log into your hosting control panel and check disk usage. If it’s near 100%, delete old backups, clear logs, and free up space before the issue worsens.

Critical issue #6: Security configuration gaps—HTTPS errors & disabled automatic updates

TL;DR: Security configuration gaps—like missing HTTPS or disabled automatic updates—are among the most common WordPress Site Health critical issues warnings. Fix them by installing an SSL certificate, forcing HTTPS redirects, and enabling auto‑updates for core, plugins, and themes.

How to spot it

Site Health may show “Your site is not using HTTPS” or “Automatic updates are disabled.” You might also see browser “Not Secure” warnings or a “Mixed Content” error in the console.

Why this matters

HTTPS is a ranking factor for Google, and browsers actively warn users when a site isn’t secure. Disabled automatic updates mean your site misses critical security patches. In 2024, vulnerabilities in popular plugins (WP Statistics, WP Meta SEO, LiteSpeed Cache) affected over 6 million installations, with attackers exploiting outdated versions to create admin accounts.

Fix HTTPS errors

Step 1: Install a valid SSL certificate.

Most modern hosts provide free Let’s Encrypt certificates. In cPanel, look for “SSL/TLS” or “Let’s Encrypt SSL.”

Step 2: Update WordPress site URLs.

Go to Settings → General. Change both “WordPress Address (URL)” and “Site Address (URL)” from http:// to https://. Click “Save Changes.”

Step 3: Force HTTPS redirect.

The easiest way is to install the Really Simple SSL plugin. It automatically detects your SSL certificate, updates the site URLs, and sets up the redirect. It also helps fix mixed content issues.

Fix disabled automatic updates

Step 1: Enable core auto‑updates.

Go to Dashboard → Updates. Look for the option to enable auto‑updates for WordPress core. Click it.

Step 2: Enable plugin and theme auto‑updates.

• Plugins: Go to Plugins → Installed Plugins. For each plugin, click “Enable auto‑updates.”
• Themes: Go to Appearance → Themes. Hover over each theme and click “Enable auto‑updates.”

Step 3: Check for code that might be disabling updates.

Open your wp-config.php file. Look for lines like:

define('AUTOMATIC_UPDATER_DISABLED', true);
define('DISABLE_WP_CRON', true);

If you find them, remove or comment them out.

Security check after fixing

If your site was vulnerable before, check for backdoors. In 2024, attackers exploited outdated plugins to create hidden admin accounts.

(Note: The following steps are for intermediate/advanced users. If you’re a beginner, you can skip this and use a security plugin like Wordfence to scan for backdoors instead.)

Run this SQL query in phpMyAdmin to check for suspicious admin accounts:

SELECT * FROM wp_users WHERE user_login LIKE '%admin%' AND user_login != 'admin';

To detect injected malicious scripts, use this command via SSH (if you have SSH access). If you don’t have SSH access, use a security plugin to scan for malicious scripts instead:

grep -r "eval(base64_decode" /path/to/wordpress/

How to verify the fix actually worked

I used to stop once Site Health showed no red warnings. After some painful experiences, I added extra checks:

1. Re-scan Site Health. Click “Re-scan site health” to confirm all critical warnings are gone.
2. Test the front end. Open your site in a private/incognito window. Click through pages, posts, categories.
3. Test admin features. Publish a new post (with an image), edit an existing one, save theme customizations. Watch for errors.
4. Check the browser console. Press F12, open the Console tab. Look for red error messages.
5. Wait 24 hours. Some issues don’t re-appear immediately. Check Site Health again the next day to be sure.

Common mistakes to avoid when fixing WordPress Site Health critical issues

Over the years, I’ve seen (and made) the same mistakes again and again. Here’s what to avoid:

Frequently asked questions about WordPress Site Health critical issues

Q: What does “WordPress Site Health critical issues” mean?
A: It means WordPress has detected a serious configuration or security problem that could lead to site downtime, data loss, or hacking. Examples include outdated PHP, plugin conflicts, or disabled automatic updates.

Q: How do I fix “REST API encountered an unexpected result”?
A: Start by temporarily disabling security and caching plugins. If that doesn’t help, regenerate permalinks (Settings → Permalinks → Save Changes). If the issue persists, contact your host to check for server‑level firewall blocks.

Q: Is it safe to enable automatic updates for all plugins?
A: Generally yes, but I recommend enabling auto‑updates for all reputable plugins and themes. For mission‑critical custom plugins, test updates on a staging site first. WordPress core auto‑updates (minor versions) are always safe to enable.

Q: Can I fix Site Health critical issues without technical skills?
A: Yes. Most fixes—PHP upgrades, enabling HTTPS, turning on auto‑updates—can be done through your hosting control panel or plugin settings. For plugin conflicts, the Health Check & Troubleshooting plugin provides a safe, guided process.

Q: Why does Site Health still show warnings after I fixed everything?
A: Sometimes caches don’t clear immediately. Try clearing your browser cache, any caching plugins, and your CDN (like Cloudflare). Then click “Re-scan site health” again. If warnings persist, the issue may be at the server level—contact your host.

Q: How do I fix “Mixed Content” errors in WordPress Site Health?
A: Mixed Content errors happen when HTTP resources load on an HTTPS page. Install the Really Simple SSL plugin to automatically fix this, or use the Better Search Replace plugin to replace all http://yourdomain.com links with https://yourdomain.com in your database.

Q: Can I ignore WordPress Site Health critical issues if my site still works?
A: No. A site can feel normal while silently running insecure code. Red warnings mean immediate action—ignoring them can lead to hacks, data loss, or SEO penalties.

A maintenance routine that keeps red warnings away

After years of firefighting, I settled on a “three-layer defense” maintenance system. It’s built from the practices that have worked best across dozens of sites.

Layer 1: Real-time monitoring

• Performance monitoring: Tools like New Relic (great for deep PHP performance insights) or Query Monitor (free, lightweight, and perfect for beginners) help track slow PHP functions and database queries.
• Security monitoring: Wordfence (free tier is powerful enough for most sites) or Sucuri (excellent for enterprise-level protection) provides a real-time firewall and malware scan.
• Availability monitoring: Uptime Robot checks your site every five minutes and alerts you if it goes down.

Layer 2: Regular checks

Weekly:

• Check Site Health (Tools → Site Health)
• Review pending plugin, theme, and core updates
• Verify that recent backups completed successfully

Monthly:

• Run a full site backup and test a restore on a staging site
• Review disk usage and PHP memory limits in your hosting panel
• Remove any unused plugins and themes
• Check SSL certificate expiration date

Quarterly:

• Review user accounts and remove inactive administrators
• Enable two‑factor authentication (2FA) for all admin users
• Check that your PHP version is still supported (PHP 8.3 is the safest stable choice as of 2026; PHP 8.4 is stable but verify plugin compatibility)

Layer 3: Disaster recovery readiness

• 3‑2‑1 backup strategy: Keep three copies of your data, on two different media types, with one copy off‑site (cloud storage like Google Drive or AWS S3).
• Documented recovery steps: Write down the exact process to restore from backup—including FTP credentials, database access, and who to contact at your host.
• Rollback plan: For major updates (WordPress core, critical plugins), test on a staging site first. If you don’t have a staging site, take a full backup immediately before updating so you can restore within minutes.

This routine has kept my sites almost entirely free of critical warnings for over two years.

Closing thoughts

Looking back at the site that got hacked in 2023, I remember how frustrated I was. But that experience taught me to respect Site Health. Every red warning since then has been a chance to fix something small before it became something big.

If you’re looking at a WordPress Site Health critical issues warning right now, I hope this post gives you a clear path forward. Most issues can be resolved in under an hour by following these steps. And if you’re stuck, don’t hesitate to send your Site Health details to your hosting provider—they deal with these problems every day.

A stable site is a site you don’t have to worry about. Get the red warnings handled, and you’ll sleep better.