I tried to let an AI post to my own blog. It took four dead ends to get there.
I own the server. I own the domain. I have the admin password. And for most of a Thursday evening, I could not get an AI assistant to publish a single word to my own website.
I own the server. I own the domain. I have the admin password. And for most of a Thursday evening, I could not get an AI assistant to publish a single word to my own website.
That gap — between “I own this” and “I can automate this” — turned out to be the interesting part.
The first assumption that was wrong
I assumed credentials were the problem. So I did what seems obvious: I generated a WordPress Application Password and handed it over. Application Passwords are the sanctioned way to let software talk to your site through the REST API. Scoped, revocable, no admin password anywhere. Textbook.
It didn’t help. Not because the password was wrong, but because the assistant’s environment could only reach a short allow-list of domains — GitHub, PyPI, a handful of others. My site wasn’t on it and couldn’t be added. The request would never leave the building. I’d handed over a key to a door on a street with no road to it.
I offered to create a limited Editor account instead, thinking a lower-privilege user might pass some check. It changed nothing. When there’s no network path, permission level is irrelevant. That took me longer to accept than I’d like to admit.
The second dead end cost me nothing but time
Next: Jetpack. My site is self-hosted, but Jetpack links a self-hosted install to WordPress.com’s infrastructure, and there’s an API on that side. Install, connect, done.
The connection worked immediately. The API access did not. For self-hosted sites, that particular door needs a paid Jetpack plan. My free tier could see the site; it couldn’t write to it.
I want to be fair here: this is not a scandal. Running that infrastructure costs money and Automattic is entitled to charge for it. But it’s worth knowing before you spend an evening assuming free means free.
The thing that actually worked was embarrassingly simple
Here’s what I’d missed. The wall was one-directional. Nothing could reach in to my site — but my site could reach out to anywhere it liked.
So instead of trying to open a door, I built a pipe.
The AI publishes to a free blog I already had, tagging the post bridge. A small plugin on my own site checks that blog every five minutes using a public API, finds anything tagged bridge, and republishes it locally. About 200 lines of PHP. No paid plan, no credentials shared with anyone, no third-party service in the middle.
It’s been running since. I say “post this to my site” and roughly four minutes later it’s live, with a generated featured image, because I taught the plugin to make one when a post arrives without.
What I’d tell someone starting this
Three things.
Check the direction of the wall before you attack it. I spent two hours trying to get something in when the answer was to have my server reach out. Firewalls, API restrictions, allow-lists — they’re almost never symmetrical, and the permitted direction is usually the one nobody’s thinking about.
Free tiers are real, but read where they stop. Jetpack connecting my site for free was genuine. Write access being paid was also genuine. The mistake was mine for assuming the first implied the second.
Own the middle. I could have paid for a plan, or wired in a third-party automation service. Instead the whole thing is a plugin file I can read, sitting on a server I control. When it breaks — and it will — I don’t have to file a support ticket. I open the file.
The next thing I want is for this to run the other way: my site pushing a summary out to Telegram when something publishes. Same principle. Outbound is the easy direction. I should have started there.
