openclaw-seo-content-writer（OpenClaw SEO 内容写作）

OpenClaw SEO Content Writer

Use this skill to run a full SEO blog production lane instead of treating “write a blog post” as only a drafting task.

Core model

Split ownership clearly:

• Tony owns draft generation, safe-template normalization, preflight, content-quality gating, source publish readiness, and artifact receipts.
• Peter owns deployment, live verification, indexability checks, Google Search Console submission, and indexing-status receipts.

Never collapse these into one fuzzy “content done” state.

Required workflow

1. Gather same-day inputs

- keyword / topic target - audience + search intent - Hunter research / evidence / proof links - brand positioning + CTA source

1. Write the draft batch

- Use a stable SEO skeleton, not freeform prose. - Ensure every draft answers the query directly and has enough structure to survive QA.

1. Normalize through safe template

- Stamp template metadata. - Ensure every draft contains a quick answer, TL;DR, scannable sections, FAQ, conclusion, CTA, and source/proof notes.

1. Run publish gates

- structural preflight - content-quality audit

1. If not publishable, recover correctly

- Do not pad with filler. - Call Hunter for bounded same-day recovery research first. - Only downgrade or replace the topic if Hunter also cannot make it longform-worthy.

1. Source publish

- Only after preflight + quality audit pass. - Write a structured source-publish receipt.

1. Peter closeout

- deploy production - verify live URL and /blog - verify canonical / sitemap / noindex / discovery - write deployment + indexability receipts

1. Search Console follow-through

- submit only INDEX_READY URLs - write GSC submission receipt - check indexing status later and write GSC status receipt

Non-negotiable rules

• No filler padding. If word count is thin, add real information or trigger research recovery.
• No publish without receipts. Preflight, quality audit, source publish, deploy, and indexability should all leave artifacts.
• No “live” claims without Peter verification. Code-ready is not live.
• No GSC submission before indexability passes. Live + self-canonical + sitemap + /blog discovery must be true first.

Minimum draft contract

Every publish candidate should have:

• direct answer / quick answer
• TL;DR
• 4+ substantial H2 sections
• comparison table or clear scannable structure
• FAQ with at least 4 real questions
• conclusion
• CTA
• source / proof notes
• enough specificity, proof, and search-intent coverage to be publishable

Recovery logic

If a draft batch fails because it is thin, weakly evidenced, or not publishable:

1. classify the problem
2. call Hunter for more research
3. rewrite once with stronger evidence / FAQ material / angles
4. rerun gates
5. only then downgrade or replace the topic if still too weak

Receipts to maintain

Use the same style of structured receipts for every lane:

• preflight receipt
• content-quality audit receipt
• source-publish receipt
• deployment receipt
• blog indexability receipt
• GSC submission receipt
• GSC index-status receipt

References

Read these files when needed:

• references/tony-pipeline.md — drafting, gating, recovery, and source publish flow
• references/peter-closeout.md — deploy, live verification, indexability, and closure rules
• references/gsc-indexing.md — Search Console submission and indexing-status workflow
• references/receipt-contracts.md — receipt expectations and truth states

Prerequisites

This skill is a workflow guide, not a standalone tool. It assumes you already have:

Deployment

• A deployment pipeline for your site (e.g. Vercel, Netlify, Cloudflare Pages, or a custom CI/CD setup)
• SSH or CLI access to trigger deploys
• A working sitemap generator (e.g. Next.js sitemap.ts, or equivalent)

Google Search Console

• A verified GSC property for your domain (sc-domain: or URL-prefix)
• Google Cloud project with the Indexing API and Search Console API enabled
• A service account JSON key with GSC permissions, or OAuth credentials
• googleapis npm package or gcloud CLI available in your environment

Content pipeline

• A content source directory or CMS where drafts are stored
• A safe-template normalization script or convention (this skill describes the contract, not the implementation)

Optional but recommended

• Tavily or web search tool for Hunter research recovery
• A receipt/artifact directory convention (e.g. mission-control/data/)

No credentials are bundled

This skill does not ship any API keys, service accounts, or deployment configs. All credentials must be configured in your own environment before use.