How I Run Three WordPress Sites With Claude, From Research to Tech Support

I needed a 40-person team for what I do now myself.

That line sounds like a pitch, so here is the plain version. I spent thirty years in marketing and computers. I was always the idea guy: I designed the systems, drew the logic, then handed it to programmers and designers and waited. I never wrote code. I used AI as a chatbot for two years before I started building real automations with it this year, and today three WordPress sites I run get researched, written, illustrated, published, and repaired by Claude, with me reviewing instead of typing.

Most “AI plus WordPress” articles stop at generating a blog post. That is the easy part, and honestly the least interesting one. The hard parts sit at the edges: not publishing the same story twice, getting a featured image that isn’t generic mush, hitting the REST API correctly, and figuring out why Google suddenly stopped seeing half your posts. That last one is where Claude has earned its keep, so this piece spends real time on it.

First, What “Claude” Means Here

A few terms, because they get thrown around loosely.

Claude is Anthropic’s AI model. I don’t use it in a browser chat window for this work. I use Claude Code, which runs in a terminal (or inside VS Code) on my own computer. It can read and write files, run scripts, search the web and call tools. Think of it as a very fast assistant sitting at your keyboard, working in a project folder you point it at.

The WordPress REST API is the built-in way for outside software to talk to your site: create posts, upload media, update settings. It lives at yoursite.com/wp-json/. The REST API handbook covers every route.

Application Passwords have been in WordPress core since version 5.6. They are separate passwords you generate per user under Users > Profile, meant for scripts and apps. You can revoke one without touching your real login. The integration guide on make.wordpress.org explains how they work.

MCP (Model Context Protocol) is a standard that lets an AI model discover and call tools. WordPress now has an official answer here: the Abilities API landed in WordPress 6.9, and the WordPress MCP Adapter turns those abilities into tools Claude can call. The code is on GitHub under the WordPress organization. I’ll come back to why I use MCP for some jobs and plain REST for others.

The Whole Pipeline on One Page

Here is what runs, in order, and which part of WordPress each stage touches.

The first five stages run on a schedule with nobody at the keyboard. The sixth happens whenever something looks wrong, which on a WordPress site is more often than any of us would like.

Stage One: Research That Knows What You Already Published

Research is two jobs, and people usually only automate the first one.

The first job is finding stories. Claude runs web searches across a fixed list of sources I trust for each site, and pulls the Google Trends daily feed (it’s a public RSS URL, no scraping required). It cross-references what several outlets are covering and brings back a short list of candidates.

The second job is saying no. Every candidate has to pass two tests before a word gets written.

The gap test. Claude has to read what the top pieces on that story already say and write one sentence naming what they are not doing. If it can’t write that sentence, the story gets dropped. “We would write it better” doesn’t count. This single rule killed more weak posts than anything else I’ve tried, because a thin rewrite of something everyone has already published is exactly what Google declines to show.

The name test. If the headline needs a phrase like “X, the former executive who…” to explain who someone is, readers don’t know the name, so the name can’t be the reason to click. Strip it out and see whether a story is still there.

Then there’s a boring check I learned the hard way. My morning runs used to decide “have we covered this today?” by reading a cached copy of the sitemap. The cache was a few hours old; it looked fresh, and it was blind to a post published at 5 am. The run went ahead and published a duplicate.

Now, before drafting anything, Claude asks the live site what went out today:

GET /wp-json/wp/v2/posts?after=2026-09-25T00:00:00&_fields=id,title,link,date

That _fields parameter matters more than it looks. Without it, WordPress returns the full rendered content of every post, which is thousands of words of HTML the AI then has to read. With it, the answer is a few hundred characters. If you’re connecting any AI tool to WordPress, ask for only the fields you need.

Stage Two: Writing, With a Gate It Can’t Talk Its Way Past

Every site has a voice file: a plain Markdown document describing who the site writes for, the tone, what it will and won’t do, and the house rules. Claude reads it before every draft. There’s also a project-wide rules file (Claude Code reads a file called CLAUDE.md in the project root automatically), which is where lessons go once I learn them so I never have to repeat them.

Here’s a real rule from mine, lightly trimmed:

Headline shape must rotate. There is no house headline form.

Rotate across: single clause / comma + contrast / two sentences /

appositive / subordinate clause. At most one “X, and Y” headline per day.

That rule exists because I looked at one site’s archive page and 14 of the last 25 headlines had the same “X, and Y” construction. Nobody had to open a post to see the pattern. Readers can spot a template, and I’d bet search engines can too.

The second half of writing is a gate. I run every draft through a Python script that fails the build on the phrases and sentence shapes that make readers think “a robot wrote this”: the “it’s not just X, it’s Y” construction, a short list of overused words, em dashes, placeholder text left behind. It exits with an error, and the draft goes back for a rewrite. The point is that the model doesn’t get to grade its own homework. A script that says FAIL is more honest than a model that says “looks good to me.”

