Work Services Writing About Let's talk
Back to writing
Website · Tools · AI

Connect Claude to WordPress in 5 minutes with application passwords

/ 6 min read

WordPress application passwords let Claude read, draft, and edit your site over the REST API. No plugin, no code. Here is the setup, the security framing, and the one gotcha that trips people up.

WordPress dashboard application passwords screen next to a Claude session connecting over the REST API
On this page

I wired Claude into a WordPress site this morning before my coffee went cold. No plugin. No Zapier. No code. Two things that ship with WordPress and Claude already, sitting there unused.

If you want Claude to read your posts, draft new ones, and tidy up old ones without anyone building an integration, you can have it working in five minutes. Here is the whole thing, plus the catch the original demo glosses over.

The 30-second version

WordPress has a feature most people scroll past called application passwords. It lets an outside tool talk to your site over the REST API (the built-in web address that returns your content as data) without you handing over your real login. You generate one, give it to Claude, and Claude can now do anything your user account is allowed to do: list posts, pull a draft, edit a page, save a new draft.

That is the connection. Generate a password, paste it in, done.

The clever part is not the API. That has been in WordPress since 2018. The clever part is that the thing on the other end can finally read your content and act on it without you writing a line of PHP.

Step 1: generate an application password

Log into your WordPress site. Go to Users, then Profile, and scroll to the very bottom. There is a section called Application Passwords.

Type a name so you remember what it is for, like "Claude", and click Add. WordPress shows you a password once, looking like this:

4CHt b6qO l7ox SU8l qcaU cOYj

Copy it now. A few things worth knowing before you move on:

  • It shows once. Miss it and you just delete it and make another. No drama.
  • You can revoke it from this same screen in about five seconds.
  • It inherits the account's permissions. If the account is an Editor, the password can do Editor things and nothing more.

That last point is your safety lever, and most people ignore it. More on that below.

Step 2: tell Claude

Open a Cowork session, where Claude has shell access. Give it the site, the username, and the password, and ask for something small first:

Here's my WordPress username and application password. List my last 10 posts. The site is example.com.

Under the hood Claude calls https://example.com/wp-json/wp/v2/posts with your credentials and pulls back whatever that account can see. Once that works, you can ask for the useful stuff:

  • Pull one post and rewrite the intro in your voice
  • Draft a new post and save it as a draft, not published
  • Fix tags and categories across a batch of old posts
  • Show everything you wrote last month, sorted by comment count

Keep "save as a draft, not published" in your instructions until you trust the setup. I would not let an AI publish straight to a live site on day one, and neither should you.

If you have read my piece on why MCP is the next evolution in API architecture, this is the scrappy cousin of that idea. No protocol, no server, just credentials and an API that was always there.

Step 3: turn it into a tool you keep

Here is the part I actually use. Once Claude can reach your site, ask it to build you a small page, an artifact, that lives in the sidebar and stays useful.

Mine is a writing pad. Drafts saved locally, a button that polishes a paragraph in my voice, one that spits out title options, one that copies the whole post as HTML so I can paste it into the WordPress editor in one move.

You can ask for whatever fits how you work:

  • A content calendar that reads your scheduled posts each morning
  • A weekly digest of which posts are pulling the most comments
  • A draft generator that reads a notes folder and pitches three angles
  • A board of every post tagged "AI" so you can see what is landing

You describe it, Claude builds the page, it stays in your sidebar. This is the same instinct that made me build an MCP server for my own portfolio: give the AI a clean way in, then build the thing you reach for every day.

The catch nobody mentions

Here is where the breezy "five minutes and you're done" story falls apart for some people, and the original post buries it in the comments.

Cowork runs Claude's shell inside a network sandbox with an allowlist. Reading your site usually works fine. But the moment you try to write (create a draft, update a post, see private content) Claude has to send an Authorization header to your domain, and the sandbox can block outbound calls to sites that are not on its list. People hit errors like "the sandbox's network proxy blocks outbound connections" or "creating drafts is blocked because my shell can't send an Authorization header."

So the read side works for almost everyone. The write side is where it breaks. The author's own answer in the comments is telling: when it fails, it is usually the hosting company or the sandbox blocking the connection, not your setup.

