seo-sitemap

示例输出：examples/seo-sitemap-notion-so-20260514/SITEMAP.md

站点地图分析

将域名的 XML 站点地图与最近一次 SE Ranking 网站审计进行比较，从两个方向揭示站点地图声明的内容与爬虫实际发现的内容。

前提条件

• 已连接 SE Ranking MCP 服务。
• 可使用 Claude 的 WebFetch 工具。
• 用户提供：目标域名。可选：站点地图 URL（如果不是 /sitemap.xml，会先尝试从 robots.txt 自动发现）。
• **前置步骤：**先对该域名运行 seo-technical-audit（或任何先前的 SE Ranking 审计）。如果没有现有审计，此技能就没有可供比较的内容——请先运行 seo-technical-audit。

流程

1. 验证目标并确认审计

   • 规范化域名。
   • DATA_listAudits → 确认该域名存在审计。如果没有，明确提示：“请先运行 seo-technical-audit；此技能会将站点地图与该审计的爬取结果进行比较。”
   • 默认使用最近一次状态为 done 的审计。
   • **检查 Firecrawl 是否可用。**如果 mcp__firecrawl-mcp__firecrawl_map 可用，当站点地图缺失或存在问题时，可使用 Mode-2（通过爬取发现 URL）。费用：每发现一个 URL 约消耗 0.5 个 Firecrawl 积分，硬上限为 500 个 URL（约 250 个积分）。如果 Firecrawl 不可用，此技能仅运行 Mode-1，并在需要 Mode-2 时说明这一限制。即使 Firecrawl 可用，用户也可以传入 --no-firecrawl，强制使用 Mode-1（节省积分，但如果站点地图损坏，将无法分析孤立页面和缺失页面）。

2. 构建 URL 列表 WebFetch（站点地图）+ mcp__firecrawl-mcp__firecrawl_map（可选的 Mode-2）

   • **Mode-1（默认）。**尝试访问 https://{domain}/sitemap.xml。如果返回 404，则获取 /robots.txt 并查找 Sitemap: 指令。对于站点地图索引，递归获取每个子站点地图。根据站点地图构建规范 URL 列表。
   • **Mode-2 触发条件。**当 (a) 无法访问站点地图、(b) 站点地图返回的 URL 数量少于审计中 DATA_getCrawledPages 数量的 10%，或 (c) 用户明确请求 --discover 时，切换到 Mode-2。运行 Mode-2 前，务必向用户说明触发原因和预计费用。
   • Mode-2 执行（需要 Firecrawl）：调用 firecrawl_map(url=domain, limit=500)。响应内容是 Firecrawl 从主页和内部链接中发现的 URL 列表。在第 6 步中将此列表作为“站点地图等效列表”——差异比较的运行方式相同，只是以发现的 URL 替代站点地图声明的 URL。
   • **如果需要 Mode-2，但 Firecrawl 不可用：**继续使用 Mode-1 返回的站点地图数据（可能为空）。在 SITEMAP.md 中明确说明：Mode-2（Firecrawl URL 发现）需要 Firecrawl，但未安装 Firecrawl——站点地图与审计的差异比较仅基于部分数据运行。

3. 获取审计中爬取的页面 DATA_getCrawledPages

   • 获取爬虫发现的所有 URL，以及状态码、可索引标记和深度。

4. 获取域名页面 DATA_getDomainPages

   • 获取域名级别的页面清单（某些情况下范围比审计的爬取范围更广）。

5. 获取孤立页面问题 DATA_getAuditPagesByIssue

   • 筛选孤立页面和深度相关问题。这些问题与站点地图分析有关。

6. 计算四类差异

   • 站点地图中缺失的页面： DATA_getCrawledPages 中的 URL（状态为 200 且可编入索引）未出现在站点地图中。可能应该将其添加到站点地图。
   • 站点地图中的孤立页面： 站点地图中的 URL 未被爬虫通过内部链接发现（交叉比对 DATA_getAuditPagesByIssue 中的孤立标记）。站点地图是唯一指向这些页面的来源——调查是否应该通过内部链接指向它们。
   • 站点地图中的失效条目： 站点地图中的 URL 在审计爬取时返回了非 200 状态码。从站点地图中移除该 URL，或修复该 URL。
   • Lastmod 问题： 站点地图条目中，(a) 所有 <lastmod> 日期都相同（说明生成方式较粗疏）；或 (b) 页面发生过更改，但 <lastmod> 早于该页面的审计爬取日期（信息过时）。

