关于 seo-aeo-audit
seo-aeo-audit 是用于评估网站搜索与答案引擎可见性的技能,面向 SEO 从业者和网站团队。它要求每项发现有可核验证据,并输出按优先级排列的执行计划,而非代写内容或构建页面。
主要功能
- 01审查搜索与答案引擎可见性
- 02按证据等级标注建议
- 03检查技术、内容与测量问题
- 04区分现场审计和建站简报
- 05提供审计脚本与基线检查
适用场景
- 01调查网站流量下降或排名停滞
- 02为新建网站或页面制定 SEO 简报
- 03评估内容能否被答案引擎提取
- 04整理有证据支持的修复优先级
MCP 相关
技能可利用已连接的 MCP;README 提到 Prowl 可提供批量竞争与需求数据。
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ ssheleg/ seo-aeo-audit --skill seo-aeo-audit安装后在 Claude Code 中输入/seo-aeo-audit确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
REFERENCE_INDEX.mdreferences/aeo-geo.mdagent-readiness.mdalgorithm-updates.mdarchitecture-and-equity.mdbenchmarks.mdbuild-time.mddeliverable-templates.mddemand-and-conversion.mddiscover.mdentity-and-brand.mdevidence-tiers.mdexperience-signals.mdexperiments.mdgrowth-plays.mdintent-and-content.mdlinkbuilding.mdmeasurement.mdmyths.mdonpage-checks.mdplaybooks.mdpreflight.mdprowl-mcp.mdranking-model.mdscripts.mdtechnical-checks.mdthreats-and-defense.mdtooling.mdscripts/agent_surface.pyai_panel.py详细介绍
seo-aeo-audit — 审计搜索与答案引擎的可见度,并交付计划
只有一项任务:检查真实网站,用证据证明问题所在,并交付按优先级排序的变更计划,覆盖传统搜索(Google、Yandex、Bing)和答案引擎(AI Overviews / AI Mode、ChatGPT、Perplexity、Claude、Copilot、Gemini、Alice AI)。
范围:审计线上网站,或在网站建成前撰写网站简报;绝不编写内容或构建页面(也不购买链接)。最终交付经过验证的诊断与可执行计划,或一份简报。
不可妥协的原则
- 无证据,不报告。 每项发现都必须包含:观察到的内容、位置(
URL、file:line、报告名称)、观察值和日期。绝不报告未经你在该网站上验证的发现。“最佳实践这么说”不是证据。 - 为每条建议标注证据等级(参见 references/evidence-tiers.md):
CONFIRMED(有引擎文档记录或已在该网站上复现)·STUDY(已发表的多站点数据)·FIELD(单个案例报告)·HYPOTHESIS。绝不能让HYPOTHESIS排在CONFIRMED阻塞项之前。 - 先诊断,再开处方。 找到原因之前,不得将修复方案写入计划。“添加 schema”不是诊断。
- 拒绝迷思清单。 参见下方的“迷思防范”——建议这些做法会浪费客户预算,是缺陷,不是小问题。
- 绝不建议欺骗性手段。 伪装、捏造共识网络、操纵评论、恶意滥用竞争对手下架手段,以及伪造点击信号,都不得出现在计划中。本技能只会在 references/threats-and-defense.md 中提及这些行为,并将其视为需要检测和防范的对象。
- 明确说明无法检查的内容。 缺少 GSC 登录权限是报告中的信息缺口,不应悄然省略。
- 绝不混淆实测与假设。 如果一份交付物同时包含两者——链接建设 CSV 一定如此——就用
source列加以区分;未实测行的数量单元格必须留空,而不是填零。0表示“已测量,没有需求”;留空表示“尚无人检查”。在别人要按预算执行的工作中,这一区别尤为重要。 - 了解每种检测工具的盲区,并在输出中说明。 规则 1 和 7 约束你写的内容;它们无法发现工具在你查看之前就已混合或省略的数据。以下两种情况屡见不鲜。静态抓取无法看到 CMS 通过 JavaScript 注入的 JSON-LD,因此在任何 Yoast/RankMath/AIOSEO 网站上,“未发现 schema”都是错误发现——
scripts/page_audit.py会在每份 schema 清单旁打印这一注意事项,只有经过渲染检查后才能报告未发现 schema。启用同意模式建模的 GA4 会在同一个数字中返回观测到的行为和估算行为——参见 references/measurement.md J1,了解三项启用条件、可见指示器,以及仅使用观测数据的备用方案。这条规则适用于所有情况:在把某种工具的沉默视为发现之前,先确认该工具确实有能力观测到相关内容。
步骤 0 — 检测模式,绝不重复询问
先检查,再行动。按以下顺序:
- 审计还是简报。 尚无线上内容(新网站、新版块或新落地页)
时,先撰写简报:遵循 build-time.md,写入
docs/seo/brief-<YYYY-MM-DD>.md,然后停止。不提供发现,不添加 myth 条目。 - 阅读
docs/seo/(或用户指定的路径)。如果已有先前的审计,本次运行就是重新审计:与其对比,并首先说明发生了哪些变化。 - 确认你能访问哪些内容——线上网站、预发布环境、
robots.txt、sitemap.xml、 Search Console / Bing / analytics、抓取导出数据、服务器日志,以及任何已连接的 MCP (Prowl 提供批量竞争和需求数据,无需购买各供应商的席位)。 测试访问权限,不要想当然 (preflight.md)。 - 只有在答案会改变工作内容时,才与用户确定范围:整个网站、某个模板、某个问题,或链接建设数据提取——这是一项交付内容,而非诊断;有无 Search Console 都可进行,并且有专属文件 (linkbuilding.md)。
- 用三行报告状态——可用输入、缺失输入、范围——然后开始。每次运行结束时,恰好提出一项下一步行动。
python3 "$SKILL_DIR/scripts/preflight.py" --site sc-domain:example.com --origin https://example.com
它会指出失败发生在哪个关卡——login、quota-project、
api-not-enabled、scope 和 permission 分别代表不同原因,而其中大多数都会返回
403。它会探测哪些内容,以及剩下的大部分工作:preflight.md。
预检通过,不代表某个步骤已覆盖。
先解析 $SKILL_DIR 并确认其路径,再依赖它——在 Claude Code 插件中使用
${CLAUDE_PLUGIN_ROOT}/skills/seo-aeo-audit;其他情况下则使用本文件所在的目录;
scripts.md 列出了这两种形式及所有调用方式。
No such file or directory 并非功能缺失,也不是悄悄继续的理由。 这表示无法访问相关工具,因此这些工具原本会执行的每项检查都只能降到证据阶梯的最低一级——而这一级会限制结论的等级。请在三行状态中说明这一点:悄悄将审计改为手动审计,会改变其结论的价值(不可妥协项 #6)。
访问规则:默认只读。未经本次会话中的明确批准,绝不提交表单、请求编入索引、拒绝链接或更改线上属性;这些都属于对外操作。
第 1 步 — 先建立基线,再做判断
记录数据并标注日期,以便后续每项结论都有据可依:
- 按国家和设备统计 12 个月的自然点击量 / 展示量 / 平均排名 (GSC + Bing),以及是否存在下跌或停滞期;
- J3b 基线: 按搜索引擎主机和语言区域统计的引荐量、品牌搜索旁边的直接流量 / 无引荐来源流量 (进行任何 AEO 更改之前)、各模板的索引量占比、分析工具可见的后端订单份额;缺少 Bing 验证或 IndexNow 密钥属于数据缺口;
- 按模板统计已编入索引与已发布的 URL 数量(
site:只能用于粗略检查,GSC Pages 报告中的数据才是准确数量); - 收入或转化量排名前 20 的页面及其当前排名;
- AI 界面基线:对每个可访问的引擎运行 references/aeo-geo.md 中的品牌和类别提示词集,并逐字记录答案;
- 实际抓取网站的 AI 爬虫(服务器日志;通过正向确认的反向 DNS 过滤伪装者),以及分析工具中出现的 AI 引荐来源;
- 更新时间线:在对原因形成任何假设之前,将曲线中的每项变化按日期与 references/algorithm-updates.md 对齐。
如果完全没有第一方访问权限,请在三行状态中说明,并根据第三方索引能确认的信息继续——当前排名、相对于按规模选定的竞争集的链接概况,以及目标词组是否有搜索需求
(prowl-mcp.md)。这类基线最高只能达到 STUDY,无法回答“为什么此页面未被编入索引”,但能区分冷启动和流量下跌,而两者需要截然不同的方案。
如果网站声称流量下跌,请先区分报告故障与排名下跌:GSC 报告冻结时,点击量会停留在某个日期;而真实的流量冲击会持续产生新的下跌数据点(gsc_pull.py 会打印 report-stale)。在诊断算法原因之前,请交叉检查 GA4 会话、服务器日志,以及通过
搜索结果页污染防护验证的独立排名跟踪工具。
第 2 步 — 十项排查
运行所有适用的排查项。每项都有自己的文件,其中列出了具体检查内容、2026 年当前的常见陷阱,以及需要收集的证据。
| # | 赛道 | 解答的问题 | 参考 |
|---|---|---|---|
| A | 访问与索引经济性 | 机器人能否抓取、渲染并承担访问成本?抓取预算消耗在哪里? | technical-checks.md |
| B | 规范化与重复内容 | 哪个 URL 是规范 URL,搜索引擎是否认同——包括 hreflang 在内? | technical-checks.md |
| C | 架构与链接权重 | 重要页面是否获得权威性、足够的深度和抓取频率? | architecture-and-equity.md |
| D | 搜索意图与 SERP 匹配度 | 每个页面是否与 SERP 匹配,页面之间是否互相蚕食流量? | intent-and-content.md + onpage-checks.md |
| E | 内容价值 | 内容是否有 AI 无法复制的排名理由?读起来是否像出自同一人之手? | intent-and-content.md + ranking-model.md |
| F | 可提取性与 AEO/GEO | 答案引擎能否检索、读取并引用内容? | aeo-geo.md |
| G | 实体与品牌共识 | 模型是否了解并始终如一地提及该品牌? | entity-and-brand.md |
| H | 体验、转化与归因 | 用户是否在此完成任务,还是跳回了搜索结果?是否产生转化并完成衡量? | experience-signals.md + demand-and-conversion.md |
| I | 风险与威胁 | 惩罚、劫持、注入、下架。 | threats-and-defense.md |
| J | 衡量 | 是否有人能判断计划是否奏效? | measurement.md |
| K | Agent 接入面 | 机器能否在此发现、验证身份并进行交易? | agent-readiness.md |
赛道 K 为条件性项目(适用于 Agent 可以在网站上购买、调用或执行自动化操作的情形)。
是否存在为 CONFIRMED,其影响大多为 HYPOTHESIS,因此大部分内容归入实验
(agent-readiness.md)。
Discover 不是十个赛道之一,也不属于赛道 A:其检查项中没有一项是渲染门槛。如果 GSC Discover 报告显示它是重要流量来源,请将 discover.md 作为第十一次检查运行。
在诊断任何下降之前,先运行 references/algorithm-updates.md 中的日期对齐与更新响应 流程——“我们受到了核心更新的影响”不算结论,而且有一半有记录的 GSC 故障 与更新发布同时发生。
每个赛道分为两部分:诊断工作和确保完整性的机械式扫描——A/B 赛道见 technical-checks.md §A3,D/E 赛道见 onpage-checks.md。先诊断;之后再通过扫描发现容易忽略的问题。只有存在可观察影响的扫描项才会进入发现结果表。
顺序很重要。 赛道 A 的阻塞问题(网站无法抓取、预渲染源中有 noindex)会让其他所有发现都失去意义。人工处置是有适用范围的乘数,不是二元开关:记录其类型、受影响的 URL 模式、适用面、严重程度和范围。SITEWIDE 处置会让所有改进失效,直到处置解除;解除处置仍是首要任务。PARTIAL 处置(例如匹配 /spam/*)只会让其覆盖范围内的改进失效——在 /checkout 上已证实的身份验证或可用性修复仍然有效、仍应发布,并在报告中注明相关处置,而不是将其掩盖。阻止受影响模式之外的依赖工作,等于凭空捏造 Google 并未施加的惩罚。在投入时间处理 F/G 之前,先完成 A → B → C。
证据阶梯——按证据强度而非便利性排序,从服务器日志一直到手动抓取;各阶梯及其路由见
tooling.md。使用你实际能够获取的最高阶梯,并说明一项发现依据的是哪一阶梯。仅进行公开信息审计、无法访问站点资源,也是有效的工作;但其中关于索引和查询的发现属于推断而非观察,应据此划分等级。
此技能附带九个脚本——preflight.py、gsc_pull.py、
page_audit.py、url_inspection.py、agent_surface.py、psi_pull.py、
sitemap_audit.py、bwt_pull.py 和 ai_panel.py。它们的调用方式,以及决定一项发现是否属实的四个陷阱——渲染后的 HTML 与服务器端 HTML、JSON 数组结构、截断导致基于计数的发现被丢弃,以及进入分流流程的证据等级(严重程度则不会)——详见 scripts.md。
步骤 3 — 分流
首先,交叉核对各条线的结论。 十条线会产出十组彼此从未见过的发现,而计划却把它们当成一个答案——这种汇总仅仅因为输入已到齐,就信任这些输入。对未排序的列表进行排序,并不等于发现其中两项无法同时执行。
计算任何分数之前,先检查以下四件事:
- 两条无法同时执行的建议。 D 认为两个页面相互蚕食,应当合并;C 认为较深的那个页面才是权重汇集之处。指出这对建议,判断以哪条为准,并说明原因——读者之后同时遇到这两条建议时,无法自行判断。
- 同一个根本原因披着两个跟踪名称。 一个阻塞渲染的模板问题同时表现为 A、F 和 H 的发现:三行、一个修复方案,而这三行抬高了计划的工作量,也分散了优先级。
- 同一个声明键的两个不兼容值。 将各行作为声明进行比较,键为
(subject, predicate, scope, time, instrument):只有同一主题在同一快照中、同一个谓词对应不兼容的值时,才存在矛盾。一个 URL 在不同谓词下分别标为CONFIRMED和HYPOTHESIS,两者并无分歧——HTTP 状态可以是已确认的,而排名原因仍然是一个假设;这些层级描述的是检测手段,而不是网站,较低层级只会在同一个谓词范围内让位。相同键、不同值——这时才需要裁定:两个检测手段之间的分歧,应明确表述为检测手段之间的分歧;同一个检测手段自相矛盾,则必须在报告前解决。 - 某条线没有返回结果,而相邻线的发现似乎表明它应该有结果——先核对谓词,再判定为漏查。 F 未发现可提取性问题,而 E 认为页面内容单薄,这是两个兼容的观察结果:单薄评估的是内容深度,可提取性是机械属性,短页面也完全可能被正确提取。只有当两条线测量的是同一个谓词,其中一条却没有发现时,才适用“有一方没有认真检查”的判断——强行要求不同属性相互吻合,会丢失真实数据。
无论结果如何,都要写明:Cross-track: clean,或列出存在分歧的配对及其裁定。若一项检查的沉默与未运行无法区分,那就不是证据——而这也最容易被忽略,因为每条线单独看都显示为绿色。
然后为每项发现排序。不要呈现未排序的列表。
四个维度,不合并成单一分数——按以下顺序比较,首先能区分两项发现的维度即为优先依据:impact · irreversibility · uncertainty · coordination。effort 需要记录,但不用于排序。综合分无法对其输入提出质疑,而各个维度可以。定义见:
deliverable-templates.md。
按以下顺序将输出分为四类:
- 阻断项 — 索引、处罚、劫持、收入页面无法访问。
- 损耗项 — 爬取预算、权重、相互蚕食、读取预算浪费。
- 收益项 — 意图匹配、信息增益、可提取性、实体共识。
- 实验项 — 根据证据层级推广策略分流至此的内容(操作风险 × 因果依据,绝不能只看层级)。按照 references/experiments.md 设计;切勿在全站范围内推广 HYPOTHESIS。
步骤 4 — 交付物
根据 references/deliverable-templates.md 中的模板骨架,编写以下文件。 切勿在未告知的情况下覆盖现有审计或计划——请新建带日期的文件,或先行询问:
docs/seo/audit-<YYYY-MM-DD>.md— 调查结果,每项都要标明其证据层级, 即观察结果的来源;来源决定其层级上限 (tooling.md)。docs/seo/plan-<YYYY-MM-DD>.md— 变更计划:每项变更都要写明确切目标、 背后的机制和层级、预期效果,以及回滚方式。docs/seo/experiments.md— 追加内容,而非按日期新建,因为它的有效期超过任何一份审计报告。只要计划中有 Experiments 类别,就必须创建此文件;任何低于CONFIRMED的事项都归入此类别。
执行摘要规则:最多 5 条,列出最重要的三个阻碍、预期收益规模,以及必须首先完成的一件事。面向具备技术素养的非专业人士撰写;术语首次出现时需展开说明。
步骤 5 — 验证,然后跟进
- 在每项变更上线前,说明其验证方法(GSC Pages 报告从 X 变为 Y;URL Inspection 实时测试显示 canonical 已被接受;日志显示 Googlebot 正在抓取
/_next/static/;提示词集中的 10 个回答有 N 个提及品牌)。 - 如实设定回查时间:索引需要 2–8 周;修复后 canonical 分组最多需要 2 周才会拆分;核心更新的影响需要一个季度;AI 训练的影响需要数月。无法承诺具体日期时,请明确说明。
- 重新审计时,与上一份报告进行差异对比,并为每项先前的调查结果标记
fixed/partially fixed/unchanged/regressed,同时提供新的证据。
误区防护 — 切勿将以下内容列入计划
最常被询问的 14 项被驳斥主张,共有 33 项。每项主张都有 2026 年证据予以驳斥;完整列表、反证以及每项主张对应的有效替代方案,见 references/myths.md——回答不在此简表中的策略问题前,请先阅读。
- 将
llms.txt作为排名或引用的手段 · 将 HTML 页面转换为 Markdown 镜像,作为 GEO 策略 · “为检索器拆分内容块” · 专门“为 AI”改写文本 · 将 schema 数量作为 AI 引用的手段 · 使用 FAQPage 标记获取富媒体搜索结果(Google 已停止支持) · 以 AMP 获得排名优势 · 更新发布日期作为新鲜度信号 · “只要增加更多页面” · 根据第三方毒性评分提交拒绝链接 · 购买“AI 可见度”数值并将其作为单一 KPI · 将自我宣传的“最佳[类别]”榜单作为 AEO 策略 · 将大规模 AI 内容作为增长策略 · 将带跟踪参数的 URL 设为Disallow以保护抓取预算(具体机制由 technical-checks.md A2 负责)。
用户询问其中任一项时,请直截了当地说明证据表明了什么,提供最接近且有效的替代方案,然后继续处理。
llms.txt 和 Markdown 镜像面向 Agent,而非排名:
myths.md,其中两项的作用边界。
触发词
“AEO audit” / “аудит по SEO и AEO”,“AI visibility audit”,“why did my traffic drop”,“why am I not ranking” / “почему нет позиций”,“why doesn't ChatGPT cite us” / “почему нас не цитирует ChatGPT”,“indexing issues” / “проверь индексацию”,“SEO change plan” / “план правок по SEO”,“google core update” / “апдейт гугла”,“keywords for linkbuilding” / “ключи для линкбилдинга”。
参考索引
加载 REFERENCE_INDEX.md,以便将跟踪、审查、监测或交付物任务转至对应的详细参考资料。