Automated content publishing to your CMS

Automated content publishing that stops at the draft

A finished article is not a published one. Between the two sit image uploads, a rich-text format every CMS stores differently, SEO fields, internal links and a record of where it all went. This system does that work for 11 sites across three CMSs, and it ends every run at a draft that a person approves.

It is built in Claude Code: one skill and one converter per site, with Python scripts that talk to each CMS's API directly.

Why copy and paste breaks at volume

A lot of what gets sold as content management automation is a sync between tools. This is narrower and harder: getting a finished article into a CMS correctly, and knowing afterwards where it went.

Pasting into an editor looks free until you count what it drops. Some editors don't convert markdown on paste, images go up one at a time, and the SEO fields live in a sidebar that someone forgets. After a few hundred articles the bigger problem is the record: nobody can say which draft became which URL, or which pages were edited by hand after they went live.

Three CMSs, three native formats

Each destination gets its content in the shape its own editor expects, not as pasted HTML:

Writing the native format is what keeps an article editable afterwards. A table stays a table in the editor, a link stays a link, and nobody has to repair the formatting before they can change a sentence.

Every run in the same order

A new article goes through five steps, and the first one changes nothing:

1. A dry run that prints what it will create: sections, images, links and tables.
2. Upload the inline images to the CMS's media library.
3. Create the post as a draft.
4. Fetch it back and confirm it exists and is not live.
5. Write the URL and status to the Airtable ledger, against the matching row in the content plan.

Nothing goes live from the script. Publishing is a separate step that a person asks for explicitly.

Some failures only show up once the draft exists, so the checks don't stop at the upload. Screenshots are confirmed to appear in the order the article describes them, and house-style problems such as em dashes or a URL in the wrong path format stop the run instead of shipping as a warning.

Editing posts that are already live

Most of the work on an established site is changing pages that already exist. The same scripts splice new material into live posts without converting the body again, so nothing edited by hand gets overwritten.

On this site that has meant 110 call-to-action banners across 55 posts and 190 internal links into the job description and industry playbook directories. Across four sites, this one included, it has placed 381 diagrams, and on Awesomic it added 366 calls to action to 183 posts.

The guards on a live edit

Changing a page people can already read needs more care than creating a draft:

• Compare the page byte for byte after every write, so an edit that touched more than intended shows up immediately
• Place inserts inside a position band, such as between 20% and 80% of the article, so nothing lands in the intro or the footer
• Label every insert, so running the same script twice doesn't insert twice
• Verify through the API rather than the public page, because a cached page can show the old version for minutes after a change

That list is the reason these are scripts and not a person with a checklist.

Where the links come from

Links go in through the same machinery, with rules of their own: the target paragraph must not already hold a link, anchors stay at four or five words, and the position band is measured again once every insert is in. Deciding which pages should link to which is a separate job, done by internal linking automation.

Sites where it earns its keep

It fits a team publishing to more than one site, or publishing enough to one site that pasting and reformatting is a real cost. It also fits anyone about to roll a change across a whole library, like a new call to action or a round of internal links, where doing it by hand means hundreds of careful edits.

It is unnecessary for one site publishing a couple of posts a month, where the editor is fine. And it doesn't decide what gets published. Articles arrive finished, usually from content creation automation.

What a publish costs

The CMS APIs are included in the plans these sites already use, and the scripts run locally, so a publish costs nothing extra.

Publishing runs under execution capacity: $2,000 a month flat for the AI agents route, added to a fractional Head of Content retainer. Wiring up a new CMS is a one-to-two-week job of field mapping and test runs on real articles.

Start with one article and your CMS

Send one finished article and read access to your CMS's collection structure. On a call we'll dry-run it and look at the draft it would create, before anything is written.