How do you build an AI workflow for blog creation?

You build it by settling three things before you write a single prompt: which source material the workflow is allowed to draw on, what it has to do when a fact is missing, and who reads the draft before anything publishes. The prompt is the easy part. Those three decisions are the difference between a process you can run every week and a draft that sounds like anyone's business.

I run blog creation this way in my own business, so what follows is the shape I actually use.

TL;DR

• The source material decision changes the output more than the prompt does. Keep the material that teaches the workflow how you write separate from the material that supplies the facts for this particular post, because they do different jobs and carry different risks.
• Training a brand voice on competitors' articles, which is what one popular template openly suggests when you have no archive of your own, produces exactly the generic draft you were trying to avoid.
• Write the missing-fact rule into the instructions: name the gap and stop, never write around it. A visible gap costs minutes. An invented figure costs you whenever someone finally checks it.
• Human review sits last, immediately before publishing, and it's the part you can't compress. Whatever a person who knows the business can genuinely read is your real publishing capacity.
• I won't tell you AI-assisted writing will lift your rankings or your traffic, and I'd be careful with anyone who does. Google's spam policies treat mass-generated pages of little value as abuse no matter how they were made.

Why do AI blog drafts come back sounding like anyone's business?

Because the assistant had nothing of yours to work from, so it wrote the average of everything else it had seen. That's the entire mechanism. You asked a general-purpose model a general question, and it answered generally.

Search this topic and the first page is mostly workflow templates and product pages, with the tool named before the process. The templates aren't wrong about the fix. One widely used n8n template solves the voice problem by importing five recent articles from a blog, then running one model step to work out the article structure and writing style and another to identify the brand voice characteristics, and using both as guidelines when it generates the new post 1. That's a sound mechanism. Your writing becomes the pattern instead of the internet's writing.

Then the same template's requirements say a source of text-heavy content is needed to break down brand voice accurately, and add: "Don't have your own? Maybe try your competitors?" 1

Read that again, because it's the whole problem in one line. If you learn your voice from your competitors, you have built a machine for sounding like your category. The template is being honest about a real constraint. It just doesn't have your archive, and neither does any tool that only gets your website URL.

What source material should an AI blog workflow be allowed to use?

Two separate piles, both named in advance, plus a short list of things the workflow must never treat as evidence.

The first pile is voice and structure. This is your own published or approved writing: articles, long emails you were happy with, a transcript of you explaining something properly. Its only job is to teach the workflow how you build a sentence, how long you let an explanation run, and what you'd never say. Nothing in this pile is a fact source.

The second pile is facts for this specific post. Prices you allow in public, what's actually included, what you really did for a customer, dates, names, the limits of a claim. This pile is narrow and it's per article. It's also the pile you'll spend the most time assembling, and the one that decides whether the draft is publishable. If you want the detail on how to assemble it, we cover what belongs in the source layer separately.

The exclusions matter as much as the piles. Three things I keep out of the fact pile:

• Your own old blog posts. They belong in the voice pile and nowhere near the facts. If a previous post contains a figure nobody can trace, feeding it back in launders that error into the next post, and then into the one after that. Old copy is a record of what you published, not evidence that it was right.
• Competitor articles. Fine for working out what a reader expects a page to cover. Not a source for anything you assert.
• Whatever the model already knows. It knows a general version of your industry and none of your business. Anything specific it produces that you didn't supply is a guess that reads like a fact.

What should the workflow do when a fact is missing?

Name the gap and stop. That rule goes into the instructions in writing, as a behaviour, not as a plea to be careful.

The version I use says: if a fact the draft needs isn't in the supplied source material, leave a visible marker naming exactly what's missing and who can supply it, and don't write around it. No plausible-sounding substitute, no hedged sentence that implies the fact without stating it, no quiet omission of the paragraph that needed it. The rule belongs in the rules layer of your instructions, and it's the one input most people skip.

This matters because the failure is invisible. A model is exactly as fluent when it's wrong as when it's right. Dom Kirby, who writes up his own AI-assisted process in some detail, puts it plainly about technical research: "Claude will happily, and confidently flat out lie to you." 2 The same applies to your pricing, your past jobs, and anything with a number in it. A gap you can see costs you a two-minute lookup. A confident invention sits in a published post looking identical to everything true around it.

There's a second reason the rule pays for itself. When the missing-fact marker fires three times on one article, that's usually the workflow telling you the article shouldn't be written yet. You don't have the material. Deciding that before the draft exists is much cheaper than deciding it after someone has spent an hour trying to rescue a paragraph.

Human review belongs last, and it's the part you can't compress

The review happens after the draft is complete and before anything publishes, and a person who knows the business reads the whole thing.

Both ends of this market agree on the placement, which tells you something. The n8n template finishes by saving a draft to WordPress for human editors to review or use as a starting point for their own articles 1. Dom Kirby, at the other end of the scale with no pipeline at all, does a manual full read before publishing and says of that step: "To me, this step is what keeps the content from just being AI generated." 2

What the reviewer is actually doing is narrower than "editing". Three checks:

1. Every specific claim traces back to the supplied source material. Not "sounds right". Traces back.
2. Nothing appeared that you didn't give it. New statistics, new customer outcomes, a confident sentence about a competitor. Anything that arrived from nowhere gets cut, not softened.
3. The article says something a reader couldn't get from the first four search results. If it doesn't, the problem is the brief, not the draft, and rewriting sentences won't fix it.

There's more on that in how to check AI output, including what sends a draft back rather than gets fixed in place.

