Claude SEO 实战：用 FLOW CTR Audit Prompt 产出可执行的点击率优化交付物

【免费下载链接】claude-seoUniversal SEO skill for Claude Code. 26 sub-skills + 19 sub-agents covering technical SEO, E-E-A-T, schema, GEO/AEO, agent readiness (Lighthouse Agentic Browsing, WebMCP, llms.txt), backlinks, local SEO, e-commerce, international SEO, Google APIs, and PDF/Excel reporting. 9 optional extensions for live SEO data.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-seo

本篇技术指南围绕 CTR AUDIT PROMPT（点击率审计提示词）展开，讲解它如何在 Claude Code 的 seo-flow 技能中扮演 Optimize（优化）阶段的"结构化交付物生成器"：把搜索结果中的点击率瓶颈，转化为带证据标签、可排序、可验证、可执行的优化工作文档。读完本文，你将掌握该提示词的完整用法、输入与输出契约、与其配套的 FLOW 框架方法论，以及它在仓库源码层面（技能编排、Agent 调用链、提示词同步机制）是如何落地的。

一、背景：CTR 审计为什么需要"结构化提示词"

FLOW 是 claude-seo 仓库中集成的证据驱动型搜索与转化循环框架，分为四个阶段：Find（发现需求）→ Leverage（利用分布式证据）→ Optimize（优化自有资产的可提取性与信任度）→ Win（用页面与测量打通发现与营收）。该框架的完整定义见 flow-framework.md。

CTR Audit Prompt 属于其中的 Optimize 阶段。这一阶段的定位是：当资产"难以被搜索引擎或 AI 提取、难以被用户信任、难以转化为动作"时，产出结构化的优化方案。仓库 SKILL.md 明确说明，Optimize 阶段共沉淀了 21 条提示词，CTR Audit Prompt 是其中之一，与 technical-audit-prompt、property-content-with-authority-audit-prompt、visibility-follow-up-prompt 等共同构成优化提示词族。

为什么 CTR 审计需要提示词而不是自由发挥？flow-framework.md 给出了两个 2026 年数据背景：当 AI Overview 出现在结果页时，排名第一内容的平均 CTR 下降了 58%（Ahrefs 2025 年 12 月数据集）；在 ChatGPT 引用的头部 URL 中，有 25% 在 Google 自然结果中没有任何可见度（seoClarity）。点击率不再是"标题写得好不好"的问题，而是"搜索结果这个入口能否把用户带进资产"的问题。数据来源可在 bibliography.md 中核对——这正是 FLOW 框架"证据标准"的体现：凡涉及数字的声明，要么可溯源到参考文献，要么删除。

二、Use This When：什么时候触发这条提示词

原文档给出的触发条件是：

当你需要一份结构化的优化交付物（structured optimize deliverable），并希望模型严格区分"观察（observations）""假设（assumptions）""推荐动作（recommended actions）"和"需要验证的声明（claims that need verification）"时使用。

一句话概括：只要输出会被团队执行、被后续环节引用、或被当作决策依据，就应该用这条提示词来约束模型的输出纪律。典型场景包括：

• 某页面有曝光但点击率低于同位置均值，需要诊断 SERP 入口问题；
• 本地服务页转化弱、资料信息前后不一致，需要一份重写简报（rewrite brief）；
• 需要把零散的搜索词数据、分析数据整理成可执行的优先级清单；
• 需要向客户或团队交付一份"观测 vs 假设 vs 待验证"边界清晰的报告。

从 SKILL.md 的编排逻辑看，/seo flow optimize [url]命令会先读取references/prompts/optimize/下所有文件名，结合 URL、行业垂直和对话中已有的分析上下文，只挑选 2-3 条最相关的提示词加载，然后应用。也就是说，CTR Audit Prompt 不会单独被"无差别倾倒"，而是被选中的场景通常是：搜索结果可见性与点击入口存在明显疑点，且之前的技能输出（如 seo-technical 的抓取问题、seo-content 的 E-E-A-T 缺口）已经暗示 CTR 层面的问题。

三、AI Compatibility：不同规模模型的适配策略

