This is the exact playbook I used to build 1317.net without ever clicking through wp-admin to configure it. You can copy-paste most of it.
The trick is two channels into your WordPress site: the built-in REST API for almost everything, and Claude in Chrome (MCP) for the ~10% the REST API cannot reach.
What you will need
- A WordPress site where you are the admin. Self-hosted is easiest. (Mine is hosted with Spacestar.net.)
- Claude Code installed locally.
- Google Chrome with the Claude in Chrome extension if you want the escape-hatch for customizer work.
- 10 minutes.
Step 1 — Enable API access with an Application Password
WordPress ships with the REST API built in — you do not need to install a plugin for it. What you do need is an authentication token. Modern WordPress uses Application Passwords: a long, revocable token separate from your login password, intended for programmatic access.
- In
wp-admin, go to Users → Profile. - Scroll to Application Passwords.
- Enter a name (e.g.
claude-code) and click Add New Application Password. - Copy the generated password. It will look like
abcd efgh ijkl mnop qrst uvwx. You only see it once.
If you do not see the section, your site may have disabled it. For self-hosted sites that is unusual; managed hosts sometimes hide it. Ask your host, or enable it with the wp_is_application_passwords_available filter.
Store it in an environment variable
Do not paste this credential into Claude prompts, screenshots, support tickets, or any file that might end up in git. The simplest safe pattern is to store it in an environment variable named WP_AUTH and reference the variable from there on.
For the current shell session only:
export WP_AUTH="your-username:abcd efgh ijkl mnop qrst uvwx"
To make it persist across terminal sessions, add the same export line to the shell config your terminal reads on startup — ~/.zshrc on macOS, ~/.bashrc on most Linux — then either open a new terminal or run source ~/.zshrc. Keep that file out of git (it already is, if you are using a normal home directory).
Every example in this guide uses $WP_AUTH instead of the raw credential. When you paste a prompt to Claude Code, paste the $WP_AUTH version — Claude will read the variable from its own shell at run time, so the secret never enters the chat log.
Test the credential
curl -s -u "$WP_AUTH" "https://your-site.com/wp-json/wp/v2/users/me"
You should get back a JSON blob with your user info. If you get 401, the username or password is wrong. If you get rest_cannot_access, your hosting provider is blocking basic auth on REST — contact them.
Step 2 — (Optional) Install the MCP Adapter plugin
The core REST API is enough for 90% of what you will want to do. But the MCP Adapter plugin exposes an MCP-native endpoint, which Claude Code can speak to directly as a first-class MCP server. Installing it is a few clicks — or, even better, have Claude do it for you with the Chrome MCP. See Step 4 below for that prompt.
Step 3 — Point Claude Code at your site
Open Claude Code in your project directory and give it the basics. The first prompt I used in this build was literally:
new project: blog.example.com
Claude asked clarifying questions. The follow-up prompt that actually kicked things off was this — notice it gives Claude both context and a way to verify access in one shot:
This is a wordpress site you will be manipulating via API. It is a fresh install, clean slate. I want it to have a professional feel, clean, easy to navigate, inviting. The site will be about AI and technology. Give me some ideas on color theme, layout, if the current template installed is the best to fit our needs. You can check out what is available. curl -s -u "$WP_AUTH" "https://your-site.com/wp-json/wp/v2/users/me"
Two things make this prompt work:
- It tells Claude the access method (REST API + this exact credential) instead of making it guess.
- It asks for reconnaissance first. Before Claude writes anything, it discovers what theme and plugins are installed. Good recommendations follow from good facts.
What Claude can do from here, with just the REST API
- Inspect active theme and installed plugins (
/wp/v2/themes,/wp/v2/plugins). - Update site settings (title, tagline, timezone, front page, posts-per-page).
- Create and delete pages, posts, categories, tags.
- Build and assign classic menus (Primary, Footer, Off-Canvas).
- Upload media, set featured images.
- Upsert content idempotently by slug.
Ask it, politely, to be idempotent. Something like: “Write the scripts so they can be re-run safely — if a page with the same slug exists, update it instead of creating a duplicate.”
Step 4 — When the API hits a wall, use Chrome MCP
Classic WordPress themes like Astra store customizer settings (colors, typography, Additional CSS) in theme_mods — and those are not exposed to the REST API by default. You can bang your head against it, or you can give Claude a different pair of hands.
Install the Claude in Chrome extension. Sign in to your WordPress site in Chrome, leave it open. Then give Claude the prompt I used when my build hit the customizer wall:
One of the key features of this site is it will be built with AI. No, I can’t do that here is a handoff.md file. My chrome is logged into the site. Use the Chrome MCP to take care of the handoff.md tasks.
That one-liner flipped the whole workflow. Claude stopped producing a HANDOFF.md for me to execute and instead executed it itself — navigating to customize.php, staging settings via wp.customize(‘custom_css[astra]’).set(...), publishing with wp.customize.previewer.save(), and verifying on the front end.
Prompt: install the MCP Adapter plugin for me
If you want Claude to set up the MCP Adapter plugin without you clicking through, this prompt works:
My Chrome is logged into https://your-site.com/wp-admin. Use the Chrome MCP to install and activate the “MCP Adapter” plugin: 1. Navigate to Plugins → Add New. 2. Search for “MCP Adapter” by the WordPress team. 3. Install it, then activate it. 4. Confirm it is active by navigating to Plugins and showing me that MCP Adapter appears with status “Active.” After it is active, fetch https://your-site.com/wp-json/ and show me whether the “mcp” namespace now appears in the namespaces array.
The last step is how you know it actually worked — the plugin registers a namespace on the REST API root.
Sample prompts from this build
Everything below is copy-paste-able. Swap in your own site details.
Initial discovery + design direction
Fresh WordPress install. Connect via the REST API using the WP_AUTH environment variable already set in my shell: curl -s -u "$WP_AUTH" "https://site.com/wp-json/wp/v2/users/me" The site is about <topic>. I want a <audience> feel. Before making changes: check what theme is active, what plugins are installed, and what the site currently looks like. Then propose 2–3 design directions with color palettes and explain the trade-offs.
Picking a direction and executing
proceed with option 1 + the layout above
When Claude proposes a plan, it is worth being this terse. Brief approvals keep the AI from over-elaborating.
Making the scripts idempotent
Write your page/menu/post creation scripts so they can be re-run safely. If a slug already exists, update that record instead of creating a duplicate. Log what changed.
Handing off the visual work to Chrome MCP
My Chrome is logged into the site. Use the Chrome MCP to apply the customizer work you previously put in HANDOFF.md — permalinks, Additional CSS, and whatever else you could not do via REST. After each change, verify by loading a front-end page and describing what you see.
Iterating on the CSS from the browser
The footer is still light. The dark-background rule is leaking into the header because Astra uses ‘.ast-builder-grid-row-container’ in both the header and footer. Fix it with a scoped selector, re-apply via wp.customize, and show me a screenshot to confirm.
That kind of specific, diagnostic-first feedback produces much better iteration than “make it look better.”
Things to watch out for
- Application Password leakage. Do not paste app passwords into public prompts, screenshots, or tickets. They are like SSH keys. Revoke and regenerate if they escape.
- Rate limits. Managed hosts sometimes throttle REST. If Claude makes 50 calls in a loop and gets 429s, ask it to batch, or switch to CLI-based bulk updates.
- Customizer settings are theme-scoped. Switching themes blows away your customizer-based design. Keep the CSS source in git so you can re-apply it.
- Caching. If you have Redis/object cache active (I do), the changes may take a moment to show up on the front end. Hit a cache-busting query param if verification seems stale.
- Review before publishing. Even in AI-driven mode, keep posts as drafts until you have read them. The model is fast but still writes things that need your voice sanded on.
Where to go next
- Read Why 1317.net — the short version of why I am building this way.
- Follow along as I try more ambitious things (automated posting, image generation, code review via Claude) on this same site.
- If you try this on your own site, leave a comment below with what worked and what did not — I will fold the feedback into future revisions of this guide.