SEO Automation on WordPress and Shopify: Content, Updates, Publishing

In short: automating SEO on WordPress and Shopify means leaving repetitive tasks (drafts, fields, scheduling, detection) to machines and keeping editorial decisions in human hands. A reliable pipeline comes down to four stages: produce, check, publish, review.

The pitfall is rarely technical. The WordPress and Shopify APIs can create pages in bulk, but they cannot tell whether a page deserves to exist. This guide shows how to build automation that serves your expertise rather than diluting it, with the practical differences between the two CMSs (content management systems).

What you can genuinely automate in SEO, and what must stay human

The simple rule: automate what is mechanical, and keep human whatever puts your credibility on the line. Creating a draft, filling in a field or scheduling a date are repetitive tasks. Choosing an angle, checking a claim or deciding that a text adds something new is a matter of judgement.

It is also important to understand that automation is not a "publish" button. It is a system with checkpoints, where each step can stop if a criterion is not met. A botched technical audit weakens the whole edifice; automation without safeguards does the same, only faster.

On the technical side, the difference between the two CMSs is structural. WordPress exposes a REST API for posts. Shopify offers theAdmin GraphQL API, which covers both blog articles and products. The working principles are similar; the mechanisms differ.

The four stages of a reliable workflow

The target pipeline runs in four stages, whichever CMS you use.

• Produce: assisted generation prepares a draft from a precise brief, your data and your sources.

• Check: a human reads through the draft, checks its accuracy and decides whether the content adds genuine value.

• Publish: the API submits the approved content, for immediate or scheduled publication.

• Review: performance data flags the content that needs revisiting, and the cycle begins again.

Tasks to automate and decisions to keep

The table below divides the roles. It is not a universal rule: depending on your sector, some checks require expertise that only your team has.

Editorial safeguards: automating without producing worthless content

Before writing a single line of code, set the editorial ground rules. A fast pipeline that publishes weak texts only accelerates the erosion of your authority. This is something few brands yet understand: speed never makes up for a lack of substance.

What counts as scaled content abuse

Under Google's spam policies, content produced at scale primarily to manipulate rankings, rather than to help users, is considered abusive. Producing large numbers of pages with AI that offer readers no benefit can therefore fall into this category.

The risk does not depend on the use of AI alone. The assessment looks in particular at the purpose of the page, its originality and the value it brings to users. A text that is machine-assisted but reviewed, enriched and useful is not targeted for that reason alone.

Google recommends content designed first and foremost for people. It warns in particular against extensive automation across many topics and against simple summaries with no added value. The right model is therefore not "generate, then publish blindly", but "assisted generation followed by editorial review based on usefulness, experience and reliability".

Pre-publication checklist

No content should move to published status without clearing these points. Adapt them to your business: they describe criteria for judgement, not a scoring scale.

• Usefulness: does the text genuinely meet a need of the intended audience?

• Accuracy: has every fact, every specification and every reference been verified?

• Experience: is first-hand expertise present where relevant?

• Uniqueness: does the page offer something that existing content does not say?

• Consistency: does it match the search intent and the real purpose of the content?

When to explain the role of automation

When automation or AI contributes substantially to producing content, it can be worth explaining the "how" to readers. Google recommends considering this information when visitors might reasonably expect it.

This transparency has a clear limit: it does not justify weak or misleading content. An honest disclosure does not redeem a worthless page. It complements work that is already solid.

Automating content creation and publishing on WordPress

WordPress is the most straightforward platform for automating publishing, because its REST API is documented for posts. The points to master are requests, statuses and, above all, SEO fields, which demand more caution than you might expect.

Creating and editing a post via the REST API

According to the WordPress documentation on posts, the posts endpoint accepts POST requests to create them. An existing post is updated at /wp/v2/posts/<id>.

Write operations require authentication and appropriate permissions. The post resource exposes, among other things, the title, content, excerpt, author, categories, tags and status. This is the foundation that automation works with.

Draft, publish, schedule

The supported statuses include draft, publish and future. The fields date and date_gmt define the publication date. Note: for the field date, it is the site's time zone that applies, which can shift a publication if you are working in universal time.

My recommendation: create posts as drafts by default. Only move to publication or scheduling after human approval. This single setting prevents most incidents.

Managing SEO fields according to the plugin

The SEO title and meta description managed by a plugin cannot be controlled through the REST API in every case. A meta field must be registered with show_in_rest to be accessible, and a custom post type must support custom fields.

Point to watch

The meta key, its schema, its validation and its permissions may be specific to your site or your plugin. Before writing any automation, check on the target instance which routes and fields are actually available.

Scheduling recurring updates on WordPress with WP-Cron

WP-Cron is WordPress's built-in scheduler. It lets you run recurring tasks: spotting content that needs refreshing, preparing update drafts or triggering SEO checks. It does not publish your articles for you; it runs processes that you have written.

