AI Blog Automation in WordPress: The Setup That Does Not Get You Penalised

Automating blog posts into WordPress is straightforward: a trigger, a generation step, and a call to the REST API that creates a draft. The plugins in this space all do roughly that. The part that decides whether it works is not the plumbing, it is whether a person reads the output before it publishes, and the setups that skip that step are the ones that end up rolled back.

Google’s position is that AI-generated content is not inherently a problem and content produced primarily to manipulate rankings is, regardless of how it was made. That distinction is the whole design constraint, so it is worth building around rather than testing.

Table of contents

• The three approaches, and what each costs
• Publishing through the REST API
• Why fully automatic publishing fails
• A pipeline that produces something worth publishing
• The practical operating rules
• How this fits the rest of the stack
• FAQ

The three approaches, and what each costs

Everything in this space is one of three shapes.

Plugins that generate inside WordPress. You install something, connect a model provider’s key, and generate from the post editor or on a schedule. Simplest to set up, and the content pipeline lives inside WordPress where it is hard to version, test, or reuse.

Workflow tools posting into WordPress. A tool such as n8n runs the pipeline, calls whichever model you want, and publishes through the WordPress REST API. More setup, and the pipeline becomes something you can inspect, run in stages, and use for other destinations.

Custom code against the REST API. Complete control, and you maintain it.

The recommendation is the middle one for anything ongoing. The reason is not sophistication, it is that generation is rarely one call. A useful pipeline researches a topic, drafts, checks the draft against something, generates an image, sets categories, and creates a draft for review. That is a workflow, and workflow tools are better at workflows than a plugin settings page.

The plugin approach earns its place when the volume is low and the person doing it does not want another system to run. That is a legitimate position and not a compromise.

Publishing through the REST API

Whatever generates the content, this is how it gets in. Application passwords are the mechanism, created per user in the WordPress profile screen, and revocable individually.

curl -X POST https://example.com/wp-json/wp/v2/posts \
  -u "editor:xxxx xxxx xxxx xxxx xxxx xxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "The post title",
    "content": "<p>The body, as HTML.</p>",
    "excerpt": "A short summary.",
    "status": "draft",
    "categories": [12],
    "tags": [34, 56]
  }'

Four things worth getting right from the start.

• Use draft, not publish. This is the single most important line in the whole setup.
• Create a dedicated user with the Editor role rather than using an administrator account. The application password inherits that user’s capabilities.
• Categories and tags are numeric IDs, not names. Look them up once and cache the mapping, or every post lands uncategorised.
• Content is HTML. Sending markdown produces a post with visible asterisks and hashes, which is a common and very obvious failure.

Featured images are a two-step process: upload to the media endpoint, take the returned ID, and set it as featured_media on the post. A single call cannot do both.

# 1. Upload, and keep the id from the response.
curl -X POST https://example.com/wp-json/wp/v2/media \
  -u "editor:${APP_PASSWORD}" \
  -H "Content-Disposition: attachment; filename=header.jpg" \
  -H "Content-Type: image/jpeg" \
  --data-binary @header.jpg

# 2. Attach it.
curl -X POST https://example.com/wp-json/wp/v2/posts/123 \
  -u "editor:${APP_PASSWORD}" \
  -H "Content-Type: application/json" \
  -d '{"featured_media": 456}'

Why fully automatic publishing fails

The temptation is obvious: remove the human and the content produces itself. Here is what actually happens.

Generated posts converge. Ask a model for an article on a topic and it produces the consensus view in the consensus structure, because that is what it was trained to do. Fifty posts generated this way have the same shape, the same hedging, and the same absence of anything specific to you. Readers notice within two posts, and there is no reason for anyone to link to it.

Factual errors publish themselves. Not often, but the ones that get through are confident, specific, and wrong, and they sit on your domain with your name on them. A single incorrect technical instruction that breaks someone’s production system costs more trust than fifty adequate posts build.

And it scales badly in exactly the wrong direction. The reason to automate is volume, and volume is what makes low-quality content actively harmful rather than merely useless, because it dilutes the pages that were working.

