A single n8n workflow that writes articles for every client does not work. I know because I built one, ran it across several clients, and ended up spending more time fixing its output than I would have spent writing the articles myself.
What worked was slower on paper. I collect the client’s own information on the topic, have an LLM draft one section at a time, and edit each section line by line before asking for the next. This article covers what went wrong with the automated version, the process I use now, and the parts of the job I still automate.
What I built: one workflow for every client
The idea is one every agency has at some point. Give the workflow a keyword and a client name, pull the client’s previously published posts so the new article copies their style, send everything to an LLM, and push the finished article to WordPress as a draft.
One build, many clients, and a stack of drafts waiting each morning. I ran it across 20 clients over 2 months.
On paper it removes the slowest part of the job. In practice it moved the slow part somewhere worse.
Why every article came out generic and identical
There were two separate problems, and they had different causes.
The articles were generic because the workflow knew too little
A workflow that knows a keyword and a company name has nothing to write with except what it already knows about the industry. Take a geyser repair article for a plumbing client. The model will explain what a geyser is, list the usual faults, and tell the reader that regular maintenance is important. It will not mention the client’s callout fee, the suburbs they cover, or the fault they see most often in winter, because nobody told it any of that.
The result is a set of sentences that fit any plumber in any city. A reader gets nothing from it that the next result on the page does not already say.
The articles looked the same because I fed it the old posts
Pulling previous published pages to copy the style sounds sensible. Style means voice: how the client talks to a customer, which words they use, what they would never say. A model reading old posts picks up structure instead, because structure is the easiest thing to copy.
So every new article had the same intro length, the same number of H2s in the same pattern, and the same closing paragraph. Each new post was generated from older posts that were generated the same way, so the pattern hardened with every article. After a handful of posts the blog looked like one template with the keyword swapped.
Editing the output took longer than writing from scratch
I assumed editing a finished draft would be quicker than starting with a blank page. It was not.
When you write something, you know where the gaps are. When you edit a 1,500-word draft you did not write, you have to find them. The draft is also plausible, which makes the weak parts harder to see. A paragraph that says nothing still reads like a paragraph.
Fixing individual sentences did not help, because the problem was missing substance: the real prices, the local detail, the way the client talks. That meant rewriting most sections, after first working out which ones needed it.
Writing from scratch was faster, and the result was better.
The WordPress draft step created its own problems
The last step of the workflow created the article as a draft in WordPress, which seemed like the neat finish. It opened a different set of problems.
The HTML the workflow produced did not match what the WordPress editor expected, and the CSS in the editor did not match the theme’s CSS on the live page. Headings, lists, tables and spacing came out looking wrong, and the article looked different in the editor than it did in preview. Each client’s site also had its own theme and plugins, so there was no single output format that suited all of them.
Cleaning the formatting took a second pass on every article, which cancelled out whatever time the automation was supposed to save.
The process that worked: client information first, then one section at a time
This is what I do now.
- Gather what the client knows about the topic. This means their services, prices or price ranges, areas covered, the questions customers ask most, mistakes they see people make, a recent job, and anything they never want said.
- Build the outline myself from the search intent and the client notes. The model does not decide the structure.
- Give the LLM one section at a time, with only the client notes that apply to that section.
- Edit that section line by line before asking for the next one.
- When a pattern bothers me, change the next prompt so it stops.
- Assemble the article and do the formatting by hand in the CMS, then check the preview on the live theme.
Each section prompt sits on top of an LLM project that holds a long list of standing instructions: the tone, the structure, and a list of AI tells to avoid. That list took months, in places years, of trial and error to build, and it grows every time a draft shows me something I do not want to see again. A section prompt can stay short because the project already carries all of that.
Here is the shape of a section prompt. The client and the figures are made up for the example:
Client notes: callout fee R650, covers Bellville, Durbanville and Parow,
most geyser jobs are element or thermostat replacements.
Heading: What a geyser repair costs
Write 200 to 250 words. Use the figures in the notes and add no other figures.
Plain language. No sales pitch.The instruction to add no other figures came from trial and error. Picture a draft for a client who has traded for six years that says “over 20 years of experience”. Nobody gave the model that number. It wrote it because it sounds like something a plumbing company says. Once you have seen that happen, you add a line to the project instructions, and it stops. Every line in that list has a story like this behind it.
This works for three reasons. The model has real specifics to write from, so the section cannot drift into advice that fits any business. You catch problems while the text is 250 words long and not 2,000. And you stay the author, so the voice stays consistent for each client without copying old posts.
It is slower per article than the workflow promised. It is faster than the workflow delivered, because nothing needs to be rewritten afterwards.
Why generating a whole article gives the model more room to hallucinate
The biggest risk of generating an entire article in one go is that the model states things that are false, with the same confidence as the things that are true. A longer output gives it more chances to do that.
There is research behind this. In 2023, Min et al. built FActScore, which splits a generated text into single facts and checks each one against a reliable source. When they scored biographies written by ChatGPT, only 58% of the facts were supported. That was an older model writing about people of varying fame, so it is not the error rate you will see on a plumbing blog today. It does show how much of a fluent, confident text can be unsupported.
A 2025 study by Zhao et al., published in ACL Findings, tested length directly. They found that longer responses have lower factual precision. Of the three explanations they tested, the main one was what they call facts exhaustion: the model gradually runs out of reliable knowledge on the topic and starts producing less reliable statements to keep going.
For client work, that matches what I saw. A model asked for 1,500 words on one keyword has a few solid facts about the industry and almost nothing about the client. Somewhere in the second half it runs out and fills the gap. The invented price, the made-up years of experience and the service the client does not offer all tend to turn up there, and they sit in the middle of paragraphs that read perfectly well.
Drafting section by section reduces this in a practical way. Each section is short, and each one arrives with the client notes it needs, so the model is not working from memory when it reaches the specifics. Editing at 250 words also means I check each claim against the notes while the notes are still open in front of me.
On a client’s site, one wrong figure is more than an embarrassment. A quoted price that is not the client’s price becomes a promise to a customer. That is the part of the job I would not hand to a workflow.
What I still automate
Not everything needs a human. The repeatable parts of the job that involve no judgement are good candidates: keeping each client’s information in one structured document, pulling Search Console data into a report, and checking a finished draft for missing meta descriptions or broken links.
The rule I use is simple. If a step needs a decision about what to say to this client’s customers, a person does it. If it moves or checks information, automation can.
Mass content works until a core update
Some of the pages from the automated workflow did rank. Then a Google core update arrived and we lost those rankings.
Google’s spam policies describe this pattern as scaled content abuse: producing many pages mainly to rank, with little original value for the reader. The policy applies whether the pages come from automation, people, or a mix of both. Pages that read the same and say nothing specific to the business fit that description whatever tool made them.
Every few months a video or a LinkedIn post announces that SEO is dead because of AI and automation. In my experience the sites that hold their rankings still have a person behind the writing and the direction, deciding what the article should say and checking that it says it. I learnt that the hard way by following the hype of mass content production.
FAQ
Can n8n write SEO articles for you?
It can produce them. I would not publish them unedited. In my case the output was generic, the formatting was identical across articles, and fixing both took longer than writing from scratch. A full article in one pass also gives the model more room to state things that are false.
Is AI-written content bad for SEO?
Google says that using AI is not against its guidelines when the content is helpful. What gets sites in trouble is publishing large volumes of thin, similar pages. The tool is not the problem. The lack of original information and editing is.
Should you publish straight to WordPress from a workflow?
I would not. Send it to a draft at most, and check the preview on the live theme before anyone clicks publish, because the editor view can hide formatting problems.
If you are about to set up a content process for several clients, start with the client information document. Every other step depends on it, and building one takes an afternoon.
