Stock & Insurance needed a steady stream of blog content on their WordPress site without a writer on staff generating it manually every week. The brief was specific: real, publish-ready posts, not thin AI filler, going in as drafts for a human to review before anything goes live, with enough built-in quality control that a bad output doesn't quietly become a published page.
What we built
A daily n8n workflow that runs at 9AM IST, pulls the next pending topic from a shared Google Sheet, generates a complete blog post against the client's actual WordPress category list, and drops it in as a draft with the post's edit link waiting in the sheet, ready for review. No topic gets touched twice, no failure disappears silently, and nothing publishes without a person looking at it first.
The flow, step by step:
Scheduled trigger fires once daily and pulls every row marked Pending from the topic sheet.
One topic at a time, processed sequentially rather than in parallel, so a single API hiccup doesn't cascade across a whole batch.
Live category fetch from the client's actual WordPress site before writing anything, so the model is picking from real, existing categories instead of inventing new ones that would need manual cleanup later.
Prompt construction that bakes in the client's actual requirements as hard constraints: minimum 2,000 words, no em dashes, no fabricated statistics, valid HTML output, a meta description under 155 characters, an SEO-friendly slug, and category selection restricted to the real list just pulled from WordPress.
Generation via DeepSeek through n8n's LangChain integration.
Parsing and a real quality gate: the response comes back as one line of structured metadata, a delimiter, then the raw HTML body, a deliberate format choice covered below. If the generated content lands under 1,800 words, it never reaches WordPress at all, it gets flagged Needs Review - short content in the sheet instead.
Draft creation via the WordPress REST API, status set to draft, never publish, so every post gets a human check before it's live.
Status logging back to the same sheet row, either a direct link to the new draft's edit screen on success, or a specific error message on failure, so nothing requires digging through workflow execution logs to understand what happened.
The engineering decisions worth calling out
Splitting metadata from content instead of nesting it all in one JSON blob. Long-form HTML content embedded inside a JSON string is a reliable source of escaping failures, stray quotes, line breaks, and special characters inside a 2,000-word post breaking JSON parsing in ways that are painful to debug. The workflow sidesteps this by having the model output one line of clean JSON metadata (title, slug, meta description, tags, category ID), a plain delimiter, then the full HTML body as raw text, not JSON-escaped at all. Parsing splits on the delimiter and only JSON-parses the small metadata line, the part that's actually safe to treat as JSON.
A real word count gate, not a hope that the model behaves. The client's requirement was substantial, well-developed posts, not thin 500-word filler. Rather than trust the prompt alone to enforce that, the workflow checks actual word count against the generated HTML and routes anything under 1,800 words to a review queue instead of WordPress. The prompt asks for 2,000+; the gate enforces a realistic floor with some tolerance, catching the cases where generation comes up short without blocking on an unnecessarily strict threshold.
Draft, not publish. Every post lands as a WordPress draft. This was a deliberate choice, not a default, automation handles the repetitive work of research-adjacent writing and formatting, a human still makes the final call on what actually goes live on the client's site.
Category matching against the live site, not a static list. Categories get fetched fresh from WordPress on every run rather than hardcoded once, so if the client adds or restructures categories on their end, the workflow picks that up automatically instead of drifting out of sync with the actual site.
Error handling on every step that can fail. The category fetch, the prompt build, the generation call, the parsing step, and the WordPress post creation all route their failure output to a centralized error logger that writes a clear status and message back to the sheet, rather than letting the workflow die silently or dump a raw stack trace nobody can act on.
Error handling on every step that can fail. The category fetch, the prompt build, the generation call, the parsing step, and the WordPress post creation all route their failure output to a centralized error logger that writes a clear status and message back to the sheet, rather than letting the workflow die silently or dump a raw stack trace nobody can act on.
Status
Live and running daily for Stock & Insurance. The client manages their topic queue directly in the shared sheet, marking rows pending as new ideas come up, and reviews each generated draft before publishing, with the workflow handling the research-adjacent writing, formatting, and WordPress upload end to end.
Flowagenz builds n8n content and workflow automation like this for clients who want AI doing the repetitive work with a human still making the final call. Happy to talk through what this could look like for your own site.
Let's create something together
Get in touch with us today.
