AI Content Automation With Google Sheets and WordPress: A Step-by-Step Workflow

Most content automation tutorials end at the moment the AI produces text and a WordPress post appears. That is the easy half. The hard half is what happens on the third Tuesday, when someone pastes a brief with an empty row above it, the OpenAI account runs out of credit, or the same brief gets drafted twice and two near-identical posts sit in your drafts folder, each slightly worse than the other.

This guide builds AI content automation for a small team that already plans its articles in Google Sheets and publishes on WordPress. A person adds a finished brief to a sheet. An automation picks up that new row, asks an AI model for a first draft, saves a copy to Google Docs, creates a WordPress draft, and logs what it did. A human then edits and publishes. Nothing goes live without someone reading it.

This guide uses Make as the integration platform because its documentation covers every piece this needs: a Google Sheets trigger, an OpenAI module, Google Docs, a WordPress app, a small built-in database for duplicate checks, and proper error handling with stored retries. Zapier or n8n can do similar work. If you are still deciding which tools deserve a place in your stack at all, start with choosing AI tools around the tasks you actually do.

One clarification before the build. The business, the sheet, the field map and both run logs below are an illustrative example built for this article: a fictional pottery studio called Kettle Lane Ceramics. They are not screenshots or logs from Viktor’s own setup or from a client. Module names and platform behaviour are taken from Make’s official documentation, checked on 20 October 2026, and are linked where they appear.

What the finished pipeline does

Kettle Lane publishes two articles a month about glazes, kiln care and studio classes. The owner writes a short brief for each one: working title, reader, key points, sources, target length. Until now she pasted each brief into ChatGPT, copied the answer into Google Docs, cleaned it up, then rebuilt it in WordPress. The copying was the slow part.

The automation replaces the copying and nothing else. It runs on a schedule, looks for new rows on a tab called Briefs, and for each new brief:

1. checks that the brief has the minimum content to be worth drafting;
2. checks that this brief ID has never been processed before;
3. marks the brief as in progress in a Make data store;
4. sends the brief and a fixed set of writing instructions to OpenAI;
5. checks the returned draft for obvious failures;
6. saves the draft as a Google Doc in a shared folder;
7. creates a WordPress post with the status Draft;
8. marks the brief as done and writes a line to a Run Log tab.

The trigger is a new brief added by a person, never a status column the automation itself edits. Automations that watch their own output tend to loop, and a loop that calls a paid AI API is an expensive way to learn about loops. For the bigger picture of which processes are worth automating first, see workflow automation for small business; this article is the detailed build for one of them.

Accounts, prerequisites and what each one costs

You need five things, and two of them bill you separately, which surprises people.

Plan details checked 20 October 2026. Prices change, so confirm on the linked pages before you commit.

Since August 2025, Make bills in credits, and most module actions cost one credit (Make credits). The OpenAI module counts as a normal operation in Make, while OpenAI bills you separately for the tokens. The catch is the trigger: Watch New Rows is a polling trigger, and a scheduled check that finds nothing still uses an operation (Make operations, types of modules). Check every 15 minutes, around the clock, and the empty checks alone come to roughly 2,900 a month, nearly three times the Free allowance, before a single brief is drafted. A team that writes two briefs a month does not need near-real-time polling. Schedule the scenario a few times per working day and the empty checks drop to a rounding error.

The WordPress connection uses the Make Connector plugin. Make’s WordPress app requires it (Make WordPress app). After activation, a Make menu appears in your WordPress admin showing the API key you paste into the Make connection. Recheck the connection after plugin updates; reviews on the plugin page mention the occasional update going badly.

The field map

The sheet is the contract between the person writing briefs and the automation. If a column means one thing to the owner and another to the scenario, the draft will be confidently wrong. People only ever add rows to Briefs. The automation only ever writes to Run Log. Keeping writers and robots on separate tabs is the cheapest duplicate prevention you will ever build.

Tab 1: Briefs (illustrative field map)

Tab 2: Run Log (written by the automation only)

Two warnings about the Briefs tab. Make’s documentation says that if a sheet contains a blank row, Watch New Rows does not process the rows after it (Google Sheets modules). So never leave a gap, and consider a Google Form that appends rows for you; forms do not leave gaps. And do not sort the tab or delete old rows while the scenario is active, because the trigger tracks rows it has already seen and rearranging them is a good way to confuse it.

Building the scenario in Make

Here is the module chain. Each line is one module in Make’s scenario editor, in order.

The failed filters at steps 2, 4 and 8 should not simply drop the bundle. Use a router so each failure path writes its own Run Log row (SKIPPED_EMPTY, SKIPPED_DUPLICATE, FAILED_CHECK). A brief that silently vanishes is worse than one that fails loudly.

The AI step

The OpenAI module’s Generate a response action takes a model, your prompt and a cap on output tokens, and reports tokens used per run. Keep the instructions in the module fixed and pass the brief fields in as clearly labelled data. If your instructions are vague here, they will be vague 24 times a year. How to write instruction prompts that hold their shape covers why “write a good blog post” fails and what to say instead; if prompting is new to you, the beginner’s guide to prompt engineering for small businesses is the better first stop.

The instruction text Kettle Lane uses (illustrative):

You draft blog articles for a small ceramics studio. Write for the reader described in the brief. Use only the key points and sources provided; if a point needs a fact the brief does not contain, write [CHECK: what is missing] instead of guessing. Do not invent statistics, prices, customer stories or quotes. Write in plain British English, warm but practical, no hype.

