AI support for WordPress hosting issues

WordPress issues

WordPress powers a large share of the sites on most hosting accounts, so it also drives a large share of the tickets. A plugin update takes a site white, a theme change throws a critical error, or the homepage suddenly reads “error establishing a database connection.” Your customer only knows that the site they had a moment ago is gone. Panelbot meets that customer in chat, works out what actually broke, and either puts it right or hands your team a clear picture of what happened.

What your customers report

The wording varies, but the underlying problems cluster into a handful of familiar shapes:

A blank white page where the site used to be (the classic white screen).
A “There has been a critical error on this website” message.
“Error establishing a database connection” shown on the site itself.
The site broke right after a plugin or theme update.
The site is stuck on a “briefly unavailable for scheduled maintenance” page long after an update finished.
The site keeps redirecting until the browser gives up.

Customers rarely know which of these applies, and they often describe two at once. Panelbot reads the message, asks for the domain if it does not already have it, and takes the guesswork off the customer.

How Panelbot looks into it

Before anything is changed, Panelbot runs a set of read-only checks. These look at the outcome a real visitor would see and at what the server reports, then match that against known WordPress failure patterns. In practice it is confirming things like: does the site respond at all, and with what kind of error; is the page genuinely blank or is it showing a specific WordPress error screen; is the database reachable; and, importantly, where the real WordPress installation lives.

That last point matters more than it sounds. Panelbot confirms it has found the real, working WordPress installation before it recommends anything, including on sites installed in a subfolder or moved between accounts. A folder that only looks like WordPress, such as the leftovers of an old or half-finished install, is reported as broken or leftover rather than called healthy, so a repair always targets the install the site actually runs on and never quietly edits the wrong directory.

None of these checks change anything. They are safe to run automatically and they give Panelbot the evidence to name a cause instead of guessing.

What it can fix, and what needs your approval

Once the cause is clear, Panelbot separates the reversible, low-risk repairs from the changes that deserve a human eye.

For common, well-understood breakage, and only when you have enabled action-taking for your account, Panelbot can offer to:

Turn off a plugin that is crashing the site so the rest comes back online.
Switch a broken theme back to a safe default so the customer can log in again.
Repair damaged WordPress core files.
Clear a leftover maintenance flag that left the site stuck after an interrupted update.
Where you have enabled restores, locate an available backup and begin a restore for approval.

These are presented as a step the customer or your team confirms, not something that happens silently. With action-taking turned off, Panelbot still works the problem all the way to a named cause and spells out the repair that would clear it, then hands the actual change to you. Higher-impact work, anything that could affect data or take the site offline further, always waits for a human to approve it. Panelbot never decides on its own that a risky change is worth the trade.

What these fixes need on your server

WordPress work reaches further into an account than a panel API call can, so check how your server is connected:

The optional agent is what runs the WordPress command line. Turning off a plugin, switching a theme, repairing core files, clearing the maintenance flag, and the other WordPress command-line repairs run through a helper that the agent installs, so they need the agent on every panel. A reseller credential cannot run them, and a root WHM token on its own cannot either, because the helper is not on a server without the agent.
WP Toolkit operations (cPanel with WP Toolkit installed), such as listing a domain’s installs, WP Toolkit backups and restores, and smart updates, go through the agent.
Finding WordPress installs across an account needs a root WHM token on cPanel, or the agent on either panel.
JetBackup restores go through the agent.
A reseller credential alone still covers the account-level checks around WordPress: the account, its databases, DNS, and certificates. Panelbot shows the capability list for each server, so you can see which of the repairs above that server can reach before a customer asks.

When a repair is out of reach on a server, Panelbot still diagnoses as far as it can, names the fix, and hands it to your team rather than attempting it.

When a human takes over

Some WordPress problems look similar on the surface but are not safe to auto-resolve, and Panelbot is deliberately conservative about them. It steps back and brings in your team when the evidence points to causes like these:

The site is out of memory, or a PHP version or extension mismatch is crashing it, rather than a single bad plugin.
The database error is not simple table damage but wrong credentials, a stopped database service, or deeper corruption a quick repair cannot touch.
A redirect loop is coming from an external proxy or SSL setting rather than a WordPress option.
The install is broken in a way that has no confidently known fix.

In each of these cases the customer hears, in plain terms, that a member of your team has been pulled in, and Panelbot forwards everything it established so your staff open the ticket already knowing what broke. This is the honest boundary: Panelbot resolves the common cases well and refuses to bluff on the rest. Escalation is not a failure mode here, it is the design.

See it in action

Real conversation flows through the widget, on a sample account under the fictional Vornalis Hosting brand. Nothing loads until you press play.