WordPress AI Agent: What It Can Safely Automate on Your Sites

Which WordPress jobs are worth handing to an agent?

The repetitive ones with a clear right answer and a way back. An agent moves the checking, not the deciding.

Weighing this against paying someone monthly? My guide on website maintenance cost covers the labor and the vendor bills.

How do you connect an agent without handing over an admin login?

Give it the narrowest credential that does the job, so the limit is a permission rather than a line in a prompt.

The obvious route is a WordPress application password, added in WordPress 5.6. It authenticates REST API requests with Basic authentication over HTTPS and is revoked from the user's profile without changing the password. One limit decides how you use it: an application password inherits the user's full capabilities. The application passwords integration guide says scoping is expected in future versions, so one issued for an administrator is, today, an administrator.

A connector plugin is worth the extra work, because you choose the surface instead of inheriting it. The pattern I build to: every request carries an HMAC-SHA256 signature over the body and a timestamp, anything outside a five-minute window is rejected, recent request identifiers are remembered so a captured call cannot be replayed, there is a read-only switch, and it answers only from an IP allow-list. WooCommerce uses the same idea for outgoing calls, as its webhooks documentation describes: a secret generates a hash of the payload, sent in the headers. SSH and SFTP are the last resort, granting the whole account with no capability system at all.

Whichever you pick, the model never holds the credential: the agent holds it, the model sees the output of a tool call. My guide to MCP covers that boundary. Then set DISALLOW_FILE_EDIT to true, which the WordPress hardening page recommends to stop PHP files being edited from the dashboard.

How do you automate updates so a bad one undoes itself?

Snapshot, update one thing, check the site, restore when the check fails. WordPress already does part of this, and knowing which part saves you from trusting the wrong half.

Since WordPress 6.3, a failed manual plugin or theme update restores itself. The announcement, New in 6.3: Rollback for failed manual plugin and theme updates, says the old copy moves to wp-content/upgrade-temp-backup/plugins/PLUGINNAME and returns if anything gives a WP_Error from WP_Upgrader::install_package(). Its limit is stated plainly: that folder is not a way back after an update that succeeded, and it empties as soon as the update finishes.

That leaves the case that hurts, an update installing cleanly and then throwing a fatal error. The Rollback Auto-Update merge proposal of 19 April 2024 describes the fix for plugin auto-updates: a loopback request to the home page, the previous version restored and a notice to the site's administration email when a fatal error appears. It was written for the WordPress 6.6 cycle, and I could not confirm it landed in core, so treat it as a proposal and keep your own snapshot.

Core's defaults sit in two constants, documented under Configuring Automatic Background Updates on the upgrading handbook page: WP_AUTO_UPDATE_CORE takes true, false or 'minor', and AUTOMATIC_UPDATER_DISABLED turns everything off.

The check afterwards is the part people skip, and a home page returning 200 is not proof. On a shop, request a product page and the cart, compare the response codes against the previous run, and read the error log for new fatal errors.

How does an agent triage a PHP error to a plugin and line?

By reading the log WordPress already writes and grouping it, which is dull work and exactly what software is for.

Turn logging on in wp-config.php the way the debugging documentation sets it out: WP_DEBUG true, WP_DEBUG_LOG true and WP_DEBUG_DISPLAY false, so visitors never see the errors. The log lands at wp-content/debug.log, and that constant also accepts a path somewhere less public. Every line carries a file path and a line number, and the folder in that path names the owner. Group by plugin, file and line, then count: a thousand entries collapse into five problems with an owner each.

WordPress hands over a second signal. Fatal error protection has shipped since WordPress 5.2, and as the recovery mode announcement explains, the site shows a technical difficulties page and emails the administrator a secret link. Following it pauses the broken plugin or theme for that one client, and an admin notice names which extensions are paused and what the errors are. Route that email where the agent reads. Do not define WP_DISABLE_FATAL_ERROR_HANDLER to make an agent's life simpler: that turns off the protection to improve the reporting.

Then work in the order a careful person works in:

1. Prove the files are official. wp core verify-checksums compares the install against the WordPress.org checksums and prints lines such as Warning: File doesn't verify against checksum: wp-includes/version.php. wp plugin verify-checksums --all uses the same wordpress.org checksums for plugins, so paid plugins are outside its reach.
2. Try the cheap fixes. Update the plugin, roll it back, or deactivate it if it is taking the site down. All three reverse in seconds.
3. Only then look at code. A model can read the trace and propose a patch, and that patch is a proposal.

Which WooCommerce checks can run unattended?

The read-only ones, and they catch more money than anything else here. The order statuses documentation gives each status a precise meaning, and two of them are where revenue goes quiet.

Webhooks need their own alert because they fail quietly. The webhooks documentation states that WooCommerce disables one automatically after more than five consecutive delivery failures, counting any response that is not a 2xx, 301 or 302. Records sit under WooCommerce > Status > Logs, filtered to webhooks-delivery. A disabled webhook means your fulfillment, accounting or CRM system has stopped hearing about orders, and nothing on the site says so.

Why does an AI code fix still need a human review?

Because a language model produces plausible code by construction, and plausible is not correct for your site. Three failure shapes keep coming back.

• The fix edits a file inside a plugin. The next update overwrites it, and meanwhile that file fails its checksum, so your integrity check cries wolf daily.
• The fix silences the symptom. A suppressed warning cleans the log and lets the empty value travel into an order total.
• The fix is right in general and wrong here. A hook two other plugins use, a template override you forgot, a cache layer the model never saw.

There is a security reason too. Site content is written by strangers: comments, form submissions, order notes, plugin readme files. If a model reading that text can also call tools, someone can try to write instructions into it. The OWASP Generative AI project files this under Excessive Agency, and recommends that you "Utilize human-in-the-loop control to require a human to approve high-impact actions before they are taken".

So one rule never moves. A fix a person wrote and reviewed can carry a policy, including a timer that approves it if nobody objects. A fix the model composed this morning is always-ask, with no timer, and it goes to a staging copy first. The same instinct applies to code an assistant writes for you by hand, which I covered in vibe coding security.

What should never be automated on a WordPress or WooCommerce site?

Money, access, and anything you cannot undo in minutes. Refunds head the list, and WooCommerce's own documentation shows why the mistake is easy.

In words: if the action touches money or payment settings, a person does it. If it cannot be undone within minutes, it always asks. If the agent cannot prove afterwards that the fix worked, it reports instead of acting. What is left runs automatically when a person wrote and reviewed the fix, and always waits for a person when the model proposed it.

The WooCommerce refunds documentation separates an automatic refund, which returns the money through the original payment method, from a manual refund, which only records it. It then warns that "Directly changing an order's status to Canceled or Refunded will not automatically refund your customer." Two expensive errors live in that gap: a customer marked refunded who is never paid, and a customer paid twice.