SEODrafts

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 records the final URL returned by WordPress.

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 server-side publisher to the WordPress REST API.

Server-side variables

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

Publishing sequence

01

Fetch only approved posts that are due for this site.

02

Find an existing post by slug so repeat runs update instead of duplicate.

03

Write title, slug, HTML body, excerpt, and configured SEO fields.

04

Mark the item published only after WordPress returns a plausible public URL.

No-write payload and mapping preview

SEO_BLOG_PUBLISH_TOKEN='<tenant-token>' \
SEO_BLOG_SITE_SLUG='<slug>' \
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 publish-cms --cms wordpress --site-slug '<slug>' --site-origin '<origin>' --dry-run

For a currently due approved post, --dry-run builds the destination payload without writing to the provider. It does not contact the provider or prove credentials, remote schema compatibility, deployment, or a live page; when no post is due, provider inputs are not exercised.

Scheduled runner health heartbeat

SEO_BLOG_PUBLISH_TOKEN='<tenant-token>' \
SEO_BLOG_SITE_SLUG='<slug>' \
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 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. It reports configuration readiness, not a live 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, content, and excerpt fields
  • Optional SEO metadata through configured post meta
  • Explicit draft and publish modes

Canonical and route

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

Known limits

  • Custom fields need REST access when a plugin consumes them.
  • An Application Password must never enter a browser bundle or prompt.
  • Page-builder-specific fields need a custom mapping or webhook.

Recovery

  • Run a dry run and verify the derived URL first.
  • For 401 responses, check HTTPS origin, user, and Application Password.
  • For layout problems, inspect the WordPress post type and theme template.

Integration questions

Where are credentials stored?

The WordPress credentials stay in CI or another 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?

Use the no-write payload preview to inspect local mapping, then separately test credentials and the first destination draft before a live run.

Keep the website your team already owns.

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

Add my website