How to Use Claude Code and Codex to Actually Build and Edit WordPress Websites

There is a big difference between asking AI to write some HTML for a WordPress website and actually giving it enough access to work on the website.

The first one is easy. You ask Claude Code or Codex for a section, copy the code, paste it somewhere, and spend the next half hour trying to make it behave properly inside WordPress.

The second approach is much more interesting.

With the right setup, AI can work directly with WordPress, create pages, change existing pages, build Elementor layouts, work with templates and, when you give it deeper server access, install plugins, modify theme files and use WP-CLI.

The trick is understanding that these are not all the same kind of access.

There is a tendency to talk about an “AI connection to WordPress” as though there is one button that gives Claude or Codex control over everything. There isn't. WordPress has several different layers, and the method you use determines what the AI can actually touch.

Once you understand those layers, the whole thing becomes much less confusing.

The simple starting point: WordPress REST API

WordPress already has a REST API.

You can think of it as a way for another application to communicate with the WordPress website over HTTP. It can read and modify WordPress data, provided the request is properly authenticated and the user has the required permissions.

WordPress also has Application Passwords specifically for this kind of integration. They are separate credentials from the user's normal WordPress login password, are intended for API authentication, and can be individually revoked. WordPress recommends using them over HTTPS.

For someone who is not technical, the important distinction is simple: an Application Password does not give AI some special new powers.

It identifies the AI connection as a particular WordPress user.

The permissions come from that WordPress user.

That means you should think carefully about which account you connect. If you give the Application Password to an administrator account, the AI connection inherits the capabilities available to that account. A dedicated account with only the permissions it actually needs is a much better setup for an ongoing integration.

You can also create separate Application Passwords for different integrations and revoke them individually when they are no longer needed.

That is the basic door into WordPress.

But there is a catch.

REST API access is not the same thing as full website development

The native REST API is excellent for working with WordPress data.

You can create and edit pages and posts, upload media and work with other resources exposed through the API. But the native API is not a remote file manager for your server.

That distinction becomes important as soon as you start talking about themes.

If you tell Claude Code, “Open functions.php and change this function,” the normal WordPress REST API does not suddenly give it access to that file. Theme PHP, CSS and other files live on the server's filesystem rather than being ordinary page content exposed through the standard REST endpoints.

The same distinction is important with Elementor.

Elementor pages are not simply a block of HTML sitting inside the normal WordPress page content field. Elementor has its own structured data and editor system. So the idea that you can connect Claude Code to the basic REST API and then tell it to change an Elementor heading from blue to red is too simplistic.

You need an integration that actually understands and exposes Elementor's editing system.

That is where things have changed considerably.

Elementor now has an official route for Claude Code and Codex

Elementor now provides an official MCP integration that connects external AI clients such as Claude Code and Codex directly to Elementor.

This is much closer to what people actually mean when they say they want AI to “design the WordPress site.”

Instead of generating a random piece of code for you to paste into Elementor, the AI can work with native Elementor structures. Elementor's current documentation describes the MCP connection as allowing AI tools to build and edit pages, work with Elementor elements, use the site's design system and update site structures directly.

The setup is also considerably simpler than building your own REST integration.

Inside WordPress, you enable Elementor MCP, choose the AI client you want to connect, generate the setup prompt and provide that connection to Claude Code or Codex. Elementor handles the Application Password as part of the connection process. The current setup documentation lists Claude Code, Claude Desktop, Codex and Cursor among the supported clients.

Now you can give the AI instructions that actually describe the design work you want done.

“Redesign the hero section.”

“Turn this section into three columns.”

“Increase the heading size.”

“Make the layout work better on mobile.”

“Create a new landing page using the existing design system.”

That is a fundamentally different workflow from asking an LLM to produce a piece of HTML and manually rebuilding it in a page builder.

The AI is working with the builder rather than working around it.

And yes, Elementor JSON is useful

There is another part of this workflow that is worth understanding because it makes the idea of AI-generated Elementor designs much more practical.

Elementor supports importing and exporting templates as JSON files. Saved templates can be imported into the Elementor Template Library, and Elementor also supports exporting and importing larger website template packages.

That means generating a template file and importing it is a legitimate workflow.

For example, you could have Claude help create or modify a structured Elementor template, import it into the site, open it in Elementor and continue editing it normally.

This is especially useful for people who like working with files and versioned assets because the design does not have to live exclusively inside the visual editor.

But there is an important distinction between using Elementor's supported template import system and manually inventing Elementor's internal JSON and writing it directly into the database.