Keep the key distinction in mind. Editorial scheduling relies on the post's status future and publication date. WP-Cron, by contrast, is used to launch custom recurring processes.

Scheduling without creating duplicates

In the WordPress documentation on scheduling, wp_schedule_event() schedules a recurring event and wp_next_scheduled() lets you check that a task is not already scheduled. You also need to register the hook that contains the process.

The classic pitfall: scheduling the event on every page load without checking. Tasks pile up and the same process runs several times. Check first, then schedule, and unschedule any tasks that are no longer needed, for example when your plugin is deactivated.

Idempotence and monitoring

An idempotent process produces the same result whether it runs once or several times. In practice, if your task creates an update draft, it must first check whether a draft already exists for that page. This protects you from duplicates, even when scheduling behaves unpredictably.

Add monitoring: a log of every run, an alert if the task fails or stops running, and a way to pause it quickly.

Testing after a WordPress update

In WordPress 6.9.0, the internal triggering of _wp_cron() was moved from the action wp_loaded to shutdown, unless ALTERNATE_WP_CRON is enabled. The documentation for wp_cron() describes this behaviour.

This change does not call your tasks into question, but it does mean you must test scheduling after every CMS update. Nor does it remove the need for idempotent, monitored processes: that is your safeguard, whatever the version.

Automating Shopify blog posts: creation, scheduling, updating

On Shopify, blog posts are managed through the Admin GraphQL API. The principle is the same as on WordPress: draft first, schedule afterwards. Only the technical mechanisms change.

Creating and scheduling a post

According to the Shopify documentation, the mutation articleCreate accepts, among other things, title, body, handle, tags, image, isPublished and publishDate. The handle is the part of the URL specific to the post. The publishDate date is a date and time in ISO 8601 format.

The app must have one of the scopes (authorisation permissions) write_content or write_online_store_pages. A post can therefore be published immediately or scheduled for later. As with WordPress, avoid publishing straight away: create it unpublished, have it reviewed, then activate it.

Updating without breaking URLs

The mutation articleUpdate modifies the body, the metadata, isPublished and publishDate. The same content scopes are required. Three use cases come up often: republishing an updated guide, scheduling a series of posts, and correcting a batch of posts.

If you change the handle, the old URL leads nowhere. The redirectNewHandle parameter can create a redirect from the old address, but it is optional: you need to request it explicitly when making the change.

Compared with WordPress, the principles are identical (draft, scheduling, targeted update). The difference lies in the tools: a future status and REST requests on one side, a isPublished flag combined with publishDate and GraphQL mutations on the other.

Automating SEO for your Shopify catalogue: product pages and SEO fields

Product pages are often a shop's first lever for growth, and the first place where mass automation goes wrong. The technique is simple. The editorial stakes, however, are considerable.

Commercial content and SEO fields

The mutation productUpdate accepts, among other things, title, descriptionHtml, handle, seo.title, seo.description, tags and status. It requires the scope write_products and appropriate user permissions.

Update the commercial content (title, description) and the dedicated SEO fields (seo.title, seo.description) separately. This separation makes your logs and approvals clearer: commercial copy is the merchant's responsibility, whereas an SEO title calls for its own distinct wording work.

Descriptions generated in bulk are subject to the same safeguards as articles. Without differentiation between product pages and without accurate product details, you produce plenty of pages that offer buyers no benefit. A feature invented by a language model becomes an error published across your catalogue.

Redirects when a handle changes

Changing a product's handle changes its URL. Here again, redirectNewHandle can request a redirect from the old address. Without one, you risk broken links to a product page that still exists.

Between ourselves, most shops that lose well-ranked pages do so over this detail: a handle "improved" by a script, with no redirect behind it.

Which Shopify API should you choose for a new automation?

For any new project, choose the Admin GraphQL API. That is the short answer. The rest explains why and what it means for your tools.

GraphQL rather than REST

According to Shopify's versioning policy, the Admin REST API has been a legacy API since 1 October 2024. The Admin GraphQL API is recommended for all new apps and integrations. An existing REST integration may require migration.

This also applies to your tools. If you use a no-code platform or a third-party app to publish, check what it uses behind the scenes. A platform such as Qilyo, which prepares content and deposits it in WordPress or Shopify, is an example of this kind of intermediary tool: always ask the provider which API it depends on before entrusting it with your catalogue.

Managing API versions

Shopify's stable API versions follow a quarterly cycle and have a limited support period. An automation written today must therefore allow for regular monitoring and regular testing. Pin the version you use, note it in your documentation, and set aside a recurring slot to validate the next one before the old one reaches the end of its support.

Worked example: a complete workflow from detection to republication

Here is a concrete scenario, which illustrates a process rather than a promised result. It starts with a page whose impressions remain high, but whose CTR (click-through rate) or position could be improved.

The common thread has five steps: detecting the page, creating an update draft, human review, publication or scheduling, and a post-publication check. The table shows how each CMS implements them.

Step by step on WordPress

