seo-maker

@rules/seo-workflow.md @rules/validation.md

SEO Maker

审核并提升项目在传统搜索引擎和 AI 答案引擎中的搜索可见度。

<instruction_contract>

字段	约定
意图	为指定目标生成按证据等级划分的 SEO/AEO/GEO/LLMO 审核，以及优先级明确、可执行的优化报告；当用户要求取得尽可能高的分数时，执行有界的分数提升循环。
范围	负责目标分类、测量方法选择、页面内/技术/内容/Core Web Vitals/AEO/GEO/LLMO 评估、评分、发现项、建议和报告工作区。不负责在经审核目标之外实施更改、发布门禁、页面或产品设计，也不负责与目标网站或内容集无关的广泛市场研究。
权限	系统/运行环境和用户指令 > 经审核目标自身的文件和实时观测 > 平台官方文档 > 此技能 > 启发式偏好。工具、实验室、合成或启发式观测绝不升级为官方要求。
证据	评分前先读取目标自身的文件、渲染页面和实时响应；每项严重和警告发现都要注明其背后的命令、URL、文件路径或探测结果。将无法执行的检查记录为 unknown，将不相关的检查记录为 not-applicable；绝不编造分数、排名、收录状态或引用。
工具	使用可用的读取/搜索/浏览器工具，并通过 scripts/render-dashboard.mjs <artifact-dir> 渲染仪表板。仅在实际可用时使用网络搜索、浏览器检查、现场 Core Web Vitals、Search Console 或 AI 引用探测；若某项能力不可用，应说明能力限制，并改用证据等级最高的可用方法。
循环	仅用于优化模式：执行有界的「审核 -> 修复或建议 -> 重新审核」循环，默认预算为三次迭代。反馈 = 可比的重新审核证据；指标 = 100 分制分数，并排除 unknown 和 not-applicable 类别；防护条件 = 可比类别不得退步，证据等级不得提升；停止条件 = 达到目标、预算耗尽、进入平台期、防护条件失效，或需要外部凭据或业务决策的工作。
输出	.hyper/seo-maker/[slug]/ 中包含复杂模式或优化模式所需的 results.json、results.js、dashboard.html、report.md、sources.md 和 flow.json；简单模式至少保留 report.md 和 sources.md。sources.md 是来源台账，记录 URL、日期、适用声明、证据类别和局限。
验证	完成时遵循 rules/validation.md：每项严重或警告发现都必须附有证据；分数必须源自观测证据，并明确处理 unknown 和 not-applicable；优化模式必须记录基线、评估者、预算、防护条件、已舍弃的迭代、停止原因，以及最佳的可比验证结果。软件包更改还必须运行针对性语料验证器、仓库标准检查和软件包测试。
停止条件	当所请求的审核或报告已完成、证据等级明确且不存在未解决的严重缺口时停止；或者当优化模式达到目标、预算上限、平台期、防护条件，或遇到外部依赖时停止。绝不声称证据无法支持的排名、AI 功能收录情况或引用。

</instruction_contract>

<output_language>

默认所有面向用户的交付内容、已保存的产物、报告、计划、生成的文档、摘要、交接说明、提交/消息草稿和验证说明均使用韩语，即使此规范技能文件以英语编写。

保留源代码标识符、CLI 命令、文件路径、架构键、JSON/YAML 字段名、API 名称、软件包名称、专有名词，以及必须使用指定语言或保留原文的引用摘录。

</output_language> 仅在用户明确要求使用其他语言、现有目标产物必须使用其他语言以保持一致，或机器可读契约要求使用准确的英文标记时，才使用其他语言。如果存在本地化模板或参考文件（例如 *.ko.md 或 *.ko.json），请优先将其用于面向用户的产物。

</output_language>

• 系统地审查网站或项目的 SEO。
• 涵盖页面 SEO、技术 SEO、内容 SEO 和 Core Web Vitals。
• 评估针对精选摘要、语音搜索和直接回答界面的 AEO 就绪情况。
• 评估内容在生成式 AI 回答中被引用的可能性，即 GEO 就绪情况。
• 评估 AI 爬虫访问、内容新鲜度和模型可读上下文方面的 LLMO 就绪情况。
• 将按优先级排序的建议和证据保存到 .hyper/seo-maker/[slug]/。
• 更新现有报告，让 SEO 改进历史保持可追溯。
• 如果用户要求最高分、满分、最高得分、完美得分或持续改进，则运行“审查并修复／提出建议，再重新审查”的循环，并保留最佳结果。

<routing_rule>

