A WordPress Site with AI: Five Ways and the Knowledge Each Needs

How do you build a WordPress site with AI? There are several ways: from copy-pasting code out of a chat to an agent that logs into the server over SSH on its own and manages content through MCP. The further you go, the more the agent can do, and the more you need to know so it doesn’t make things worse. Below, these ways in order.

WordPress or an AI site builder: why WordPress

You can build a site in a native AI site builder, or you can build it on WordPress. I’m always on the side of WordPress, for three reasons.

Control. It’s entirely yours. It’s hosted on your server or your hosting, and you have full control over the data, the database, the code and everything else. Any feature you can think of can be built on top. It’s only a question of developer time, and these days more and more of AI agent tokens. Some builders let you export the code, but that doesn’t replace the rest.
It’s a ready-made CMS. Code lives separately and content lives separately, in the database. A person who doesn’t know code can work with the content in the admin panel. Later in this story that becomes the key point.
Ecosystem. Plugins, WooCommerce, integrations with payment providers, delivery services and CRMs. No need to reinvent everything from scratch.

But you pay for this freedom. The server, updates, security, PHP and WordPress vulnerabilities are now on you, not on a platform. AI doesn’t cancel that. So the main question isn’t “can AI build a site”, it’s “what do you need to know so AI doesn’t make things worse for you”. More on that below.

First there was chat

Before agents, there was just chat. As a developer (like any other developer), I asked ChatGPT, Claude or something else to write a single function. I worked out all the logic myself: I said exactly what the function receives as input, what it should return and how it should work. AI just wrote that code.

Then I assembled these pieces into one whole: a plugin, a theme or something else. Files or functions were copied one by one and uploaded to the server over FTP. That’s the first way.

Here AI only sees what you showed it in the chat. You need minimal knowledge, but everything is done by hand: you decide what to ask for, and you carry every file to the server yourself. Content too: it had to be filled in manually or imported.

An AI agent for WordPress over SSH: it sees the code

To make your work easier, you can run an agent. Now it no longer waits for you to show it a file, it sees the whole codebase of the site. But here you already need deeper knowledge, and there are two roads.

An agent on the remote server over SSH (way 2). You need to know SSH, server and key setup, and the security of all of that. The cost of a mistake is higher too: it lands right on the live site.
An agent locally on your computer (way 3). You deploy a copy of the site, work on it, and then pass the changes to the server by some method. Here you need to know both SSH and git so the code stays in sync. It’s safer because the live site isn’t touched, but there’s extra hassle: the local copy has to match the server.

What you need to know here:

SSH and keys. A key pair instead of a password, key-only access, a separate user for the agent without root, and an understanding of what exactly it can run on the server.
The server. The web server (Nginx or Apache), PHP-FPM and the PHP version, file permissions and owners, logs. Without logs you can’t tell why the site suddenly returns a 500 after the agent’s changes.
git. A repository, branches, commits, so any change can be rolled back. .gitignore, so that wp-config.php, passwords and uploaded files don’t end up in the repository. Plus how exactly the code gets from the local copy to the server.
WordPress itself. Theme and plugin structure, child themes, hooks and filters, why you shouldn’t edit the core or other people’s plugins (everything disappears after an update), WP-CLI.
Cloudflare. DNS and cache, so you can tell whether you’re looking at a fresh result or an old one.
PHP and WordPress security. Typical vulnerabilities and the ability to read the code the agent wrote instead of just believing that it “works”.

So here you already need specialized knowledge. There’s one more limit: the agent sees the code, but not the content. It can write a plugin, but pages, texts and images you have to add yourself.

WordPress MCP: the agent sees the content too

Now the most important part. Before, the code was ready and the content had to be filled in. A site always consists of two layers: the codebase and the database with all the content. Before MCP servers, an AI agent only saw the first layer. No matter how much it coded, the content had to be filled in manually or imported. MCP gives the agent access to the second layer too.

Today you can build a custom MCP for any WordPress site and give it exactly the capabilities you need. This is no longer a niche: the Abilities API has been part of WordPress core since version 6.9, and it’s where plugins and themes describe what exactly they can do (WordPress Core Blog). To expose those abilities to AI agents there’s the official MCP Adapter, which is a separate plugin rather than part of core (WordPress Developer Blog, WordPress/mcp-adapter). In other words, you decide what exactly the agent can do with the site.

Right in the chat (in Claude, ChatGPT or Cursor) you can simply tell the agent what to do: which post to create, in what status (draft or published), with what content. You can even ask it to generate a thumbnail and write alt text for it.

There are two options:

MCP locally (way 4): in the AI chat you use on your own computer.
MCP locally and remotely (way 5): plus an agent running on the remote server with the same MCP, plus local git.

Here it all is together:

Way	What AI sees	What you need to know	Main risk
0. AI site builder	only what the platform allows	nothing	platform lock-in
1. Chat + FTP	only what you showed in the chat	PHP and WordPress basics, FTP	mistakes in manual copying
2. Agent over SSH	code on the server	SSH, keys, security	a mistake lands on the live site
3. Agent on a local copy + git	code of the local copy	git, SSH, deploying a copy	the copy drifts from the server
4. SSH + MCP locally	code and content (through MCP in your chat)	the above + MCP, user permissions	the agent can change content
5. SSH + MCP locally and remotely + git	the same, plus an agent on the server with the same MCP	everything above + staging, backups, rollback	maximum autonomy, the most expensive mistake