The recurring task identifies a page to review and opens an update request. A draft is prepared via the REST API, with an automation that first checks that no request is already in progress for that page. A revision of the article is kept before any change is made.

After human review, the article is published or given the status future with a date. A post-publication check verifies the rendering, the SEO fields and the data tracking.

Step by step on Shopify

The detection process is the same, but it runs outside the CMS, for example in a service that queries your data. The new content is prepared, reviewed, then applied with articleUpdate, controlling isPublished and publishDate.

If the handle changes, the redirect must be requested explicitly with redirectNewHandle. The final check confirms that the old URL redirects properly to the new one.

Human checkpoints

Three moments require a human: review before publication, validation of any information added, and the decision on whether or not to proceed. You should also define stop criteria: the workflow halts if the update adds nothing of real value, or if a new piece of information cannot be verified.

A draft that says nothing more than the live version should not be published, even if it is perfectly written. This decision to hold back is precisely the one that no script will make for you.

Trigger updates from data rather than an arbitrary calendar

Revising content because "it's been a year" is not a strategy. It is better to let the data point to the pages that deserve your attention.

Feed a prioritisation queue

According to the Search Console Search Analytics API documentation, searchanalytics.query returns rows with clicks, impressions, ctr and position. This data can be grouped by page, query, country and device, among other dimensions.

Access requires authorisation and read permissions on the property. Results are limited to the top available rows, so they do not guarantee that all data is complete. Treat them as a signal, not a full inventory.

From there, build a prioritisation queue with three inputs:

• high-potential pages, which are very visible but rarely clicked;

• declining pages, where clicks or position are slipping;

• uncovered queries, which call for new content rather than an update.

The queue proposes, the human decides: it is the human who determines the order of treatment.

What the Indexing API does not allow

You should not automate the submission of all your editorial pages to Google's Indexing API. According to its getting-started documentation, it can only be used for pages containing JobPosting or BroadcastEvent embedded in VideoObject.

For other WordPress or Shopify content, a content update does not give you access to a general indexing notification through this API. A script that calls it every time you republish will therefore not deliver anything you are hoping for.

Securing the workflow: access, reversibility and rate limits

An automation has write access to your site or shop. That justifies treating it with the same rigour as a team member: limited permissions, traceability and the ability to roll back.

WordPress authentication

For remote automation, application passwords are preferable to the user's main password. WordPress has provided them since version 5.6 for API requests over HTTPS. They can be revoked application by application: if one tool is compromised, you cut its access without affecting the others.

The user's permissions are still required. Create a dedicated account with only the permissions the workflow needs, preferably those of a role that cannot publish if your process does not require it.

Revisions and restoration

WordPress exposes post revisions via REST. GET /wp/v2/posts/<parent>/revisions lists the revisions of a post, and GET /wp/v2/posts/<parent>/revisions/<id> retrieves a specific revision. The documented fields include the author, dates, title, content and excerpt.

Your automation can therefore log and compare versions before each update.

Good to know

Being able to view a revision does not prove that you will be able to restore it cleanly. Test the procedure on your own theme, plugins and content types, and arrange human approval and a restoration plan before any bulk change.

Shopify rate limits

Bulk processing on Shopify should include a queue, GraphQL cost monitoring and delayed retries, to avoid throttling (a slowdown imposed by the platform). GraphQL limits are calculated as a cost per app-and-store combination. The single-query cap is 1,000 points, and the rate depends on the plan.

Responses provide cost and throttle metadata: make use of it. Shopify recommends limiting the pace of requests, caching, handling errors and waiting before retrying.

Finally, whichever CMS you use, log every action, set up alerts and keep the ability to suspend everything with a single action.

Common mistakes and an actionable summary

Pitfalls to avoid

In the automations I come across, the same mistakes keep recurring. All of them can be fixed, provided they are identified before going live.

• Publishing without human review on the grounds that the text "looks good".

• Rescheduling the same WP-Cron event on every page load.

• Assuming that all SEO fields are accessible via the API, when their exposure depends on registration and on the plugin.

• Changing a handle without a redirect.

• Using the Admin REST API for a new Shopify project.

• Submitting every page to Google's Indexing API.

Getting-started checklist

Set up your pipeline in this order: each step protects the next.

1. Safeguards: define the validation checklist and the stop criteria.

2. Secure access: application passwords for WordPress, minimal scopes for Shopify.

3. Draft creation: no content is published without validation.

4. Idempotent scheduling: check before scheduling, log, monitor.

5. Measurement: feed a prioritisation queue with Search Console data.

6. Revision: review, compare with the previous version, and republish with full knowledge of the facts.

Several peripheral topics deserve separate treatment: choosing an SEO plugin, auditing a shop, migrating from one CMS to another, or comparing WordPress and Shopify. They go beyond the scope of this guide, which focuses on the automation pipeline itself.

A good SEO automation is recognised by the extra time it leaves your experts to judge, verify and enrich, not by the number of pages it publishes in their place.