很多 CMS 会把标签页、搜索页、筛选参数、草稿地址和 canonical 重复页全部输出到 Sitemap。结果 XML 看起来很完整，却在向搜索引擎主动提交一批自己都不希望被索引的 URL。
01 Sitemap 的角色是发现提示，不是强制收录清单
Google 当前文档将 Sitemap 作为帮助搜索发现 URL 的方式，特别适合大型、新站、内部链接较弱或包含丰富媒体的网站。
提交 Sitemap 并不保证 URL 一定被抓取和索引，页面本身仍需要可访问、有价值并符合索引条件。
02 只放 canonical、可索引并希望出现在搜索中的 URL
如果页面 noindex、重定向、404 或 canonical 指向其他地址，就不应该继续出现在主要 Sitemap 中。
把冲突 URL 提交给搜索，只会增加排查噪音。Sitemap 应该是站点对外表达的“首选页面集合”。
03 lastmod 只有真实更新时才有价值
很多系统每次生成 Sitemap 都把所有 URL 的 lastmod 写成当天，等于告诉搜索“全站刚刚更新”。这种数据不可信就失去意义。
应该在主要内容实质变化时更新 lastmod，而不是 Header、统计脚本或 Sitemap 本身生成时间。
04 大型网站需要拆分 Sitemap 并使用 Index
Google 当前规范支持单个 Sitemap 最多 50,000 个 URL，未压缩文件上限 50MB。超过后需要拆分，并通过 Sitemap Index 汇总。
即使没有达到上限，也可以按内容类型拆分：产品、文章、案例、视频，便于监控不同页面群的索引问题。
05 Sitemap 不能补救糟糕的内部链接
一个页面只存在 Sitemap、站内没有任何可抓取链接，搜索可能发现它，但用户也很难自然到达。
核心页面仍应通过导航、分类和正文内链建立结构。Sitemap 是补充发现机制，不是替代信息架构。
06 多语言网站可以把 hreflang 放在 HTML 或 Sitemap 中
Google 支持通过 Sitemap 声明语言/地区变体，但维护复杂度较高。无论选择哪种方法，都要确保双向关系和 URL 一致。
不要同时维护多套互相冲突的 hreflang 数据源。
07 Search Console 提交后重点看的是异常，不是“已提交成功”
Sitemap 状态正常只说明文件可读取。更重要的是已发现 URL、索引覆盖和页面实际状态。
如果提交 20,000 个产品页，长期只有 2,000 个被索引，需要回到内容质量、重复、内部链接和抓取问题，而不是每天重复提交。
08 CMS 应自动维护 Sitemap，但规则必须由人定义
自动生成可以避免人工漏页，但“哪些类型应该进入”需要 SEO、内容和开发共同决定。
每次新增模板、筛选页或多语言版本，都应评估 Sitemap 规则，防止 URL 数量随着功能增长悄悄失控。
09 Sitemap 可以拆分，但拆分规则要服务运营
大型网站常把产品、文章、案例、多语言页面拆成多个 Sitemap，再由 Sitemap Index 汇总。这样做不仅为了突破数量上限，也方便团队观察哪一类 URL 出现提交与索引异常。
拆分方式应和内容生命周期一致。按每天随机切 1 万条虽然技术上可行，却不利于定位问题；按内容类型、语言或业务线组织通常更容易维护。
10 不要把“已提交”误解为“应该被索引”
Sitemap 是发现和规范化信号，并不是收录申请表。一个薄弱、重复、被 noindex、被重定向或返回错误状态的 URL，即使天天提交也不会因此获得稳定索引。
真正的排查应回到页面是否可访问、是否独立有价值、canonical 是否正确、内部链接是否存在，以及服务器是否稳定。
常见问题
提交 Sitemap 会加快收录吗？
它能帮助发现 URL，但不能保证抓取和索引；页面质量和站点结构仍然重要。
Sitemap 可以包含 noindex 页面吗？
不建议。Sitemap 应优先包含希望索引的规范 URL。
lastmod 每天更新更好吗？
不。应反映主要内容真实修改时间，虚假更新会降低信号价值。
一个 Sitemap 最多多少 URL？
Google 当前文档规定单个 Sitemap 最多 50,000 URL，未压缩大小不超过 50MB。
需要把 Sitemap 链接放在 robots.txt 吗？
可以，也可以通过 Search Console 提交；两种方式可以同时使用。
相关服务与进一步咨询
链接复制成功