7. 验证

   • 每个文件中的 URL 数量少于 50,000（站点地图协议限制）。超出时标记。
   • robots.txt 中引用了站点地图。
   • 编码：每个 URL 都符合 XML 格式要求（转义和号等）。
   • HTTPS 一致性：站点地图 URL 使用的协议与规范协议一致。
   • <lastmod> 是 Google 仍会读取的唯一可选标签。 验证该标签（步骤 6）。Google 多年来一直明确忽略 <priority> 和 <changefreq>（参见 Google 站点地图文档——“Google 会忽略 priority 和 changefreq 的值”）。不要验证这两个标签；如果存在，请将其标记为低价值噪声，用户可移除它们以缩小站点地图。

8. 综合整理 SITEMAP.md

输出格式

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

seo-sitemap-{target-slug}-{YYYYMMDD}/
├── SITEMAP.md                       (synthesised report — primary deliverable)
├── recommended-sitemap-diff.md      (proposed changes: add X, remove Y — load-bearing artefact engineering applies to sitemap.xml)
└── evidence/
    └── source-data.md               (consolidated raw step output: fetched sitemap content, Firecrawl-discovered URLs if Mode-2 ran, audit's crawled-pages list, the four diffs (missing/orphans/broken/lastmod-issues) — preserved for reproducibility)

顶层包含：SITEMAP.md 和 recommended-sitemap-diff.md。七个原始步骤文件（01-sitemap-raw、01b-firecrawl-discovered、02-audit-pages、03-missing-from-sitemap、04-orphans-from-sitemap、05-broken-entries、06-lastmod-issues）整合为一份 evidence/source-data.md 文档，并保留各步骤对应的章节标题——需要重放差异检查的读者可在一个文件中找到所有原始输入，无须查阅七个文件。

SITEMAP.md 的结构如下：

# Sitemap Analysis: {domain}

> Sitemap pulled {YYYY-MM-DD} · Audit reference {audit-date}

## Mode

- **Mode-1 (sitemap-vs-audit):** {ran / skipped — no sitemap reachable}
- **Mode-2 (Firecrawl URL discovery):** {ran with {n} URLs / not triggered / triggered but Firecrawl not installed}

## Health summary

| Metric | Value | Status |
|---|---|---|
| Sitemap URLs (Mode-1) | {n} | — |
| Discovered URLs (Mode-2, if ran) | {n} | — |
| Audit crawled URLs (200, indexable) | {n} | — |
| Missing from sitemap (probable adds) | {n} | {🔴 if >5%} |
| Orphans from sitemap (probable cuts or link-ins) | {n} | {🟡 if >5} |
| Broken sitemap entries (non-200) | {n} | {🔴 if >0} |
| Lastmod issues | {n} | {🟡 if uniform; 🔴 if stale} |

## Recommended changes

### Add to sitemap ({n} URLs)
- {URL} — found by crawler at depth {n}, status 200, indexable.
- ...

### Remove from sitemap ({n} URLs)
- {URL} — returns {status code}.
- ...

### Investigate (orphan from sitemap, {n} URLs)
- {URL} — in sitemap but not reachable via internal links. Either link from {suggested parent} or remove from sitemap.
- ...

### Fix lastmod ({n} URLs)
- {URL} — lastmod is {date} but the audit crawled the page on {date} and detected changes since.
- ...

## Validation

- Total URL count: {n} ({✓ under 50k limit | ✗ exceeds — split into sitemap-of-sitemaps})
- Referenced in robots.txt: {✓/✗}
- HTTPS consistency: {✓/✗}
- Encoding: {✓/✗}

## Apply
- See `recommended-sitemap-diff.md` for the proposed sitemap.xml changes.
- After applying, re-run `seo-technical-audit` to refresh the crawl, then re-run this skill to verify.

提示

• 先运行 seo-technical-audit。没有审计结果，此技能就没有可供比较的内容。
• 页面清单发生变化（新增内容、删除页面、URL 结构调整）后重新运行。
• 对大型网站来说，站点地图索引的级联抓取范围可能很大——此技能会递归获取所有子站点地图。对于拥有 50 个以上子站点地图的网站，获取操作会占用大部分运行时间，但不会增加费用。
• <priority> 和 <changefreq> 已失效——Google 明确忽略这两者。无需花时间调整它们；如果站点地图生成器会输出这两个标签，它们只会增加文件体积。Google 仍会读取 <lastmod>，因此请确保该值准确。
• “调查孤立页面”列表往往是最具影响力的发现——页面已存在却没有链接指向，通常是意外导致的孤立页面；添加几个内部链接就可能让它们重新发挥作用。
• 与 seo-drift 配合使用，随时间跟踪站点地图的组成情况（URL 数量、lastmod 模式）。
• 费用：通常约为 5–10 个 SE Ranking 积分（主要来自 getCrawledPages 和 getDomainPages 调用）。模式 2 还会消耗 Firecrawl 积分，每发现一个 URL 约需 0.5 个积分——触发前先显示预估费用。