Auto-publishing to WordPress with n8n and AI (without sacrificing quality)

A blog that publishes regularly is an SEO asset; a blog that pushes out machine-generated text with no review is a liability. Between the two sits a well-designed pipeline: n8n pulls a content source (monitoring feed, meeting transcript, product data), an LLM drafts and formats, and the article lands on WordPress as a draft — never live — until a human has read and approved it. This guide builds that pipeline piece by piece — native WordPress node, wp-json REST API, Application Passwords, featured image, categories, SEO fields, and scheduling — keeping the editorial guardrail at the center rather than as an option.

The native WordPress node and the wp-json REST API

n8n ships with a native WordPress node covering the essentials of a post's lifecycle: create, read, and update a post, with title, content, status (draft, publish…), slug, categories, and tags. Under the hood, it talks to the REST API that every WordPress site has exposed for years at https://your-site.com/wp-json/wp/v2/: posts live under /posts, media under /media, categories and tags under /categories and /tags.

That duality is a strength: everything the node doesn't cover (media upload, an SEO plugin's meta fields, custom post types) stays reachable with a plain HTTP Request node pointed at the same wp-json, using the same authentication. So you use the native node for the nominal case — creating the draft — and the raw REST API for the finishing touches.

Authentication: Application Passwords, no plugin required

Since WordPress 5.6, Application Passwords are built into WordPress core — no plugin needed. In the WordPress user's profile (ideally a dedicated n8n account with the Author or Editor role, not your admin account), the "Application Passwords" section generates a dedicated password, revocable independently of the main password.

On the n8n side, the WordPress API credential asks for three fields: the site URL, the username, and that application password. Authentication travels as Basic Auth on every request, which imposes one non-negotiable condition: the site must be served over HTTPS, otherwise credentials travel in plain text. For the complementary HTTP Request calls (media, meta), the same credential can be reused by picking Predefined Credential Type → WordPress in the node.

The reference pipeline: from source to reviewed draft

1. A content source, not a blank page

An LLM starting from nothing produces filler. An LLM starting from precise raw material produces a useful first draft. Three sources that work well as pipeline input:

• A monitoring feed: the week's notable articles aggregated by an AI-powered competitive monitoring workflow, or data extracted from public pages with a supervised AI scraping pipeline, become the basis of a sourced weekly digest.
• A transcript: a webinar or client meeting transcribed via a Whisper transcription and summary pipeline already contains the ideas, the examples, and the vocabulary — the LLM only restructures.
• Product data: a catalog in Airtable or a SQL database, where each row (specs, price, use cases) feeds a written product page — the facts come from the database, not from the model.

2. Drafting and formatting by the LLM

An AI Agent node (or a plain LLM node) receives the raw material and a system prompt that pins down the editorial voice: tone, length, heading structure, banned phrases. The technical detail that changes everything: request structured output rather than a free-form block of text. A Structured Output Parser constrains the model to return JSON along these lines:

{
  "title": "…",
  "slug": "…",
  "content": "<p>…</p>",
  "excerpt": "…",
  "categories_suggestions": ["…"],
  "tags_suggestions": ["…"]
}

Each field then maps cleanly onto the WordPress node, with no fragile regex to carve up the response. The content field can be requested directly as simple HTML (<p>, <h2>, <ul>), which the WordPress editor accepts as-is.

3. Creating the post as a draft

The WordPress node with the Post → Create operation receives the title and content, with these additional fields: Status = draft, the slug, and the category and tag IDs. That status choice isn't an implementation detail — it's the architectural decision of the pipeline: nothing the LLM produces is publicly visible at this stage. The draft sits there, formatted, ready to be reviewed in the usual WordPress editor — the AI saved the time of the first draft; it did not take over the editorial line.

4. Human review before publishing

The workflow then sends a Slack or email notification with the title, an excerpt, and the draft's preview link. Two variants depending on the level of integration you want:

• Simple asynchronous approval: the notification is enough, and publishing happens by hand in WordPress after review. Zero extra machinery.
• In-flow approval: the human-in-the-loop pattern with the Wait node and Slack buttons pauses the workflow; clicking "Publish" resumes the execution, which flips the post's status to publish (or future with a date). Clicking "Reject" archives the draft.

