OpenClaw GEO Content Ops

Design and manage OpenClaw GEO content operations including sources, clusters, tasks, publish targets, artifacts, receipts, and visibility analytics beyond s...

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:

Object	Purpose	Example Artifact
knowledge_sources	Trusted facts, docs, product pages, customer proof, FAQs, competitor notes	catalogs/sources.jsonl, source briefs, uploaded docs
topic_clusters	Search/AI questions grouped by intent and entity	keyword master, topic cluster markdown
content_tasks	Planned work units with owner, date, source, status, target query, and publish scope	daily manifest, task JSON
draft_assets	Generated article, metadata, schema, social/X derivative, images	delivery/seo-geo/YYYY-MM-DD/
publication_targets	Where content can go	ClawLite blog, WordPress, static GEO site, X, Feishu doc
geo_artifacts	LLM/search-readable outputs around content	llms.txt, sitemap, Schema, TXT map, FAQ blocks
receipts	Durable proof of state transitions	generation, audit, publish, deploy, live QA, patrol
visibility_signals	Evidence content is discoverable or useful	crawl 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.