How to Automate On-Brand Blog Articles with Minimal Editing

Article production automation is a system that turns a vetted topic queue and brand voice rules into publish-ready drafts, routes a short human edit pass, then opens a CMS pull request with images, internal links, and metadata handled for you.

We built and shipped this for our own site and for anonymized clients who publish frequently. In production it handles topic intake, voice control, fact-grounding, diagram generation, MDX assembly, and a PR to the content repo so the final human step is accept or tweak.

The problem it solves

A consistent publishing cadence breaks on two choke points: on-brand drafts and editing time. Manual workflows jump between briefs, outlines, drafts, link checks, image creation, internal links, and CMS entry. Teams stall, quality drifts, and posts miss windows where they would rank.

How does the automation work end to end?

The system is a narrow assembly line: a topic enters, a publishable PR exits. We keep the AI steps boxed in by deterministic rules, and anything risky is enforced in code rather than hoped for in prompts.

• Topic queue and policy guardrails: one source of truth for ideas, target queries, and forbidden claims. Each topic carries required internal links and a no-cannibalize rule.
• Brand voice and structure engine: YAML voice rules, headings, table and definition blocks, and the no em-dash punctuation policy enforce style before any drafting.
• Outline and brief generator: AI proposes an outline from the topic. We inject the structure and verify it covers the search intent.
• Fact-grounding pass: a link collector and validator pin facts to real sources. The draft cannot include a stat without a URL.
• Draft compiler and assets: the engine writes the MDX, generates a workflow.svg from a template, and assembles frontmatter, tags, and alt text.
• PR and distribution: a branch is created, MDX and SVG are committed, a PR opens for a human check, and a drip entry is queued for LinkedIn once merged.

Step-by-step: how to build it

1) Define brand voice and structure in a policy file

Lock tone, tense, punctuation, and required blocks before any drafting. We keep this in version control and load it on every run.

# brand.yml
name: "House Voice"
persona: "Experienced automation team. We write from shipped builds."
style:
  tense: present for how-it-works, past for results
  pov: first-person plural
  punctuation:
    forbid: [", ", ", ", "emoji", "!"]
    replace_rules:
      em_dash: "use colon or period"
  headings:
    h2_shape: "question"
  blocks:
    require: ["definition", "manual_vs_automated_table", "diagram", "faq"]
  formatting:
    mdx_safe: true  # keep angle brackets inside fenced code only

The gotcha: do not rely on the model to remember rules. Inject them into every generation and add a linter that rejects outputs violating the policy.

2) Create a single topic queue with statuses

A flat CSV or JSON works. Include target query, intent, required internal links, and status.

[
  {
    "slug": "automate-article-production-minimal-editing",
    "query": "automate producing on-brand blog articles",
    "intent": "how-to",
    "requiredInternal": ["/services#ai-search-optimization", "/blog/optimize-for-ai-search-geo-playbook"],
    "status": "approved"
  }
]

Add a uniqueness check that fails the run if a topic collides with a published or in-flight slug.

3) Generate an outline from the topic and voice rules

Wrap your model call behind a function that always includes brand.yml and structure scaffolding. Keep the model swappable.

// outline.ts
import fs from "node:fs";
import { callLLM } from "./llm"; // your provider wrapper
 
export async function generateOutline(topic: string) {
  const policy = fs.readFileSync("brand.yml", "utf8");
  const prompt = [
    { role: "system", content: `Follow this policy:\n${policy}` },
    { role: "user", content: `Draft an H2/H3 outline for: ${topic}. Include a definition sentence and a manual-vs-automated table.` }
  ];
  return await callLLM({ messages: prompt });
}

Key gotcha: never hardcode a specific model in business logic. Keep it in config so you can upgrade without refactoring.

4) Collect and validate sources for any hard facts

Do not let a stat through without a URL. A simple validator can catch dead links and missing protocols.

// sources.ts
import fetch from "node-fetch";
 
export async function validateLinks(urls: string[]) {
  const checks = await Promise.all(urls.map(async u => {
    try {
      const res = await fetch(u, { method: "HEAD" });
      return { url: u, ok: res.ok };
    } catch {
      return { url: u, ok: false };
    }
  }));
  const bad = checks.filter(c => !c.ok);
  if (bad.length) throw new Error(`Invalid sources: ${bad.map(b => b.url).join(", ")}`);
  return true;
}

Gotcha: model outputs often drop protocols or give homepage URLs. Force deep links and re-run HEAD checks before compiling.

