mcpField
S
seo-platform-detect

seo-platform-detect

github.com/hainrixz营销与增长7969 次安装3 天前更新
代码仓库

关于 seo-platform-detect

seo-platform-detect 是用于 SEO 审计的平台识别技能，可判断网站的平台、框架、CMS 插件、托管和环境。它生成基于证据的配置供审计 Agent 选择检查项与修复路径，并明确标记未能识别的结果。

主要功能

  1. 01独立识别平台与框架
  2. 02评估 CMS 插件和托管信息
  3. 03按层记录证据与置信度
  4. 04生成供审计分发使用的配置
  5. 05支持快照、路径和探测输入

适用场景

  1. 01在 SEO 审计前识别网站平台
  2. 02选择平台专属的审计检查项
  3. 03判断哪些修复适用

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/hainrixz/claude-seo-ai --skill seo-platform-detect

安装后在 Claude Code 中输入/seo-platform-detect确认已加载。

详细介绍

seo-platform-detect

平台配置决定了任何模块都无法自行决定的三件事：哪些平台条件检查 ID 会触发、哪些发现会因为相关事项由平台负责而标记为 not_applicable，以及 fix 会调用哪个修复适配器。在每次审计中运行一次：快照完成后、派发任务前。

平台检测与垂直领域检测彼此独立：seo-vertical-detect 回答 这是哪种类型的网站，本技能回答 这个网站基于什么构建。两者都会写入同一个 profile.json。

何时运行

在常规的 /audit 和 /geo 流程中，无需自行运行此工具：audit.mjs 已经会基于本次运行的首页快照调用相同的 detect()，并将结果保存为 <run_dir>/profile.json。请先读取该文件。只有在需要无头检测阶段无法获取的信号时，才直接运行脚本——使用 --path <project> 获取仓库和软件包信号，或使用 --probe 获取 WordPress 插件判定；在运行器之外工作时也需要直接运行。无论哪种情况，每次审计都只运行一次，并在构建派发信封前完成；所有子 Agent 都读取同一份平台配置。

如何运行

node "${CLAUDE_PLUGIN_ROOT}/scripts/detect-platform.mjs" --snapshot "<run_dir>/pages/<home-slug>.json"

仅在适用时添加相应标志：

  • 当用户提供本地项目（--project）时，使用 --path <project>。只有通过此方式才会检查仓库和软件包信号；不提供此参数时，无法检测 Payload，Next.js 路由器检测也会退回到 DOM 标记。此参数还会启用 capabilities.local_files，这是本地文件修复得以实现的必要条件。
  • 当目标可访问且需要判定 WordPress 插件时，使用 --probe。此参数会请求 /wp-json/、/.well-known/ucp、/products.json 和 /wp-sitemap.xml——仅发送四次 GET 请求。REST 命名空间列表是区分 Yoast、Rank Math 和 AIOSEO 的唯一可靠方式；HTML 注释只能表明有某个插件输出了注释，而不能证明该插件处于启用状态。
  • 使用 --out "<run_dir>/profile.platform.json" 将结果保存到文件，而不是通过标准输出传递 JSON。

离线／夹具模式（测试使用，也适用于没有网络的情况）： --html <file> [--headers <json>] [--cookies <json>] [--probes <json>] [--url <u>]。

退出代码：0 表示成功 · 1 表示调用错误或输入不可读 · 2 表示获取失败。

返回内容

{ version: "detect-platform/1", target, platform, framework, cms_plugins[], hosting, environment, capabilities, write_targets[], candidates, vertical_hints[], cards[], sources, notes[] }。

platform、framework、cms_plugins[] 和 hosting 各自都会包含对应的 confidence （high 表示 ≥ 8 且信号种类 ≥ 2，medium 表示 ≥ 5，low 表示 ≥ 2）以及产生该结果的 signals。 证据不足的层会返回 null——平台未解析出来也是一种结果，并非缺失。 请报告为未解析，并让本次运行继续使用 instructions；切勿在文字描述中把 low 提升为更高置信度。

四个层级分别评分，因此无头架构也能正确解析：WordPress 后端搭配 Next.js 前端时，会得到 platform: wordpress 以及 framework: nextjs，并且 capabilities.head_owner 会变为 framework。当卡片结果不一致时，请以 head_owner 为准。

合并到 profile.json

<run_dir>/profile.json 是此工具输出与 seo-vertical-detect 输出的并集。audit.mjs 会写入该文件：刷新 detect() 管理的每个键，同时保留你添加的键，因此文件中已有的 vertical 块会在重新运行时保留（--vertical 标志会覆盖该块）。结构如下：

{ "version": "detect-platform/1", "platform": {…}, "framework": {…}, "cms_plugins": [],
  "hosting": {…}, "environment": {…}, "capabilities": {…}, "write_targets": [],
  "candidates": {…}, "vertical_hints": [], "cards": [], "sources": {…}, "notes": [],
  "vertical": { "primary": "ecommerce", "also": [], "multilingual": false, "locales": [] } }

将 vertical_hints[] 作为 信号 传给 seo-vertical-detect，而不是作为判定结果——它仍必须引用自身的证据。将 environment.kind 传给评分器（score.mjs --environment preview|staging|local），这样在非生产主机上会抑制 noindex 类严重度 5 的上限，并将其报告为预期情况。

每张卡片分配给哪个子 Agent

profile.cards[] 已列出路径（references/platforms/<id>.md）。将这些路径放入每个调度信封中的 platform_cards，并与 platform 字段（绝对路径 profile.json）和一行摘要（ "shopify (high) · theme head · staging theme available · environment production"）一同提供，并逐字包含以下两条指示：

  • 当规则匹配时，输出卡片 §10 中的检查 ID；
  • 卡片 §4 中的项目 ⇒ not_applicable，并在 evidence.observed 中注明负责人——绝不能默默判定通过，也绝不能因为平台不允许任何人更改而判定 fail。

将平台卡片、框架卡片和任何插件卡片一并提供；无头站点显然需要这三者。capabilities.instructions_only 为 true 时，还要告知 Agent，他们提出的每项修复都会以点击路径的形式交付，因此 fix_preview 必须是人类可读的文字，而非差异内容。

诚实原则

  • write_targets 中的 needs 列出的是凭据键名。通过检查 CLAUDE_PLUGIN_OPTION_<KEY> / <KEY> 是否存在来确认；绝不会读取、打印或记录其值。ready: false 表示“尚未配置”，绝不表示“密钥错误”。
  • Cookie 名称可作为证据；绝不记录 Cookie 值。
  • 未提供 --path 时，不会有仓库信号；未提供 --probe 时，不会有探测信号；配置文件中的 notes[] 会注明这一点。请在报告中重申，而不要将不完整的配置文件描述为完整内容。
  • 卡片 §12 中标记为 UNVERIFIED 的信号可以支持检测判定，但绝不能支持写入。当修复取决于未经验证的 API 细节时，答案为 needs_api。

评论

支持 Markdown