当主要目标是 SEO/AEO/GEO/LLMO 审查、优化报告或基于证据的搜索可见度提升计划时，使用 seo-maker。

将相关工作转交给其他技能：

• 页面或产品 UI 设计：使用 designer 或相关的前端设计技能。
• 不涉及网站审查的竞争对手或市场调研：使用 research。
• 输出仅为部署通过／不通过结论，而非搜索可见度审查的发布门禁检查：不属于此技能的输出范围。
• 不涉及搜索背景的纯性能工程：使用相关的性能或优化工作流。
• 不涉及目标网站或内容集的广泛 AI 搜索趋势调研：使用 research。

</routing_rule>

<activation_examples>

正面示例：

• “审查这个网站的 SEO。”
• “检查元数据和结构化数据。”
• “创建一份 SEO 审查报告。”
• “审查搜索引擎优化状况并提供改进建议。”
• “总结如何提升 Core Web Vitals 得分。”
• “优化我们的内容，让 AI 搜索引擎能够引用。”
• “检查 ChatGPT 或 Perplexity 是否能展示我们的品牌。”
• “从 AEO 和 GEO 的角度分析这个网站。”
• “持续迭代修复，直到 SEO 得分尽可能高。”
• “反复审查、修复和验证，直到搜索优化得分接近完美。”

负面示例：

• “设计这个落地页。” -> 使用 designer。
• “研究竞争对手的市场定位。” -> 使用 research。
• “部署前检查发布清单。” -> 这是部署门禁结论，而非搜索可见度审查。

边界示例：

• “优化这个页面的性能。” 仅当通过 SEO/Core Web Vitals 影响来评估性能时，才使用 seo-maker。
• “研究 AI 搜索趋势。” 仅当输出与目标网站、页面或内容清单相关时，才使用 seo-maker。

</activation_examples>

<trigger_conditions>

情况	模式
为新项目或网站进行完整 SEO 审查	create
审查特定页面的页面 SEO	create
在现有 SEO 报告中添加新的分析	update
针对 Core Web Vitals 或技术 SEO 进行专项分析	create
SEO 改进后的再次检查	update
迭代改进，争取最佳分数或满分	optimize
AEO/GEO 引用就绪情况分析	create
在现有报告中添加 AEO/GEO 分析	update

</trigger_conditions>

<supported_targets>

• HTML 页面和 Next.js/React 组件中的元数据和 SEO 元素。
• robots.txt、sitemap.xml、llms.txt、规范链接标签和结构化数据。
• LCP、INP 和 CLS 等 Core Web Vitals 指标。
• <head> 元素，包括标题、元描述、Open Graph 和 Twitter Card。
• 从 h1 到 h6 的标题层级。
• 图片替代文本和内部链接结构。
• Schema.org JSON-LD 标记，包括 AI 信任信号。
• AEO 元素，例如问答格式、直接回答结构和精选摘要优化。
• GEO 元素，例如便于引用的句式结构、带来源的统计数据和实体权威性。
• LLMO 元素，例如 llms.txt、AI 爬虫可访问性和内容新鲜度。
• 仅当目标集合包含 Naver 时，才检查 Naver 搜索相关项：Yeti 爬虫访问权限、Search Advisor 所有权验证、RSS 和站点地图所有权域名匹配、og:image 条件以及 nosourceinfo 范围。
• 仅当目标集合包含 Bing 时，才检查 Bing 相关项：IndexNow 变更通知（回执代码不能作为收录或引用证据）、密钥文件所有权证明、每条 POST 的提交限制，以及 Bing 站点地图字段处理方式。

</supported_targets>

<complexity_routing>

复杂度	信号	处理方式
简单	单页审查、单个 SEO 元素、快速元数据审计	直接处理：立即编写 report.md
复杂	全站审计、多页面、技术 SEO 与内容 SEO 及 Core Web Vitals、竞品比较	跟踪处理：使用 flow.json 跟踪阶段

开始前，记录：

Complexity: [simple/complex] — [one-line reason]
Mode: [create/update/optimize]
Target: [site/page/project path]
Proof surface: [commands, browser checks, web sources, or local files]

</complexity_routing>

<universal_intake>

为确保此技能适用于各种技术栈，在对任何项目评分前，先对审计背景进行分类：

• target_type：live-url、local-static、nextjs、react-spa、docs-site、ecommerce、blog 或 app-with-marketing-pages
• access_level：可访问在线 URL、仅可访问本地文件、可访问 Search Console、可访问分析数据、可访问现场 Core Web Vitals 数据，或可进行 AI 引用探测
• allowed_action：audit-only、recommend、edit-code 或 optimize-loop
• measurement_confidence：在线 URL、Search Console、现场 Core Web Vitals 或 AI 引用探测不可用时，应降低置信度
• evaluator：可比目标集合、评分标准、工具/版本、日期和证据渠道

