seo-competitor-pages

示例输出：examples/seo-competitor-pages-linear-vs-jira-20260514/COMPARISON.md

竞品对比与替代方案页面

制作针对比较意图关键词（“X vs Y”“X 的替代方案”“适用于 Y 的最佳 X”）的转化优化落地页。交付内容是一份可直接粘贴使用的页面草稿，包含功能矩阵、平衡的结论、结构化数据标记，以及可将处于对比阶段的流量转化为客户的 CTA 流程。

此技能生成的页面类型

1. “X vs Y”正面对比——直接比较两款产品或服务。目标关键词：[Product A] vs [Product B]。
2. “X 的替代方案”——采用清单式页面，将用户的产品定位为某个品类领导者的 N 个替代方案之一。目标关键词：[Competitor] alternatives 或 alternatives to [Competitor]。
3. “适用于 Y 的最佳 X”——针对某种使用场景或受众的细分最佳产品页面。目标关键词：best [category] for [use case]。

前提条件

• 已连接 SE Ranking MCP 服务。
• 可使用 Claude 的 WebFetch 工具。
• 用户需提供：(a) 用户的品牌/产品（页面主推对象）；(b) 目标竞品（至少 1 个；替代方案页面最多可选 5 个）；(c) 页面类型（若用户未指定，则根据关键词自动检测）；(d) 目标国家（默认为 us）。

流程

1. 验证并确定页面类型

   • 根据用户的输入，识别页面类型：对比 / 替代方案 / 最佳榜单。
   • 如果无法确定页面类型，请询问用户。不要擅自猜测。

2. 获取竞争对手背景信息 DATA_getDomainCompetitors

   • 针对用户的域名，按 common_keywords 重合度列出自然搜索竞争对手。
   • 验证用户指定的竞争对手是否在列表中（或与列表中的竞争对手接近）。

3. 按品牌获取关键词数据 DATA_getDomainKeywords

   • 针对用户的域名和每个指定的竞争对手，获取排名前 100 的自然搜索关键词。
   • 找出：各品牌独有的关键词、双方都排名的关键词，以及关键词差距。

4. 获取对比类 SERP 数据 DATA_getSerpResults 和 DATA_getKeywordQuestions

   • 针对“X vs Y” / “X 的替代方案” / “适用于 Y 的最佳 X”等目标关键词：
     • 前 10 个自然搜索结果——还有哪些网站在这些对比类关键词上排名？
     • PAA 问题（可作为 FAQ 部分的内容）。
     • 精选摘要（如果有，记录答案模式）。

5. 抓取现有对比页面 WebFetch（始终使用）+ mcp__firecrawl-mcp__firecrawl_scrape（可用时）

   • 先用 WebFetch（免费）：获取 SERP 排名前 3 的页面 Markdown。提取 H2 大纲、功能矩阵维度、结论模式和 CTA 位置。
   • 再用 Firecrawl（消耗 3 个 Firecrawl 点数——每个排名靠前的页面 1 个）——补充 WebFetch 的 Markdown 无法展示的内容：
     • 从 <script type="application/ld+json"> 区块获取 Schema 类型（Product ×N、BreadcrumbList、FAQPage、Review、AggregateRating）。
     • 从 metadata 获取 og:title / og:description / og:image / twitter:card。
     • 从实际 HTML 获取 <title> 和 meta description 的长度。
   • 如果 Firecrawl 不可用： WebFetch 部分照常运行。evidence/04-existing-pages-teardown.md 中的“Schema 类型”行显示 (skipped — Firecrawl required for JSON-LD)。第 8 步的 Schema 生成将使用默认的 Product + BreadcrumbList + FAQPage 模板，而不是仿照排名靠前的页面所使用的 Schema。
   • 以此为依据，让草稿基于实际观察到的有效模式。

5b. 批量抓取竞争对手页面 mcp__firecrawl-mcp__firecrawl_scrape（可选，需主动选择）

• 当用户传入 --bulk-scrape <urls> 或提供一组要直接比较的竞争对手 URL（超出 SERP 排名前 3 的页面）时，使用 Firecrawl 抓取每个 URL。
• 对每个 URL，提取：<title>、og:*、twitter:*、JSON-LD @type、主视觉图片是否存在、定价区块检测（使用正则表达式匹配正文中的 $N/mo、€N/mo 等）、CTA 数量、对比表是否存在、是否提及免费套餐。
• 输出 competitor-elements.csv——每个竞争对手 URL 对应一行，包含上述信号。
• 费用：每个 URL 消耗 1 个 Firecrawl 点数。运行前告知预估费用；如果 URL 超过 50 个且未提供 --confirm-cost，则拒绝运行。

6. 获取关键词对比数据 DATA_getDomainKeywordsComparison（如果这些品牌有可用数据）

   • 并排比较关键词重合情况。

7. 构建功能矩阵

   • 根据 SERP 排名靠前页面推断维度（例如“定价”“免费套餐”“集成”“支持等级”“最适合”）。
   • 单元格使用：✓ / ✗ / 部分支持 / “TBD — 请与 PM 确认”，作为无法自动推断字段的占位内容。
   • 如果 SE Ranking 数据能为某个单元格提供依据（例如“在 X 个企业级关键词上排名”），则获取该数字。

