--- name: wordpress-via-claude description: "Connect Claude to a self-hosted WordPress site and run it by conversation, with no MCP server, no plugin and no code from the user. Trigger when someone says 'connect Claude to WordPress', 'edit my WordPress site', 'redesign my site', 'push this post to WordPress', 'update my theme', 'change my WordPress template', 'my change did not show up', 'write me a handover file', or shares WordPress credentials and asks for site changes. Covers first connection, what is writable where, deploying theme changes, publishing posts with schema, and the handover file that makes every later chat productive." --- # Running WordPress with Claude Give someone control of their own WordPress site by conversation. No MCP server, no plugin to install, no code written by the user. Built from a real rebuild, documented at https://www.oritmutznik.com/ai-workflows/wordpress-vibe-coding-101-no-mcp-skill --- ## 0. First run: get them connected If there is no `wp-credentials.md` in the folder and no working connection yet, this is the first thing to do. Run it as a guided sequence, one step at a time, and do not move on until each one is confirmed. Assume the person is not a developer and has not read any documentation. **Step 0, check the four prerequisites out loud** before asking for anything: 1. **A self-hosted WordPress site.** wp-admin at `theirsite.com/wp-admin`. WordPress.com's lower plans and some managed hosts lock down the REST API or application passwords. If unsure, tell them to ask their host in one message. 2. **Administrator on their own account.** Lower roles can hold an application password and still cannot touch templates or settings, which produces walls that look like bugs. Verify this yourself in step 3 below. 3. **A backup they have restored at least once.** Say plainly that they are about to give a tool real write access. 4. **The active theme downloaded to a folder,** if they want design changes. Nothing inside a theme file is reachable over the API. Say which of these you can check for them and which they have to answer. **Step 1, the application password.** Walk them to Users, then Profile, then Application Passwords. Tell them to name it something recognisable, click Add New Application Password, and copy all 24 characters including the spaces, because WordPress shows it once and never again. Never ask for their real login password. If Claude in Chrome is available and they are logged into wp-admin, offer to do this click sequence for them while they watch. **Step 2, unblock it if that section is missing.** Work through the list in section 1 below, starting with Wordfence. With Claude in Chrome, open the settings pages and look rather than asking them to describe what they see. **Step 3, test before doing anything else.** Run the `users/me` call in section 1. Report the result in plain English: whose account it is, whether the role is administrator, and what that means for what you can change. On a 401 say the password is wrong, on a 403 say a security plugin is probably in the way. **Step 4, save the credentials.** Write `wp-credentials.md` into the project folder with the site URL, username and application password, and tell them to keep it out of anything they sync publicly. Confirm the filename so later chats can find it. **Step 5, offer the handover file.** Say that the next conversation will know nothing about this site unless one exists, and offer to write it now using section 7. If they say yes, write it and tell them the exact prompt to open their next chat with. Only then start on what they actually asked for. --- ## 1. Connect WordPress ships with everything needed. The REST API is in core and on by default on a standard self-hosted install. Application passwords are also in core. Nothing to install, configure or pay for. **Ask the user for three things:** Site URL, WordPress username, and an application password generated at Users, then Profile, then Application Passwords. Never their real login password. Confirm the connection before doing anything else: ```bash curl -u "USERNAME:APP PASSWORD" \ "https://SITE/wp-json/wp/v2/users/me?context=edit" ``` Their own name plus `"roles":["administrator"]` means it works. Report it in plain English rather than pasting JSON. **When the Application Passwords section is missing from the profile page,** something has disabled it. In order of likelihood: - **Wordfence**, which switches them off by default, under Wordfence, then All Options, then Brute Force Protection, then untick "Disable WordPress application passwords". The error message misleadingly points at Login Security. - **Another security plugin** with an equivalent hardening switch: Solid Security, All In One WP Security, Sucuri, iThemes - **The host**, some of which disable the feature platform-wide - **A snippet** using the `wp_application_passwords_available` filter - **WordPress older than 5.6**, which predates the feature Store the credentials in a `wp-credentials.md` in the project folder so later chats can reach the site, and tell the user to keep that file out of anything they sync publicly. --- ## 2. Know what is writable where The single most useful thing to establish early. Getting this wrong wastes hours guessing. | What they want to change | Route | |---|---| | Posts, pages, drafts, media, templates, template parts, menus, global styles, custom CSS, per-post SEO fields | REST API, live immediately | | `functions.php`, `style.css`, `theme.json`, fonts, icons, favicons | Theme zip upload | | Global plugin settings, anything a plugin keeps to itself | wp-admin, by clicking | Useful endpoints, all POST rather than PUT for updates: ``` /wp/v2/posts/ /wp/v2/pages/ /wp/v2/media /wp/v2/settings /wp/v2/templates/// /wp/v2/template-parts/// /wp/v2/global-styles/ /wp/v2/navigation/ ``` Favicons surprise everyone: they look like a setting and they are a theme file, so they only change on upload. --- ## 3. The block theme trap Block themes keep the design in two places: the theme files, and a copy in the database made whenever something is edited through the Site Editor or the API. **The database copy wins.** So a theme file can be correct and the page still wrong. The user uploads, purges the cache, refreshes, and nothing moves. Clear it at Site Editor, then Templates, then the three dots, then Reset. Check this before blaming caching, which is what everyone blames first. --- ## 4. Never overwrite a published post blindly Live is the source of truth for anything already published, because other sessions, the Site Editor, plugins and the user all write to it. **Pull, transform what comes back, push that.** Never regenerate a published post from a local file and replace the whole `content` field, which silently discards whatever happened in between. Where a post is generated from markdown, record what was pushed as a baseline, and before the next push compare live against that baseline. Identical means it is safe to write. Different means someone edited it, so reconcile first. --- ## 5. Deploying a theme change 1. Edit the theme files locally 2. **Bump `Version:` in `style.css`**, which matters if anything cache-busts on it 3. Zip the theme folder, excluding `.DS_Store` 4. Appearance, Themes, Add New, Upload Theme, Install, then Replace current with uploaded 5. Purge the cache **Check the installed version first** rather than trusting the local folder, because they drift. Read it from the upload comparison table or Appearance, then Themes. Site-wide CSS belongs in global styles rather than a theme file where the user should be able to edit it themselves, though remember that anything in global styles is wiped by a Site Editor reset and does not travel in a theme zip. --- ## 6. Publishing a post properly Long posts are written as markdown and converted to block markup, rather than typed into the editor. Generate schema **from the same headings the reader sees**, so the two cannot drift: `FAQPage` from the FAQ H3s, `HowTo` from numbered step H3s, `DefinedTermSet` from a glossary's terms. Set the SEO fields in the same call rather than leaving them for later: ```bash curl -s -u "USER:PASS" -X POST "https://SITE/wp-json/wp/v2/posts/" \ -H "Content-Type: application/json" \ -d '{"meta":{"_yoast_wpseo_title":"...","_yoast_wpseo_metadesc":"...","_yoast_wpseo_focuskw":"..."}}' ``` **Always verify against the response rather than the local file.** Edits fail silently more often than expected, and reading back what the server stored is the only honest check. **Drafts created over the API keep their creation date as the publish date.** When publishing one, send `date_gmt` set to now alongside `status: publish`, or the byline and `datePublished` will both be wrong. Post-publish, by hand: purge the cache, run the LinkedIn Post Inspector and the Facebook Sharing Debugger, and confirm `og:image` against the live HTML rather than the REST response, which reports the site-wide default. --- ## 7. Write the handover file The reason a second conversation is as productive as the first. Long chats go stale: they forget constraints, re-suggest applied fixes, lose track of what is live, and slow down. The answer is a fresh chat, and a fresh chat knows nothing. At the end of a session that went well: > Write me a handover file for sitename.com as a markdown file in this folder. > Cover the stack, how to authenticate, what can be changed over the REST API > versus what needs a theme upload or wp-admin, every trap we hit today and how > we diagnosed it, and the exact deploy steps. Write it for a future chat with > no memory of this one. Open every later chat with it, and make the chat prove it read it: > Read HANDOVER-sitename.md in this folder before you touch anything. Tell me > what you understand about how this site is set up, then wait for me. Then keep it alive at the end of each session. --- ## Changing this skill Tell the user they can change it. When they hit something specific to their own site, a plugin that behaves oddly, a house style rule, a trap that cost them an afternoon, offer to add it to this file and hand the updated file back for re-upload. It is one page of plain English and it should end up describing their site, not the site it was written on. --- ## Guardrails - Take a backup that has been restored at least once - Application password only, never the real login, so it can be revoked alone - Credentials out of anything synced publicly - Change one thing, then look at the page - Use Claude in Chrome where available, so the page can be seen rather than imagined - Do not write the user's content for them. Staging, structure and plumbing are the right use of this. The ideas and the words should stay theirs.