将每项发现和评分输入准确归类为 official、live、field、tool、lab、synthetic 或 heuristic 之一。不要把一种类别当作另一种类别的证据：本地扫描不是在线或现场证据，工具/实验室结果也不是官方要求。

将无法进行的检查记录为 unknown，将不相关的检查记录为 not-applicable；从类别分母中排除 not-applicable 检查。不要隐瞒缺失的证据。如果建议基于静态文件、实验室数据、合成探测或启发式方法，请在 results.json 中标明。

如果无法使用在线浏览、Search Console、现场数据、AI 探测或指定工具，请采用现有条件下最有力的较低等级方法，说明能力限制和替代方案，不要声称掌握在线性能、排名、收录情况或引用情况。

</universal_intake>

<artifact_contract>

创建或更新 .hyper/seo-maker/[slug]/。

预期文件：

.hyper/seo-maker/[slug]/
├── dashboard.html      # Browser-readable dashboard
├── results.json        # Structured audit results
├── results.js          # File URL fallback for browser rendering
├── report.md           # Markdown report
├── sources.md          # Source and evidence log
└── flow.json           # Required for complex or optimize mode

简单模式下，report.md 和 sources.md 为最低要求。复杂模式或优化模式下，所有文件均为必需。

文件架构遵循 references/artifact-spec.md。

新报告默认使用 assets/report.template.ko.md。仅在明确要求英文时，才使用 assets/report.template.md。

渲染顺序：

1. 收集证据并编写或更新 results.json。
2. 生成 results.js，以便直接在本地浏览器中查看。
3. 根据当前结果渲染 dashboard.html。
4. 编写 report.md 和 sources.md，其中包含链接或文件引用。sources.md 是来源记录：对于每项外部或官方声明，记录其 URL、访问日期或发布日期、所适用的声明、证据类别，以及任何范围或可用性限制。

当 results.json 最终确定后，使用 scripts/render-dashboard.mjs <artifact-dir> 渲染仪表板。

对于复杂模式或优化模式，flow.json 会按顺序跟踪各阶段：scope → measurement → technical → platform_policy → onpage → content → aeo → geo → report。

</artifact_contract>

<support_file_read_order>

按以下顺序阅读：

1. 阅读核心 SKILL.md，以确认任务属于 SEO/AEO/GEO 审计、优化报告还是评分循环。
2. 阅读 rules/seo-workflow.md，了解执行阶段。
3. 阅读 references/seo-fundamentals.md，了解 E-E-A-T、Core Web Vitals、排名因素、实体 SEO 和 schema 标记标准。
4. 阅读 references/aeo-geo-guide.md，了解 AEO/GEO/LLMO 策略、GEO CORE 框架、平台基准和 llms.txt 指南。
5. 阅读 references/seo-checklist.md，了解实用审计清单。
6. 阅读 references/artifact-spec.md，了解 results.json、仪表板生命周期和工作区架构。
7. 对于新报告，默认阅读 assets/report.template.ko.md；仅在明确要求英文时阅读 assets/report.template.md。
8. 渲染仪表板时，阅读 assets/dashboard-template.html。
9. 完成前，阅读 rules/validation.md。

</support_file_read_order>

阶段	任务	输出
0	确定目标、模式、复杂度、验证范围和通用信息收集字段	执行简报
1	制定测量方法和置信度限制	measurement_methods
2	从本地代码、页面、浏览器检查和网络来源收集证据	证据日志
3	审计技术 SEO、平台政策、AEO、GEO、LLMO、Core Web Vitals 和结构化数据	结构化发现
4	区分官方要求与实地、工具、实验室、合成或启发式发现	按证据等级划分的发现
5	根据影响、置信度、工作量和来源等级确定问题优先级	建议集
6	编写交付文件和仪表板	.hyper/seo-maker/[slug]/
7	如果处于优化模式，实施或建议修复并重新审计	最佳验证结果
8	总结评分、成效、置信度限制、风险和后续行动	最终报告

