用途
该技能用于闭合 SEO 问题发现与修复推广之间的流程：在 SE Ranking 中定位薄弱页面、技术问题和内容缺口，然后在 Planable 中协调端到端修复。Planable 的 Universal content pages 用于存放改写后的页面文案，使其可以在发布到网站前接受评论评审并正式审批；社交层则安排帖子来分发更新后的页面。
前置条件
- SE Ranking MCP 已连接（有项目可支持可重复审计与竞争背景；一次性审计无需项目也可运行）。
- Planable MCP 已连接，并具备用于页面文案评审的 Universal content page 以及用于分发的社交页面。页面需在 Planable 内添加，无法通过连接器创建。
这两者可能位于不同工作区（例如用于页面文案的“Universal pages”工作区和用于社交的品牌工作区）。这没有问题——在拥有 Universal page 的工作区运行改写，在拥有已连接社交页面的工作区运行分发。需先用 list_pages 确认两者；如果缺少 Universal page，请用户添加一个。
连接器健康检查
在执行任何操作前，先验证两个 MCP 均可访问：
-
SE Ranking：调用 DATA_getSubscription。如果失败或返回认证错误，立即停止并告知用户：
“SE Ranking 连接器无响应——请先重新连接再继续。设置指南：https://seranking.com/api/integrations/mcp/”
-
Planable：调用 list_workspaces。如果失败或返回认证错误，立即停止并告知用户：
“Planable 连接器无响应——请先重新连接再继续。设置指南：https://help.planable.io/hc/en-us/articles/27538577098780-How-to-connect-Planable-MCP-to-your-AI-tools”
只有当两个调用都返回成功响应后，才继续执行下面的流程步骤。
流程
1. 获取审计——先复用再爬取
完整爬取速度慢且消耗套餐爬取预算，因此先检查是否存在现有审计：
- PROJECT_listAudits（或 DATA_listAudits）——如果该域名存在近期已完成的审计，则复用；用 PROJECT_getAuditReport / DATA_getAuditReport(audit_id) 读取。记录审计日期并告知用户其新鲜度——如果已过时（超过一两个月），可提议重新运行。
- 仅当不存在审计（或用户想要新数据）时：PROJECT_createAudit(domain, settings?) → 轮询就绪状态 → getAuditReport。没有项目时，使用 DATA_createStandardAudit（或 createAdvancedAudit）。对大型站点合理设置 max_pages 范围。
然后通过 DATA_getAuditPagesByIssue / getIssuesByUrl 列出每个问题背后的具体页面。重点关注影响排名且与页面文案相关的问题：重复/缺失的标题和描述、缺失 H1、内容单薄，以及技术标记（失效链接、可索引性、重定向）。
2. 补充竞争与需求背景
对于值得修复的页面，理解“好”的标准：
- DATA_getDomainCompetitors + DATA_getDomainKeywordsComparison——竞争对手在这些主题上排名而该页面没有覆盖的内容（丢弃偏离品牌/无价值的缺口词——参见 seo-gaps 技能的说明）。
- DATA_getSerpResults 针对页面的目标查询——需要匹配的主导内容格式和 SERP 特性。
- DATA_getRelatedKeywords + DATA_getKeywordQuestions——改写应覆盖的子主题和问题（查询几个种子词；每次只返回少量结果）。
3. 排定优先级
构建排序后的修复列表：页面 URL → 问题 → 机会（目标查询、搜索量、缺口）→ 工作量。优先处理同时具备真实问题和真实需求的页面。向用户展示该列表并确认要起草哪些页面。
4. 在 Universal content page 中起草改写文案（评审界面）
对于每个已确认的页面，撰写改进后的文案（标题、元描述、H1/H2 大纲，以及基于步骤 1–2 的正文或详细章节指导）。在 Planable 的 Universal content page 上创建：
- create_post(workspaceId, universalPageId, text)——将线上页面 URL 放入正文，以便评审者知道它对应哪个页面。
这为团队提供了真实的评审对象：
- create_comment(workspaceId, postId, text) 用于反馈和提问（teamOnly: true 用于内部备注）。
- update_post(workspaceId, postId, text) 用于就地应用修订。
- approve_post(workspaceId, postId) 用于签核。
将页面文案草稿与社交帖子分开——create_grouped_post 会将 universal 和非 universal 页面拆分为不同子组，因此不要试图在一个分组帖子中同步网站文案和社交文案。
5. 安排社交分发层
对于每个已批准的页面更新，起草宣布或支持它的社交帖子——按平台使用 create_post，或在社交页面间同步文案时使用 create_grouped_post（记住分组帖子共享同一文本，因此要注意最严格平台的长度限制）。用标签（例如“content-refresh”）将它们关联到同一活动；注意标签是按工作区划分的，因此如果社交与 Universal page 位于不同工作区，也要在那里创建标签。
调度——创建前先询问。不要猜测日期，也不要默认全部不设日期。询问用户希望如何为该批次设定日期，并提供选项：在时间窗口内均匀分布（例如未来 7 天，每个时段一篇，选择合理时间）、固定节奏/间隔（例如每个工作日 10:00，从用户给出的开始日期排布）、每篇手动设定日期，或暂不设日期（未定日期的草稿，稍后放到日历上）。将每个选定时间转换为 ISO 8601 并作为 scheduledAt 传入。保持帖子为提议草稿——不要设置 publishAtScheduledDate——这样不会自动发布；仅在用户明确希望自动发布时才设为 true。计划时间按 UTC 处理，因此请确认时区或说明时间为 UTC。
6. 移交发布步骤
已批准的页面文案已准备好，交由网站/CMS 负责人发布——该步骤为手动操作，不在这些 MCP 范围内。总结：起草了哪些页面、其评审/审批状态，以及排队分发它们的社交帖子。可提议在更改上线后重新审计，以确认问题已清除。
内容指引：针对关键词与 AI 可见性缺口写作
在撰写页面改写文案以及旨在针对特定关键词或闭合 AI 可见性缺口的支持性社交内容时，请记住：
- 每篇针对一个意图。选择一个关键词或问题，清晰地回答那一件事。试图覆盖所有内容的帖子什么都排不上名，也得不到引用。
- 先给出答案。把要点放在第一行，然后展开支持。浏览者和 AI 引擎都会提取最清晰、最自包含的陈述——不要把它埋起来。
- 按人们实际提问的方式写。将钩子、文案和标题表述为真实问题和通俗语言的答案。AI 提示是对话式的，因此自然措辞胜过关键词堆砌。
- 让论断可独立引用。AI 工具会脱离上下文提取片段，因此每个关键句子都应能独立成立——一个观点、陈述式、不要“如上所述”。
- 具体。数字、具体示例、命名步骤、清晰定义。具体性才是被引用的关键，也是你区别于竞争对手已占据的通用内容的地方。
- 填补缺口，而非重复。如果竞争对手已占据某主题，找出他们遗漏的子问题或角度，而不是重复已经排名的内容。
- 跨渠道保持一致。在社交、网站和个人资料上使用相同的术语和论断，以便 AI 构建出关于你品牌是何种问题答案的一致图景。
- 保持人性化。它仍然必须读起来像一篇好帖子——为关键词或 AI 优化不应让文字变得机械。
输出
- 优先级修复列表——页面 → 问题 → 机会 → 工作量。
- Universal content page 草稿——改写后的文案，位于 Planable 中，可供评论和审批（含链接）。
- 社交分发草稿——支持每个更新页面的已排期帖子。
- 协调总结——哪些已批准、哪些待评审、哪些已排队，以及哪些需要发布到网站。
提示
- Universal content page 是页面文案的协作界面；将其帖子视为文档，而非社交文案。将线上 URL 放入正文，以便评审者获得上下文。
- 复用审计，不要过度爬取。爬取预算受套餐限制——当现有审计足够新鲜时读取它，必须爬取时限定 max_pages。
- 每条改写建议都要以审计 + SERP 证据为依据；不要在没有数据理由的情况下断言“增加 800 字”。
边界情况与限制
- 发布到网站不在范围内。这些 MCP 负责评审和批准文案并处理社交分发；它们不会推送到 CMS。请明确说明移交。
- Universal page 和社交页面可能位于不同工作区。不要假设一个工作区同时拥有两者——用 list_pages 确认，并在各自页面所在处运行每一层。
- 页面无法通过连接器创建。如果工作区缺少 Universal content page（或所需的社交页面），请用户先在 Planable 中添加。
- 审批需要配置好的工作流。approve_post 仅在工作室区配置了审批工作流时有效；如果没有，请使用评论进行签核并说明。
- 重新审计以验证修复，只有在更改实际发布到线上网站后才会反映变化。