How to Perform a WordPress Health Check for Troubleshooting (2025 Guide)

A WordPress health check is a systematic diagnostic process that evaluates your site's PHP version, database integrity, active plugins, theme compatibility, server environment, and security posture — all from within the WordPress admin dashboard or via dedicated tooling. Running this check regularly prevents cascading failures, identifies performance bottlenecks before they affect rankings, and surfaces security vulnerabilities before they become breaches.

The built-in Site Health tool (introduced in WordPress 5.2) provides an automated status report and a raw debug information panel that experienced developers use as the first stop in any troubleshooting workflow. Combined with the Health Check & Troubleshooting plugin, you can replicate production issues in an isolated session without touching the live site — a capability that eliminates the single biggest risk in WordPress debugging: breaking things for real visitors while you investigate.

Why WordPress Health Checks Matter More Than Most Guides Admit

Most tutorials treat Site Health as a checklist to tick off once. In practice, it is a continuous operational signal. Google's Core Web Vitals directly penalize slow or unstable sites. A single outdated plugin with a known CVE can result in a full site compromise within hours of public disclosure. PHP version mismatches between your server and a plugin's minimum requirement silently degrade performance long before they throw a fatal error.

Running on a well-configured VPS Hosting environment gives you direct control over PHP versions, server-level caching, and security hardening — control that shared environments simply cannot provide. The health check workflow described below assumes you have SSH access or a control panel capable of modifying server-level settings, which is the correct baseline for any production WordPress deployment.

Step 1: Access the Built-In WordPress Site Health Tool

Navigate to Tools > Site Health inside your WordPress admin dashboard. WordPress will immediately begin running automated checks and populate the Status tab with results categorized by severity.

There is no plugin required for this step. Site Health is core functionality, and its results are generated server-side, meaning they reflect the actual runtime environment — not a simulated one.

What Site Health actually checks under the hood:

• PHP version, memory limit, and max execution time
• Active WordPress version versus latest stable release
• Whether the REST API is accessible and returning valid responses
• Scheduled cron job execution (wp-cron) status
• HTTPS enforcement and SSL certificate validity
• Presence of the debug.log file in a publicly accessible location
• Loopback request capability (required for background updates and plugin installations)
• Database server version and whether it meets WordPress minimums
• File and directory permissions for sensitive paths

Step 2: Interpret the Site Health Status Report Correctly

The status page categorizes findings into three tiers. Understanding what each tier actually means — and what it does not mean — prevents both complacency and unnecessary panic.

Critical issues that demand immediate attention:

• Outdated PHP version — PHP 7.4 reached end-of-life in November 2022. Running it means no security patches. WordPress 6.x officially recommends PHP 8.1 or 8.2.
• Inactive plugins still installed — Inactive plugins are still readable by the file system and can contain exploitable code. Delete them, do not merely deactivate.
• REST API blocked — Many modern plugins, the block editor (Gutenberg), and WooCommerce depend on REST API availability. A blocked REST API produces silent failures that are notoriously difficult to trace.
• Loopback request failure — If WordPress cannot make a loopback HTTP request to itself, automatic background updates and scheduled tasks will fail silently.
• WP_DEBUG enabled on a live site — Debug mode writes sensitive configuration data and stack traces to debug.log. If that file is in wp-content/ without server-level access restrictions, it is publicly readable.

A frequently missed edge case: Site Health reports a "Good" status for object caching if *any* object cache is detected — including a file-based one. File-based object caching on high-traffic sites can actually increase I/O load rather than reduce it. The correct solution is a Redis or Memcached backend, which requires server-level configuration beyond what Site Health can provision.

Step 3: Extract and Use the Debug Information Panel

Click the Info tab on the Site Health page. This panel is arguably more valuable for troubleshooting than the Status tab because it exposes raw environment data.

Key sections and what to look for:

• WordPress — Confirms active theme, whether multisite is enabled, and whether WP_DEBUG is active.
• Directories and Sizes — Reveals if wp-content/uploads/ has grown to a size that is straining disk I/O or backup processes.
• Active Plugins — Lists every active plugin with its version. Cross-reference against the WordPress Vulnerability Database (wpscan.com) for known CVEs.
• Server — Shows PHP version, PHP memory limit, max upload size, max execution time, and whether mod_rewrite or equivalent URL rewriting is active.
• Database — Confirms MySQL or MariaDB version and the database character set. utf8mb4 is required for full emoji and multilingual support; utf8 (3-byte) will silently truncate certain characters.
• Must Use Plugins — Often overlooked. MU plugins load before all other plugins and cannot be deactivated from the admin UI. If a hosting provider has injected an MU plugin (common with managed hosting), it appears here.

