XML 站点地图 QA 检查清单：网站上线前必做

XML 站点地图是给搜索引擎发现 URL 的文件，只应该放值得被抓取和索引的页面。它不是 CMS、Shopify 主题、WordPress 插件或 Headless 构建能够生成的所有路由清单。如果里面混入被屏蔽页面、重复页面、staging URL 或已经下线的内容，上线信号就会变得很嘈杂。

这份清单适合网站改版、Shopify 上线、WordPress 重做、B2B 网站项目和 Headless Commerce 迁移。建议在内容冻结后、提交 Search Console 前执行一次，上线后等重定向和生产环境规则生效后再执行一次。

不要一开始就信任自动生成的 sitemap。先列出计划被索引的页面类型：主页、服务页、商品页、分类页、资源页、博客、案例、落地页和不同语言版本。然后把这份计划清单与实际生成的 XML 站点地图对照。

第一条 QA 问题很简单：这个 URL 是否应该出现在搜索结果里？如果答案是否定的，它通常不该出现在站点地图里。这样可以在上线前抓出草稿落地页、筛选分类页、旧活动页、标签归档、站内搜索页和占位 CMS 内容。

• 导出生成的站点地图，并按页面类型统计 URL 数量。
• 把 sitemap 与上线 URL 清单和内容冻结清单对照。
• 把缺失的重点 URL 和意外出现的低价值 URL 分开标记。
• 确认每个语言或市场 URL 都有明确负责人和上线状态。

站点地图里的 URL 通常应该返回 200、允许索引，并且 canonical 指向自身。不要提交会重定向、返回 404 或 410、被 robots.txt 屏蔽、带 noindex，或 canonical 指向其他页面的 URL。这类 URL 会浪费抓取注意力，也会让上线诊断更困难。

电商和 B2B 网站尤其要注意参数 URL。排序、筛选、追踪、搜索、分页、session 和 UTM 变化可能生成成千上万个看似可抓取的路由。如果它们不是独立排名页面，就不要放进 sitemap，而应该通过 canonical、robots 规则或路由逻辑处理。

• 爬取 sitemap URL，并导出状态码、可索引性、canonical 和 robots 数据。
• 从 sitemap 来源中移除 3xx、4xx、5xx、noindex 和 robots-blocked URL。
• 除非参数生成独立可索引页面，否则排除 query-string URL。
• 检查分页、筛选和站内搜索页是否符合预期 SEO 规则。

站点地图、canonical 标签和 hreflang 标注应该传达一致的页面关系。如果 sitemap 列出一个 URL，但页面 canonical 到其他地址，搜索引擎就会收到互相冲突的信号。如果多语言页面进入 sitemap，却没有匹配的 hreflang alternate，国际化索引问题也会更难排查。

多语言网站要按页面组检查。英文、中文和其他本地化 URL 应该都是可索引、自 canonical，并在存在对应版本时互相连接 hreflang。不要把机器生成但还没准备好给用户看的占位翻译放进 sitemap。

• 确认每个 sitemap URL 都自引用 canonical，除非有明确记录的例外。
• 验证 hreflang alternate 指向对应语言下真实上线、可索引的 URL。
• 让 sitemap 的语言目录结构与公开 URL 结构保持一致。
• 移除未发布、未翻译或故意 noindex 的本地化页面。

不同平台会在不同位置产生 sitemap 问题。Shopify 会根据发布状态和销售渠道可见性暴露商品、collection、页面和博客。WordPress 可能包含 taxonomy 归档、媒体附件 URL、作者归档和插件生成路由。Headless 网站则取决于构建脚本、CMS 发布状态和路由生成逻辑。

不要因为平台自动生成了 sitemap 就默认它正确。平台默认值只能当起点，仍然要和上线计划对照。B2B 网站还要特别关注 gated 资源、私有文档、测试表单和重复活动页，因为它们可能和公开内容放在同一个 CMS 里。

• Shopify：确认商品、collection、页面和文章符合发布与市场规则。
• WordPress：检查文章类型、taxonomy、媒体附件 URL、作者归档和插件设置。
• Headless：用 CMS 草稿、定时发布、语言和路由数据测试 sitemap 生成器。
• B2B CMS：排除 gated、测试、法务草稿和内部专用页面。

lastmod 应该帮助爬虫理解哪些页面发生了有意义的内容更新。如果每次构建都会更新 lastmod，即使内容没变，它就会变得嘈杂。如果重大改写后 lastmod 仍然过旧，迁移或改版后的重抓取优先级也会受影响。

同时要给 sitemap 更新建立负责人规则。市场团队可能负责博客和落地页，电商团队负责商品可见性，技术 SEO 负责 canonical 和 noindex 规则，开发负责生成器。没有负责人，sitemap 错误会在每次活动、导入或插件更新后反复出现。

• 检查 lastmod 是否反映内容变化，而不只是部署时间。
• 确认新改写页面和迁移 URL 有合适的更新时间。
• 为商品、CMS、博客、资源和多语言 sitemap 规则分配负责人。
• 记录谁可以批准从公开 sitemap 中移除某个 URL。

Staging QA 可以发现生成逻辑问题，但 production QA 才能验证真实上线环境。内容冻结后先在 staging 爬取 sitemap；DNS、重定向、CDN、robots.txt 和鉴权设置最终生效后，再在 production 爬取一次。很多 sitemap 缺陷只会在正式域名下出现。

把爬取结果当成上线检查表。每个 sitemap URL 都应该可访问、可索引、canonical 正确，并渲染预期模板。大型网站至少要测试完整 sitemap index，再抽样重点商业页面、近期内容、本地化页面和迁移中改动过的页面。

• 爬取 sitemap index 和子 sitemap 文件，不要只看第一个 XML。
• 检查状态码、可索引性、canonical、标题、meta description、hreflang 和响应时间。
• 验证生产 URL 使用最终协议、域名、尾斜杠和语言路径规则。
• 保留上线 QA 导出，方便后续维护时对比变化。

只有当生产环境 sitemap 已反映公开上线状态后，才提交最终 URL。然后在前 7 天、14 天和 30 天监控 Search Console。重点查看 discovered-not-indexed 增长、提交 URL 被 robots.txt 屏蔽、提交 URL 标记 noindex、重定向、404、重复 canonical 和异常排除页面。

提交不是任务结束。Sitemap 是持续运营文件。新商品、未发布页面、本地化内容、重定向和 CMS 导入每周都可能改变它。把 sitemap review 加入每月维护，让搜索发现始终和你真正希望被索引的网站保持一致。

• 在 Google Search Console 和 Bing Webmaster Tools 提交生产 sitemap URL。
• 上线后按 7 天、14 天和 30 天节奏检查索引覆盖。
• 排查被屏蔽、noindex、重定向、重复或缺失的 submitted URL。
• 把 sitemap QA 加入每月维护和大型内容导入流程。