Audit WordPress Site Health and Fix Critical Issues

Turns a WordPress Site Health report (Critical issues / Recommended improvements / Passed tests, from Tools > Site Health) into a prioritized, risk-tiered fix plan, executing the safe fixes directly and handing off the rest with exact commands or code.

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"

Because it edits wp-config.php, .htaccess, and php.ini-equivalent settings and deletes plugins/themes - all one bad edit away from a white screen of death - a non-negotiable safety sequence runs before any change: back up the specific file(s) outside the web root (shown above), confirm a full site/database backup exists before deleting anything or running wp search-replace, never run wp search-replace without --dry-run first (shown to the user before the real run), lint every PHP edit with php -l wp-config.php before reloading, change one thing at a time and verify the site still loads before the next change, and give the exact rollback command alongside every edit. If a user says "skip the backup," the backup still happens silently and the user is told so afterward.

Phase 1 parses the report into WordPress's own three buckets - Critical issues (always fixed first, always confirmed), Recommended improvements (triaged by risk tier), Passed tests (never "fixed" or re-verified). Phase 2 classifies every non-passed item into three risk tiers: Tier 1, safe/reversible/auto-fixable in wp-admin or WP-CLI (removing inactive plugins/themes, turning off WP_DEBUG_DISPLAY in production, fixing search-engine indexing, updating the default tagline); Tier 2, requiring host/server-level access, where the skill drafts the exact change for the user or host to apply (a permalink structure change, which requires a redirect plan and CDN/cache flush since existing URLs break without one; post_max_size/upload_max_filesize mismatches; missing persistent object cache; missing page cache; PHP version/module changes; HTTPS/SSL config; and loopback/REST API failures); and Tier 3, informational/host-dependent items with no fix needed (e.g. an already-current SQL server version notice), reported but never acted on.

Phase 3 matches each item's WordPress-generated title to a fix recipe - e.g. deleting inactive plugins/themes via wp plugin delete/wp theme delete (never the active theme's parent or the last fallback default theme); raising post_max_size above upload_max_filesize via host panel, php.ini, .htaccess, or .user.ini (never ini_set() in wp-config.php, since these are PHP_INI_PERDIR and silently fail there); enabling a persistent object cache via a Redis/Memcached drop-in plugin if the host supports it; and fixing HTTPS via wp option get siteurl/home plus a dry-run wp search-replace. Phase 4 refuses to invent a nonexistent wp site-health WP-CLI command, claim a fix is complete without confirmation, guess PHP/server values instead of asking, or skip the safety sequence for "small" changes. Phase 5's output is a scannable triage table (item, category, tier, fix summary), Tier 1 fixes executed with before/after shown, Tier 2 fixes given as exact snippets with backup/lint/rollback commands, Tier 3 items listed as informational one-liners, and a recommendation to re-run Site Health afterward.

Use it when a user pastes a WordPress Site Health report or debug info and wants it triaged and fixed, or asks to clean up/harden/speed up a WP install based on that screen. It has no shell access to the user's actual server - every command is drafted for the user or host to run - and doesn't cover multisite or WooCommerce-specific health checks, or replace a full security audit.

Input is a pasted Site Health report (Status tab text, Info debug export, or screenshot). Output is a risk-tiered triage table plus, per item, either an executed Tier 1 fix, a Tier 2 snippet with backup/lint/rollback instructions, or a Tier 3 informational note.

Built around WP-CLI (wp plugin, wp theme, wp option, wp search-replace), core WordPress config files (wp-config.php, .htaccess, .user.ini, php.ini), and caching plugins (Redis Object Cache, WP Super Cache, W3 Total Cache) for the relevant fix recipes.

WordPress site owners, agency developers, and hosting-support staff who regularly triage Site Health screens across multiple sites and want the risk-tier judgment call (auto-fix vs. draft-for-host vs. ignore) made consistently rather than re-decided from scratch each time a yellow item shows up.