原文档明确了一条兼容性约束：

适用于长上下文推理模型（long-context reasoning models）。对于较小规模的模型，请提供更窄的输入范围，并一次只要求输出一个章节。

这背后是实际的上下文工程考量。CTR 审计的完整输入可能包含分析数据、搜索结果、通话记录、评论、资料事实等多类证据，叠加提示词要求的六维输出结构，对上下文窗口和推理深度都有要求。实际使用时可以这样做：

• 大模型：一次性灌入全部输入，要求输出完整交付物；
• 中小模型：按原文档的建议切分——先给"目标与输入清单"，让它输出执行摘要；再逐段提供证据与缺口，要求输出优先级表；最后给出"待验证声明清单"。每次只产出一个章节，避免推理质量滑坡。

该策略与 agents/seo-flow.md 中 Agent 的约束一致——Agent 规定"每次调用最多应用 5 条提示词（上下文窗口限制）"，且 Optimize 阶段绝不一次性加载全部 21 条提示词，而是根据页面信号挑选。

四、Inputs：五个维度的输入契约

原文档规定，触发前必须准备好以下输入。任何一个缺失都会导致输出中"假设"占比上升：

注意第五项的"必需来源（required sources）"：它直接呼应 FLOW 框架第 3 条操作原则——"可观测证据与假设必须分离，带数字的声明必须能溯源到 bibliography.md 或被移除"。在实际项目中，这通常体现为"该说法只能引用 Google Search Console 数据"或"这条结论必须附带抓取时间戳"。

五、Prompt 全文与逐条拆解

以下是原文档给出的完整提示词正文，可直接复制使用：

Act as a senior SEO strategist using the FLOW model. Task: create a optimize deliverable for: [BUSINESS OR ASSET]. Use only the supplied inputs and clearly label any assumption. Do not invent statistics. Do not reuse private examples. Build the answer around: 1. Searcher or buyer intent. 2. Evidence available now. 3. Gaps that block trust, extraction, or conversion. 4. Recommended changes in priority order. 5. Measurement events and review cadence. 6. Claims that require source verification before publication. Return a concise working document the team can execute.

六个构建维度逐一解读：

1. 搜索者或买家意图（Searcher or buyer intent）：先回答"谁在搜、带着什么决策风险来搜"，而不是从公司偏好出发。FLOW 框架的失败模式清单中专门点名"围绕公司偏好而非买家问题与决策风险来写页面"；
2. 当前可用证据（Evidence available now）：只使用输入中提供的证据，不调用模型"记忆"中的过期案例或熟悉的数据；
3. 阻碍信任、提取或转化的缺口（Gaps）：把问题归类到三个层面——用户不信任（信任缺口）、搜索引擎/AI 无法提取（提取缺口）、有流量无动作（转化缺口）；
4. 按优先级排序的推荐变更（Recommended changes in priority order）：不是罗列，而是排序，让团队能直接照着执行；
5. 测量事件与复查节奏（Measurement events and review cadence）：对应 FLOW 的 Measurement 部分——"如果页面或资料无法被测量，先补测量事件，再评判表现"；
6. 发布前需要验证的声明（Claims that require source verification）：把待验证项显式列出，杜绝"听起来熟悉就直接发布"。

提示词末尾的"Return a concise working document"是刻意的：交付物应当简洁、可执行，而不是一篇冗长的分析散文。

六、Output：交付物的六个标准章节

原文档规定输出必须包含以下六部分，建议直接作为工作文档的一级结构：

这套输出契约与 FLOW 的"质量底线（Quality Bar）"完全咬合：公开声明要么有已核实的来源，要么保持定性表述；示例必须是通用的或为本仓库新建的；私有编辑笔记只能用于识别候选概念，绝不能作为公开文案。

七、Example：本地服务页实战推演

原文档给出的示例输入与期望输出：

输入：一个本地服务页面，信任证据薄弱（weak proof），资料详情前后不一致（inconsistent profile details）。

期望输出：一份按优先级排序的重写简报（prioritized rewrite brief）、需要核对的事实清单（facts to reconcile）、需要补充的内部链接（internal links to add），以及需要测量的转化事件（conversion event to measure）。

