WordPress SEO content automation with editorial review

The WordPress integration is built for teams whose blog already lives on their own domain. SEODrafts does not replace the theme or route structure. After editorial approval, the tenant-side publisher creates or updates the post and verifies the rendered public URL before recording completion.

Best for: Existing WordPress blogs that want a structured research, briefing, review, and publishing workflow without moving to a hosted content subdomain.

Support status: stable
Publisher: wordpress

How the connection works

Authentication

A dedicated WordPress user and Application Password. Basic authentication is sent only from the tenant-owned server-side publisher to the WordPress REST API.

Server-side variables

  • SEO_BLOG_PUBLISH_TOKEN
  • SEO_BLOG_SITE_SLUG
  • SEO_BLOG_CMS_LOCALE
  • WORDPRESS_URL
  • WORDPRESS_USERNAME
  • WORDPRESS_APP_PASSWORD
  • SEO_BLOG_SITE_ORIGIN

Publishing sequence

01

Validate the authenticated user, edit and publish capabilities, and native post schema without writing.

02

Fetch only approved posts that are due for this site.

03

Find an existing post by slug and create or update title, slug, HTML body, and excerpt.

04

Verify article identity and the exact canonical on the public page before marking the item published.

Validate and initialize WordPress

SEO_BLOG_PUBLISH_TOKEN='<tenant-token>' \
SEO_BLOG_SITE_SLUG='<slug>' \
SEO_BLOG_CMS_LOCALE='<primary-bcp47-locale>' \
WORDPRESS_URL='<wordpress-url>' \
WORDPRESS_USERNAME='<wordpress-username>' \
WORDPRESS_APP_PASSWORD='<wordpress-app-password>' \
SEO_BLOG_SITE_ORIGIN='<origin>' \
npx --yes @wotaso/seo-blog-admin-cli@0.2.2 init-cms --cms wordpress --site-slug '<slug>' --site-origin '<origin>' --locale '<primary-bcp47-locale>'

init-cms performs the connector's read-only credential, permission, and destination-schema checks first. It writes seo-blog.config.json and the scheduled tenant workflow only after validation passes; review both files, add the named GitHub secrets and variables, then trigger the workflow once manually.

Scheduled runner health heartbeat

SEO_BLOG_PUBLISH_TOKEN='<tenant-token>' \
SEO_BLOG_SITE_SLUG='<slug>' \
SEO_BLOG_CMS_LOCALE='<primary-bcp47-locale>' \
WORDPRESS_URL='<wordpress-url>' \
WORDPRESS_USERNAME='<wordpress-username>' \
WORDPRESS_APP_PASSWORD='<wordpress-app-password>' \
SEO_BLOG_SITE_ORIGIN='<origin>' \
SEO_BLOG_SCHEDULED='true' \
npx --yes @wotaso/seo-blog-admin-cli@0.2.2 health --config seo-blog.config.json --mode cms --site-slug '<slug>' --site-origin '<origin>'

Run this from the real scheduled runner after seo-blog.config.json contains the selected connector configuration and the listed secrets are loaded. CMS health re-runs the remote read-only validation; it still does not create an article. The dashboard expires readiness at the returned deadline, with a 36-hour fallback when no deadline is available.

Fields and data model

  • Native title, slug, status, content, and excerpt fields
  • SEO metadata remains owned by the active theme or SEO plugin
  • Read-only setup validation before the scheduled runner is installed

Canonical and route

WordPress and the active theme or SEO plugin remain responsible for the permalink, canonical tag, sitemap, metadata, schema, and rendering. SEODrafts verifies the final public WordPress page rather than creating a parallel proxy page.

Known limits

  • Custom fields need explicit REST support and a reviewed extension.
  • An Application Password must never enter a browser bundle or prompt.
  • Page-builder-specific fields are outside the focused launch connector.

Recovery

  • Run init-cms again after correcting credentials or WordPress capabilities.
  • For 401 responses, check HTTPS origin, user, and Application Password.
  • For canonical or layout problems, fix the WordPress theme or SEO plugin before rerunning publication.

Integration questions

Where are credentials stored?

The WordPress credentials stay in the managed GitHub App or a tenant-owned CI/server-side secret environment.

Does SEODrafts own the canonical URL?

No. The destination website owns its route, canonical tag, sitemap, rendering, and analytics.

Can the integration be tested before publishing?

The init-cms and health commands validate credentials, permissions, and destination schema without writing; the first manual workflow run then verifies the rendered public page.

Keep the website your team already owns.

Review the opportunity and draft in SEODrafts, then publish approved work through WordPress.

Add my website