How to Connect WordPress to AI (And Why It Can't Build You a Site)

TL;DR#

You can connect WordPress to AI today, in about five minutes, with no plugins. Create an Application Password under Users → Profile, save it locally, and an agent like Claude Code can hit the WordPress REST API directly.

What works well:

• Creating and editing posts and pages, including full Gutenberg layouts like hero sections and CTA rows
• Bulk content edits — metadata across 200 posts, sitewide copy changes, category restructuring
• Media uploads, menus, comments, and site settings like setting a static front page

The big gap: you can't say "build me a dentist's website" and walk away. In Next.js, an agent scaffolds an entire site from nothing — routes, components, styling — because the site is the code. In WordPress the site is state in a MySQL database, spread across theme options, page-builder blobs, and plugin settings. There's no text representation of a finished WordPress site for an agent to write. So AI is genuinely great at editing WordPress and genuinely bad at building it.

The smaller limits:

• No PHP or theme code through the REST API — by design. Workaround: SFTP or SSH from your host, then the agent edits files directly.
• No site-wide CSS on classic themes like Kadence, Astra, GeneratePress, or Divi. Workaround: per-page CSS works through the API today; site-wide needs file access.
• No visual judgement. It edits what you describe. Taste is still your job.
• It doesn't know what to fix. A non-issue solo — you already know what's broken. A real problem when the instructions come from someone else.

If the instructions come from clients, that last one is where the hours go: reading "the button looks weird on mobile" and working out which button, which page, which breakpoint. Tools like Simple Commenter make it arrive as structured data — element, screenshot, URL — that an agent can read through MCP. Narrow fit, not a fix for anything above it. Skip that section if you work alone.

The rest of this post is the detail behind each point.

The setup everyone is trying right now#

Every WordPress agency I talk to is running the same experiment. They've got Claude Code or Cursor open in one window, a client site in another, and they're trying to work out how much of the boring work an AI agent can actually take off their plate.

The honest answer is: more than you'd think, and less than the demos suggest.

This guide covers both halves. First, the setup that genuinely works — how to give an AI agent real, controlled access to a WordPress site in about five minutes, no plugins required. Then the part nobody writes about: the gap that opens up the moment you try to use it on real client work.

Part 1: Giving an AI agent access to WordPress#

WordPress ships with a REST API and an authentication method called Application Passwords. Together they're all you need. No plugin, no marketplace, no third-party middleman holding your credentials.

An Application Password is a revocable, API-only credential tied to a single WordPress user. It can't be used to log into wp-admin through the browser login form, and you can revoke it in one click without touching your real password. That distinction matters, and it's why this is the right way to do it.

Step 1: Create the Application Password#

In wp-admin, go to Users → Profile, scroll to the bottom, and find the Application Passwords section. Give it a name like Claude Code and click add. WordPress shows you the password exactly once — something like abcd efgh ijkl mnop qrst uvwx. Copy it now.

Two things that trip people up here:

• Your site must be on HTTPS. WordPress disables Application Passwords on plain HTTP. If the section is missing, check this first.
• A security plugin may be hiding it. Wordfence and similar tools disable the feature by default in some configurations. It's a toggle in their settings.

Step 2: Store the credentials outside the chat window#

Don't paste the password into a chat, a Slack message, or an email. Save it to a local file your agent can read. On macOS or Linux, create ~/.wp-credentials:

WP_URL="https://clientsite.com"
WP_USER="your-wordpress-username"
WP_APP_PASSWORD="abcd efgh ijkl mnop qrst uvwx"

Keep the quotes. The password contains spaces, and without quotes your shell will silently mangle it — this costs people twenty minutes more often than it should. Then lock the file down:

chmod 600 ~/.wp-credentials

Step 3: Verify it works#

source ~/.wp-credentials
curl -s -u "$WP_USER:$WP_APP_PASSWORD" "$WP_URL/wp-json/wp/v2/users/me"

A JSON blob with your username and roles means you're connected. From here your agent can create and edit posts and pages, upload media, manage categories and comments, and change site settings — including building full Gutenberg block layouts like hero sections, button rows, and column grids.

If you get a 404 page instead of JSON, your site is using plain permalinks. Either switch to Post name under Settings → Permalinks, or use the alternate URL format:

curl -s -u "$WP_USER:$WP_APP_PASSWORD" \
  "$WP_URL/?rest_route=/wp/v2/users/me"

A note on scoping access#

Give the agent an Editor role rather than Administrator when you can. Editors can do everything content-related and nothing account-related. Create a separate Application Password for each tool and each person, so you can revoke one without breaking the others. If a credential leaks, revoking takes thirty seconds and doesn't touch your login.

What this setup actually gets you#

Real things, to be clear about it:

• Content at speed. "Draft five location pages using this template" is a two-minute job instead of an afternoon.
• Bulk edits without a plugin. Fixing metadata across 200 posts, updating a phone number sitewide, restructuring a category tree.
• Page building. Gutenberg blocks are just structured markup. An agent can write a full hero section, features grid, and CTA row into a page, and it stays fully editable in the block editor afterwards.
• Site config. Setting a static front page, adjusting reading settings, managing menus.

That's genuinely useful, and if you stop reading here you'll still get value out of the afternoon.

Part 2: The gap — AI can't build WordPress sites the way it builds Next.js sites#

Here's the thing nobody says out loud.

Open Claude Code in an empty folder and type "build me a landing page for a dental clinic with a booking form and a services section." In Next.js, you get one. Actual files, actual components, actual routing, running on localhost in about a minute. The agent writes code, runs the dev server, reads the errors, fixes them, and iterates until it works. You review a diff.

Now try the same sentence pointed at a WordPress install. It falls apart immediately, and not because the model isn't smart enough.

Why the same prompt works in one and not the other#

In Next.js, the website is the code. Every part of it — layout, styling, content, routing, behaviour — lives in text files in a folder. That's the entire reason agents are good at it. An agent can read the whole project, write to any part of it, run it, and see what broke. One source of truth, fully readable, fully writable, with a feedback loop that closes in seconds.

In WordPress, the website is state in a database. Content sits in wp_posts. Layout might be Gutenberg block markup (text, fine) or a serialized Elementor blob in post meta (effectively opaque). Design lives in theme options and Customizer settings in wp_options. Functionality is spread across the settings tables of fifteen plugins. Your theme's actual appearance is the product of a hundred toggles somebody clicked in an admin UI.

There is no file an agent can open that represents "this website." There's no diff to review. There's no npm run dev that reveals what broke. The agent is reaching into a running database through a keyhole.

Page builders make it worse. Elementor, Divi, and WPBakery store layouts as serialized PHP or nested JSON — machine-generated structures with internal IDs and widget schemas that were never meant to be hand-authored. An agent can technically write Elementor JSON. It will be wrong, and you'll spend longer fixing it than building the page yourself.

So the practical split looks like this:

• Building a site from scratch: Next.js yes, WordPress no
• Editing existing content: both, easily
• Iterating on design: Next.js yes, WordPress only if you're on a block theme or writing raw CSS
• Reviewing what changed: Next.js gives you a git diff, WordPress gives you a database you have to go look at

This is why "I connected AI to my WordPress site" experiments so often end in a shrug. The connection works perfectly. It's just that WordPress was designed for humans clicking in an admin panel, and agents are good at exactly the thing WordPress doesn't have — a codebase.

The practical read: use AI to edit and populate WordPress, not to build it. Build the structure yourself, the way you always have, then hand the agent the content and the tweaks. That plays to what the setup in Part 1 is genuinely good at.

Everything below is a consequence of the same root cause.

Code is off-limits through the REST API#

The REST API gives an agent write access to content. It does not give it access to code. PHP functions, functions.php, theme templates, custom post type registration, hooks and filters — none of it is reachable, and that's a deliberate security decision by WordPress, not an oversight. An API credential that could execute arbitrary PHP would be a catastrophic thing to leak.

Your options, in the order I'd actually try them:

• SFTP or SSH from your host. This is the real answer. Ask support for "SFTP credentials" and you'll usually have them the same day. Now the agent edits theme files, builds a child theme, or writes a small custom plugin, and a syntax error is fixable in seconds because it can just edit the file again.
• A code snippets plugin like WPCode or Code Snippets. Good for one-off functions and shortcodes, and each snippet can be deactivated individually if it breaks something — which makes it safer than raw file editing. The catch is you're managing PHP inside a database table instead of in version control.
• The Theme File Editor in wp-admin. Technically works. Don't. A PHP syntax error there white-screens the site, and recovering needs the file access you were trying to avoid.

Site-wide CSS has the same wall#

The Customizer's Additional CSS panel isn't exposed to the REST API on classic themes. Kadence, Astra, GeneratePress, Divi — the themes most agencies actually build on — all leave you reaching for file access or a plugin.

What does work through the API today is per-page CSS: an agent can drop a scoped style block into a single page's content. That covers a surprising amount of real work, like hiding a theme's page-title banner on one landing page. Site-wide still needs SFTP or a snippets plugin.

It can't see#

An agent can't tell that your spacing is inconsistent or that the hero looks cramped on a laptop. It edits what you describe to it. Screenshot-capable models help, but you're still the one deciding something looks wrong. There's no workaround here, and anyone selling you one is overselling.

So the honest ceiling:

• Content: fully automatable today
• Per-page CSS: yes, through page content
• Site-wide CSS and PHP: needs SFTP or SSH
• Taste: still yours

And it doesn't know what to fix#

This one is different from the others, because whether it's a problem at all depends on how you work.

An agent can edit any page on the site. It has no idea which page needs editing, or why. If you're working solo, that's a non-issue — you already know what's broken, so you open the terminal and say it. The loop is short because you're both ends of it.

It becomes a real problem when the instructions come from somebody else. An email that says "the button looks weird on mobile." A WhatsApp voice note. A PDF with a red circle drawn on a screenshot. Twelve items buried in one paragraph, half of which contradict each other.

Then you're the translation layer. You read "the button on the top right," work out which of the four top-right buttons they mean, on which page, at which breakpoint — and only then do you get to the part you just automated. Connecting WordPress to AI speeds up the fixing. It does nothing for the translating.

If that's not your situation, you're done — everything you need is in Part 1. The next section is only for people whose input comes from clients.

Part 3: If your instructions come from clients#

The translating problem isn't solved by a better agent or a smarter prompt. It's solved by changing the format feedback arrives in, so it lands as structured data instead of prose in an inbox.

That means whatever tool you use should capture, at minimum: which element, which page, what it looked like on screen. Any tool that does that can feed an agent. Simple Commenter is the one I build, so it's the one I can show you end to end — but the pattern matters more than the product, and it's worth reading that way.

Step 1: Let the client point at the thing#

Simple Commenter puts a lightweight widget on your WordPress site. Your client opens the page, clicks the element they want changed, and types what they want. No account, no signup, no browser extension.

That's the whole design premise. The moment you ask a non-technical client to create an account before they can tell you the logo is too big, you've lost a week. Removing the login step is the single biggest thing you can do to shorten a review cycle — and it happens to be the same thing that makes the output machine-readable.

Every comment carries context automatically:

• The exact DOM element, captured as an XPath
• The page URL and click coordinates
• A screenshot of what the reviewer was looking at
• Browser and screen size
• Threaded replies, so a follow-up stays attached to the original note

Because it's a real WordPress plugin rather than a script tag wearing a plugin badge, you manage comments, replies, members, and settings inside WP admin.

Step 2: Hand the feedback to your agent#

This is where the two halves connect. Simple Commenter ships a native MCP server, published on npm as @simple-commenter/mcp-server. MCP is the open protocol AI agents use to talk to outside tools — Claude Code, Cursor, and most modern agents support it.

Setup is one command:

npx @simple-commenter/mcp-server init

The wizard authenticates you with a six-digit code, lets you pick a project, and writes an .mcp.json into your project root. Restart your AI tool and it's connected. If anything looks off:

npx @simple-commenter/mcp-server doctor

The server exposes five tools to the agent:

• list_projects — every site in your account
• list_comments — filtered by status, priority, page, or search term
• get_comment — full detail, including the element XPath, screenshot, click position, and replies
• update_comment_status — move an item to in progress or done
• reply_to_comment — write back what you found and fixed

Step 3: Let it run#

Now the workflow you actually wanted is possible. You open Claude Code and type:

"Check Simple Commenter for open feedback and fix the issues."

The agent calls list_projects to find the site, pulls open comments with list_comments, and reads each one with get_comment — so it sees the exact element, the screenshot, and the page URL rather than a paraphrase of them. It marks items in progress, makes the fixes, replies with what it changed, and marks them done.

Your client sees their comments getting answered and resolved in the same widget where they left them. Nobody had to translate anything.

The shape is: client points at the problem → structured comment with full context → agent reads it through MCP → agent fixes it through the REST API or your codebase → agent replies and resolves. Note what this is and isn't. It's a way to skip the translating step on revision rounds. It doesn't make WordPress buildable by AI, and it won't help you at all if you're the one writing the tickets.

What to do with this#

Realistically, in order:

1. Set up the Application Password. Five minutes, no plugins, works on any HTTPS WordPress site. Worth having on its own, whatever else you do.
2. Get SFTP or SSH from your host if you touch code at all. This is the single biggest upgrade to what an agent can do for you, and it costs one support ticket.
3. Adjust what you're asking for. Build structure by hand; hand the agent content, copy, bulk edits, and tweaks. That's where it's genuinely faster than you, and where it stops being a novelty.
4. Only if your work is client-driven, make feedback arrive as structured data and wire it in. Run one real revision round through it before deciding.

One caution worth taking seriously: keep the agent on drafts and staging while you're building trust in it. Review before you publish. These agents are genuinely good now, but "genuinely good" is not "unsupervised on a client's live site."

And if you find yourself fighting WordPress to get an agent to build something from scratch — that's not a prompting problem, and there's no clever wording that fixes it. WordPress is a database with an admin panel, and agents are built for codebases. Use each for what it's actually good at.