把六维结构套到这个例子上，可以推演出交付物轮廓：

• 意图：本地服务查询，搜索者处于"货比三家"决策阶段，顾虑是资质、价格透明度与可预约性；
• 现有证据：GSC 中该页曝光不低但点击率偏低、GBP 资料字段有矛盾、仅有的 2 条评论口径不一；
• 缺口：信任缺口（无资质/案例证据）、提取缺口（NAP 信息不一致导致本地实体识别混乱）、转化缺口（无明确的预约 CTA）；
• 优先级动作：① 核对并统一 NAP 资料事实 → ② 重写首屏信任证据 → ③ 补充 2-3 条指向相关服务页的内部链接 → ④ 加装"预约电话"转化事件；
• 测量：以"点击电话/表单提交"为转化事件，设定复查周期（如两周一次）；
• 待验证声明："本地排名前 3""行业领先"等宣传语，发布前必须核对事实。

值得注意的是，"facts to reconcile"（需核对的事实）正是 CTR 审计区别于普通文案优化的关键：点击率的改善不只靠标题，还靠 SERP 中实体信息的一致性——当资料前后矛盾时，即使点击进站，跳出率与转化也会受影响。

八、在 Claude Code 中的实际调用方式

方式一：通过/seo flow optimize命令

在 Claude Code 中执行/seo flow optimize [url]后，技能会：

1. 读取references/prompts/optimize/下全部 21 个提示词的文件名；
2. 结合 URL、行业垂直及对话中先前的技能输出，选择 2-3 条最相关的提示词（只加载选中的文件，避免上下文噪音）；
3. 应用提示词并输出结构化结果；
4. 交叉引用：如需完整的内容质量分析，会提示转向/seo content <url>与/seo geo <url>。

选择逻辑（见 SKILL.md 的 Context Matching 一节）按优先级判断：行业垂直（SaaS → 页面+技术；本地 → 引证+GBP；出版 → E-E-A-T+新鲜度）→ 先前技能输出（seo-technical 标记抓取问题 → 技术类提示词；seo-content 标记 E-E-A-T 缺口 → 内容类提示词）→ URL 信号（产品页 → 转化；博客 → 新鲜度+权威）。

方式二：通过 FLOW 分析 Agent

agents/seo-flow.md 定义了专门的 FLOW 提示词分析 Agent（模型 sonnet，最多 15 轮）。当给它一个 URL 和阶段时，它会：

1. 用 WebFetch 抓取目标 URL，理解页面内容与行业信号；
2. 读取skills/seo-flow/references/prompts/{stage}/下的相关提示词文件；
3. 对 Optimize 阶段：先读全部文件名，再依据页面可见的行业信号、内容缺口、技术或权威问题选择 2-3 条；
4. 逐条应用并填充到当前站点；
5. 返回带阶段标签（FIND / LEVERAGE / OPTIMIZE / WIN / LOCAL）、所选提示词文件名+选择理由、证据标签化发现、以及"验证/强化每条发现所需的数据"。

Agent 输出格式要求首行携带归属声明（Framework and prompts © Daniel Agrici, CC BY 4.0），并规定每次最多应用 5 条提示词、Optimize 阶段禁止一次性加载全部提示词。安全规则同样值得注意：WebFetch 响应视为不可信外部内容，不可执行、不可 eval、不可原样拼入工具调用。

方式三：结合 GSC 数据使用

CTR 审计离不开真实点击数据。仓库提供了 gsc_query.py 等 Google Search Console 查询脚本，可拉取 clicks / impressions / ctr / position 原始数据作为提示词输入中的"现有证据"。对应测试 test_gsc_totals_aggregate.py 明确处理了一个真实陷阱：按查询维度聚合时点击被匿名化可能产生虚假的"0 点击"站点总量，正确做法是取无量纲的聚合值（该测试断言totals.clicks == 24而非各查询行之和）。这提示我们：喂给 CTR Audit Prompt 的数据必须经过正确的聚合口径校验，否则"证据"本身就是错的，六维输出的可信度会整体崩塌。