One small warning if you build something like this on Windows. My first version of that check used a grep command that crashed on my machine’s text encoding, and because of how the command was written, a crash counted as a pass. Every draft sailed through for weeks. Test your gate against a draft you know is bad before you trust it.

Stage Three: Graphics Without the Stock-Photo Look

Every post gets a 1200×630 featured image, which is the size Facebook, LinkedIn, and most link previews expect. Claude writes the image prompt from the article, calls an image model, resizes and center-crops the result, converts it to WebP, and uploads it through /wp/v2/media.

Three rules keep the images from looking like AI filler:

1. No headline text in the image. Your theme already prints the title right above it. Text inside an AI image also tends to come out misspelled.
2. A real reference photo first when the story is about a real person. Generating a public figure’s face from a text description gives you a generic look-alike. Claude now fetches an actual photo (a public-domain portrait from Wikimedia Commons, for example) and passes it to the image model as a reference.
3. Real logos when the story is about a company. A news story about a brand should show the brand, not a vague glowing cube.

The funniest bug in the whole system lived here. One image model kept returning images in the wrong shape no matter what aspect ratio I asked for. The script was sending the setting under one parameter name, and the model was reading a different one, so it silently ignored the request and fell back to its default size. Claude found it by reading the provider’s docs against the request my script was actually sending. The fix was sending both names. Two lines.

Stage Four: Publishing Through the REST API

This is where WordPress people will have the most opinions, so I’ll be specific.

Claude creates each post with a single authenticated request. Stripped down, it looks like this:

curl -X POST https://yoursite.com/wp-json/wp/v2/posts \

  -u “claude-bot:xxxx xxxx xxxx xxxx xxxx xxxx” \

  -H “Content-Type: application/json” \

  -d ‘{

    “title”: “Your headline”,

    “slug”: “your-slug”,

    “content”: “<!– wp:paragraph –><p>Opening line.</p><!– /wp:paragraph –>”,

    “status”: “future”,

    “date”: “2026-09-25T07:10:00”,

    “categories”: [12],

    “featured_media”: 4821,

    “excerpt”: “The one-line summary.”

  }’

A few things in there are deliberate.

The user is a dedicated account. claude-bot is its own WordPress user with the least role that can do the job, and the application password belongs to that user only. If something goes wrong, I revoke one password and nothing else is affected. The WordPress MCP Adapter documentation recommends the same thing: a dedicated user with limited capabilities for production access.

The content is block markup. Those <!– wp:paragraph –> comments are how the block editor stores content. Send plain HTML and WordPress wraps it in a Classic block, which is fine until someone opens the post in the editor and wonders why it looks different. Claude writes proper blocks: paragraphs, headings, tables, embeds.

Group publishes are staggered. When three posts go out in one run, the first publishes now and the others go in as “status”: “future” with times five to twelve minutes apart. Three posts landing in the same second looks like exactly what it is.

SEO fields go in too. I use Rank Math, and a small snippet on the site registers its title, description and focus keyword fields with the REST API, so every post ships with them filled in. On my third site, which doesn’t have that bridge set up, the post excerpt does the same job for the meta description.

Why I Moved Publishing Off MCP

I started with an MCP server for everything, and I still use one for reads and small edits. But the WordPress MCP tools I was using returned the entire post object after every write. On a long post, that response was bigger than what the tool could pass back, so the call reported an error even though the post had been created successfully. An AI that sees “error” will helpfully try again, and now you have two posts.

So publishing moved to a small Python script that calls the REST API directly and prints back four fields: id, link, status and date. MCP is great for letting Claude explore a site and discover what it can do. For the one write that happens every morning, a boring script that returns only what I need is safer. With the Abilities API in core now, I expect that gap to close, but check what your tools return before you let an AI retry anything.

Stage Five: Running It While I Sleep

The schedule is nothing fancy. Windows Task Scheduler (cron on a Mac or Linux box does the same job) fires a short PowerShell script at a set time each morning. That script runs Claude Code in headless mode, meaning no chat window, just a prompt in and a result out. The prompt is a Markdown file that lives in my project’s git repository, so every change to how the morning run behaves is versioned.

The lesson from this stage is the most important one in the article: an automated run’s own report is not proof of anything.

Early on, a morning run finished cleanly and reported that everything had been published. It had published two posts out of five and logged none of them. The model wasn’t lying on purpose. It wrote a confident summary at the end, and the summary was wrong. Now every run is checked against WordPress itself: what does the REST API say went live today? If the site and the report disagree, the site wins.

I apply the same rule everywhere now. When a script deletes something, it ends by reading the live state back and failing loudly if the thing still exists. A green checkmark from the thing that did the work is a claim. A read-back from the system is evidence.

Stage Six: Technical Support, Which Is the Part I Didn’t Expect

I built all this for content. The biggest surprise was how much of my WordPress support Claude now handles. Here are real cases from the last few months, because they’re more useful than a list of features.

The Sitemap That Froze

