WP Site Health Auditor

When to Use This Skill

• The user pastes a WordPress Site Health report (Tools > Site Health), as text or screenshot
• The user pastes raw Site Health debug info (Tools > Site Health > Info) and asks what's wrong
• The user mentions "site health", "recommended improvements," or "critical issues" for a WordPress site
• The user asks to clean up, harden, or speed up a WP install based on that screen

Turns a WordPress Site Health report (Critical issues / Recommended improvements / Passed tests) into a prioritized, risk-tiered fix plan — then executes the safe fixes and hands off the rest with exact commands or code.

⚠️ Safety — read before touching any file

This skill edits wp-config.php, .htaccess, and php.ini-equivalent settings, and deletes plugins and themes. All three are one bad edit away from a white-screen-of-death or a broken upload path. Never skip this section, even for a one-line change, even if the user is in a hurry.

Before any edit or deletion, in this order:

1. Back up the specific file(s) you're about to touch outside the web root, not just "have a backup somewhere":

   umask 077
   backup_dir="../wp-site-health-backups/$(date +%Y%m%d-%H%M%S)"
   mkdir -p "$backup_dir"
   cp -p wp-config.php "$backup_dir/wp-config.php"
   cp -p .htaccess "$backup_dir/.htaccess"
   

   If shell access isn't available, tell the user to download the current file via SFTP/host file manager first, and don't proceed until they confirm they have it.
2. Confirm a full site/database backup exists before deleting any plugin or theme, or running wp search-replace. If the user doesn't have one and has a backup plugin active (UpdraftPlus, etc.), trigger a backup first: wp updraftplus backup or the plugin's own WP-CLI command, or tell them to click "Backup Now" and wait for confirmation before continuing.
3. Never run wp search-replace without --dry-run first, and always show the dry-run output to the user before running it for real. This command rewrites the database in place — a wrong pattern can corrupt serialized data across every table it touches.
4. After any PHP file edit, lint it before reloading the site:

   php -l wp-config.php
   

   For .htaccess changes, run apachectl configtest if available, or check the site immediately. A syntax error in wp-config.php takes the entire site down immediately. Do not skip the lint check to save a step.
5. Change one thing at a time, then verify the site still loads (homepage + wp-admin) before making the next change. Don't batch multiple Tier 2 file edits into one pass — if something breaks, you want to know which change did it.
6. Give the user the exact rollback command alongside every edit:

   cp ../wp-site-health-backups/<timestamp>/wp-config.php wp-config.php
   

   State this even if nothing goes wrong — it costs one line and saves a panicked user later.

If the user says "just do it, skip the backup" — still create the backup silently as part of the edit sequence and tell them you did. Refuse to skip step 1 or step 4 entirely; those two are non-negotiable regardless of urgency, since the failure mode (corrupted wp-config.php, dead site) is worse than the ten seconds a backup costs.

Overview

The Site Health screen is diagnostic, not prescriptive. It tells the site owner that something is wrong (e.g. "you should use a persistent object cache") but not how to fix it, and it mixes items that are one-click-safe (deactivate a plugin) with items that require host-level changes (php.ini, object cache backend) or are purely informational (SQL server version — no action needed). This skill sorts that out — safely.

Phase 1 — Parse the report

Input is usually one of:

• Pasted plain text copied from Tools > Site Health (Status tab)
• Pasted plain text from Tools > Site Health > Info (the debug data export)
• A screenshot of the Status tab
• WP-CLI output (wp site-health check is not a core command; note that up front, don't invent one — see Phase 4)

Extract three buckets exactly as WordPress labels them:

1. Critical issues (red) — always fix first, always confirm before touching.
2. Recommended improvements (yellow) — the bulk of real work; triage by risk tier below.
3. Passed tests (green) — skip. Do not "fix" or re-verify passed tests unless the user asks. Do not

…