8. 综合整理 COMPARISON.md

   • 主视觉区（H1 中包含目标关键词，定位均衡）。
   • TL;DR / 结论框，置于前 200 个词内。
   • 功能矩阵。
   • 按主要维度设置分节（每个 H2 对应一个维度）。
   • 根据 PAA 整理 FAQ（取第 4 步中的前 3–5 个问题）。
   • 结论 / 推荐。
   • CTA 流程。
   • 可用于 Schema 的 JSON-LD：Product（×N）+ BreadcrumbList + FAQPage（如果有真实问答）。

输出格式

创建文件夹 seo-competitor-pages-{target-slug}-{YYYYMMDD}/，其中包含：

seo-competitor-pages-{target-slug}-{YYYYMMDD}/
├── COMPARISON.md                     (the page draft — primary deliverable)
├── 05-feature-matrix.md              (inferred dimensions × brands — load-bearing reference for PMs/writers)
├── schema.jsonld                     (paste-ready Product + Breadcrumb + FAQ — load-bearing artefact for engineering)
├── 05b-competitor-elements.csv       (only if --bulk-scrape ran: competitor URL × on-page-element grid)
└── evidence/
    ├── 01-competitor-context.md      (DATA_getDomainCompetitors — raw step output)
    ├── 02-keyword-overlap.md         (DATA_getDomainKeywords for each brand — raw step output)
    ├── 03-comparative-serp.md        (top 10 + PAA for the target keyword — raw step output)
    └── 04-existing-pages-teardown.md (top-3 SERP winners' structure + schema/og — Firecrawl-recovered)

顶层文件：COMPARISON.md、05-feature-matrix.md 和 schema.jsonld。01–04 步骤文件会在 evidence/ 中保留原始 API/抓取输出。只有传入 --bulk-scrape 时，才会生成 05b-competitor-elements.csv。

“X vs Y”页面的 COMPARISON.md 遵循以下结构：

# {User's Brand} vs {Competitor}: 2026 Comparison

> Updated {YYYY-MM-DD}. Compare {Brand A} and {Brand B} on pricing, features, integrations, and best-fit use case.

## TL;DR
{One paragraph balanced verdict — when to choose A, when to choose B}

## At a glance

| Dimension | {Brand A} | {Brand B} |
|---|---|---|
| Starting price | {$X/mo} | {$Y/mo} |
| Free tier | {✓/✗} | {✓/✗} |
| Best for | {use case} | {use case} |
| Integrations | {n} | {n} |
| Support | {tier} | {tier} |
| ... | | |

## {Dimension 1 header — e.g., Pricing}
{Side-by-side detail, balanced. Avoid hyperbole.}

## {Dimension 2 header — e.g., Features}
{...}

## {Dimension 3 header — e.g., Integrations}
{...}

## {Dimension 4 header — e.g., Support}
{...}

## When to choose {Brand A}
- {scenario 1}
- {scenario 2}
- {scenario 3}

## When to choose {Brand B}
- {scenario 1}
- {scenario 2}
- {scenario 3}

## FAQ
**{PAA question 1}**
{Answer}

**{PAA question 2}**
{Answer}

**{PAA question 3}**
{Answer}

## Get started
{Brand A} CTA — {link}
{Brand B} CTA — {link if balanced; otherwise drop}

## Schema
See `schema.jsonld` — paste into `<head>`.

提示

• 平衡才能带来转化。 假装用户的产品总是更好的页面会失去信任和排名。诚实的评估效果胜过偏袒一方的评估。
• 遵守速率限制。步骤 5（获取 SERP 排名前 3 的页面）需要调用 3 次 WebFetch，以及更早进行的 MCP 查询。
• 费用：通常约需 15–25 个 SE Ranking 积分；步骤 5 中的 schema/og 基准分析额外需要 3 个 Firecrawl 积分；步骤 5b 中每个 URL 需要 1 个 Firecrawl 积分（仅选择启用时）。传入 --no-firecrawl 可跳过这两个 Firecrawl 步骤。
• Schema： 对于“vs”页面，两款产品都使用 Product，并添加 BreadcrumbList；如果 FAQ 部分是真正的问答（而非人为编造），则添加 FAQPage。
• 对于“X 的替代品”页面，将用户的产品定位为 N 个选项之一（通常为 5–10 个），而非排名第一。带编号的清单文章比自我推销式的替代品页面转化效果更好。
• 对于“适用于 Y 的最佳 X”页面，明确按使用场景划分——例如“适合独立开发者”与“适合企业团队”——这样可以覆盖多个长尾关键词变体。
• 页面发布 30 天后运行 seo-page，跟踪排名走势。
• 发布前搭配 seo-content-audit 检查草稿的 E-E-A-T。
• 步骤 4 中基于 PAA 得出的 FAQ 非常有价值——这些是用户实际搜索的问题，在页面中回答它们可以提高内容被 AIO 引用的就绪度。
• 不要自动发布。将草稿交给作者或 PM 进行事实核查并调整品牌语气。