Sitemap 是最容易被当成“提交就好”的东西：文件放上去，在 robots.txt 里写一行，然后就等着。实际排查中更常见的情况是，文件确实存在，但搜索引擎没有按预期读取，或者读到了却用不上。下面按从外到内的顺序，把常见的核对点过一遍。

先看清 Sitemap 的定位

Sitemap 只是 URL 发现的一条补充通道，它负责把地址交出去，既不保证被抓取，也不保证被索引。所以当“提交了但没效果”时，问题往往不在 Sitemap 本身，而在清单里的 URL 状态。把它当成一份需要维护的“地址清单”来看，判断标准会清楚很多：里面的地址是不是真实、稳定、可抓取。

一、声明与可访问性

• robots.txt 中的 Sitemap 行要写完整的绝对地址，包含协议和域名，不要用相对路径。
• 直接访问该地址，返回码应为 200，内容确实是 XML，而不是登录页、验证页或错误页。
• 站点若存在 www 与非 www、http 与 https 并存的情况，确认声明的是当前主用域名下的地址。
• CDN 或防火墙如果对 XML 路径做了拦截或限速，直接访问一次就能先暴露出来。

二、文件格式的细节

• XML 语法要合法，标签闭合完整，一个字符出错整个文件都可能被丢弃。
• 编码使用 UTF-8，注意不要带 BOM，部分解析器会被开头几个字节卡住。
• 根节点与命名空间按标准书写，不要自行简化结构。
• 每个 loc 都应为绝对地址并包含协议，且与站点主域一致，跨域地址通常不被接受。
• lastmod 用标准日期格式，不确定时宁可不写，写错的时间反而干扰判断。

三、规模与拆分

单个 Sitemap 文件的 URL 数量和体积都有上限，超出后需要拆分，并用索引文件把它们串起来。拆分时按内容类型或目录来分，不要随机切，方便后续核对哪一部分没被读到。压缩格式要确认服务器返回的类型与实际内容一致，避免“文件是 gzip、声明却是 xml”这种错配。

四、清单里的 URL 状态

这一步比前面几步更容易出问题。Sitemap 里应该只保留返回 200、内容有效的地址。以下几类如果混进去，会让整份清单的可信度下降：

• 会 301、302 跳转到其他地址的 URL；
• 返回 404、410 或软 404 的 URL；
• 被 robots.txt 禁止抓取的路径；
• 带有 noindex 的页面；
• 参数随机、每次生成都不一样的地址。

定期把清单和实际状态做一次比对，比一次性堆进大量地址更有意义。

五、看反馈而不是看感觉

搜索引擎后台的 Sitemap 报告会给出读取状态和发现数量，服务器日志里则能看到抓取记录。两者结合着看：文件被读取了却没有后续抓取，说明问题在 URL 层；文件根本没被读取，才回到前面几步继续查。这个过程存在延迟，几天内没有变化属于正常现象。

可复用的核对清单

1. robots.txt 里的声明地址能直接打开且返回 200；
2. XML 语法与编码无异常；
3. loc 全部为绝对地址且为同一主域；
4. 文件未超限，必要时已拆分并建立索引文件；
5. 清单内 URL 均为可抓取的正常页面；
6. 后台报告与服务器日志中出现读取记录；
7. 与导航、内链的实际覆盖情况做交叉核对。

把 Sitemap 当作一份需要持续维护的清单，而不是一次性的提交动作，很多“提交了没反应”的问题会在逐项核对中自然显现。