OpenClaw GEO Content Ops#

This skill turns GEO from "write more posts" into an operating system for trusted source material, content production, publication targets, LLM-friendly artifacts, receipts, and visibility analytics.

It is inspired by GEOFlow's content-engineering architecture, but it does not require adopting GEOFlow's Laravel CMS. Use it to extend the existing OpenClaw SEO/GEO workflow, not to replace openclaw-seo-geo-workflow or ai-search-visibility-content-writing.

Use Boundaries#

Use this skill for:

• GEO operating model design.
• Content asset inventory and source-of-truth planning.
• Topic cluster, keyword, FAQ, and question map organization.
• Daily/weekly content ops planning.
• Multi-site or multi-channel publication design.
• llms.txt, sitemap, TXT map, Schema, Open Graph, and AI-summary artifact planning.
• Receipt design for publish, crawl, citation, and analytics evidence.
• GEO dashboard/KPI design.
• Deciding what to borrow from GEOFlow.

Do not use this skill as the writing layer for a single article. Use ai-search-visibility-content-writing for that.

Do not claim live publish, indexing, ranking, crawler visits, or AI citations without receipts.

Core Object Model#

Use these nouns consistently:

ObjectPurposeExample Artifactknowledge_sourcesTrusted facts, docs, product pages, customer proof, FAQs, competitor notescatalogs/sources.jsonl, source briefs, uploaded docstopic_clustersSearch/AI questions grouped by intent and entitykeyword master, topic cluster markdowncontent_tasksPlanned work units with owner, date, source, status, target query, and publish scopedaily manifest, task JSONdraft_assetsGenerated article, metadata, schema, social/X derivative, imagesdelivery/seo-geo/YYYY-MM-DD/``publication_targetsWhere content can goClawLite blog, WordPress, static GEO site, X, Feishu docgeo_artifactsLLM/search-readable outputs around contentllms.txt, sitemap, Schema, TXT map, FAQ blocksreceiptsDurable proof of state transitionsgeneration, audit, publish, deploy, live QA, patrolvisibility_signalsEvidence content is discoverable or usefulcrawl logs, GA4, indexing, AI crawler, citation checks

Canonical source catalog:

text

clawlite-brain/catalogs/sources.jsonl

Relationship to ClawLite wiki:

• knowledge_sources is the evidence/source index. It points to raw docs, canonical files, receipts, URLs, and selected compiled wiki pages.
• clawlite-brain/wiki/ is the durable compiled knowledge layer for project memory and retrieval.
• synthadoc/wiki/ is a readable/generated wiki layer for brand, SEO, Hunter topics, and agent navigation.
• Prefer raw/canonical sources for factual claims; use wiki pages for fast orientation and retrieval.
• When daily findings become durable, promote them from receipts into sources.jsonl and then into topic/entity/synthesis wiki pages when warranted.

Operating Loop#

1. Collect sources. Confirm the facts are real, owned, current, and citeable.
2. Build clusters. Convert sources into user questions, entity maps, keywords, comparison angles, and FAQs.
3. Create tasks. For each task, define target reader, core query, primary answer, required sources, publish target, and success signal.
4. Generate and audit. Use the writing layer for drafts; require source grounding, direct answer, extractable structure, metadata, and schema hints.
5. Publish by target. Treat source publish, site deploy, social post, and remote distribution as separate state transitions.
6. Emit GEO artifacts. Keep llms.txt, sitemap, TXT map, Schema, Open Graph, and canonical data aligned with published content.
7. Write receipts. Store what happened, what was skipped, what failed, and which evidence supports the claim.
8. Measure signals. Monitor AI crawler hits, search index state, page views, citations, top content, failures, and stale content.
9. Feed learning back. Promote useful daily findings into keywords-master.json, topic clusters, source catalog, or rescue tasks.

Required Task Brief#

Every GEO content task should include:

json

{
  "taskId": "geo-YYYY-MM-DD-slug",
  "status": "planned",
  "targetReader": "specific reader",
  "coreQuery": "question this page answers",
  "primaryAnswer": "short answer the page must give",
  "requiredSources": ["source-id-or-url"],
  "entities": ["OpenClaw", "ClawLite"],
  "topicCluster": "cluster-name",
  "publishScope": ["clawlite_blog"],
  "geoArtifacts": ["schema", "sitemap", "llms_txt"],
  "successSignals": ["live_url", "index_check", "ai_crawler_log"]
}

If any field is missing, make the smallest honest assumption and mark it in the receipt. Do not silently invent sources.

Publication Target Rules#

• clawlite_blog: requires source apply/build evidence and, for production claims, deploy plus live QA.
• wordpress_rest: requires remote ID/URL, media sync result, and API response receipt.
• static_geo_site: requires generated HTML/Markdown, sitemap/TXT map update, and reachable URL check.
• x_post: requires a derivative artifact tied to the article's narrative spine; do not treat social posting as blog publication.
• feishu_doc: useful for internal review; not a public GEO signal unless explicitly published externally.

Remote distribution failure must not rewrite history. Mark the target as FAILED or NEEDS_RETRY; keep local publish status separate.

GEO Artifact Checklist#

For public web targets, check whether each published page or batch has:

• canonical URL and stable slug
• title and meta description
• Open Graph/Twitter metadata where relevant
• Article/FAQ/HowTo/Organization schema where appropriate
• sitemap inclusion
• llms.txt or site-level AI-readable map inclusion
• TXT map or Markdown index for important content hubs
• internal links to and from related cluster pages
• source/evidence block where claims need grounding
• clear update timestamp for evergreen pages

Receipts#

Recommended receipt shape:

json

{
  "date": "YYYY-MM-DD",
  "taskId": "geo-YYYY-MM-DD-slug",
  "stage": "publish|artifact|patrol|analytics",
  "target": "clawlite_blog",
  "status": "PASS|FAIL|SKIPPED|NEEDS_DATA|PASS_WITH_WARNINGS",
  "evidence": {
    "localPath": "path/to/file",
    "liveUrl": "https://example.com/page",
    "deployId": "optional",
    "checkedAt": "ISO timestamp"
  },
  "warnings": [],
  "nextActions": []
}

Status vocabulary must match openclaw-seo-geo-workflow where possible.

Analytics Questions#

When designing or auditing GEO analytics, answer:

• What was created, audited, published, deployed, skipped, or failed?
• Which sources and clusters produced publishable work?
• Which targets received the content?
• Which pages are included in sitemap/ llms.txt/TXT maps?
• Which content received crawler traffic or AI crawler hits?
• Which pages need refresh, consolidation, internal links, or rescue?
• Which daily findings should be promoted into durable source/keyword/topic files?

When Borrowing From GEOFlow#

Borrow patterns, not the whole stack:

• structured source library before generation
• task queue state machine
• local publish separate from remote distribution
• target-site Agent / WordPress provider abstraction
• llms.txt, sitemap, TXT map, Schema output
• access-log and AI-crawler analytics

Read references/geoflow-patterns.md when designing implementation details or mapping this to code.