Practical use of the "Copy site info to clipboard" button:

When opening a support ticket or posting to a developer forum, paste this output directly. It eliminates the back-and-forth of basic environment questions and allows experienced engineers to spot configuration anomalies immediately — for example, a memory_limit of 40M when WooCommerce requires a minimum of 128M, or a max_execution_time of 30 seconds when a large import process requires 300.

Step 4: Use the Health Check & Troubleshooting Plugin for Safe-Mode Debugging

The Health Check & Troubleshooting plugin (available free from the WordPress plugin repository) enables a session-isolated safe mode. This is the correct method for diagnosing plugin and theme conflicts on a live production site.

How session isolation works technically:

The plugin sets a browser cookie that WordPress reads on each request. When the cookie is present, WordPress loads only the default theme and deactivates all non-essential plugins — but *only for the browser session carrying that cookie*. All other visitors experience the site exactly as it was before. This is not a staging environment; it is a runtime filter applied at the WordPress bootstrap level.

Installation and activation:

# If you have WP-CLI available on your server (recommended)
wp plugin install health-check --activate

Or navigate to Plugins > Add New, search for "Health Check & Troubleshooting", and click Install Now, then Activate.

Running a troubleshooting session:

1. Go to Tools > Site Health and click the Troubleshooting tab.
2. Click Enable Troubleshooting Mode. Your session now runs with all plugins deactivated and the default theme active (Twenty Twenty-Four as of WordPress 6.5+).
3. Reproduce the issue. If it is gone, a plugin or theme is responsible.
4. Re-enable plugins one at a time using the Troubleshooting tab's plugin list. After enabling each one, reload the affected page and test.
5. Once the issue reappears, the last plugin you enabled is the conflict source.
6. Click Disable Troubleshooting Mode to restore the full production environment.

Edge cases and pitfalls:

• If the issue persists even in safe mode (no plugins, default theme), the problem is at the server or WordPress core level — not a plugin conflict. Check php_error.log and the WordPress debug log next.
• MU plugins are not deactivated by safe mode. If you suspect an MU plugin, you must manually rename it in wp-content/mu-plugins/ via SFTP or SSH.
• The troubleshooting cookie is browser-specific. If you are testing on mobile, you need to enable troubleshooting mode in that browser session separately.

Step 5: Diagnose and Resolve Plugin and Theme Conflicts

Plugin conflicts fall into two categories that require different resolution strategies:

Type 1: Direct PHP conflicts — Two plugins attempt to define the same function or class. This produces a fatal error immediately. The error log will contain Cannot redeclare function or Cannot redeclare class.

Type 2: Silent behavioral conflicts — Two plugins both hook into the same WordPress action or filter and produce unexpected output or data corruption without throwing an error. These are significantly harder to diagnose and require methodical one-by-one isolation.

Resolution workflow:

# Check the WordPress debug log for fatal errors
tail -n 100 /path/to/wp-content/debug.log

# Enable WP_DEBUG temporarily via wp-config.php if debug.log is empty
# Add these lines to wp-config.php before the "stop editing" comment:
# define('WP_DEBUG', true);
# define('WP_DEBUG_LOG', true);
# define('WP_DEBUG_DISPLAY', false);

When a plugin is the confirmed conflict source:

1. Check the plugin's changelog for a recent update that addresses the conflict.
2. Search the plugin's support forum on wordpress.org for reports of the same conflict.
3. If no fix is available, identify an alternative plugin with equivalent functionality.
4. If the plugin is business-critical, contact the plugin author with the specific error from your debug log — include your PHP version, WordPress version, and the conflicting plugin name and version.

Step 6: Update PHP and Database Server Versions

This is the single highest-impact maintenance action for both performance and security. PHP 8.1 and 8.2 deliver measurable throughput improvements over PHP 7.4 — benchmarks consistently show 20–30% faster execution for typical WordPress workloads due to JIT compilation and improved OPcache behavior.

PHP version compatibility matrix for WordPress:

Updating PHP via cPanel (for VPS with cPanel environments):

1. Log in to WHM (root access) or cPanel (user-level, if MultiPHP Manager is enabled).
2. Navigate to MultiPHP Manager under the Software section.
3. Select your domain and choose the target PHP version from the dropdown.
4. Click Apply.

Updating PHP via the command line (Ubuntu/Debian):