5) Compile MDX with frontmatter and inject internal links

Assemble the post with required sections, alt text, and safe code fences for any JSX-like snippets.

// compile.ts
import fs from "node:fs";
 
export function writePost({ slug, title, description, body, tags }: any) {
  const frontmatter = `---\ntitle: "${title}"\ndescription: "${description}"\ndate: "${new Date().toISOString().slice(0,10)}"\nauthor: "Jacky Lei"\ncategory: "Marketing & Content Automation"\ntags: ${JSON.stringify(tags)}\ncta: book\n---`;
  const mdx = `${frontmatter}\n\n${body}\n`;
  fs.mkdirSync(`src/content/blog/${slug}`, { recursive: true });
  fs.writeFileSync(`src/content/blog/${slug}.mdx", mdx);
}

Gotcha: MDX parsers treat raw angle brackets in prose as JSX. Keep them inside fenced code blocks only.

6) Open a PR with the MDX and the diagram asset

Automate branch naming, commits, and PR creation so review is one click.

# publish.sh
set -euo pipefail
SLUG="$1"
BRANCH="blog/$SLUG"
 
git checkout -b "$BRANCH"
git add "src/content/blog/$SLUG.mdx" "public/blog/$SLUG/workflow.svg"
git -c user.name="rex-automaton" -c user.email="rex.automaton@gmail.com" commit -m "blog: $SLUG"
git push -u origin "$BRANCH"
 
gh pr create --title "blog: $SLUG" --body "One new post: $SLUG. Draft PR for editorial pass."

Gotcha: never use a blanket git add -A. Stage only per-post files to avoid cross-branch conflicts.

Where does this get complicated in production?

• Brand drift under pressure: models regress on tone when asked to handle edge cases. Solve it with pre-commit policy linting and rejection on violation, not softer prompts.
• Fact stability and links: stats rot. Add a stale check that flags sources older than a threshold and routes them to manual review.
• Duplicate and cannibalization risk: your queue must de-duplicate against published and in-flight topics. Block merges that would target the same primary query.
• Images and diagrams at scale: generate templated SVGs with strict text lengths. Oversized strings cause unreadable assets. Enforce max characters per line.
• Internal links and related services: require one services anchor and one related post in the queue spec so each draft ships with real interlinking.

What this actually changes

After we shipped this, editing turned into a focused pass rather than a rewrite. The system enforces voice, structure, and safe MDX while the validator blocks unlinked stats. That makes a higher cadence practical without hiring. Consistency matters because search clicks concentrate at the top: SISTRIX found position one in Google garners about 28.5 percent average CTR across keywords. Source: https://www.sistrix.com/blog/ctr-study-google/

The structural value is that each post is consistent, fact-grounded, and quick to ship. That unlocks topic clusters and internal linking that a human-only process rarely sustains week after week.

Frequently asked questions

Will Google penalize AI-written content?

Google states it rewards helpful, people-first content. Our system treats AI as a drafting engine with guardrails. It grounds claims to real sources, enforces structure, and keeps a human approval step. The result reads like a consistent expert voice with citations, which is the standard Google wants.

How do you keep articles on-brand without heavy editing?

We codify voice rules in YAML and inject them into every generation. Then a linter rejects drafts that violate tense, punctuation, or required sections. The editor sees a near-final draft and focuses on substance rather than cleanup.

Can this include custom diagrams and images?

Yes. We generate hand-authored SVGs from templates sized for short lines and consistent styling. The system enforces max line lengths and alt text. You can still replace the image with a designer asset before merge if needed.

What CMS does this support?

Anything Git-backed or API-driven works. We ship MDX to a repo with a PR step or post to a headless CMS via API. The mechanics are swappable. The important part is keeping a review gate before publish.

How much human time remains per article?

Editing becomes a focused approval pass. You check claims, adjust a paragraph or two, confirm internal links, and merge. The goal is a short, high-leverage review rather than hours of drafting and formatting.

How long does it take to implement?

Most teams can pilot in a couple of weeks. The critical work is writing your voice policy and curating the first topic queue. The drafting, validation, MDX, and PR pieces are standard and repeatable once your rules exist.

If you want this running against your topics and brand voice, we build the same production pipeline for clients and wire it to your CMS and distribution. See our service detail at /services#ai-search-optimization, read how we approach AI search in /blog/optimize-for-ai-search-geo-playbook, and when you are ready, /book a quick scoping call.