How to let Claude fix a WordPress white screen (without giving it the server)

"There has been a critical error on this website." Every agency knows the message, and it always shows up at the worst time: right after a plugin update, a theme tweak, or a "small" change in functions.php.

AI assistants like Claude are now good at reading a PHP stack trace and finding the line that broke. The hard part is giving the AI access to a broken site without giving it the keys to the server.

Here is the setup I use, and why the place where your AI tool runs matters more than which model you pick.

Why a plugin can't fix a white screen

Most WordPress AI connectors (MCP servers) are plugins. They run inside WordPress, which is great for creating posts or managing WooCommerce products.

But when WordPress dies with a fatal error, every plugin dies with it, including the one your AI uses to talk to the site. The connector is down exactly when you need it.

To repair a site that won't boot, the AI has to work from outside WordPress: on the files, and through WP-CLI.

The safe way: files + WP-CLI, with guardrails

Giving Claude plain SSH works, but it is a bad idea on client sites. One misunderstood instruction and it can run rm -rf, read wp-config.php (your database password ends up in a chat log), or "fix" things you never asked it to touch.

What you want instead is a small set of fixed tools:

• Read and search theme and plugin files, never secrets (wp-config.php, .env, SQL dumps, keys)
• Edit with a backup of every file, and one-call undo
• A PHP syntax check before anything is saved
• WP-CLI from an allow-list (plugin deactivate yes, eval and db drop no)
• An audit log of every call

I built PressBridge for this: a self-hosted MCP server that runs next to your sites and gives Claude exactly those tools, nothing else.

Fixing a white screen, step by step

With the site connected, this is the whole conversation:

You: acme shows "There has been a critical error". Find out why and fix it.

In a typical session, Claude then:

1. Runs check_site_health: the home page answers HTTP 500, and WP-CLI can't load WordPress. The fatal error points to a file in one plugin, say wp-content/plugins/some-plugin/includes/class-x.php, line 212.
2. Reads that file and the plugin version (wp plugin list), and sees the plugin was updated an hour ago.
3. Deactivates the plugin (wp plugin deactivate some-plugin --skip-plugins, on the Pro edition). The site is back.
4. Tells you what broke, which version, and suggests rolling back or waiting for a fix.

Claude never sees a password, and every step is in the audit log.

The part I care about most: it can't make things worse

The scariest moment with an AI on a live site is the fix that breaks something else.

Since version 1.2, PressBridge checks the site after every change Claude makes. It loads your key pages and boots WordPress through WP-CLI. If the site worked before the change and is broken after it, the change is undone on the spot (file restored, plugin deactivated, previous theme back) and Claude is told what failed.

I tested this on real WordPress with MariaDB: a change that passes php -l but crashes at runtime is rolled back automatically, and the site comes back on its own.

Try it

The free edition is read-only and enough to diagnose a white screen:

pip install pressbridge

Setup takes about ten minutes on a server you already run: install guide.

The paid editions add editing with backups, the automatic rollback, plugin and theme updates, and a nightly security watch. The Agent plan has a 14-day free trial.

If you manage client sites and try it, I'd like to hear what breaks. Comments are open.

Written with help from Claude.