I Gave Claude Code a WordPress App Password and One Sentence. It Managed the Whole Site.

One sentence. No stack details. No plugin names. Claude Code figured out the rest — and then kept going.

8 min read

A client sends me an email. Nothing dramatic: swap the Spanish flag for a Mexican flag in the language switcher on their WP site. The kind of stuff you don't do every day and that can easily burn your whole morning.

I haven't touched this site in forever. A contractor built it years ago. I don't even remember how he set up the i18n. And honestly? Not feeling it.

Then I had an idea. What if Claude Code could just... handle this.

So I did the thing: generated a WordPress app password, pasted it into Claude Code with the site URL and the client's request, and went to do something else.

TL;DR: Claude Code found Polylang on its own, swapped the flag, purged the Elementor cache, verified the front-end. I never mentioned which plugin managed languages. Then it audited the rest of the site. Then I opened my 54 other client sites. What was a chore became a workflow.

Overwhelmed worker vs confident AI developer managing WordPress site with ease
AI just dropkicked WordPress complexity into next week 🚀

The Client Ticket I Almost Ignored

The request was simple enough. Client has a bilingual site (Spanish/English), and the language switcher shows a Spain flag for the Spanish version. They want the Mexican flag instead. Makes total sense for their audience.

Now normally, you log in, find the translation plugin settings, locate the flag configuration, change it, purge whatever cache is running, check the front-end, reply to the client. Twenty minutes if you know the site. Forty-five if you don't.

I didn't know this site. I outsourced it to a contractor two or three years ago. I don't remember what he used for translations, what page builder is in there, what cache plugin is running. The whole mise en place of someone else's WordPress install, and I'm supposed to just dive in blind.

So instead of logging into wp-admin like a responsible adult, I went to Settings > Users > Application Passwords. Thirty seconds. I pasted the URL, the app password, and the client's email into Claude Code. One sentence of context from me: "handle this."

And I left.

I gave it the keys. I didn't tell it what kind of car it was.

It Found Polylang. I Never Said Polylang.

Flag changed. Cache purged. Front-end verified. Five minutes total. That's the result.

The transcript tells a different story than what I expected (I read it after the fact, because at the time I was somewhere else entirely).

Claude Code fetched the site's HTML source. It spotted a CSS class: cpel-switcher__flag--es. From that class alone, it figured out Polylang was handling translations. It queried /pll/v1/languages via the REST API, found the language entry for Spanish, changed flag_code from es to mx via PUT, then went after the cache.

The cache part was messy (as it always is with Elementor). Claude Code tried several endpoints before finding the one that actually triggered a purge. Then it fetched the front-end HTML again and ran a grep on the classes to confirm the new flag was live.

Honest note: Claude Code didn't nail it on the first try. It initially tried to open Chrome and log in through the wp-admin form. It had the app password but interpreted it as regular credentials. I sent one correction: "use the REST API, not the browser." One sentence. After that, fully autonomous.

It inferred the entire stack from raw HTML. I would have spent ten minutes just clicking through settings panels.

Then I Asked If Anything Was Wrong. That Was a Mistake.

The flag was done. But I still had Claude Code connected to the site, and I'm the kind of person who can't leave a tool running without poking at it. So I typed: "while you're in there, anything look off? Read-only. Don't change anything."

I expected maybe a missing alt tag. An outdated plugin. Something polite.

Three minutes later: eight issues. And not the cosmetic kind.

XML sitemap incomplete: the Mexican pages were entirely absent. On a bilingual commercial site, that’s your SEO for half your content just… not indexed. No SEO plugin installed at all. Page titled “About US” where the caps made it read as “United States” (likely a remnant of three redesigns that nobody caught). Polylang translations not properly cross-linked, meaning the language switcher sent users to the homepage of the other language instead of the translated page they were actually on. Security headers absent across the board: no HSTS, no X-Frame-Options, no CSP. Admin username was literally admin. A random ZIP file sitting in the media library that nobody could explain. And one Mexican page with no English equivalent, breaking the bilingual structure.

Here's what made this uncomfortable: I'm the one who's supposed to maintain this site. These issues were sitting there the whole time. A client paying for maintenance, and the contractor (and then me, by extension) had missed all of it. Claude Code found it in three minutes by methodically querying every REST endpoint and comparing what should exist against what actually does.

A WordPress consultant bills a minimum 2 hours for this kind of audit. Some agencies package it as a standalone deliverable.

This cost one sentence I typed on a whim.

The 8 audit findings presented as a structured diagnostic report. Two-column lay...
The 8 audit findings presented as a structured diagnostic report. Two-column lay...

Why This Works on Any WordPress Site You've Never Touched