The setup that works keeps a person in the loop at one point: nothing publishes without a human reading it. That single constraint eliminates most of the risk and costs a few minutes per post.

Everything else can be automated. Research, drafting, image generation, internal link suggestions, category assignment, scheduling. The review step is the one to keep.

A pipeline that produces something worth publishing

Generation quality is mostly a function of what you give the model, not which model you use. A pipeline that adds real input outperforms one that adds prompt engineering.

1. Start from a keyword with actual demand, from a real keyword source rather than a topic somebody imagined.
2. Fetch what currently ranks for it and extract the structure: what every result covers, and what none of them do. The gap is your angle.
3. Generate against that research, with an explicit brief including the angle, the audience, and the things you specifically do not want said.
4. Add what only you have. A product detail, a real number, an opinion, something you learned the hard way. This is the step that separates your post from every other generated one, and it is the step most pipelines omit.
5. Check the claims. Anything specific and factual gets verified, and anything unverifiable gets removed.
6. Create as a draft, with the featured image, categories, and internal links already set.
7. A person reads it, edits it, and publishes.

Step four is where the value is. Steps one through three are commodity work that any pipeline does, and the output of steps one through three alone is the generic article everyone else is publishing.

In practice a good pipeline gets you to a draft that is eighty percent there and needs a person for the twenty percent that makes it worth reading. That is a large productivity gain and it is not the same as removing the person.

The practical operating rules

• Publish as draft, always. Set the status field to draft and never make it configurable, so nobody can turn the safety off on a busy day.
• Attribute honestly if your jurisdiction or audience expects it, and keep an internal record of what was generated either way.
• Rate limit the pipeline. A bug in a loop that publishes 400 drafts overnight is a real event that happens to people.
• Store the model provider key as an environment variable, never in a plugin settings field that ends up in a database backup shared with a contractor.
• Monitor which posts actually get traffic. If generated posts consistently do not, the pipeline is producing cost rather than value and should be stopped or changed.
• Prune. Content that never performs is not neutral, and removing it is a legitimate action.

The last two are what separate a content operation from a content spigot. The point of measuring is to be willing to conclude that it is not working, and a pipeline nobody evaluates will run indefinitely regardless of whether it helps.

How this fits the rest of the stack

The workflow half of this needs somewhere to run that is not a laptop: a scheduled trigger fires whether or not anyone is at their desk, and a failed run needs a log rather than silence. n8n is available as a managed tool on RunxBuild with its own plan, custom domains, environment variables, and logs, alongside a managed Postgres instance, and WordPress plans start at $3 a month. The RunxBuild hosting calculator shows those as separate line items.

Useful related references:

• How to Duplicate a Page in WordPress, With and Without a Plugin
• CSS Animations in WordPress Without a Plugin or a Performance Hit
• A WordPress Plugin Stopped Working: The Debug Order That Finds It
• Services on RunxBuild

FAQ

Does Google penalise AI-generated content?

Not for being AI-generated. Google’s stated position targets content produced primarily to manipulate rankings, regardless of how it was made. Generated content that is genuinely useful is treated on its merits, and generated content that is filler is treated as filler.

How do I publish to WordPress automatically?

Through the REST API using an application password created for a dedicated Editor-role user. POST to /wp-json/wp/v2/posts with HTML content and status set to draft. Categories and tags are numeric IDs rather than names.

Should AI posts publish automatically?

No. Keep a human review step before publishing. It is the single constraint that removes most of the risk from factual errors and generic output, and it costs a few minutes per post while everything else stays automated.

Why does my automated post show asterisks and hashes?

Markdown was sent where the REST API expects HTML. Convert the generated markdown to HTML before posting, or the raw syntax renders as literal characters in the published post.

What is the best way to run an AI content pipeline for WordPress?

A workflow tool posting through the REST API, rather than a plugin generating inside WordPress. A useful pipeline has several stages, and a workflow tool lets you inspect, test, and rerun each one independently.