What to do about it:

  • Test read first. If listing posts works but drafting fails, you have hit the sandbox wall, not a credentials problem.
  • Check your host. Some WordPress hosts block REST API write traffic or strip the Authorization header at the server. Cloudflare and security plugins do this too. Confirm the REST API is reachable and writable before you blame Claude.
  • If writes matter to you, this hack is the wrong tool. A proper WordPress MCP server runs the connection as a real, named integration with explicit permissions, instead of leaning on shell calls that the sandbox can cut off. It is more setup, and it is the right call once you are doing this daily on a client site.

That is the honest line: application passwords plus a shell are a brilliant way to read and experiment. For reliable writing on a site that matters, treat them as a prototype, not the finished thing.

Treat the password like a key, because it is one

One application password is a working key to your site, scoped to that account. So:

  • Make a dedicated user with only the role it needs. An Editor account cannot touch plugins, users, or settings, which is exactly what you want for a content tool. Do not hand it an Administrator login out of laziness.
  • Never paste it anywhere you cannot revoke it from. Not a public chat, not a shared doc.
  • If it leaks, delete it. The revoke button is on the same screen, and the worst case really is a five-second fix.

This is the same least-privilege habit I bang on about in why your auth system is probably wrong. Give a tool the smallest set of permissions that lets it do the job, and a leak stays small. If you run your own stack, my self-hosted security checklist covers the rest.

What about WooCommerce?

Same mechanism. WooCommerce exposes orders through the REST API at /wp-json/wc/v3/orders, so in principle Claude can read them if the connected account has the right capability (Shop Manager or Administrator). That opens up "show me today's orders" or "draft a follow-up for delayed orders." Same caveat as everything else here: the write side runs into the sandbox wall, and giving a content tool Administrator access to your store is a bigger risk than giving it Editor access to your blog. Read-only reporting is the safe starting point.

The bigger point

The interesting bit is not that Claude can post to WordPress. It is that the REST API has been sitting in every WordPress install for years, useful and ignored, and AI is what finally makes it casually reachable by people who never wanted to write Python.

If you can describe what you want, you have a WordPress integration today. No marketplace, no JSON, no webhooks page. Just know where the read/write line sits so you do not waste an afternoon fighting a sandbox you cannot see.

What to do now

Make a dedicated Editor user, generate an application password for it, and ask Claude to list your last 10 posts. If that works, ask it to draft one post as a draft and check whether the write goes through. If it does, build yourself a small sidebar tool and stop copy-pasting from a blank editor. If the write fails, you have learned exactly where the wall is, and you can decide whether a real WordPress MCP is worth setting up. If you want a steadier footing with Claude in general before you start, my guide to using Claude Code right is the place to start.

← Previous Someone built a mini Claude Code in an afternoon. Here is what to steal from it
FAQ

Frequently asked

It is a separate password WordPress generates for outside tools to use over the REST API, instead of your real login. It is tied to one user account and inherits that account's permissions, so an Editor account's application password can only do Editor things. You create and revoke them under Users, then Profile, at the bottom of the page. If one leaks, you delete it and the access is gone.

Technically yes, if the connected account has permission and the connection can write. In practice you should keep it to saving drafts until you trust the setup, and you may hit a sandbox restriction in Cowork that blocks write calls altogether. Read operations work for almost everyone. Write operations are where setups break, usually because of the network sandbox or the hosting company.

The most common reason is Cowork's network sandbox blocking outbound calls that carry an Authorization header to your domain. You will see errors about the proxy blocking connections or the shell being unable to send auth. It can also be your host or a security plugin stripping REST API write traffic. Test a simple read first: if reading works but writing fails, it is the sandbox or the host, not your credentials.

It is as safe as the account you attach it to. Create a dedicated user with the lowest role that does the job, usually Editor for content work, never an Administrator unless you truly need it. Never share the password somewhere you cannot revoke it, and delete it the moment you suspect a leak. The revoke button is on the same screen where you made it.

No, application passwords plus the REST API are enough to read and experiment with no plugin and no code. But for reliable writing on a site that matters, a proper WordPress MCP server is the better path, because it runs as a named integration with explicit permissions instead of relying on shell calls the sandbox can block. Use the application password trick to prototype, then move to an MCP setup for production work.

Yes, in principle. WooCommerce exposes orders at /wp-json/wc/v3/orders, so Claude can read them if the connected account has the Shop Manager or Administrator capability. The same write limits apply, and handing a content tool Administrator access to your store is riskier than read-only reporting. Start with read-only order summaries before you consider anything that changes data.

Enjoyed this? Let's talk.

Start a conversation →