One honest condition on all of this. The reviewer has to be someone who would notice. If nobody available can tell whether a claim about your own service is right, you don't have a review step. You have a publish step with a delay in front of it.

Which five inputs do you write down first?

Context, Task, Source, Rules and Output. We teach these five in the workshop because once they're written down you have instructions you can run again, instead of a prompt you got lucky with once. For a blog workflow they look like this:

• Context. The business, the customer, and the situation this post is written for. Who is reading it and what decision are they making.
• Task. One post, one question, one reader. Not "write about AI".
• Source. The two piles above, named by document, with the exclusions stated.
• Rules. The limits. The missing-fact rule, the claims you never make in public, the words you don't use, the things only you are allowed to approve.
• Output. The format, and what has to appear under each heading, so the draft can be compared with a written standard rather than a mood.

Rules is the input that gets skipped and the input that does the most work. You can see the full breakdown in the five-input prompt.

How do I run blog creation in my own business?

At Searchmaxxed, my own business, we built AI workflows for creating blog posts, doing SEO and preparing custom proposals. The blog one has a shape that's more specific than a prompt, and it's the part I think transfers.

The writing step gets a written assignment rather than a chat message. That assignment names the article and the question it has to settle, lists the source files it's allowed to read, supplies the voice material, lists the internal links that exist, states the phrases we don't use, and gives it a folder of its own to write into. It has no permission to touch the live site. That last part isn't a safety slogan. It's what lets me hand the step a lot of context without handing it the ability to make a mistake in public.

It returns more than an article. It returns the draft, a brief showing what it researched and why it chose that structure, a source list where every outside claim carries a real URL and the exact sentence it came from, the page metadata, and a candid note on what it couldn't verify. Those extra files exist for one reason: they make my review fast. Checking a claim against a named excerpt takes seconds. Checking an unsourced claim means doing the research again myself, which is the expensive failure mode that makes people give up on AI writing altogether.

Then I read the whole thing, and the decision to publish stays with me.

What decides the topic sits upstream of all of it. My AI workflows for SEO feed the choice, so the question is what the market evidence says should be written next rather than what a content calendar guessed in January. That connection between evidence and the next action is the part I find genuinely interesting, and I've written more about how I run my business on AI workflows if you want the wider picture.

Be clear about the boundary, though. This is a workflow that retrieves, drafts and revises. It doesn't publish, it doesn't spend money, and it doesn't decide what's true.

Volume is limited by review, not by generation

Generating a draft is now close to free and close to instant. So the constraint has moved, completely, to review.

Which gives you a real number. Your publishing capacity is how many complete articles a person who knows your business can read carefully in a week. For most small businesses I'd put that closer to one or two than to ten. It isn't a mindset problem and no tool changes it, because the reviewing is the part that requires knowing things.

The market sells you a different number. One vendor's guide to this exact topic states that its own team scaled its own content "from 70k to over 750,000 daily impressions in just three months" using its own product 3, which is a self-measured claim about the thing being sold, with no independent verification and no revenue attached to it. Another platform advertises "Guaranteed quality" and promises to "Achieve 100% brand and voice consistency" 4, which is not a claim anybody can keep. A third sells a humanizer feature promising content that "Bypasses tools like ZeroGPT and Winston AI" and is "Undetectable AI content" 5. Look at what that feature is for. It isn't a better article. It's an article that survives a detector, which is a quiet admission that the output wouldn't stand up on its own merits.

Meanwhile, Google's spam policies name scaled content abuse as "when many pages are generated for the primary purpose of manipulating search rankings and not helping users", describe it as "creating large amounts of unoriginal content that provides little to no value to users, no matter how it's created", and list using generative AI tools to generate many pages without adding value as an example. The same document says sites that violate the policies "may rank lower in results or not appear in results at all" 6.

So I'm not going to tell you a blog workflow will improve your rankings or your traffic. What I'll tell you is the shape of the risk: publishing past the point where you can review moves you towards the practice Google explicitly names, and the volume you can review is a business constraint rather than an attitude to fix.

How do you tell whether the workflow is working?

Measure the review, not the output. Four numbers tell you most of it.

• Review time per article, and whether it's falling. This is the one that matters commercially. A workflow that halves review time on the fifth article is working. One where review takes as long as writing did is not.
• Facts corrected per article. Rising means your source material is stale or the wrong pile is being used.
• Drafts sent back, and the reason. A missing fact, a wrong claim and a flat argument are three different faults with three different fixes. The reason is more informative than the count.
• How often the missing-fact rule fires. A workflow that never reports a gap is either perfectly sourced or quietly filling holes. Assume the second until you've checked.

Published volume is the last thing to measure, not the first. If you want to put numbers on the time side properly, we cover how to measure what an AI workflow saves.

Where can you build this with help?

Two ways, and the choice is mostly about whether this is your workflow or your team's.

If it's yours, bring it to the public Sunshine Coast workshop. You get a full day in person to put AI to work across your business, and you build it on your own laptop with hands-on help.

If blog work moves between people, a writer drafting, a manager approving, someone else publishing, then the review step is the thing that needs designing and it needs the actual people in the room. That's private onsite AI training: we come to your workplace, scope the session around your team's tasks and experience, and quote a fixed price after that conversation. Sessions are scoped for roughly 4 to 20 people, and larger teams can be split across sessions. Private onsite training is available on the Sunshine Coast and in Brisbane, Gold Coast, Ipswich, Noosa, Moreton Bay, Logan, Redlands, Toowoomba and Gympie, and people from other areas can travel to the Sunshine Coast public workshop.

Frequently asked questions