Why is this step non-negotiable? Because the problem with generated text isn't that it's bad — it's that it's plausible. Back in 2014, Christer Clerwall's pioneering study Enter the Robot Journalist (Journalism Practice — see it on Google Scholar) had participants read news texts without telling them which ones were written by software: readers struggled to tell the automated text from the journalist's, and rated it credible and informative — but less pleasant to read. Twelve years on, the lesson still holds: the machine passes the credibility test, not the style or angle test. That's exactly what human review contributes, and it's also what protects the site on the SEO front — search engines explicitly target scaled content produced to manipulate rankings, and a pipeline publishing without supervision mechanically ends up producing exactly that.

Featured image, categories, and tags

The WordPress node doesn't handle media upload: that's the HTTP Request node's job, in two steps.

1. Upload the file — a POST to /wp-json/wp/v2/media with the image binary (generated by an AI image node or pulled from an internal library):

POST https://your-site.com/wp-json/wp/v2/media
Headers:
  Content-Disposition: attachment; filename="featured-image.jpg"
  Content-Type: image/jpeg
Body: the binary file (Body Content Type = n8n Binary File)

The response contains the id of the created media item.

2. Assign it to the post — a POST to /wp-json/wp/v2/posts/{{ $json.postId }} with {"featured_media": <media id>}. The image then shows up as the draft's featured image.

For categories and tags, the API expects numeric IDs, not names. Two approaches: maintain a name-to-ID mapping table in the workflow (stable if the taxonomy rarely changes), or query /wp-json/wp/v2/categories?search=… to resolve them dynamically — while constraining the LLM to pick from the existing list rather than inventing new taxonomies with every article.

SEO plugin fields: possible, but tread carefully

Yoast SEO and Rank Math store their data (meta title, meta description) in post meta fields. Those fields are not writable by default through the REST API: depending on the plugin and its version, you'll need an extension, a setting, or a few lines of code on the WordPress side (register_post_meta with show_in_rest) to expose them. The exact field names vary between plugins and versions — check your plugin's documentation and test on a draft post before industrializing, rather than copying a field name from a dated forum thread. The pragmatic fallback: have the LLM propose the meta title and meta description in its JSON output, include them in the Slack approval message, and let the reviewer paste them into the plugin at publish time.

Scheduling publication

Two mechanisms combine well:

• WordPress side: create or update the post with status = future and a date field set in the future — WordPress publishes on its own at the appointed time, letting you approve on Monday an article that goes out on Thursday.
• n8n side: a Schedule Trigger paces the pipeline upstream (generate drafts every Monday at 8am, for instance). Watch the instance's timezone, a classic source of posts published an hour off — our Schedule Trigger, cron, and timezones guide covers the settings to check.

Good use cases — and what not to do

The pipeline shines when the raw material is factual and the editorial value real:

• Product pages written from a structured database, where every claim comes from a data field. A model grounded in a queryable document base — the architecture of the RAG Assistant Pack ($119) — further reduces the risk of invention by forcing the LLM to cite documentation rather than its memory.
• Controlled programmatic pages: pages built on a shared template from verified data (cities, integrations, comparisons), with sample-based review and reasonable volumes.
• A monitoring digest: a sourced weekly summary of industry news, where the LLM condenses and the human validates the angle. The same draft can also feed other channels, following the model of the automated LinkedIn publishing pipeline.

By contrast, generating dozens of articles a day on keywords with nothing to say, no source, and no review is the textbook case of scaled content abuse: at best ephemeral traffic, more likely a degraded domain reputation. The referee remains measurement: a weekly SEO report wired to Search Console will quickly tell you whether the content the pipeline publishes ranks and earns real clicks — or dilutes the site.

Wrapping up

The pipeline comes down to five building blocks: a real content source (monitoring, transcript, data), an LLM with structured output for the first draft, the WordPress node creating the post as a draft, human approval via Slack or email, and the wp-json API through HTTP Request for the featured image and finishing touches. The automation covers the mechanics — fetching, drafting, formatting, scheduling — never the editorial judgment. That division of labor, not prompt quality, is what separates a blog that climbs from a blog that spams.