Posts on one site stopped showing up in Google. Claude checked the obvious things first: robots.txt was open, the sitemap index was updating, nothing was marked noindex. Then it opened the individual post sitemaps and compared their dates to the index. The index said “updated today.” The post sitemaps inside it were being served from a database cache that had stopped refreshing a month earlier. Every post published in that month was simply missing from the file Google reads.

The fix in Rank Math was two clicks in the admin: Status & Tools > Database Tools > Remove transients, then saving the Sitemap Settings page to force a rebuild. To stop it happening again, Rank Math’s own docs describe turning off sitemap caching with one filter, which can go in a code snippets plugin or a child theme’s functions.php:

add_filter( ‘rank_math/sitemap/enable_caching’, ‘__return_false’ );

What I’d want you to take from this isn’t the specific fix. It’s the method: Claude didn’t guess. It read each layer and found the one that disagreed with the others.

The Table You Couldn’t Read in Dark Mode

A post with a data table looked fine in light mode and was unreadable in dark mode: every other row was pale text on a pale background. Claude traced it to the block’s “Stripes” style. Core hardcodes a light gray background on odd rows, and my theme kept its light text color in dark mode, so half the rows disappeared. The fix was switching to the default table style, which inherits the theme’s colors, plus a rule in the writing instructions so it never uses the striped style again.

The Theme Update That Doubled Everything

After a theme update, new posts suddenly showed two share bars and the featured image twice. The new theme version had started rendering its own share bar and a full-width hero image, and my publishing instructions were still adding the old ones inside the post body. Claude compared a fresh post to an older one, found the duplication, updated the instructions and wrote a small cleanup step that strips the old elements from any body that still has them.

The Tool That Was Doing the Wrong Thing

This one is humbling. For two months I’d been sending every new article URL to Google’s Indexing API, because a lot of SEO advice online says to. When I asked Claude to work out why indexing still looked weak, it read Google’s own documentation and pointed out that the Indexing API is officially for two kinds of pages: job postings and livestream videos. For a regular article, Google accepts the request, returns a success code and ignores it. The 200 response I’d been treating as proof meant nothing, and Google warns that misusing the API can get access revoked. Article submissions are coming out of my pipeline. An AI that will tell you your own setup is wrong is worth more than one that tells you it’s great.

The Sitemap That Wasn’t Missing

The reverse happens too. Three separate checks once concluded one of my sites had no Google News sitemap, because they all went looking for a file like /news-sitemap.xml and got a 404. It existed the whole time. The XML Sitemap & Google News plugin serves it as a feed at /?feed=sitemap-news, not as a file. Now I keep a short table in my project notes of every endpoint like that, so the next session doesn’t waste an hour rediscovering it. A failed guess at a URL is not proof something is missing.

If You Want to Try This on Your Own Site

You don’t need all six stages. Here’s the order I’d go in.

1. Start on staging or with drafts. Have Claude create posts as “status”: “draft” for the first few weeks and publish them yourself. You’ll learn what it gets wrong before any reader does.
2. Make a dedicated user. Give it the lowest role that works (Author is enough to publish your own posts) and its own application password.
3. Write your voice file before your first prompt. One page: who you write for, what you never say, how long posts run, how you cite sources. Everything downstream gets better.
4. Automate the “no” before the “yes”. A duplicate check and a quality gate will save you more embarrassment than a better prompt.
5. Use Claude for support first if content feels risky. Point Claude Code at a copy of your theme or a broken page and ask it to find out why. It’s the lowest-stakes way to see what it can do, and it’s where I got the most unexpected value.
6. Verify against the live site, always. Whatever the AI reports, check what WordPress says. Keep your regular maintenance routine too; WPFloor’s monthly WordPress maintenance checklist is a good baseline, and Claude can run most of those checks for you once it has access.

Where It Still Needs Me

I’m skeptical of anyone who says their AI system runs with zero human involvement. Mine doesn’t. I still decide what each site stands for, and I read the morning output. I still catch things: a headline that was clever but didn’t say what happened, an obituary for someone who wasn’t famous enough to warrant one, a pattern the gate didn’t know to look for yet. Each catch becomes a rule in the project file, and the rule is what keeps it from happening twice.

What changed is where my hours go. I used to spend them waiting on people to build what I’d designed. Now I spend them deciding what good looks like and writing it down clearly enough that a machine can hold the line. You can see what that produces every morning in the AI News Roundup on scoy.ai, which this same pipeline researches, writes, illustrates, and publishes.

When AI can handle the whole stack, and you’re not relying on anybody, it makes you feel like you can do anything. That’s been my experience with WordPress this year, and it’s the part I’d want you to try for yourself.

Frequently Asked Questions

About the author: Scott Scoy has spent thirty years in marketing and computers and now builds agentic AI systems for businesses at Scoy Agentic. He runs his own publishing, research, and support work on Claude Code and shares what holds up (and what breaks) at scoy.ai.