Producing 30 articles a month with AI is easy. Producing 30 articles a month that rank, read like a human wrote them, and survive a manual review — that is the real problem. Here is the workflow that actually scales.
Background
In 2026, Google’s helpful-content systems have gotten significantly better at detecting AI-shaped writing — the giveaway is not vocabulary, it is structure. Lists of 5 with parallel headings, “in conclusion” paragraphs, no specific examples, no opinion. You can still ship AI-assisted articles at volume, but the workflow has to put a human in the loop at the points where machines fail: topic selection, factual claims, and voice.
How to tell
- You are publishing fewer than 4 articles a week and want to get to 10+ without hiring writers.
- Your existing manual articles have a clear voice you can describe in 3-4 sentences.
- You have a system for capturing real questions from readers, support tickets, or forums.
- You can spend 30-45 minutes editing each draft, not zero.
Quick verdict
AI scaling works when the human stays in the loop on topic, facts, and tone, and is removed from the loop on structure, transitions, and first-draft prose. Reverse that and you publish slop.
Step by step
Each step gives a copy-paste prompt / template / shell command.
-
Write a 1-page style guide: save as
style_guide.md, paste into every prompt:# Content Style Guide ## Voice - First person (I / we), no "the reader" / "you" filler - Direct: avg sentence length ≤14 words - No adjective stacks: forbidden — "very", "really", "incredibly", "engaging" - No marketing speak: forbidden — "Introducing", "Excited to announce", "revolutionary" ## Default structure (every article) - First line: concrete claim or counter-conventional opener (not "This article will") - "When to use / When NOT to use" short subsection - "Step by step" numbered list — every step carries code / command / number - "Common mistakes" 3-5 items - No "In conclusion" paragraph ## Link conventions - Internal links use absolute paths starting with / - External links → original source + publication date - At least 3 internal links to existing articles per piece ## Banned phrases (full-text grep must return 0) comprehensive, robust, powerful, essential, seamless, empower, ecosystem, disrupt, crucial, indispensable, game-changer, delve into, tapestry, navigating, in today's fast-paced -
Build the topic pipeline: a 50-100 row CSV. Never let AI choose:
slug,question,target_keyword,intent,evidence_required,priority nextjs-deploy-vercel,How to deploy Next.js to Vercel,nextjs deploy vercel,how-to,"3 config screenshots,1 next.config.js block",P1 ...intent=how-to / what-is / comparison / troubleshoot / opinion.evidence_required= the specific evidence to collect before publish. -
One unified drafting prompt per article: only the placeholders change:
Below is our style guide and the current task: --- STYLE GUIDE --- <paste style_guide.md in full> --- THIS TASK --- Topic: <question from the pipeline> Target keyword: <target_keyword> Reader intent: <intent> 3-5 facts / experiences I must include (these are from me — do NOT fabricate): 1. <fact 1, e.g. "Vercel Hobby includes 100GB/month bandwidth free"> 2. <fact 2> 3. <fact 3> Before writing the body, do exactly 2 things: 1. Outline (H2s + H3s + each section's ≤10-word promise) 2. Map: which section will absorb each of my 3-5 facts I'll review and approve, then you write the body.Human-review the outline + fact mapping, then let it draft.
-
Editorial checklist: every draft must pass these 5, write as
editorial_checklist.md:- [ ] Opening line: not "This article" / "In today's"; concrete claim / counter-conventional / number - [ ] Every claim has 1 piece of concrete evidence (number, tool version, screenshot, personal) - [ ] At least 1 counter-conventional paragraph (specify which one) - [ ] No 5-bullet parallel-structure filler list - [ ] Ends on the last concrete point — no "In conclusion" Check each box and note "yes / which section". Only then proceed to fact-check. -
Fact-check pass: AI hallucinates numbers / product names / dates most:
# Surface everything that needs verifying grep -oE "([0-9]+%|\\\$[0-9]+|[0-9]+(\\.[0-9]+)?[KMB]?)" article.md | sort -u grep -oE "v[0-9]+\\.[0-9]+(\\.[0-9]+)?|[0-9]\{4\}-[0-9]\{2\}-[0-9]\{2\}" article.md | sort -u grep -oE "(Astro|Next\\.js|Vercel|Firebase|Cloudflare|Claude|GPT-[0-9])[a-zA-Z0-9.-]*" article.md | sort -uFor each hit, verify against the source (official docs / release notes / your own screenshot). Mark verified spots in the article with
<!-- verified 2026-05-21 -->. -
Add one human-written paragraph: this is the line between “published” and “slop”:
Pick at least one (per article): - Real story: "Last year I hit X when doing Y, took Z days to fix" (time + concrete detail) - Screenshot: your own dashboard / terminal / settings page screenshot - Failure: tried X, didn't work, here's the number that proves it - Reverse prediction: "In 3 months I expect X because..." Placement: after the final step. Title it "What I learned" / "From my own runs" / "The time this failed". -
Publishing cadence:
Monthly cap: 12 articles (3/week) No end-of-month batch of 30 — Google flags spam waves and the whole domain takes a hit Min 6-day gap between publishes; never 3+ on the same day Tool: build a content calendar in Notion / Airtable; plan next week's 3 every MondayDate helper (controlled by frontmatter
publishedAt):for i in \{1..28\}; do date -v+$\{i\}d +"%Y-%m-%d"; done | head -12 -
Audit last 10 articles every 30 days: recurring calendar event
1st of each month — content quality review:Walk every article through 4 questions: 1. Cover the author name — does it still feel like the same site / same person? 2. Are all numbers / links still valid today? 3. Where the article promises "actionable", does it actually carry copy-paste code / commands / tools? 4. 30 days post-publish, does GSC show ≥100 impressions? If not → topic or quality problem Any "no" → flag red. Next week: refresh, or move to noindex.At every review, update
style_guide.md— add new traps discovered to the banned list / must-include list.
Common pitfalls
- Treating “AI writes, human edits” as a binary. Editing AI prose is slower than people think — sometimes rewriting from an outline is faster.
- Trying to scale before you have a clear voice. AI amplifies whatever voice you give it; if your voice is “generic blog,” AI will produce generic blog at scale.
- Skipping fact-checks because the model “sounded confident.” Confidence is unrelated to accuracy in LLM output.
- Letting AI write the opening paragraph. Openings are where AI-shape is most detectable; write them yourself.
- Publishing in bursts. 30 articles dropped on the same day looks like exactly what it is.
Who this is for
Indie publishers with an established voice, a topic backlog, and the discipline to edit every draft.
When to skip this
New sites with no audience signal, no clear voice, and no fact base — you will produce volume that helps nobody and ranks for nothing.
FAQ
- Will Google penalize AI-assisted content?: Not by virtue of being AI-assisted. Google penalizes unhelpful content. AI-assisted articles that include real expertise, examples, and editing survive fine.
- How many articles per week is realistic for a solo builder?: With this workflow, 5-8 per week is sustainable. Beyond that, quality drops noticeably unless you add another reviewer.
- Which model is best for drafting?: In 2026, Claude and GPT both produce usable drafts. The bigger lever is prompt quality and your style guide, not model choice.
- Should I disclose that AI helped?: Not required by Google, but if your site has a strong personal brand, transparency about your workflow actually builds trust.