XML Sitemap 检查指南：格式正确不代表页面会被收录

Sitemap 最容易制造一种错觉：文件能在浏览器打开，搜索引擎后台也显示“已提交”，于是收录问题就和网站地图无关了。实际上，XML 合法、协议字段合理、URL 可抓取和页面值得索引，是四个不同层次。

XML Sitemap 结构检查工具负责前两个层次中的本地部分：解析 XML 或 .xml.gz，检查条目、URL、日期、重复项和协议边界。它不会请求页面，也不会假装预测 Google 或 Bing 的最终决定。

先分清 urlset 和 sitemapindex

普通网站地图使用 urlset：

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/page</loc>
    <lastmod>2026-07-16</lastmod>
  </url>
</urlset>

站点较大时，用 sitemapindex 汇总多个子文件：

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemaps/posts-1.xml.gz</loc>
    <lastmod>2026-07-16</lastmod>
  </sitemap>
</sitemapindex>

根元素写对还不够，命名空间也应使用 Sitemap 协议地址。漏掉命名空间的 XML 在普通解析器中仍可能看似正常，但不应依赖搜索引擎容错。

完整协议可参考 Sitemaps.org Protocol，搜索引擎的实际支持与建议则应同时看 Google Search Central 的 Sitemap 文档和对应平台后台。

50,000 条与 50 MB 是两个独立限制

一个 Sitemap 文件最多包含：

• 50,000 个 URL；
• 50 MB 未压缩内容。

压缩成 .xml.gz 只减少传输体积，不会把一份 80 MB 的解压后 XML 变成合规文件。只要任一限制超出，就应拆分。

不要等到刚好 50,001 条才改生成器。接近 45,000 条或 45 MB 时，就应该按稳定规则分片，例如：

• 文章；
• 产品；
• 分类；
• 工具；
• 图片；
• 按年份或固定编号分片。

稳定分片比“每次随机塞满 50,000 条”更好排查。某个内容类型生成失败时，可以只看对应子 Sitemap，也更容易观察提交和抓取变化。

loc 应该放规范 URL

loc 必须是完整绝对 URL：

<loc>https://example.com/tools/sitemap-auditor</loc>

不要写：

<loc>/tools/sitemap-auditor</loc>

同一 Sitemap 应属于同一个主机。example.com、www.example.com 和 shop.example.com 不应随意混在一份文件里。协议和搜索引擎的跨站提交能力还有所有权要求，不能用一个索引文件绕过站点边界。

生成前还要统一：

• HTTP 与 HTTPS；
• www 与非 www；
• 结尾斜杠；
• 大小写路径；
• 追踪参数；
• 分页与筛选参数；
• URL 编码。

如果 Sitemap 中的 URL 随后 301 到另一个地址，或页面 canonical 指向别处，搜索引擎会收到互相冲突的信号。网站地图应提交准备被索引的最终规范 URL，而不是“站内出现过的所有地址”。

XML 中的 & 必须转义为 &。URL 里的空格、非 ASCII 路径和查询参数也应正确编码。用字符串拼接生成 XML 时，这些问题尤其常见。

lastmod 不是“今天”

lastmod 可以只写日期：

<lastmod>2026-07-16</lastmod>

也可以写带时区的日期时间：

<lastmod>2026-07-16T18:35:20+08:00</lastmod>

它应该反映该 URL 代表的主要内容上次发生重要修改，而不是：

• 搜索引擎上次抓取时间；
• Sitemap 文件生成时间；
• 每次部署时间；
• 数据库读取时间。

如果生成器每天把全站 lastmod 改成当前日期，字段很快失去区分度。正文、商品状态、结构化数据或会影响搜索结果的重要资源真实变化时再更新。只改后台统计数、随机推荐顺序或无关装饰，通常不值得刷新全部页面。

未来日期往往来自时区或格式错误，应在提交前修正。

changefreq 和 priority 不会购买抓取额度

changefreq 可使用 always、hourly、daily、weekly、monthly、yearly、never。priority 范围是 0.0 到 1.0。

它们是提示，不是命令，也不是排名分数。把所有页面写成：

<changefreq>always</changefreq>
<priority>1.0</priority>

不会让全站持续抓取，更不会提升排名。priority 只表达同一站点内的相对关系。没有可靠生成逻辑时，省略比批量填假值更清楚。

图片与 hreflang 扩展要核对完整关系

图片 Sitemap 扩展可以把页面关联的主要图片放入 <image:image>。多语言页面则可在 URL 条目中使用 xhtml:link 表示 alternate。

结构检查可以发现缺少 hreflang、href 不是绝对 URL 等明显问题，但完整 hreflang 还要验证：

• 每个版本是否互相回链；
• 语言和地区代码是否正确；
• x-default 是否需要；
• alternate URL 是否可访问；
• canonical 是否与语言版本关系一致。

单独使用 hreflang 生成与检查工具会更适合整理一组多语言页面。

为什么结构通过仍然不收录

Sitemap 只是 URL 发现渠道。页面能否进入索引，还会受这些因素影响：

• robots.txt 禁止抓取；
• 页面或响应头带 noindex；
• canonical 指向其他 URL；
• 返回 404、5xx、软 404 或重定向链；
• 页面依赖脚本但渲染失败；
• 内容与其他页面高度重复；
• 内链太弱，只有 Sitemap 能找到；
• 服务器慢、频繁限流或对爬虫返回不同内容；
• 内容质量、站点信誉和抓取资源不足。

因此本地审计后，还要把 Sitemap 部署到稳定公开 URL，在搜索引擎后台提交，并查看“已发现、已抓取、已索引”分别停在哪一步。服务器访问日志能确认 Googlebot、Bingbot 是否真的请求了文件和页面。

提交前的实际检查顺序

1. 在本地解析 XML，清掉语法、命名空间和字段错误；
2. 检查未压缩大小与条目数量；
3. 去重并统一主机、协议和规范 URL；
4. 抽查 lastmod 是否来自真实内容更新时间；
5. 部署后检查 Sitemap URL 返回 200、正确 Content-Type，gzip 可正常解压；
6. 确认 robots.txt 中的 Sitemap 声明指向正式地址；
7. 在搜索引擎后台提交索引文件；
8. 抽查一批 URL 的响应、robots、noindex 与 canonical；
9. 结合抓取报告和访问日志继续排查。

网站地图值得维护，但它不是收录开关。把它当作一份可验证的规范 URL 清单，比把所有 SEO 希望都塞进 XML 更有用。