Front-End Checklist 站点的 Sitemap Coverage 审计确保每个可索引页面都被收录进 XML Sitemap【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist导读本文基于 Front-End Checklist 仓库中的 sitemap-coverage 规则文档及对应的 Agent 技能定义展开。你将掌握如何界定哪些页面必须进 sitemap、哪些必须排除、如何用 Google Search Console 找出覆盖缺口、如何用 Next.js 自动生成 sitemap 杜绝遗漏以及如何在代码评审与 CI 中验证该规则——并以前端清单官网自身 sitemap.ts 的实现为真实案例。什么是 Sitemap CoverageSitemap coverage站点地图覆盖率衡量的是你的 XML sitemap 在多大程度上代表了你真正希望被搜索引擎收录的页面集合。覆盖率不是sitemap 里有多少 URL而是sitemap 里的 URL 是否恰好等于你希望被索引的 URL——多了混入 noindex 页面和少了漏掉可索引页面都是问题。在 Front-End Checklist 仓库中这是一条独立的 SEO 规则Include indexable pages in your sitemap元数据定义在 packages/content/rules/en/seo/sitemap-coverage.mdx 的 frontmatter 中类别seotechnical 子类别优先级medium难度intermediate预估耗时10 分钟核心描述Checks for canonical-url, indexable pages that are missing from the XML sitemap.同一主题还有配套的 Agent 技能定义 skills/sitemap-coverage/SKILL.md它把规则封装为可供 AI 审计代理直接调用的检查流程并完整引用了 references/rule.md 中的实现细节。仓库还以relatedRules声明了它与sitemap-4xx、noindex-in-sitemap、sitemap-domain、sitemap四条规则的关联见 sitemap-coverage.mdx说明这是 sitemap 审计体系中的一环而非孤立检查。为什么覆盖缺口会拖慢索引规则文档whyItMatters字段给出了直接答案Pages absent from the sitemap rely entirely on crawl discovery via links, which can delay indexing of new content, especially on large sites or pages with few inbound links.不在 sitemap 中的页面搜索引擎只能通过链接爬行crawl discovery去发现。这意味着新发布内容如果首页和外部没有指向新文章的链接Googlebot 可能要等下一次常规爬行才碰到它索引延迟明显大型站点页面数以万计时仅靠链接发现的概率急剧下降低内链页面内链稀疏的页面如促销落地页、活动页几乎没有被动发现的机会。sitemap 在这里扮演的是主动推荐名单的角色它告诉搜索引擎这些页面是重要的、请优先爬取和收录。这也是为什么sitemap规则packages/content/rules/en/seo/sitemap.mdx强调大型或新上线站点尤其依赖 sitemap 保证索引。需要特别区分的是两个方向相反的问题问题方向表现后果覆盖不足本规则可索引页面不在 sitemap新内容索引延迟覆盖过度noindex-in-sitemap 规则noindex 页面在 sitemap信号矛盾、浪费爬取预算后者由配套规则 noindex-in-sitemap.mdx 专门处理sitemap 是请收录的建议noindex 是不要收录的指令同一 URL 上两者并存时 Google 最终会遵循 noindex但该 URL 仍会被爬取白白消耗 crawl budget。快速参考收录与排除的标准SKILL.md 的 Quick Reference 与 rule.md 的 Include/Exclude 清单共同给出了最实用的判定标准。✅ 应当进入 sitemap返回 HTTP 200 的 canonical 页面带meta namerobots contentindex, follow或无 robots 标签的页面带自引用 canonical 标签的页面link relcanonical href[same URL]最近 7 天内发布的新页面对及时索引具有高优先级属于must have而非可选项。❌ 应当排除出 sitemap带meta namerobots contentnoindex的页面被robots.txt阻止的页面反正无法被抓取canonical 指向其他 URL 的页面重复内容的非 canonical 版本重定向页面3XX 响应分页子页面如/category/?page2除非它们有独特的、可索引的内容与 canonical 分类页重复的 faceted/筛选 URL登录页、结账页及其他私有页面。判断口诀规则原文给出的检查逻辑可以浓缩为一句话Flag any page that returns HTTP 200, has nonoindexdirective, has a self-referencing canonical, but is absent from the sitemap.即HTTP 200 无 noindex 自引用 canonical 不在 sitemap 覆盖缺口。冲突信号的代码示例rule.md 用一对代码片段演示了最常见的错误sitemap 收录了 noindex 页面。!-- sitemap.xml includes a noindex page — wrong -- url lochttps://example.com/thank-you/loc /url!-- /thank-you carries noindex — contradicts sitemap inclusion -- meta namerobots contentnoindex/thank-you感谢页被写进 sitemap但页面本身携带 noindex。两个信号相互矛盾。Google 的最佳实践非常明确sitemap 里只能列出你希望被索引的页面。对应的正确做法见 noindex-in-sitemap.mdx 的决策树Is this URL listed in the sitemap? ↓ Does it have a noindex directive? ↓ YES Do you WANT it indexed? ↓ YES ↓ NO Remove noindex Remove from sitemap注意其中的关键结论该规则以 Warning 形式强调Google 优先遵循 noindex——即使 URL 同时出现在 sitemap 中页面也不会被收录但仍会被爬取。所以正确的修复是二选一而不是两个都留着。自动生成 sitemap从数据源保证覆盖率人工维护 sitemap 在大站点上必然产生覆盖缺口。规则给出的自动化方案是从 CMS 或数据库中只查询已发布且可索引的内容来生成 sitemap。rule.md 提供了最小示例// Next.js sitemap.ts export default async function sitemap() { const posts await fetchPublishedPosts() // Only published posts return posts.map(post ({ url: https://example.com/blog/${post.slug}, lastModified: post.updatedAt, })) }关键点在于fetchPublishedPosts()只返回已发布内容——把过滤草稿、过滤 noindex、过滤非 canonical下沉到数据查询层从源头杜绝把不该收录的 URL 写进 sitemap。真实案例Front-End Checklist 官网的 sitemap.ts仓库自身就是一个 Next.js 项目其 apps/web/app/sitemap.ts 完整实现了上述自动化思路分为四层静态页面[, /rules, /mcp, /guides]首页changeFrequency: weekly、priority: 1其余daily/0.8分类页面从allRules中提取primaryCategory去重生成/rules/${category}规则页面遍历allRulesURL 为/rules/${rule.primaryCategory}/${rule.slug}lastModified取规则的lastUpdated缺失则回退为当前日期指南页面遍历allGuides生成/guides/${guide.slug}。其中allRules、allGuides来自内容集合content-collections。其只收录已发布内容的保证由 apps/web/content-collections.ts 实现所有规则 MDX 通过 schema 校验zod并经过transform归一化后才会进入集合——例如slug、primaryCategory、url都在 transform 中生成只有通过校验的有效内容才会被sitemap.ts遍历到。这就是自动生成 sitemap让新发布内容立即进入的完整链路MDX 内容 → content-collections schema 校验与归一化 →allRules/allGuides→ sitemap.ts 生成 URL 条目 →/sitemap.xml同时 apps/web/app/robots.ts 在robots.txt中声明了 sitemap 位置sitemap: ${SITE_URL}/sitemap.xmlSITE_URL定义在 packages/config/src/routes.tsprocess.env.NEXT_PUBLIC_SITE_URL || https://frontendchecklist.io。这也呼应了sitemap规则中在 robots.txt 中引用 sitemap的实践。补充参数Next.js MetadataRoute 字段结合 sitemap.mdx 中的元素表格与 sitemap.ts 的实际用法MetadataRoute.Sitemap的核心字段如下字段用途是否必填url页面完整 URL须与 canonical 一致是lastModified最后修改时间Date或 ISO 字符串推荐changeFrequency更新频率提示always/weekly/monthly/yearly/never等可选priority相对重要性0.0–1.0首页 1.0可选alternates.languageshreflang 语言替代官网用于声明en版本可选优先级建议来自 sitemap.mdx首页 1.0、主分类页 0.8–0.9、产品/服务页 0.7–0.8、博客文章 0.5–0.7、法律页 0.3–0.5、归档/标签页 0.3–0.4。官网的实现取值首页 1 / 0.8、分类 0.7、规则 0.6、指南 0.7与该指南一致。如何发现覆盖缺口规则文档给出三种递进式排查方法Google Search Console → Coverage 报告重点看 Discovered – currently not indexed已发现但尚未索引状态的页面——它们通常就是缺少 sitemap 条目的候选者需要补录整站爬取对比用爬虫如 Screaming Frog SEO Spider见 noindex-in-sitemap.mdx 的推荐工具抓取全站所有返回 200 的页面与 sitemap 中的 URL 列表做集合差凡是可索引但不在 sitemap的就是缺口日志分析检查服务器日志中 Googlebot 实际访问的 URL凡是被爬取但不在 sitemap的 URL 值得排查——它们可能因缺少 sitemap 条目而被低效爬取。第三步尤其适合验证索引延迟是否源于覆盖问题如果 Googlebot 已经在爬这些页面却迟迟不收录问题可能在内容质量或站点整体爬取预算而非 sitemap 覆盖这也正是 SKILL.md 中aiContext强调的使用场景——调查为什么新页面迟迟不出现搜索 results时使用本规则。代码评审要点SKILL.md 的codeReviewprompt 定义了代码评审的检查面审查元数据生成、渲染后的 HTML、结构化数据以及与 sitemap 覆盖相关的响应头定位违反规则的精确路由或模板并描述如何验证最终页面输出。落地到实际操作核对生成逻辑检查 sitemap 的 URL 来源是否只来自已发布、可索引数据集合对照官网 sitemap.ts 的模式核对排除逻辑检查是否存在把noindex页面、分页子页、筛选参数页混入 sitemap 的模板或路由如/thank-you类页面核对最终输出抓取渲染后的 HTML确认meta namerobots、link relcanonical与实际 sitemap 条目不矛盾核对响应头检查X-Robots-Tag头是否对某些 URL 施加了与 sitemap 条目冲突的noindex见 noindex-in-sitemap.mdx 的checkprompt。例外与处理优先级规则文档SKILL.md 与 rule.md 一致给出了三条重要的边界有意为之的例外staging、工具页、登录页、账户页、站内搜索页如果本就不打算参与排名可以有意识地使用不同的爬取/索引信号迁移噪音临时迁移状态会产生噪音中间信号应标记线上生产环境的 URL 模式而非一次性过渡产物信号冲突时先修最强信号当重定向、canonical、robots 指令、索引性信号互相冲突时优先修复最终生效的最强信号而不是把每个下游症状都当作独立阻塞项上报——这条与 indexability-conflicts.mdx 系列的审计思路一致。验证清单规则文档给出的 Verification 同时覆盖自动与手动两条路径自动化检查检查渲染后的 HTML 与 HTTP 头确认预期的元数据/可爬取性信号存在用 Google Search Console 或等价工具测试受影响的 URL部署后对代表性页面集合进行 re-crawl重新爬取。手动检查确认修改没有制造新的 canonical、robots 或结构化数据信号冲突。结合 sitemap.mdx 的补充验证项验证 sitemap 的 XML 格式合法、在 Google Search Console 中检查 sitemap 提交状态、确保 sitemap 中的 URL 与 canonical 版本一致。完整修复后应看到覆盖报告中的 Discovered – currently not indexed 数量下降新发布内容的收录时间明显缩短。小结Sitemap coverage 是一条双向校验规则既不允许漏掉可索引页面本文主题也不允许收录不可索引页面由noindex-in-sitemap规则承接。最稳妥的工程实践是用自动化生成从源头保证——像 Front-End Checklist 官网 sitemap.ts 那样只从经过校验的内容集合生成 URL配合 robots.ts 声明 sitemap 位置再用 Google Search Console 的 Coverage 报告持续监控缺口。对于使用 Agent 技能 或审计工具执行该规则的团队可把 rule.md 中Check → Fix → Explain → Code Review四段式 prompt 直接固化为自动化巡检与代码评审的标准流程。【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/20 13:11:35 · 阅读 1.2k Front-End Checklist 站点的 Sitemap Coverage 审计：确保每个可索引页面都被收录进 XML Sitemap
Front-End Checklist 站点的 Sitemap Coverage 审计确保每个可索引页面都被收录进 XML Sitemap【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist导读本文基于 Front-End Checklist 仓库中的 sitemap-coverage 规则文档及对应的 Agent 技能定义展开。你将掌握如何界定哪些页面必须进 sitemap、哪些必须排除、如何用 Google Search Console 找出覆盖缺口、如何用 Next.js 自动生成 sitemap 杜绝遗漏以及如何在代码评审与 CI 中验证该规则——并以前端清单官网自身 sitemap.ts 的实现为真实案例。什么是 Sitemap CoverageSitemap coverage站点地图覆盖率衡量的是你的 XML sitemap 在多大程度上代表了你真正希望被搜索引擎收录的页面集合。覆盖率不是sitemap 里有多少 URL而是sitemap 里的 URL 是否恰好等于你希望被索引的 URL——多了混入 noindex 页面和少了漏掉可索引页面都是问题。在 Front-End Checklist 仓库中这是一条独立的 SEO 规则Include indexable pages in your sitemap元数据定义在 packages/content/rules/en/seo/sitemap-coverage.mdx 的 frontmatter 中类别seotechnical 子类别优先级medium难度intermediate预估耗时10 分钟核心描述Checks for canonical-url, indexable pages that are missing from the XML sitemap.同一主题还有配套的 Agent 技能定义 skills/sitemap-coverage/SKILL.md它把规则封装为可供 AI 审计代理直接调用的检查流程并完整引用了 references/rule.md 中的实现细节。仓库还以relatedRules声明了它与sitemap-4xx、noindex-in-sitemap、sitemap-domain、sitemap四条规则的关联见 sitemap-coverage.mdx说明这是 sitemap 审计体系中的一环而非孤立检查。为什么覆盖缺口会拖慢索引规则文档whyItMatters字段给出了直接答案Pages absent from the sitemap rely entirely on crawl discovery via links, which can delay indexing of new content, especially on large sites or pages with few inbound links.不在 sitemap 中的页面搜索引擎只能通过链接爬行crawl discovery去发现。这意味着新发布内容如果首页和外部没有指向新文章的链接Googlebot 可能要等下一次常规爬行才碰到它索引延迟明显大型站点页面数以万计时仅靠链接发现的概率急剧下降低内链页面内链稀疏的页面如促销落地页、活动页几乎没有被动发现的机会。sitemap 在这里扮演的是主动推荐名单的角色它告诉搜索引擎这些页面是重要的、请优先爬取和收录。这也是为什么sitemap规则packages/content/rules/en/seo/sitemap.mdx强调大型或新上线站点尤其依赖 sitemap 保证索引。需要特别区分的是两个方向相反的问题问题方向表现后果覆盖不足本规则可索引页面不在 sitemap新内容索引延迟覆盖过度noindex-in-sitemap 规则noindex 页面在 sitemap信号矛盾、浪费爬取预算后者由配套规则 noindex-in-sitemap.mdx 专门处理sitemap 是请收录的建议noindex 是不要收录的指令同一 URL 上两者并存时 Google 最终会遵循 noindex但该 URL 仍会被爬取白白消耗 crawl budget。快速参考收录与排除的标准SKILL.md 的 Quick Reference 与 rule.md 的 Include/Exclude 清单共同给出了最实用的判定标准。✅ 应当进入 sitemap返回 HTTP 200 的 canonical 页面带meta namerobots contentindex, follow或无 robots 标签的页面带自引用 canonical 标签的页面link relcanonical href[same URL]最近 7 天内发布的新页面对及时索引具有高优先级属于must have而非可选项。❌ 应当排除出 sitemap带meta namerobots contentnoindex的页面被robots.txt阻止的页面反正无法被抓取canonical 指向其他 URL 的页面重复内容的非 canonical 版本重定向页面3XX 响应分页子页面如/category/?page2除非它们有独特的、可索引的内容与 canonical 分类页重复的 faceted/筛选 URL登录页、结账页及其他私有页面。判断口诀规则原文给出的检查逻辑可以浓缩为一句话Flag any page that returns HTTP 200, has nonoindexdirective, has a self-referencing canonical, but is absent from the sitemap.即HTTP 200 无 noindex 自引用 canonical 不在 sitemap 覆盖缺口。冲突信号的代码示例rule.md 用一对代码片段演示了最常见的错误sitemap 收录了 noindex 页面。!-- sitemap.xml includes a noindex page — wrong -- url lochttps://example.com/thank-you/loc /url!-- /thank-you carries noindex — contradicts sitemap inclusion -- meta namerobots contentnoindex/thank-you感谢页被写进 sitemap但页面本身携带 noindex。两个信号相互矛盾。Google 的最佳实践非常明确sitemap 里只能列出你希望被索引的页面。对应的正确做法见 noindex-in-sitemap.mdx 的决策树Is this URL listed in the sitemap? ↓ Does it have a noindex directive? ↓ YES Do you WANT it indexed? ↓ YES ↓ NO Remove noindex Remove from sitemap注意其中的关键结论该规则以 Warning 形式强调Google 优先遵循 noindex——即使 URL 同时出现在 sitemap 中页面也不会被收录但仍会被爬取。所以正确的修复是二选一而不是两个都留着。自动生成 sitemap从数据源保证覆盖率人工维护 sitemap 在大站点上必然产生覆盖缺口。规则给出的自动化方案是从 CMS 或数据库中只查询已发布且可索引的内容来生成 sitemap。rule.md 提供了最小示例// Next.js sitemap.ts export default async function sitemap() { const posts await fetchPublishedPosts() // Only published posts return posts.map(post ({ url: https://example.com/blog/${post.slug}, lastModified: post.updatedAt, })) }关键点在于fetchPublishedPosts()只返回已发布内容——把过滤草稿、过滤 noindex、过滤非 canonical下沉到数据查询层从源头杜绝把不该收录的 URL 写进 sitemap。真实案例Front-End Checklist 官网的 sitemap.ts仓库自身就是一个 Next.js 项目其 apps/web/app/sitemap.ts 完整实现了上述自动化思路分为四层静态页面[, /rules, /mcp, /guides]首页changeFrequency: weekly、priority: 1其余daily/0.8分类页面从allRules中提取primaryCategory去重生成/rules/${category}规则页面遍历allRulesURL 为/rules/${rule.primaryCategory}/${rule.slug}lastModified取规则的lastUpdated缺失则回退为当前日期指南页面遍历allGuides生成/guides/${guide.slug}。其中allRules、allGuides来自内容集合content-collections。其只收录已发布内容的保证由 apps/web/content-collections.ts 实现所有规则 MDX 通过 schema 校验zod并经过transform归一化后才会进入集合——例如slug、primaryCategory、url都在 transform 中生成只有通过校验的有效内容才会被sitemap.ts遍历到。这就是自动生成 sitemap让新发布内容立即进入的完整链路MDX 内容 → content-collections schema 校验与归一化 →allRules/allGuides→ sitemap.ts 生成 URL 条目 →/sitemap.xml同时 apps/web/app/robots.ts 在robots.txt中声明了 sitemap 位置sitemap: ${SITE_URL}/sitemap.xmlSITE_URL定义在 packages/config/src/routes.tsprocess.env.NEXT_PUBLIC_SITE_URL || https://frontendchecklist.io。这也呼应了sitemap规则中在 robots.txt 中引用 sitemap的实践。补充参数Next.js MetadataRoute 字段结合 sitemap.mdx 中的元素表格与 sitemap.ts 的实际用法MetadataRoute.Sitemap的核心字段如下字段用途是否必填url页面完整 URL须与 canonical 一致是lastModified最后修改时间Date或 ISO 字符串推荐changeFrequency更新频率提示always/weekly/monthly/yearly/never等可选priority相对重要性0.0–1.0首页 1.0可选alternates.languageshreflang 语言替代官网用于声明en版本可选优先级建议来自 sitemap.mdx首页 1.0、主分类页 0.8–0.9、产品/服务页 0.7–0.8、博客文章 0.5–0.7、法律页 0.3–0.5、归档/标签页 0.3–0.4。官网的实现取值首页 1 / 0.8、分类 0.7、规则 0.6、指南 0.7与该指南一致。如何发现覆盖缺口规则文档给出三种递进式排查方法Google Search Console → Coverage 报告重点看 Discovered – currently not indexed已发现但尚未索引状态的页面——它们通常就是缺少 sitemap 条目的候选者需要补录整站爬取对比用爬虫如 Screaming Frog SEO Spider见 noindex-in-sitemap.mdx 的推荐工具抓取全站所有返回 200 的页面与 sitemap 中的 URL 列表做集合差凡是可索引但不在 sitemap的就是缺口日志分析检查服务器日志中 Googlebot 实际访问的 URL凡是被爬取但不在 sitemap的 URL 值得排查——它们可能因缺少 sitemap 条目而被低效爬取。第三步尤其适合验证索引延迟是否源于覆盖问题如果 Googlebot 已经在爬这些页面却迟迟不收录问题可能在内容质量或站点整体爬取预算而非 sitemap 覆盖这也正是 SKILL.md 中aiContext强调的使用场景——调查为什么新页面迟迟不出现搜索 results时使用本规则。代码评审要点SKILL.md 的codeReviewprompt 定义了代码评审的检查面审查元数据生成、渲染后的 HTML、结构化数据以及与 sitemap 覆盖相关的响应头定位违反规则的精确路由或模板并描述如何验证最终页面输出。落地到实际操作核对生成逻辑检查 sitemap 的 URL 来源是否只来自已发布、可索引数据集合对照官网 sitemap.ts 的模式核对排除逻辑检查是否存在把noindex页面、分页子页、筛选参数页混入 sitemap 的模板或路由如/thank-you类页面核对最终输出抓取渲染后的 HTML确认meta namerobots、link relcanonical与实际 sitemap 条目不矛盾核对响应头检查X-Robots-Tag头是否对某些 URL 施加了与 sitemap 条目冲突的noindex见 noindex-in-sitemap.mdx 的checkprompt。例外与处理优先级规则文档SKILL.md 与 rule.md 一致给出了三条重要的边界有意为之的例外staging、工具页、登录页、账户页、站内搜索页如果本就不打算参与排名可以有意识地使用不同的爬取/索引信号迁移噪音临时迁移状态会产生噪音中间信号应标记线上生产环境的 URL 模式而非一次性过渡产物信号冲突时先修最强信号当重定向、canonical、robots 指令、索引性信号互相冲突时优先修复最终生效的最强信号而不是把每个下游症状都当作独立阻塞项上报——这条与 indexability-conflicts.mdx 系列的审计思路一致。验证清单规则文档给出的 Verification 同时覆盖自动与手动两条路径自动化检查检查渲染后的 HTML 与 HTTP 头确认预期的元数据/可爬取性信号存在用 Google Search Console 或等价工具测试受影响的 URL部署后对代表性页面集合进行 re-crawl重新爬取。手动检查确认修改没有制造新的 canonical、robots 或结构化数据信号冲突。结合 sitemap.mdx 的补充验证项验证 sitemap 的 XML 格式合法、在 Google Search Console 中检查 sitemap 提交状态、确保 sitemap 中的 URL 与 canonical 版本一致。完整修复后应看到覆盖报告中的 Discovered – currently not indexed 数量下降新发布内容的收录时间明显缩短。小结Sitemap coverage 是一条双向校验规则既不允许漏掉可索引页面本文主题也不允许收录不可索引页面由noindex-in-sitemap规则承接。最稳妥的工程实践是用自动化生成从源头保证——像 Front-End Checklist 官网 sitemap.ts 那样只从经过校验的内容集合生成 URL配合 robots.ts 声明 sitemap 位置再用 Google Search Console 的 Coverage 报告持续监控缺口。对于使用 Agent 技能 或审计工具执行该规则的团队可把 rule.md 中Check → Fix → Explain → Code Review四段式 prompt 直接固化为自动化巡检与代码评审的标准流程。【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考