Content · Complete guide
Automating SEO article creation on WordPress: the pipeline step by step
A five-step tutorial on handing the operational work (REST API, media, metadata, scheduling) over to automation, while keeping strategy, checking and approval in human hands.
In this article 9 sections
- 01 · What you can automate (and what must stay human) in a WordPress article
- 02 · Step 1: build a brief and a generation process that add value
- 03 · Step 2: send the article to WordPress as a draft via the REST API
- 04 · Step 3: enrich the article with media that has reliable alt text
- 05 · Step 4: fill in your plugin's SEO fields without assuming anything
- 06 · Step 5: build in human checks before the move from draft to published
- 07 · A worked example: one article, from brief to scheduled publication
- 08 · Common mistakes to avoid
- 09 · Practical tips: securing access and measuring results
In short: a reliable pipeline sends each article to WordPress as a draft via the REST API, enriches the media and metadata, then stops at human approval. The speed comes from the tool; the value comes from your brief, your expertise and your review.
Automating publication is the easy part. The real risk is building a technically successful workflow that mass-produces pages nobody needed to read. This tutorial shows you how to build the opposite: a machine that handles the repetitive tasks, and a process in which every article has to earn its move to published status.
What you can automate (and what must stay human) in a WordPress article
The dividing line is simple. The tool can transport, file and schedule. The human decides what deserves to be written, contributes what nobody else can, and approves. The common thread of this tutorial follows that order: generate as a draft, check, enrich, then publish.
Technically, this separation is possible because WordPress exposes a native REST API. An external orchestrator (a script, an automation tool, or an editorial platform such as Qilyo, which presents itself as able to prepare content and deliver it to WordPress) can therefore create or edit the elements of an article without going through the editor. The principle described here holds true whichever tool you use.
Useful WordPress routes
The WordPress REST API exposes resources for posts, media, categories, tags, revisions and other CMS objects. For an editorial workflow, five routes are enough to get started.
Route | Role in the pipeline |
|---|---|
| Create or update the article |
| Create the image and its metadata |
| Find or create categories |
| Find or create tags |
| View the edit history |
Private or editing operations require authentication and the appropriate permissions. We will come back to this in the final section.
What stays under human control
Repetitive tasks can be automated: sending the content, taxonomies, image, scheduling. Choosing the topic, contributing expertise and giving final approval remain human. In the projects we support, the workflows that disappoint are almost always those where this boundary has been erased to save time.
Step 1: build a brief and a generation process that add value
Action: write a brief for each article before any generation. Without one, you are not running an editorial workflow; you are feeding a variant-producing machine.
The brief, the starting point of the workflow
A useful brief includes the target keyword, the reader's intent, the H2/H3 outline, the sources to consult and the proprietary angle, meaning what your site can say that others don't. Also plan for the original contribution you expect: an example, internal data, a first-hand account, or the expertise of the reviewer who will sign off. This last field is the most neglected, and it is what separates an article from a mere summary.
Avoiding mass-produced variations
Google does not ban generative AI as such. However, it cites the use of generative tools to produce many pages with no value for users as an example of a potential breach of its spam policy (scaled content abuse). The criterion is not the technology; it is the purpose and the real value of the content.
The risk is therefore higher if your workflow mass-produces variations by city, variant or query, without expertise or original input. A practical rule: if two of your drafts differ only by a city name, the workflow should stop and ask you why.
Step 2: send the article to WordPress as a draft via the REST API
Action: call the endpoint /wp/v2/posts with the generated content and a status that does not publish.
Create or update a post
The Posts endpoint supports the title, content, excerpt, slug, author, featured image, categories, tags, date and status. An orchestrator sends these properties on creation, then addresses the article's ID to update it. Some fields require the corresponding capabilities on the account being used.
Think about revisions: the route /wp/v2/posts/<id>/revisions lets you keep a record of changes, which is useful for comparing what the tool wrote with what your reviewer corrected.
Choosing the right status
The field status separates generation from publication. The available statuses include draft, pending, future, private and publish. The permitted status depends on the rights of the integration account. I recommend draft or pending by default: the former for raw text, the latter for text that is ready for review.
Point to watch
If the integration account can write as publish, a simple parameter error is enough to put unreviewed text live. Limiting the account's rights turns a good intention into a technical safeguard.
Taxonomies and IDs
Categories, tags and the featured image must reference valid WordPress IDs. Your workflow must therefore first look up or create the category and tag via their routes, retrieve the IDs, then pass them in the article request. A category name written out in full is not enough.
Step 3: enrich the article with media that has reliable alt text
Action: create the media item before the article with POST /wp/v2/media. The route accepts, among others, alt_text, caption, description and post. You then retrieve the media ID to reuse it as the featured image.
You can generate or select the image according to clear rules (format, approved image library, brand style). But the alt text must describe the actual content of the image. The API does nothing to guarantee its editorial relevance: it stores what it is sent. Alt text written from the article's topic rather than from the image remains wrong, even if it is well written.
Step 4: fill in your plugin's SEO fields without assuming anything
Action: check on your own instance that the SEO plugin's fields are genuinely writable before building anything on top of them.
The Posts endpoint accepts an object meta, but that does not mean every field of an SEO plugin is accessible. A custom meta field must be registered with show_in_rest set to true to appear in the key meta, and the content type must support custom fields. It is up to the plugin, or a custom extension, to expose and authorise these fields.
Testing writing to the SEO fields
The test procedure comes down to four steps, on the exact instance, plugin and content type you will be using:
create a test draft;
write the SEO title and meta description via the API;
read the article back via the API to see whether the values have been retained;
check the output in the editor, then in the page's source code.
Do not treat the internal name of a plugin's meta field as a stable public interface: it may change during an update. If necessary, plan for a custom extension or a mechanism officially exposed by the plugin, and retest after every major update.
The case of FAQ markup
FAQ rich results have no longer been displayed in Google Search since 7 May 2026. Your generator can keep a Q&A section if it genuinely helps the reader. However, do not automate FAQ markup in the name of a rich result that no longer exists.
Please note
This change concerns the appearance of the rich result in Google Search, not the usefulness of an editorial FAQ. A good question, well answered, keeps its value for the person reading.
Step 5: build in human checks before the move from draft to published
Action: put a mandatory human approval step between pending and publish. The workflow must not be able to bypass it.
Approval checklist
Google recommends a people-first approach. In particular, it warns against extensive automated production across many topics, simple summaries with no added value, and content created primarily to attract search engine traffic. Google prescribes no approval tool: the checklist below is an operational application derived from these criteria.
Fact-checking of every specific claim.
Original or expert input: first-hand experience, internal data, real-world examples.
Match with search intent: does the text answer what the reader is looking for?
Cited sources where necessary.
Editorial review: tone, clarity, repetition, consistency with the rest of the site.
Disclosing the use of automation
When automation or AI generates content to a substantial degree, Google recommends considering whether this use should be made clear to visitors, and explaining its role where that would reasonably be expected. Your workflow can therefore include a disclosure field or a methodology note, especially when the "how" matters for the reader's trust. This is a recommendation, not a universal requirement or an announced ranking factor.
Following the official guidelines
On 1 October 2026, Google updated its documentation on AI-generated content, adding material drawn from its guidelines for quality raters. It also clarified, in an update dated 27 May 2026, that its spam policies apply to Google Search's generative responses. You should therefore review your workflow's rules periodically. These texts do not amount to a new ban on AI, nor do they guarantee visibility.
A worked example: one article, from brief to scheduled publication
Let's take a fictional gardening blog and an article on pruning roses in spring. The table shows what each step produces, and who makes the decisions.
Step | Action or request | Result | Human decision |
|---|---|---|---|
Brief | Writing the structured brief | Keyword, intent, outline, sources, angle | Choice of topic and angle |
Generation |
| Draft created, ID retrieved | None; the text stays internal |
Media |
| Image created, ID retrieved | Checking the alt text against the image |
Holding | Updating the article to | Image, category and associated tags | Designated reviewer |
SEO fields | Writing the SEO meta data, reviewing it via the API | Values confirmed in the source code | Correcting the title and description |
Review | Editing in WordPress | First-hand experience added | Checklist sign-off |
Scheduling | Updating to | Article scheduled | Choice of date |
From brief to draft
The brief sets the angle: here, a pruning method based on the experience of one of the blog's gardeners. The workflow generates a first draft, sends it to draft, then creates the image with its alt text. Our reviewer compares that text with the actual image: a vague description such as "flowering garden" is replaced with what can genuinely be seen.
From review to scheduling
The article moves to pending. The SEO field test confirms that the title and description have been written correctly, including in the source code. The gardener then adds their first-hand experience, the checklist is ticked, and only at that point does the article move to future with a publication date.
The workflow stops automatically as soon as a check fails: an article that fails the checklist stays in draft. There is no technical exception to this rule.
Common mistakes to avoid
Here are the six pitfalls we encounter most often, with the matching safeguard.
Publishing straight to
publishwithout approval: requiredraftorpendingand limit the account's permissions.Producing dozens of near-identical variants to cover queries or cities: a clean brief for each page, with real added value.
Assuming an SEO plugin field has been written: test on a draft and review via the API.
Letting AI write alt text without checking the image: systematic human checks.
Building the workflow around the promise of FAQ rich results: they have no longer been displayed since 7 May 2026.
Using the main administrator account for the connector: create a dedicated account.
Practical tips: securing access and measuring results
Dedicated, secure access
Create a dedicated user with limited permissions, using an application password. WordPress has included these since version 5.6, and they are the recommended native mechanism for external REST access. They are used over HTTPS with Basic authentication. Keep this password secret, revoke or replace it if it is compromised, and avoid the Basic Authentication plugin in production, as it was designed for development.
Closing the loop with Search Console
The Google Search Console Search Analytics API automates the tracking of clicks, impressions, CTR and position, notably by page and by query. A scheduled scenario can identify underperforming pages, feed a revision queue, then send approved changes back to WordPress. Access requires Search Console authorisation, and results are limited to the top rows returned.
Be patient: data is generally only available after 2 to 3 days, and data requested as fresh may still change. Allow for a lookback window, distinguish between final and provisional data, and never trigger a major rewrite on the basis of a single day of recent data.
Key takeaways
Automate the transport, never the judgement: draft by default, restricted access, tested SEO fields, human approval before any publication, and measurement based on stabilised data.
If you also run an online shop, the same logic of safeguards applies when you want to automate SEO for WordPress and Shopify. Whatever the channel, a pipeline earns its place in your team if it frees up more time for your experts to contribute what no model can invent on their behalf.
FAQ
Google does not ban generative AI in itself, but producing large numbers of pages that offer users no value can count as scaled content abuse. Keep human approval in place before publication.