The latter is possible for a developer who understands exactly how Elementor stores and processes its data, but it is much easier to break things. You also have to consider Elementor's generated CSS, revisions and other internal behaviour.

If the official editor or template system can do the job, there is usually little reason to reinvent it.

Then there is the developer route: SSH and WP-CLI

This is where things get much more powerful.

WP-CLI is the command-line interface for WordPress. Instead of communicating with WordPress through the normal web dashboard or REST API, you are operating WordPress from the server environment.

That changes what is possible.

With the appropriate server access, WP-CLI can install and activate plugins and themes, update them, manage WordPress data and perform other administrative operations. It can also export the WordPress database.

So imagine connecting Claude Code to a development server through SSH.

Instead of saying:

“Can you tell me how to install WPForms?”

you can potentially have Claude Code perform the operation through WP-CLI.

Instead of manually downloading a theme, you can use WP-CLI to install and activate it.

Instead of manually creating a database backup before a risky change, you can have the development workflow create one first.

And because Claude Code is already designed to work in a terminal, the combination of Claude Code + SSH + WP-CLI is particularly natural for developers.

This is the part that is often missing from discussions about AI and WordPress.

The REST API and WP-CLI are not competing versions of the same thing.

They operate at different levels.

Think of the setup as layers

At the simplest level, you have WordPress REST API access with an Application Password.

That is useful for authenticated work with WordPress data.

Then you have specialized integrations such as Elementor MCP, which understand the structure of a particular system and let the AI perform more meaningful design work inside it.

Then you have server-level access through SSH and tools such as WP-CLI.

That last layer is where you get much closer to full developer control because the AI can work with the WordPress installation itself rather than being limited to whatever the REST API exposes.

This gives you a useful mental model:

Application Password = authentication.

REST API = communication with exposed WordPress data and capabilities.

Elementor MCP = an integration that lets AI work with Elementor's actual editing system.

SSH + WP-CLI = deeper server-level WordPress control.

Once you understand that, a lot of the confusion disappears.

This also makes AI useful for non-technical people

You do not have to understand PHP, REST requests or WP-CLI to benefit from this.

A non-technical WordPress user might simply want to say:

“Create an About page using the same visual style as the homepage.”

Or:

“Change the hero section so the heading is larger and the call-to-action is more obvious on mobile.”

Or:

“Create a three-column services section underneath this heading.”

If the appropriate Elementor connection is in place, those instructions can become actual Elementor work rather than code that the user has to figure out how to install.

That is a much more interesting future for AI website builders.

The person does not necessarily need to learn how the underlying data structure works. They need to know what they want the website to do and how to describe it clearly.

The technical user gets something different from the same setup.

A developer can inspect the project, work with code, use version control, create custom functionality and use server-level tools when necessary. AI becomes another interface into the development environment rather than a replacement for the environment itself.

Both workflows can exist on the same WordPress website.

The best workflow is not “let AI do everything”

This is where I would be careful.

Giving AI more access does not automatically make the workflow better.

The more access you provide, the more important backups, permissions, staging and review become.

A simple content edit is one thing.

Changing a theme file, installing a plugin, modifying a database or changing a production site's structure is something else entirely.

For client work, I would much rather have AI make changes in a controlled environment, inspect the result, test the website and then publish the change than give an agent unrestricted access to production and hope it makes good decisions forever.

The AI is extremely useful.

It is still capable of making a bad change.

That is why the strongest workflow is not based on how much access you can give the model. It is based on giving it enough access to do the job while keeping the system recoverable when something goes wrong.

WordPress development is becoming a different kind of work

This is the part I find most interesting.

You can now have a conversation with an AI about a WordPress website and move from an idea to an actual implementation much faster than before.

A non-technical person can describe a design.

An Elementor user can refine the design directly in the builder.

A developer can ask Claude Code to inspect the project and make code changes.

A more advanced developer can connect over SSH and use WP-CLI to handle operations that the REST API cannot.

And Elementor templates can still be imported and edited normally when you want a file-based workflow.

The important thing is not choosing one magical AI WordPress tool.

It is understanding which layer of the website you are trying to change.

If you only need content, the REST API may be enough.

If you want AI designing Elementor pages, use an integration that actually understands Elementor.

If you need to install plugins, modify theme files or perform deeper WordPress administration, you are moving into WP-CLI or another server-level workflow.

AI does not remove those technical boundaries.

It makes the tools on the other side of those boundaries much easier to operate.

And that is probably the more useful way to think about AI and WordPress.

You are not asking AI to replace WordPress.

You are giving it better ways to work with WordPress.