The WordPress REST API is not a feature. It's the entire site, exposed as endpoints, natively, since version 5.6. And that changes what "giving access to an AI" actually means.

No plugin to install. No MCP server to spin up. No config file, no Docker container, no nothing. The API is already running on every WordPress site that hasn't explicitly disabled it (almost none do). Posts, pages, media, users, plugins, site config. And the ecosystem followed: Polylang ships /pll/v1/. WooCommerce ships /wc/v3/. Yoast, RankMath, same pattern. All documented, all queryable.

An application password gives the bearer the exact same permissions as the WordPress user who generated it. That's the entire setup. Thirty seconds in wp-admin. No OAuth dance. No API key dashboard. No webhook registration.

Now pair that with what Claude Code already does well: read documentation, explore API surfaces, infer context from responses. It reads the site's HTML, spots Polylang from a CSS class, queries the right endpoint, validates the result. This is the same pattern as the n8n MCP server that gives Claude Code structured access to n8n's full API, with complete autonomy and zero UI. Except with WordPress you don't install anything. It's been there for years, sitting in plain sight.

The bridge between Claude Code and WordPress has existed since 2021. We just noticed.

I Had 54 Other Sites. Here's What Happened.

I manage 54+ client sites. The flag session took less than ten minutes. So I kept going, and over the next few days I ran three real tests on different sites.

Content updates and article creation. Claude Code reads existing pages via the API, picks up the tone and structure of what's already published, generates matching content, and pushes it via POST/PUT on /wp/v2/posts and /wp/v2/pages. No wp-admin, no copy-paste into Gutenberg, no reformatting. A one-line brief goes in, a published page comes out.

Batch alt-tag updates. Claude Code fetched all media via /wp/v2/media, identified every image with missing or empty alt text, and updated them batch by batch. One site had 200+ images. That's an afternoon of clicking through the media library, writing alt text one by one, saving, scrolling, next. One session handled it.

Security hardening. Renaming the predictable admin username, checking response headers, auditing user permissions and roles. The stuff that lives on your "I'll do it next month" list for every client site you manage.

Here's the thing that only hits you when you look at the full picture: none of these tasks are hard individually. Any dev can update alt tags. Any dev can rename an admin user. The problem was never difficulty. It was that doing it on one site is fine, doing it on 54 sites is a raison d'être for procrastination. The API turns each task into a repeatable session. Claude Code turns the session into a batch. The multiplication is what matters, not the unit.

Honest disclosure: I tested content and alt-tag workflows on 3-4 sites, not all 54. But the pattern held identically each time, and scaling to the full portfolio is arithmetic at this point, not speculation.

54 sites. Before: one chore per site. Now: one session per batch.

The Part Nobody Tells You About Giving an AI Admin Access

Alright. Let's talk about the thing you're already thinking about.

An app password with admin privileges gives full write access through the REST API. Full. That means creating, modifying, and deleting content. On an ambiguous request like "clean up unused media," Claude Code might interpret "clean up" more generously than you intended.

On one test, I asked Claude Code to "review and organize the media library." It flagged files for potential deletion and asked before proceeding. It was cautious. But cautious is a behavior, not a contract. The model decides how to interpret your request, and you don't always control that interpretation in advance.

Non-negotiable rule: full backup before any session. Or work on staging. Pick one.

Second thing: scope drift. The flag session showed it clearly. Claude Code tried the browser login before I corrected it. Without an explicit perimeter in the prompt, it will explore what it can access, and that surface might be wider than what you expected.

This is exactly where defining the execution scope before launching Claude Code on a client site makes the difference between a smooth session and an incident. "Modify only the Polylang config. Do not touch page content." That kind of explicit boundary.

One more thing the REST API doesn't cover: PHP files, theme code, WordPress core. For that you need SSH access. Claude Code knows this and says so when it hits that wall.

The app password gives you the keys to the truck. You better have said where you're going before you start the engine.


Next year someone will ship a WordPress plugin at $29/month that does exactly this. Clean UI. Seven-step onboarding. People will pay.

Meanwhile, the REST API has been there since 2021. The app password takes thirty seconds. Claude Code figures out the rest. No plugin. No setup. No subscription.

(And for the app password rotation across all your sites? You just ask Chrome in Claude to batch-generate them. Shh.) 🤫


Sources

WordPress REST API Handbook: developer.wordpress.org/rest-api


If your workflow involves more Claude Code than Stack Overflow these days, I write about the patterns that actually ship. Follow along if that's your kind of reading.

(*) The cover is AI-generated. The flags are accurate though, which surprised me more than the article itself.


Want to see how AI can turn tedious WordPress maintenance into a one-sentence workflow? Our newsletter breaks down real-world production patterns for shipping autonomous agents.

Join the AI ops newsletter