Check this page with an assistantOpens a chat asking it to summarise this article and name the evidence behind each claim.
Claude opens with the prompt on your clipboard: Anthropic does not support prefilled prompts on the web, and we would rather copy it than ship a button that drops it.
Decisions first
Authenticate with a named, revocable application credential over HTTPS; inspect the post types and fields; create or update a draft idempotently; upload media; map metadata through the site's supported fields; read the post back; then publish and verify the public URL.
- Discover the site's actual schema and plugin behavior before writing.
- Use draft as the default status and store the WordPress post ID.
- Verify REST storage and rendered public output separately.
Create a site-specific publishing contract
Core WordPress posts are predictable, but the SEO title, description, schema, author, taxonomy, blocks, and custom fields depend on the site. Inventory them before the first automated draft.
Record the WordPress origin, REST namespace, post type, allowed statuses, content representation, author policy, taxonomy IDs, media behavior, permalink rules, and the fields exposed by the active SEO and custom-field plugins. Confirm that the API user can do the required operation and nothing wider.
A successful test writes a disposable draft into the intended post type, reads it through REST, renders its preview, and removes or archives it through the normal workflow. Production mapping is approved from that evidence.
| Object | Contract question | Failure if ignored |
|---|---|---|
| Post type | Which REST base and capabilities? | Content lands in the wrong model |
| Body | Blocks or classic HTML? | Broken layout or escaped markup |
| SEO fields | Which plugin exposes which keys? | Missing or invisible metadata |
| Taxonomy | Which IDs are valid? | Wrong category or failed write |
| Media | Who owns uploads and alt text? | Hotlinks or inaccessible assets |
Use scoped, revocable authentication
For a remote HTTPS workflow, WordPress Application Passwords provide revocable credentials for API access. Use a dedicated named account and protect the credential like any production secret.
Grant the minimum role that can create or edit the required post type and status. Do not reuse an owner's password or put credentials in URLs, logs, analytics, or content payloads. Record the credential owner and a revocation and rotation procedure.
Authentication proves identity; WordPress capabilities decide authorization. Test each required action and confirm that out-of-scope actions fail. Separate sites and environments so a staging credential cannot write to production.
- HTTPS only
- Named API account
- Revocable application credential
- Minimum WordPress capabilities
- Encrypted secret storage
- Auditable action log
Create or update the draft idempotently
Every job keeps a stable WordPress post ID. A retry looks up that ID and approved content version before deciding whether another write is required.
Upload approved media through the site's expected path, then create the post with draft status and mapped title, slug, content, excerpt, author, taxonomy, featured media, and exposed metadata. Store both the job ID and returned post ID. For an update, compare the current post and approved base so a human edit is not overwritten silently.
Read the post back through REST and compare normalized critical fields. Then inspect a preview because theme filters, blocks, shortcodes, and plugins can render differently from the stored representation.
Publish, verify, and monitor
The publish transition needs explicit authority and a public check. The REST response alone cannot prove the canonical page is indexable or visually correct.
After publication, check the public status, permalink, canonical, robots directive, title, description, H1, image, internal links, and a known text fingerprint. Record the final modified time and destination post ID. If the site or cache serves a stale version, keep the job in verification rather than marking it complete.
Add the URL to the measurement queue with its query cluster, baseline, and conversion event. WordPress is the destination; the outcome is whether the page performs the job that justified it.
Continue the workflow
Connect a staging site and run create, update, human-edit conflict, media failure, timeout retry, publish, and public verification tests before production.
- WordPress integration guide: review the connection, states, field mapping, and known issues
- automated content publishing: design the destination-independent delivery contract
- content decay automation: return live posts to the refresh queue
Questions teams ask
- Can WordPress posts be created as drafts through the REST API?
Yes. The posts endpoint supports post status, subject to the authenticated user's capabilities. Draft-first is the safe default for an automated publishing workflow.
- What authentication should a WordPress automation use?
For remote API access over HTTPS, Application Passwords are a documented, revocable option. Use a dedicated account with minimum capabilities and protect the credential.
- Can every SEO plugin field be updated through WordPress REST?
No. Exposure and field names depend on the plugin and site configuration. Discover and test the site's actual REST schema rather than assuming a universal metadata mapping.
Primary sources
The SearchHandled Editorial Team prefers first-party documentation and names the limits of each source. Links were checked on the access date.
- WordPress Developer Resources: REST API posts referenceAccessed August 29, 2026
- WordPress Developer Resources: REST API authenticationAccessed August 29, 2026
- WordPress Developer Resources: Application PasswordsAccessed August 29, 2026
- Google Search Central: Creating helpful, reliable, people-first contentAccessed August 29, 2026 · Quality principles, not a promise that any page will rank.