WordPress security with an AI agent: what keeps it manageable

The higher you go up the ladder, the more the agent sees and can do, and the more expensive its mistake becomes. That’s why you need insurance.

Staging. You can work locally on your own computer, or you can keep both staging and production on a remote server. The point is the same: the agent does everything on a copy of the site, and only what has been checked reaches the live one. Staging is a separate subdomain or directory with its own database, closed to indexing and ideally password-protected. When you clone the database you need to replace the site addresses (WP-CLI search-replace), otherwise staging will redirect to production. Code goes from staging to production through git, while content and settings live in the database, and git won’t carry them over, so that has to be handled separately.
Permissions and isolation. The agent must not count as an admin. For the server, that means a separate user and a separate SSH key without root and without sudo. For MCP, a separate WordPress user with a minimal role (editor or author), not an administrator. Secrets (wp-config.php, keys, passwords) are not given to the agent.
Backups and rollback. This matters especially now, and here we come back to server administration and git. Before every serious step by the agent, take a snapshot of the database and the files. Code in git, so any change can be undone. The database is restored from a dump. Without this, an agent over SSH is roulette.
Cloudflare and cache. Cloudflare may serve old HTML, and it looks like the agent changed nothing. You need to check the result bypassing the cache (for example, add a random parameter to the URL and look at the cf-cache-status header). There’s a nuance too: in my case Cloudflare did not block requests to the MCP endpoint, but security rules can, so if the connector doesn’t connect, look there too.
PHP and WordPress vulnerabilities. The agent can add vulnerable code or an unreliable plugin, and old versions of PHP and plugins are holes. Updates, PHP versions and checking what the agent added are also on you. Also don’t leave service files in the web root, for example .git or backups.

Security in code, not in the prompt

Asking an agent “don’t publish” is unreliable: a prompt can be forgotten, and the model may misread it. It’s more reliable when the dangerous action simply doesn’t exist in MCP. Your own abilities for WordPress (Abilities API) are written for a specific task, and the rules are built into the code itself. On my site it looks like this:

The status is locked. A post created through MCP is always a draft, and an attempt to set “published” or “scheduled” is rejected. A person publishes it in the admin panel.
Narrow tools instead of “do whatever you want”. There are separate abilities for changing alt text (Ukrainian and English), for SEO fields and for form messages. They can’t do anything else, so they can’t break anything outside their zone.
The result can be verified. After SEO fields are changed, the ability returns the already assembled title and description, so the agent sees what actually ended up on the page, not what it meant to write.

It’s the same principle as a separate user without admin rights, only at the level of a single action.

Another trap from practice: you can get carried away and work with two or three agents at once. ChatGPT as a regular chat, Claude locally, Cursor on the server. Each sees only its own part and easily overwrites the other’s changes. Add forgotten commits and undeployed changes, and you can lose a whole day of work and end up with nothing. The more agents, the more you need git and discipline.

Yes, that’s a lot. Want to figure all of it out yourself? Go ahead, there’s no secret here. It’s just not a “site in minutes”, like they write on landing pages.

What to ask AI for

It’s the same skill it all started with in the chat: you work out the logic yourself and say clearly what goes in, what comes out and how it should work. An agent is just faster, so a vague task costs more. AI is good at executing a clear task and worse at guessing what you meant. So here’s what works:

Say what can be touched and what can’t. Your own plugin and child theme — yes, the core and other people’s plugins — no.
Ask for verification, not “done”: what exactly changed and how to see it without the cache.
Break the task down: one step, one change that can be rolled back.
Understand what you actually want. If you don’t know what a child theme, a hook or Cloudflare cache is, you’ll ask for the wrong thing.

In the end

In the end, a client can get MCP on their phone and manage their WordPress site from it: add content through a chat with AI, or even dictate, on Claude’s free plan. No git, no SSH, no admin panel: just write in the chat which post to create and what it should contain. It becomes safe when the agent only creates drafts and a person publishes. Updates, plugins and the server stay with me.

If you want a site like that, I’ll build a simple website and set up everything needed. If you already have a site, I can take on support: updates, backups, security.

AI didn’t leave me without work, it left me without routine. I used to copy files over FTP, now I read what the agent did. The knowledge didn’t go anywhere, it just moved from “writing” to “checking”: the agent writes fast and confidently, and the question “why did it do that” is still mine to ask.

FAQ

Can you build a WordPress site with AI without any knowledge?

A simple site, yes. But the more autonomy you give the agent, the more you need to understand about servers, git and security. Without that, you won’t even notice the agent’s mistake.

WordPress or an AI site builder: which to choose?

A builder is faster to start and requires nothing. WordPress gives you control over the code, data and server, plus the plugin ecosystem, but administration becomes your job.

What is WordPress MCP?

It’s a way to give an AI agent access not only to the site’s code but also to its content: creating posts, setting status, adding images. You decide exactly what it’s allowed to do.