# Add the Ondrej PHP PPA (Ubuntu)
sudo add-apt-repository ppa:ondrej/php
sudo apt update

# Install PHP 8.2 with common WordPress extensions
sudo apt install php8.2 php8.2-mysql php8.2-curl php8.2-gd php8.2-mbstring 
  php8.2-xml php8.2-zip php8.2-intl php8.2-bcmath php8.2-imagick

# Switch the CLI default (if using WP-CLI)
sudo update-alternatives --set php /usr/bin/php8.2

Critical pre-upgrade step: Before changing the PHP version in production, test your theme and every active plugin against the new version. Use WP-CLI on a staging environment:

wp core check-update
wp plugin list --update=available --format=table
wp theme list --update=available --format=table

Database version considerations:

WordPress requires MySQL 5.7+ or MariaDB 10.3+. MariaDB 10.6 and 10.11 (LTS) are the current recommended versions. Running an older database server version introduces both security exposure and missing query optimizer improvements that affect sites with large post tables or WooCommerce order volumes.

-- Check current database version from within WordPress or phpMyAdmin
SELECT VERSION();

-- Check table storage engines (InnoDB is required for full-text search and transactions)
SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'your_wordpress_database';

If any tables show MyISAM as the engine, convert them to InnoDB for better crash recovery and concurrent write performance:

ALTER TABLE wp_options ENGINE=InnoDB;

Step 7: Measure and Optimize Site Performance

Site Health does not measure front-end performance — that requires external tooling. Use Google PageSpeed Insights (measures Core Web Vitals in real-world conditions), GTmetrix (waterfall analysis), and WebPageTest (multi-location, advanced configuration) as complementary tools.

Performance optimization by layer:

Server layer:

• Enable OPcache for PHP bytecode caching. On a properly configured VPS, this alone reduces PHP execution time by 40–60%.

; Add to php.ini or a custom .ini file
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.revalidate_freq=60
opcache.jit_buffer_size=100M
opcache.jit=1255

• Use Redis for persistent object caching. Install the redis-server package and the Redis Object Cache WordPress plugin, then add to wp-config.php:

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_CACHE', true);

Application layer:

• Image optimization — Use WebP format with JPEG/PNG fallbacks. The Imagify or ShortPixel plugins handle bulk conversion and automatic WebP delivery via .htaccess rewrite rules.
• Lazy loading — WordPress 5.5+ adds loading="lazy" to images automatically, but verify it is not being overridden by your theme.
• Database optimization — Run OPTIMIZE TABLE on high-churn tables (wp_options, wp_postmeta) monthly. The WP-Optimize plugin automates this.

# Optimize all WordPress tables via WP-CLI
wp db optimize

• Caching plugins — W3 Total Cache with Redis backend or WP Rocket (premium) are the two most capable options. Avoid running two caching plugins simultaneously — they will conflict.

CDN integration:

A CDN offloads static asset delivery and reduces TTFB for geographically distributed visitors. Cloudflare's free tier provides adequate CDN functionality for most sites. For media-heavy sites, BunnyCDN offers better performance per dollar. Configure your CDN to cache static assets aggressively but exclude the WordPress admin (/wp-admin/) and any dynamic endpoints.

Step 8: Harden Security and Establish a Vulnerability Monitoring Routine

Security is not a one-time configuration — it is an ongoing operational practice. The Site Health tool surfaces some security issues, but it does not perform vulnerability scanning.

Layered security approach:

At the server level (requires VPS or dedicated server access):

# Disable XML-RPC if not required (common attack vector for brute force amplification)
# Add to .htaccess
# <Files xmlrpc.php>
#   Order Deny,Allow
#   Deny from all
# </Files>

# Restrict wp-config.php access
chmod 600 /path/to/wp-config.php

# Verify file permissions across the WordPress installation
find /path/to/wordpress/ -type f -name "*.php" -perm /022
# Any PHP file writable by group or world is a security risk

At the application level:

• Wordfence Security — Provides a Web Application Firewall (WAF), malware scanner, and real-time threat intelligence feed. The free tier is sufficient for most sites; the premium tier adds real-time firewall rule updates.
• Limit login attempts — The Limit Login Attempts Reloaded plugin or Wordfence's built-in brute force protection. Set lockout after 3–5 failed attempts.
• Two-factor authentication — Enforce 2FA for all administrator accounts using WP 2FA or Google Authenticator plugins.
• SSL/HTTPS enforcement — Every WordPress site must run over HTTPS. Obtain and install an SSL certificate; if you need one, SSL Certificates from your hosting provider are the most straightforward path. Add the following to wp-config.php to force HTTPS at the application level:

define('FORCE_SSL_ADMIN', true);

And in .htaccess:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Automated vulnerability monitoring:

Subscribe to the WPScan Vulnerability Database email alerts for plugins you use. The WPScan CLI tool can be integrated into a cron job to alert you when a new CVE is published for any installed plugin:

# Install WPScan (requires Ruby)
gem install wpscan

# Run a vulnerability scan against your site
wpscan --url https://yourdomain.com --api-token YOUR_API_TOKEN 
  --enumerate vp,vt,u --plugins-detection aggressive

Database backups as a security control:

A clean, recent backup is your most reliable recovery mechanism after a compromise. Automate daily backups to an off-server location (S3-compatible object storage, remote SFTP). The UpdraftPlus plugin handles this reliably. Verify restore procedures quarterly — a backup you have never tested is not a backup.

WordPress Health Check: Decision Matrix and Key Takeaways

Use this matrix to determine the correct action based on what Site Health reports:

Operational checklist for ongoing WordPress health:

• Run Site Health status review monthly; treat Critical findings as incidents.
• Keep PHP on a supported version (8.1 minimum; 8.2 or 8.3 preferred).
• Delete inactive plugins and themes — do not merely deactivate them.
• Enable Redis object caching on any site with more than 500 daily visitors.
• Automate daily off-server database backups with verified restore testing.
• Subscribe to vulnerability alerts for every plugin and theme in your stack.
• Enforce HTTPS sitewide and set FORCE_SSL_ADMIN in wp-config.php.
• Use WP-CLI for batch updates and database operations — it is faster and scriptable.
• On a Dedicated Server or VPS, configure a server-side cron job instead of relying on wp-cron — wp-cron only fires when a visitor hits the site, making it unreliable on low-traffic sites.

# Replace wp-cron with a real cron job (add to crontab)
# First, disable wp-cron in wp-config.php:
# define('DISABLE_WP_CRON', true);

# Then add to crontab (crontab -e):
*/15 * * * * php /path/to/wordpress/wp-cron.php > /dev/null 2>&1
# Or with WP-CLI (preferred):
*/15 * * * * wp --path=/path/to/wordpress cron event run --due-now > /dev/null 2>&1

If you are evaluating hosting environments for a WordPress deployment, VPS Control Panels provide the server-level access necessary to implement every optimization and hardening measure described in this guide — PHP version management, Redis configuration, server-side cron, and firewall rules all require root or sudo access that shared environments do not provide.

FAQ

What is the difference between the Site Health Status tab and the Info tab?

The Status tab runs automated checks and categorizes findings by severity (Good, Recommended, Critical). The Info tab displays raw environment data — PHP configuration, active plugins with versions, database details, and directory sizes — without any pass/fail judgment. The Info tab is primarily used for manual diagnosis and sharing with support engineers.

Does enabling Troubleshooting Mode affect live visitors?

No. Troubleshooting Mode uses a browser cookie to apply the safe-mode environment exclusively to your session. Visitors without the cookie experience the site normally. The only exception is if a fatal error in a plugin is crashing the server process itself — in that case, all visitors are affected regardless of the plugin's activation state in your session.

Which PHP version should I use for WordPress in 2025?

PHP 8.2 is the recommended version for production WordPress sites in 2025. It is actively maintained with security patches, offers measurable performance improvements over 8.0 and 8.1, and is supported by all major WordPress plugins. PHP 8.3 is stable and suitable for new deployments, but verify plugin compatibility before upgrading an existing site.

Why does Site Health report "Good" when my site is clearly slow?

Site Health checks configuration and security posture — it does not measure front-end performance metrics like Largest Contentful Paint (LCP) or Time to First Byte (TTFB). A site can pass all Site Health checks and still score poorly on Core Web Vitals due to unoptimized images, no caching layer, a slow database, or a geographically distant server. Use Google PageSpeed Insights or WebPageTest for performance measurement.

How do I fix a loopback request failure in WordPress Site Health?

A loopback failure means WordPress cannot make an HTTP request to its own URL from the server. Common causes include: a firewall blocking outbound connections from the web server process, a hosts file entry that misroutes the domain, an SSL certificate error on the loopback request, or a security plugin blocking the request. Start by temporarily disabling your security plugin and re-running Site Health. If that resolves it, whitelist the server's own IP in the security plugin's firewall settings.