Using the WordPress Site Health tool

Where Site Health lives

WordPress ships a built-in diagnostic tool called Site Health, introduced in version 5.2 and found under Tools > Site Health in the admin menu. It has two tabs: Status and Info. The Status tab runs a set of automated checks against the installation and reports them as passed, recommended, or critical. The Info tab is a read-only dump of the environment: the WordPress version, active and inactive plugins and themes, PHP version and settings, memory limits, database details, file permissions, and the constants defined in wp-config.php.

Site Health is useful as the first stop in any troubleshooting order because it surfaces facts about the environment (the PHP version, the memory limit, the upload limits) before you guess at a cause. Nothing on either tab is editable from that screen, so it is a diagnostic reading, not a settings panel. The performance and memory values it reports are the same ones you would adjust with the constants covered in the wp-config advanced constants reference.

Read the Status tab

The Status tab opens with an overall score and a headline: the site is either in good shape or it is not. Below that sit the individual checks, colour-coded and grouped into performance and security sections. Read the ones that are failing before anything else.

A recommended or critical check is a description of a concrete state: a PHP version that is too old, a directory that is not writable, a loopback request that failed, or a plugin that is out of date. Each failing check links to the setting or plugin behind it, so the fix path is explicit. The troubleshooting order reference explains how to prioritise these findings instead of treating every recommendation as equal.

Two checks deserve weight because they are common false-negative sources. A failed loopback or REST availability check often explains why site features that rely on background HTTP calls stop silently; the wp-cron troubleshooting article digs into that symptom. An out-of-date PHP version or memory-limit finding is worth acting on even when the site loads fine, because it only fails under load. The memory limit article covers the fix.

Copy and share the Info tab

When you need a developer or host to diagnose an issue, the Info tab is the exact payload to send. Expand the sections to confirm the details if you want, then click Copy site info to clipboard, paste into a plain text file, and attach it to the support request. The export is designed to be shared: it strips the most sensitive private values such as the database password before it is copied, so it is safe to paste into a forum or support ticket.

Include the Site Health export alongside the error itself. A 500 page or plugin conflict is far easier to debug with the environment already attached, because a version mismatch or a stale constant in the export is often the actual cause. The debugging sequence in the troubleshooting guide recommends capturing the export at the start, before any change, so you have a clean baseline to compare against after a fix.

Site Health is a diagnostic surface, not a fixer. It tells you what to look at and shares the facts cleanly, and the articles it links to (the wp-config constants, the performance settings, and the cron guide) are where the actual repairs happen.