Return valid JSON only, with exactly these keys: “title” (under 70 characters), “excerpt” (140 to 160 characters), “body_html” (the article as HTML using p, h2, h3, ul and li tags only, no h1). Aim for the target word count, within 15 percent.

BRIEF
Title: {{working_title}}
Reader: {{reader}}
Key points: {{key_points}}
Sources: {{sources}}
Target words: {{target_words}}

Notice the [CHECK] instruction. It stops the model filling gaps with plausible fiction and gives the editor a searchable marker for what still needs research. Kettle Lane lets drafts with [CHECK] markers through to WordPress, since honest holes beat no draft; step 8 only blocks leftover {{ }} tags, which mean a field mapping broke.

Storing the draft and creating the WordPress post

Google Docs’ Create a Document module accepts HTML content and a target folder, so the Doc keeps headings and lists. The Doc is the archive: if someone overwrites the WordPress draft, the original survives.

In the WordPress Create a Post module, set status to Draft explicitly. Do not map it from a sheet column, where one careless edit could turn it into Publish. Map title, content, excerpt and category from the parsed JSON and the sheet. If you want the editor to know where a draft came from, put the brief ID and Doc link in the excerpt field or a custom field rather than at the top of the article body, where it will eventually get published by accident.

Credentials

Every account connects through Make’s connection settings, which store the credentials. Never paste an API key into a sheet cell, a prompt or a module’s text field, because those get copied, shared and logged. Create a dedicated OpenAI API key for this scenario so you can revoke it without breaking anything else,. When someone leaves the team, rotate both keys and update the connections.

Duplicate prevention and processed-row tracking

The trigger already tries to return only rows it has not seen. That is necessary but not enough, because people do strange things to spreadsheets. They copy a row to “reuse the format”, undo a deletion, or paste last month’s brief back in. So the scenario keeps its own memory in a Make data store, keyed by brief_id, and checks it before spending money on the AI call.

The order of steps 5 and 11 matters more than it looks. The record is written as in_progress before the AI call and updated to done only after WordPress confirms the draft. If the scenario dies in the middle, the record stays at in_progress, so a re-run cannot quietly create a second draft. The cost of this caution is that a stuck brief needs a human to look at it. That is the right trade.

The rule for a stuck record: if it has said in_progress for more than a day with no wp_post_id, check the WordPress drafts and the Docs folder. If a draft exists, add its ID to the record and mark it done. If nothing exists, delete the record and add the brief again as a new row with the same ID.

One successful sample run

Below is an illustrative run log for a normal day. Timestamps, IDs and token counts are sample data, not output from a real account.

Nine modules ran (filters are not modules), so this brief used about nine Make credits plus the OpenAI tokens. The owner opened the draft, searched for [CHECK], filled in the firing temperature from her own notes, cut a paragraph that repeated itself, and published it the next morning. The automation saved her the copying. The judgement stayed hers.

One failure, and the recovery

Failures are where this design earns its keep, so here is an illustrative one. A WordPress plugin update deactivates Make Connector overnight. The next brief arrives.

Three Make features make this work, and you have to set up each one yourself. First, Store incomplete executions must be enabled in the scenario settings; it is off by default (incomplete executions). Second, the Retry error handler on the WordPress and OpenAI modules pulls the failed bundle aside, stores the error and the data, and lets the rest of the queue continue, with automatic attempts at the interval you choose. Third, when you resolve an incomplete execution, Make runs it again starting with the module that failed, using the original input (manage incomplete executions). The OpenAI step is not repeated, so you do not pay for the draft twice and you do not get a different draft the second time.

Make also retries some temporary errors without any handler, once incomplete executions are on. Rate limit errors, connection errors and module timeouts are retried on a backoff schedule (automatic retry). That covers the common case of OpenAI being briefly overloaded. It does not cover a rejected API key or a deactivated plugin, which no amount of waiting will fix, so the error route that writes a human-readable note to the Run Log matters. A sheet people already open is a better alarm than an email they filter.

The checks to run before you switch it on

Test with a throwaway WordPress category or a staging site, and run each case on purpose before a real brief ever touches the scenario.

• A normal brief creates exactly one Doc and one WordPress draft, and the Run Log says DRAFTED.
• A row with empty key_points produces SKIPPED_EMPTY and no OpenAI call. Check the Make history to confirm.
• Pasting the same brief_id a second time produces SKIPPED_DUPLICATE.
• Temporarily breaking the WordPress connection produces RETRY_PENDING and an incomplete execution, and resolving it creates the draft without a second AI call.
• An AI reply that is not valid JSON fails at Parse JSON, is stored, and does not reach WordPress.
• Nothing in the whole chain can set a post to Publish.
• Your schedule’s empty checks fit inside your Make credit allowance with room to spare.

Then read the first five drafts properly; if they drift off-voice, fix the instruction text, not each draft. If you have a long recording or webinar rather than a brief, AI content repurposing is a better starting point than this pipeline.

Where AI content automation should stop

The obvious next idea is to remove the human and set the status to Publish. I would not. The value of this setup is that it turns a blank page into a structured, sourced, flagged draft and puts it exactly where the editor works. The last ten percent, checking facts, cutting the paragraph that says nothing, deciding whether the article should exist at all, is the part readers notice. Automating it saves the least time and costs the most trust.

Start with drafts, watch the Run Log for a month, then decide what else deserves automating. Direktorium keeps adding practical guides on prompts and AI workflows when you are ready for the next piece. If you would rather have a pipeline like this designed and set up for you, BBDirector builds them.