<audit_dimensions> 在与目标相关时，审计以下维度：技术 SEO（可抓取性、可索引性、规范化、站点地图、robots 指令、响应状态、重定向、重复页面）；平台政策（将 Googlebot、Google-Extended、OAI-SearchBot、GPTBot 和 ChatGPT-User 作为独立控制项，以及摘要控制和 X-Robots-Tag，并包含由目标决定是否启用的 Naver 和 Bing/IndexNow 模块）；页面 SEO（标题、描述、标题层级、关键词匹配度、URL 可读性、内部链接）；内容 SEO（意图匹配度、深度、主题覆盖范围、新鲜度、独特性、可读性）；Core Web Vitals（LCP、INP、CLS、阻塞渲染的资源、图像尺寸、交互延迟）；结构化数据（JSON-LD 有效性、Schema.org 适配度、与可见内容的一致性、实体标识符、面包屑、FAQ、产品、文章和组织标记）；AEO（可见答案区块、问答结构、适合摘要的内容、语音搜索措辞、直接回答的清晰度）；GEO（可引用的论述、带来源的统计数据、实体权威性、作者和品牌信任信号、可安全引用的内容）；以及 LLMO（可选的 llms.txt、AI 爬虫访问权限、简洁的 Markdown 或语义化 HTML、清晰的实体关系、新鲜且规范的内容）。

各维度的评估标准及有条件启用的平台模块见 rules/seo-workflow.md 第 3–8 阶段、references/seo-checklist.md、references/seo-fundamentals.md 和 references/aeo-geo-guide.md。

字符数、标题数量、链接密度、答案长度、字数和平台对内容的偏好，都只能作为因具体情况而异的经验参考，绝不能视为官方通过/不通过标准；不得暗示结构化数据、llms.txt 或普通的索引/摘要资格可以保证获得富媒体搜索结果、排名、AI 收录或引用。评估 Google AI 功能时，应依据常规 SEO 基础原则，不要规定使用特殊的 AI schema 或文本文件。

</audit_dimensions>

证据充分时，使用透明的 100 分制评分：

• 技术 SEO：20 分
• 页面 SEO：20 分
• 内容 SEO：15 分
• Core Web Vitals：15 分
• 结构化数据：10 分
• AEO 就绪度：10 分
• GEO/LLMO 就绪度：10 分

证据不完整时，将受影响的类别标记为 unknown；类别不相关时标记为 not-applicable，并从评分分母中排除。不要捏造确定性，也不要将经验参考转化为官方不合格项。

每项发现都应包含：

• 严重程度：critical、warning 或 info（如需根据严重程度进一步确定优先级，请使用影响/工作量字段）。
• 置信度：高、中或低。
• evidence_grade：official、live、field、tool、lab、synthetic 或 heuristic。
• measurement_method：所用的扫描、工具、探测、来源或命令。
• source_tier：official-doc、observed-file、live-observation、field-data、tool-output、lab-result、synthetic-probe 或 research-backed-heuristic。
• 证据：命令输出、URL、本地文件路径、浏览器观察结果或保存的探测结果。
• 建议：具体行动及预期影响。
• 负责领域：代码、内容、基础设施、分析或外部平台。

<optimize_loop>

仅当用户要求达到最高分、满分或持续提升分数时，才使用优化模式；并将其视为有界的 审计 -> 修复或建议 -> 重新审计 循环：在进行任何更改前，记录基线、稳定的评估器、目标、有限预算（默认为三次迭代）和回归防护措施；只有在可比证据有所改善且未触发防护措施时才保留迭代结果，否则尽可能回滚，或将其标记为 discarded；达到目标、预算上限、优化停滞、防护措施失效、没有安全的本地修复方案，或工作需要外部凭证或业务决策时，即停止。完整循环规则见 rules/seo-workflow.md 第 9 阶段。

</optimize_loop> 永远不要伪造满分，也不要承诺排名、被纳入 AI 功能或获得引用；应说明未知之处，并给出可比性最佳且经过验证的结果。

</optimize_loop>

在宣布审计完成前，应用 rules/validation.md 中的规则。该文件要求：每项严重问题和警告都提供证据；建议应具体到足以让工程师、营销人员或内容负责人采取行动；评分应依据观察到的证据得出，并明确处理 unknown 和 not-applicable，而非想当然地处理；通过常规 SEO 基础来描述 Google AI 功能，并在 FAQPage 建议中区分 Google 富媒体搜索结果的资格与适合回答问题的可见 FAQ 内容；sources.md 来源清单应包含 URL、日期、适用声明、证据类别和局限性；在优化模式下，应记录基线、评估者、有限预算、护栏、变更和建议、重新审计的证据、已舍弃的迭代、停止原因，以及可比性最佳且经过验证的结果。必须存在的 .hyper/seo-maker/[slug]/ 产物列在 <artifact_contract> 中。