You have articles ready. They are written, reviewed, sometimes approved, and they sit in a shared folder waiting for someone to find an hour to put them live. The usual reaction is to want to produce faster, often with AI. Before that, I check whether the better move is to automate content publishing, because a text sleeping in a folder helps nobody.
I talk about this because I lived it on a project: the bottleneck was not the writing but the publishing, done by hand. Since then, my content machines publish on their own. Here is how I spot that bottleneck, the order in which I automate, and what this automation does not fix.
01The bottleneck is not always the writing
When content production slows down, people blame the writing first: not enough writers, not enough time, not enough ideas. On that project, the writing kept up. What did not keep up was publishing, done manually, one article at a time.
In that situation, adding writers, human or not, only makes the queue longer. That is the lesson I kept: before producing more, I measure the stock of articles that are ready but not yet live. If it grows from one week to the next, the jam is downstream of the writing.
The question I ask is simple: how many finished texts have no publication date? If the answer comes with a pause, you have found where to work.
02What publishing means, step by step
"Publishing" looks like one click. In practice it is a string of small actions that nobody has ever written down. I suggest listing them with the person who does them, on a real article, noting the time each one takes. The list often looks like this:
- paste the text into the editor and redo the formatting (headings, lists, bold);
- prepare the image, resize it, write its alt text;
- fill in the SEO title, description, excerpt and slug;
- add internal links and check that external links respond;
- choose the category, author and date;
- publish, then wait for or force the cache refresh;
- open the public page to check it displays;
- update the tracking sheet.
Each action is quick. End to end, they need a time slot and someone who knows the CMS. That dependency is often what creates the bottleneck, more than the time itself.
Once the list is written, I split it into two families. What repeats identically (formatting, fields, cache, tracking) gets automated. What needs judgement (the title, the choice of image, the review) stays human, but is prepared so the decision takes a minute.
03Automating publishing, in order
I do not automate everything at once. I follow an order that closes the longest and riskiest steps first.
1. Write to the CMS through its API
Most headless CMSs let a script create or update content. On this site, built with Next.js and Sanity, my machine sends the article through Sanity's Mutations API. It is transactional: a batch of changes goes through in full or not at all, which avoids a half-filled page.
The text goes in as structured content, not copy and paste. Headings, lists, the FAQ and the SEO fields land in the right place. This is the step that saves the most time.
2. Refresh the page cache
A fast site often serves cached pages. Publishing in the CMS is therefore not enough: you have to tell the site the page has changed. Next.js handles this with revalidatePath, called from a route: the page is regenerated on the next visit. My publishing step calls a revalidation route protected by a secret, then loads the page once.
In Vercel's video introducing on-demand revalidation, the problem is put clearly: a short interval regenerates the page for nothing, a long one keeps the reader waiting. Better to regenerate when the data changes. Vercel's ISR documentation adds a reassuring detail: if revalidation fails, the previous version keeps being served and a new attempt happens 30 seconds later.
3. Check the public page, as a visitor would
This is the step people forget. A CMS form can keep the content while nothing has actually gone out, and a page can display for the logged-in team but not for visitors, because of the cache. After every publication, I check the public URL: a 200 response, image and alt text present, headings, FAQ, internal links that respond, no email address in plain text.
On one project, I made this check the only condition for a calendar line to move to "published". Until it is green, the article does not count as live.
4. Update tracking automatically
The content calendar has to reflect the real state. Mine is a versioned file: publishing writes the status and the date into it. If your team already runs everything in Airtable, Airtable automations work with a trigger, such as a record changing status, and one or more actions, including a script or a call to another app. Zapier plays the same role between tools that do not talk to each other.
5. Plan for failure
An automated publication must be safe to rerun without creating duplicates. I log every step, export the old content before rewriting a live article, and never let the machine type in credentials. When publishing goes through a CMS back office driven in the browser, the session is checked before saving; if it has expired, the batch is skipped and the report asks me to log back in.
04Keeping a human review without making it the bottleneck
The objection comes quickly: if everything goes out on its own, who reviews it? I chose not to wait for human sign-off before publishing, because that was precisely the bottleneck. An article that passes the automated check goes live with a "to review" status. I read it on the site, then mark it "Reviewed" in the Studio, which has a dedicated list.
That choice only holds if the check before publishing is serious. Mine blocks what can be verified: structure, sources actually read, links, confidential information, words that give away generated text. I described it in the article on human review in an AI content machine. The acceptance testing and go-live checklist follows the same logic on the project side.
It is not a universal rule. For the LinkedIn posts of Moonworkers, my own company, I do the opposite: the post is created as a draft in the scheduling tool, never scheduled, because the date and slot are not mine alone to decide. The Moonworkers blog, on the other hand, publishes two articles a day with its machine. The right line depends on what a mistake costs, and on who has to decide.
05What automation does not fix
Automating publishing speeds up what already exists. If the articles are weak, they will go live faster, that is all. Google says so plainly in its guidance on generative AI content: producing many pages that add little can count as scaled content abuse, and generated text must be checked for accuracy before it is published.
Publishing is not the same as being indexed either. Google's page on asking it to recrawl your URLs reminds you that crawling can take anywhere from a few days to a few weeks, and that a request guarantees nothing. I track indexing separately, in SEO reporting that sends itself.
Finally, it has a cost. You need a CMS with an API, someone to write and maintain the script, and a check that evolves with the mistakes you meet. For four articles a year, I would not do it: a written list of steps and one trained person are enough.
06Where to start on Monday
Count the finished articles that are not live, and note how long each one has been waiting. Then take the next one and have the usual person publish it while you write down every step, with its duration.
With that list, you will know whether publishing really is the bottleneck, and which step to automate first. For me, it is almost always sending to the CMS, then checking the public page. If you would like to look at your publishing chain together, my short diagnostic and build engagements are made for that, and we can talk about it.