I Let Claude Run My Website. Here’s the Exact Setup.

Last Saturday morning I typed one sentence into Claude: I want my website to update itself. By dinner, it did. Blog posts, page edits, image uploads, even file deploys now happen through an AI that I mostly leave alone. It emails me a summary when it does something.

Short version for the skimmers: WordPress ships with an API that can do almost everything the admin screen can. You give Claude a revocable Application Password, a playbook document it reads at the start of every session, and two scheduled tasks. That’s the whole trick. No paid plugins, no third-party services, and one click kills the whole thing if you ever want out.

What I actually built

My site runs WordPress on Hostinger. Before Saturday, publishing anything meant logging into wp-admin, fighting my page builder, and manually purging caches. Now any Claude session, including ones on my phone, can write and publish a post, update a section of my homepage, or push a new version of the Bible reader app I host here. On top of that, two scheduled tasks run without me: a weekly one that works through my content backlog, and a monthly health check that hunts for broken links and missing SEO fields.

The weirdest side effect: while auditing the site, Claude discovered my page builder was doing almost nothing. Every page was a thin wrapper around HTML I had written myself. We migrated all eight pages off it in an afternoon. My homepage dropped from 79KB to 52KB and I get to cancel that subscription.

The five pieces that make it work

First, the WordPress REST API is the backbone. It handles posts, pages, media, categories, and even plugin management out of the box. Second, a Claude Project acts as the robot’s memory: a single playbook document holds the credential, the site map, my writing rules, and the current state. Every session reads it before touching anything, which is what makes session #47 as capable as session #1. Third, scheduled tasks give it a heartbeat. Fourth, a small deploy endpoint lets it write static files with automatic backups. Fifth, the guardrails are written down instead of implied: never delete anything without being asked, draft when unsure, email me after every run.

If you only steal one idea from this post, steal the playbook. Without it, every session starts from zero and you spend your life re-explaining your own website.

Give Claude a key, not your password

WordPress has a feature built for exactly this, and most people have never seen it: Application Passwords. Go to wp-admin, then Users, then your profile, and scroll to the bottom. Generate one, hand it to Claude, and the API accepts it for everything your account can do. Your real login password never gets shared, and revoking the app password takes one click.

The test that proves it works:

curl -u 'you@email.com:xxxx xxxx xxxx xxxx xxxx xxxx' \
  https://yoursite.com/wp-json/wp/v2/users/me?context=edit

If that returns your user record, you’re in business. Have Claude create a draft, edit it, and delete it as a full rehearsal before anything touches real content.

The four dead ends and their fixes

This section is why the post exists. Each of these cost me real time, and each has a fix that takes minutes once you know it.

The Application Passwords section is missing

Some hosts and security plugins turn the feature off. You can check from outside: if curl https://yoursite.com/wp-json/ | jq .authentication returns an empty list, it’s disabled. The fix is either a toggle in your security plugin or one line in a code snippets plugin:

add_filter( 'wp_is_application_passwords_available', '__return_true', 100 );

The right password fails, and so does the wrong one, identically

Memorize this signature. When a wrong password produces the exact same error as the right one, your credential never reached WordPress at all. Something between you and the server is eating the authentication header. In my case it was two layers back to back: the server config, then Hostinger’s CDN. The server fix is one line at the top of .htaccess, above the WordPress block so a permalink flush can’t erase it:

SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

If it still fails after that, temporarily disable your CDN and test again. Mine was stripping the header entirely.

Everything checks out and it still says 401

WordPress fails loudly on a wrong password but silently on a username that doesn’t exist. I had created the app password while logged in as myself, then tried to authenticate as a separate bot user. The password belongs to whichever profile page you were on when you made it. On a personal site, using your own account is fine anyway. Posts get your byline, which is what you want.

Your host’s firewall blocks the code snippets

When I tried to save a snippet with file functions in it, Hostinger’s firewall threw a 403 and refused. The workaround became my standard route: put the code in a .php file and upload it through the hosting file manager into wp-content/mu-plugins/. The file manager doesn’t pass through the same firewall, and files in that folder run automatically.

Schedules: the part where you stop doing anything

Claude’s scheduled tasks spin up a fresh session on a timer. Mine run Tuesday mornings for content and monthly for a health check. Each one reads the playbook, does its work, updates the playbook, and emails me what happened with links to review.

Do yourself a favor and start in draft mode. My playbook has a flag the schedule reads: for the first two runs, posts get saved as drafts and I get an email asking for a review. After two good ones, the flag flips and it publishes on its own. Trust is earned, even by robots.

The prompt that starts everything

You don’t need to design any of this yourself. Open a Claude session inside a dedicated Project and paste this, filled in with your details:

You are a senior web automation engineer. I want you to set up my
website so you can update it automatically from any future session,
with as little ongoing work from me as possible. I'm willing to do
one-time setup work now.

My setup:
- Site: [YOUR DOMAIN] on [HOST + PLAN]
- Platform: [WordPress / other], theme [THEME],
  page builder [BUILDER OR "none"]
- Key plugins: [SEO, FORMS, CACHE, SNIPPETS]
- My content: [BLOG TOPICS, PAGES YOU UPDATE OFTEN]

Your role: research the best architecture for this (prefer the
platform's native REST API with revocable credentials over plugins
or third-party services), then give me a plan with: what you'll be
able to change on your own, setup steps split into "you do" vs
"I do", the security model with kill switches, and how scheduled
runs will work. Ask clarifying questions about scope and autonomy
before finalizing. Save the plan as a playbook document in this
Project so every future session can pick it up. Always explain WHY
before WHAT, give exact copy-paste commands, and flag risks before
changes.

Confirm you understand this brief, then start your research.

From there it walks you through everything else, including writing the code snippets for your specific plugins. When you hit one of the dead ends above, you’ll already know the fix.

Is this safe?

Fair question, and I wanted a real answer before going live. The credential is scoped to one account and dies with one click. The deploy endpoint I use for static files refuses every executable file type, so the API physically cannot write code to my server. That boundary matters: changing PHP still requires a human at the hosting file manager, which is exactly where that line should sit. Everything the automation overwrites gets backed up first, drafts come before publishing, and nothing is ever deleted without me asking.

The one trade-off worth naming: the app password lives in my Claude Project, readable by anyone with access to it. On a personal account, that’s me. If you share your project, rotate the credential.

Questions people ask

Can Claude update a WordPress site automatically? Yes. The REST API plus an Application Password covers posts, pages, media, and settings, and scheduled tasks make it run without you. No plugins are required for the core loop.

Do I need to know how to code? No. You paste a few snippets Claude writes for you and upload one file through your hosting file manager.

Does this work on shared hosting? Mine runs on a regular Hostinger Business plan. The fixes above cover the host-specific quirks I hit.

What does it cost? A Claude subscription and the hosting you already pay for. Nothing else.

Can it edit Elementor or Brizy pages? Not directly, and don’t try. Page builders store layouts in formats nothing should touch programmatically. Route around them with shortcode-based sections, or audit whether you need the builder at all. I didn’t.

What if it publishes something bad? Draft-first mode, an email after every run, WordPress revisions, and a rule against deleting anything. In two months I’ll tell you if that was enough.

If you build one of these, I’d like to hear how it goes. The newsletter is where I write up what breaks and what holds. And if you want to see what else the robot and I maintain around here, the projects page has the tour.