How to build a blog publishing pipeline with Claude Code

A publishing pipeline is the fixed route a blog post takes from draft to live page: one place where drafts live, a script that checks them, a build that turns them into pages, a preview a person approves, and a deploy. Claude Code is good at building and running that route. It writes the validation script, converts drafts into your site's templates, fixes what the checks flag, and reports what changed. A person still edits for facts and voice, and approves what goes live.

The point of a pipeline is repeatability. Publishing one post by chatting with Claude Code is fine. Publishing fifty that way gives you fifty slightly different results. On eseospace.com, more than 300 articles have gone live through a scripted pipeline built with Claude Code, and the lessons below come from running it.

The pipeline at a glance

Step 1: choose one source of truth

Decide where post content lives before you write a single script: Markdown or text files in the repository, a headless CMS, or WordPress itself. Everything else is generated from that source.

This matters more than it sounds. On eseospace.com, a publishing step once regenerated every post from its source files and deleted edits that had been made only in the built copy. The lesson we kept: make edits in the source of truth, not in the generated output. Write that rule into your project's CLAUDE.md so every session knows it. Our guide to writing a CLAUDE.md for a website shows how to phrase rules like this.

Example CLAUDE.md lines:

Post content lives in posts/. Never edit files in dist/.
Run npm run validate before every commit.
Internal links must come from links.md.

Step 2: write the house rules down

A validator can only enforce rules that exist in writing. Put them in a short file in the repository:

• The draft format: which fields are required (title, meta title, meta description, slug, date, author).
• Length targets for titles and descriptions. Google says there is no length limit on either, but both are truncated in results "as needed", so a target is a house choice, not a Google rule.
• The HTML tags a post may use, and any banned patterns (inline styles, scripts).
• The approved list of internal links, so drafts don't link to pages that don't exist.
• Byline rules. Google's guidance says "Giving AI an author byline is probably not the best way to follow our recommendation", so name the person accountable for the post.

Step 3: have Claude Code write the validator

Example prompt: Read rules.md. Write a script, validate, that checks every file in posts/drafts against those rules and prints one line per problem with the file name. Exit with an error if anything fails. Run it on the current drafts and show me the output. Don't fix the drafts yet.

Reading the first report before letting Claude Code fix anything tells you whether the rules are right. If half the drafts fail on a rule nobody cares about, change the rule.

Then make the check automatic. You can package the routine as a skill that you run with a command, or add a hook that runs the validator whenever Claude finishes a turn. Our explainers on Claude Code skills and hooks for website projects cover both. Anthropic describes hooks as deterministic, while CLAUDE.md instructions are advisory, so a hook is the better fit for a rule that must hold every time.

Check: introduce one deliberate error in a test draft and confirm the validator catches it.

Step 4: the editorial review only a person can do

A validator checks format. It can't tell whether a claim is true. Google's guidance on AI content is direct: "It is critical to manually factcheck and review all AI-generated content for accuracy and trustworthiness before publishing." It explains why: "generative models don't retrieve facts, but predict a likely sequence of words based on their training data."

Claude Code can make the review faster without replacing it.

Example prompt: List every factual claim, number, date, price, law and product name in this draft, each with the sentence it appears in and the source cited, if any. Flag claims with no source.

A person reviews: each flagged claim against a primary source, the post's advice for your business and readers, and the voice. For regulated topics such as health, legal or financial advice, the reviewer should be someone qualified to sign off. Our article on AI-generated versus human-edited content covers the editorial side in more depth, and teams writing at volume will find more in Claude Code for content teams.

Volume deserves a caution of its own. Google's spam policies say "using generative AI tools or other similar tools to generate many pages without adding value for users" may be scaled content abuse. A pipeline makes publishing cheap, and that's exactly why every post needs a reason to exist.

Step 5: build, preview and check more than one page

Have Claude Code build the posts into your templates and serve or deploy a preview, never the live site. Then check several outputs. On our own rebuild, a script replaced the wrong container, so new posts carried the template post's text. The first post looked fine. Check the second and third posts a build produces, and one with tables or unusual characters.

Example prompt: Build the three new posts to the preview. For each one, report the title tag, meta description, H1, word count, number of internal links, and the first sentence of the body. Flag any two posts that share a sentence.

Check: each built page shows its own content, and the metadata matches the draft. Our QA routine for every deploy covers the wider checks: links, structured data and a real-browser look.

Step 6: publish through git, with a person approving

Have Claude Code commit the posts on a branch and open a pull request. The person who approved the content approves the merge, and the merge triggers the deploy. That gives you a record of what went live, when, and who approved it, and an easy way to revert.

Be careful with automatic pushes. Anthropic's auto mode docs say it "allows pushes to any branch of the repository you're working in, including the default branch". If a push to your main branch deploys the site, add an ask rule so Claude Code always stops and asks first. The documented syntax, in .claude/settings.json:

{ "permissions": { "ask": ["Bash(git push *)"] } }

The docs add a caveat: the rule matches commands that begin with git push, so a push written another way, such as git -C <dir> push, isn't caught. For a firmer gate, the docs point to a PreToolUse hook, and branch protection on your Git host adds another layer.

Before any deploy, check git history for changes you didn't make. On eseospace.com, one session once regenerated pages that another session had just edited, and the edits disappeared. Our list of common Claude Code mistakes on websites describes that failure and others.

Step 7: check after launch

1. Each new URL returns a 200 status, with the right title and canonical.
2. The post appears in the sitemap. Google uses a sitemap's lastmod value only "if it's consistently and verifiably" accurate, so set it from real changes, not from every build.
3. The hub or category page links to the new post, and the post's internal links resolve.
4. The live page matches the build output. If it doesn't, check the build output and git log before redoing work. On our site, a CDN once served a stale copy after a deploy, which made a finished change look missing.

Don't change publish dates to make old posts look fresh. Google's helpful-content guidance asks site owners whether they are "changing the date of pages to make them seem fresh when the content has not substantially changed".

Updating posts after they're live

Treat updates exactly like new posts: edit the source, validate, review, build, preview, publish. If a fact changes across many posts, such as a price or a phone number, run it as one site-wide change with its own checks rather than as dozens of separate edits.

Conclusion

A Claude Code publishing pipeline gives you one source of truth, a validator that enforces your rules, a preview, and a deploy a person approves. Claude Code builds and runs the machinery. People own the facts, the claims and the decision to publish. If you'd like help setting up a pipeline for your site, see our Claude Code development services. More guides are in our Claude Code Guide.

Frequently asked questions