SEODrafts

Markdown and MDX SEO content publishing workflow

Astro, Next.js, Nuxt, SvelteKit, Hugo, and other Git-based sites do not need a CMS API. The static publisher writes approved work into the existing content directory and leaves rendering, sitemap generation, review, and deployment with the host repository.

Best for: Sites with versioned content, a reproducible build, and deployment triggered by repository changes.

Support status: stable
Publisher: static

How the connection works

Authentication

A tenant-scoped publishing token stored as a CI secret. It is never written into the repository configuration or generated content.

Server-side variables

  • SEO_BLOG_PUBLISH_TOKEN
  • SEO_BLOG_SITE_SLUG
  • SEO_BLOG_SITE_ORIGIN
  • SEO_BLOG_ADMIN_API_URL (optional for self-hosting)

Publishing sequence

01

Create a project config and scheduled or manual CI workflow.

02

Fetch only approved, due posts for the configured site.

03

Write deterministic Markdown or MDX with project-specific frontmatter.

04

Let the normal build deploy and verify the final public route.

Initialize Git publishing

SEO_BLOG_SITE_SLUG='<slug>' \
SEO_BLOG_SITE_ORIGIN='<origin>' \
npx --yes @wotaso/seo-blog-admin-cli init-static --site-slug '<slug>' --site-origin '<origin>' --content-dir '<content-dir>' --extension mdx

Run this once inside the tenant website repository. It writes seo-blog.config.json and a scheduled GitHub workflow; review those generated files before committing. This initializer is not a dry run.

Scheduled runner health heartbeat

SEO_BLOG_PUBLISH_TOKEN='<tenant-token>' \
SEO_BLOG_SITE_SLUG='<slug>' \
SEO_BLOG_SITE_ORIGIN='<origin>' \
npx --yes @wotaso/seo-blog-admin-cli health --config seo-blog.config.json --mode static --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

  • Content directory and file extension are explicit
  • Frontmatter can match the framework schema
  • Generated image data can be materialized under public assets

Canonical and route

The host framework exclusively owns routes, canonical tags, and the sitemap. The integration does not create a second hosted blog or a client-side content dependency.

Known limits

  • The project must render the generated frontmatter and MDX syntax.
  • A Git commit is not proof of a successful deploy.
  • Build and sitemap behavior remain project-specific by design.

Recovery

  • Review generated config and workflow in a pull request first.
  • Test the publisher with the same Node version as CI.
  • Fix generated content after a build failure and never print the publishing token.

Integration questions

Where are credentials stored?

The Markdown/MDX + Git 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 Markdown/MDX + Git.

Add my website