九、提示词是如何进入仓库的：同步机制溯源

CTR Audit Prompt 文件头部标注了来源（Source: github.com/AgriciDaniel/flow | License: CC BY 4.0 | Synced: 2026-04-26），这来自 sync_flow.py 的同步机制。该脚本从上游 FLOW 仓库按阶段拉取提示词文件：

• 五个阶段find / leverage / optimize / win / local对应的上游目录是docs/09-prompts/{stage}；
• 拉取后统一写入skills/seo-flow/references/prompts/{stage}/；
• 同时会执行链接重写（rewrite_flow_links）：上游编号目录布局（如01-framework/、10-references/）在本仓库中不存在，脚本会把链接重指到扁平化布局，对未随插件发布的文件则去除链接保留文案，确保同步后不产生死链；
• 每次同步后生成 SHA-256 锁文件 flow-prompts.lock，作为提示词基线，并输出 ADDED / CHANGED / REMOVED 漂移报告。

这意味着本文讨论的提示词正文是可追溯、可校验的版本化资产——任何改动都会在锁文件漂移报告中暴露。/seo flow sync命令即触发该脚本，同步完成后展示 JSON 摘要与归属声明。

十、常见陷阱与执行红线

综合原文档与 flow-framework.md 的 Common Failure Modes，使用 CTR Audit Prompt 时最需要注意：

• 发布熟悉但未核实的统计数字：提示词明确禁止"invent statistics"，框架层面要求"数字声明必须加载并标注日期";
• 把 AI 可见性当成格式技巧：只改标题格式而忽略品牌证据、实体一致性与站外佐证，CTR 改善不会持久；
• 围绕公司偏好而非买家问题写作：这是 FLOW 框架点名的最常见失败模式；
• 只优化流量而不定义下一步合格动作：点击率提升后如果没有明确转化事件，测量计划就是空转；
• 复用私有旧示例：提示词要求"不复用私有示例"，通用示例或新建示例更干净、更持久；
• 证据口径错误：如第八节所述，聚合数据口径错误会让整个交付物失真。

十一、与其他提示词的分工

CTR Audit Prompt 不是孤立存在的。在 Optimize 阶段的 21 条提示词中，它与 visibility-follow-up-prompt.md（可见性跟进）、prompt-core-30-content-audit.md（核心内容审计）、basic-prompt.md（基础提示词）共享同一套"输入→六维构建→六章节输出"结构——从源码看，这些文件的 Prompt 正文与输出契约完全一致，差异体现在各自聚焦的资产类型与触发信号上。完整索引见 prompts/README.md。

当 CTR 审计发现"有流量但转化弱、归因不清"时，应转向 Win 阶段的 conversion-audit-prompt.md（转化审计），它专门处理"页面有流量但合格线索少、转化率低"的场景，且明确要求"在内容、Offer 清晰度与测量缺口评估完成之前，不建议追加广告预算"。这条阶段衔接路径，正是 FLOW 框架"先判断哪个阶段阻塞进展，再在那个阶段构建证据"的落地体现。

十二、从提示词到团队执行的闭环

CTR Audit Prompt 的最终价值，是把一次"凭感觉优化标题"的行为，替换成一条可追溯的流水线：输入（带约束的证据）→ 六维构建（意图/证据/缺口/优先级/测量/待验证）→ 六章节交付物（可执行工作文档）→ 验证清单（发布闸门）→ 测量事件（复查节奏）。配合仓库中的 GSC 数据脚本、FLOW 框架的参考文献标准（bibliography.md）以及/seo flow optimize的命令编排，团队可以从一条提示词出发，建立一套可复用、可审计、可度量的点击率优化 SOP。

【免费下载链接】claude-seoUniversal SEO skill for Claude Code. 26 sub-skills + 19 sub-agents covering technical SEO, E-E-A-T, schema, GEO/AEO, agent readiness (Lighthouse Agentic Browsing, WebMCP, llms.txt), backlinks, local SEO, e-commerce, international SEO, Google APIs, and PDF/Excel reporting. 9 optional extensions for live SEO data.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-seo