Site Doctor

What It Does

Site Doctor answers "where do I start" in one click. Press "Find what's slow" and it runs its own configuration checks alongside the measurements the other modules already own — autoload burden, database bloat, and any slow queries that have been captured — then ranks everything worst-first so you are not guessing which module to open. Every finding explains why it matters and links straight to the module that owns the fix. New installs land on this page after activation. The configuration checks verify that OPcache is enabled and healthy (hit rate, OOM restarts, key table), that an object-cache drop-in is actually engaged (a drop-in pointing at a dead Redis backend is flagged critical), that your homepage is served from a page cache (via a loopback HTTP probe), whether LiteSpeed Cache is active, and whether any enabled WooCommerce payment gateway is stuck in test/sandbox mode. Where an object cache is missing it recommends a specific one for your server — including SQLite Object Cache on shared hosting, where Redis usually is not available — rather than a generic "add Redis", and if a suitable plugin is already installed it tells you to enable that one instead of installing another. Since version 1.7.0 it also carries 21 Redis object-cache checks that read the server's running configuration instead of inferring health from a successful connect. Each finding gets a severity (ok/info/warn/critical) and a guided fix with the exact values to set. It is read-only, runs only on demand, and everything runs locally on your server.

Features

• Whole-site scan in one pass: configuration checks plus autoload burden, database bloat, and captured slow queries, all ranked worst-first
• Every finding explains why it matters and links to the module that owns the fix
• Sources that were skipped are named, so a short list of findings is never mistaken for a clean site
• Configuration checks cover OPcache health, object-cache drop-in status, page cache (loopback probe), LiteSpeed Cache detection, and WooCommerce payment gateway test-mode detection
• Object-cache recommendation is specific to your server — SQLite Object Cache on shared hosting where Redis is not available, rather than a blanket "add Redis" — and tells you to enable a suitable plugin you already have installed instead of installing a second one
• Read-only by design — the scan never changes anything; every fix is guided remediation you apply yourself
• Never runs on page load — only on an explicit "Find what's slow" click or via WP-CLI (wp multitool doctor)
• OPcache analysis: distinguishes genuinely disabled OPcache from hosts that restrict the status API (Kinsta/WP Engine style opcache.restrict_api), checks hit rate, OOM restarts, and key table saturation
• Flags object-cache.php present but not engaged (dead Redis backend) as critical — the failure that page-load checks never surface
• Vendor detection for the object-cache drop-in (Redis Object Cache, Memcached) from its file signature
• 21 Redis object-cache checks (added in 1.7.0) that talk to the server and read its running configuration — almost every Redis check in the WordPress ecosystem only asks whether the connection succeeded, a test that cannot fail the ways Redis actually fails
• Catches maxmemory-policy noeviction under a memory ceiling: once full, Redis rejects every write, so WordPress runs the query anyway and pays a round-trip on top — or the drop-in throws and the site returns HTTP 500
• Catches eviction thrashing, measured as a delta between two scans because evicted_keys is cumulative since the server booted — the first scan records a baseline and says so
• Catches a shared keyspace with no prefix, where a cache hit can return another site's data, plus salts too generic to isolate anything
• Catches load-bearing cache groups on the ignore list — options above all, which carries alloptions — so Redis is connected and paid for on every request while caching none of what would repay it
• Catches missing global groups on multisite, where keys get a per-blog prefix and one site can read another site's users and settings
• Catches round-trip latency that outweighs the database work saved: a WordPress page issues on the order of a hundred cache lookups, so latency is multiplied before anything is gained. It reports the cost and stops short of a verdict — whether the cache is still worth keeping is an A/B on your own templates
• Also checks replica role, persistence failures and fork stalls, connection churn, flush storms, memory fragmentation, hit rate, and the autoload blob against the ~1MB per-value ceiling
• Read-only and on demand only, never on a normal page load: it uses INFO, CONFIG GET, DBSIZE and one bounded SCAN, and never KEYS, which would block the server for the length of the whole keyspace
• Where a host blocks CONFIG GET (Kinsta, WP Engine and Cloudways among them) the affected checks report "cannot verify this here" and never "ok" — no data is not the same as no problem. Cluster and Sentinel are detected and skipped rather than described from one node
• The eviction-rate baseline is stored in a non-autoloaded option, not a transient: a transient would live in the very Redis being measured and be evicted by the thrashing it exists to detect
• Sites not using Redis get no Redis findings at all, rather than a list of "not applicable" rows
• Loopback cache probe reads real cache headers (x-litespeed-cache, cf-cache-status, x-cache, Age, x-varnish, x-kinsta-cache) and distinguishes HIT, MISS, and origin-rendered responses
• Probe falls back to localhost with a Host header for split-horizon DNS and Docker environments; reports "probe not possible" instead of guessing
• WooCommerce gateway check covers Stripe, PayPal, Przelewy24, PayU, Mollie, Square, Braintree, Authorize.net, and more — flags enabled gateways still in test/sandbox mode where real customers cannot pay
• Non-production host detection (.loc, .test, staging.* subdomains, localhost) automatically downgrades severities — a dev clone without a page cache is normal, not critical
• Guided fixes include exact php.ini values, computed for your server (e.g. suggested opcache.memory_consumption and max_accelerated_files)
• Scan result cached for 5 minutes in a transient — the loopback probe only runs during a scan
• Severity summary pills (critical/warning/info/ok) at the top of the results
• CLI twins: wp multitool doctor for the ranked whole-site scan, and wp multitool redis [--force] [--format=json] for the full object-cache report

How to Use

1. Open Site Doctor

   Go to WP Multitool > Site Doctor — new installs land here after activation. The page shows the last cached scan if one exists; it never triggers a scan just by loading.

2. Run a scan

   Click "Find what's slow". The module runs its configuration checks, the Redis object-cache checks where Redis is in use, and a loopback HTTP probe of your homepage, then pulls in autoload burden, database bloat and captured slow queries. Results stream back and take a few seconds.

3. Start at the top

   Findings are ranked worst-first, each as a card with a severity badge, an explanation of why it matters, and the raw data (hit rates, cache headers, Redis policy and memory figures, gateway names). Skipped sources are named, so a short list is not a clean bill of health.

4. Apply the guided fixes

   Each non-ok finding includes a concrete fix — exact php.ini directives, the redis.conf line to persist, the WP_REDIS_* constant to set, or the module that owns the problem. Site Doctor never applies changes itself.

5. Re-scan to verify

   After fixing, click "Find what's slow" again (the button always forces a fresh scan, bypassing the 5-minute cache) to confirm the finding turned green. The Redis eviction rate needs two scans a minute or more apart, because the underlying counter is cumulative — the first run only records a baseline.

FAQ

Related Modules