Sitemap 经常被当成“提交给搜索引擎的任务”，但它的实际作用更朴素：给蜘蛛一份可以对照的地址清单。内链决定蜘蛛能走到哪一步，Sitemap 决定它有没有机会知道还缺哪些。两边对不上时，问题通常出在清单这一侧，而不是蜘蛛。

先想清楚清单要解决什么问题

如果站内互链足够密，绝大多数页面本来就能被爬到，这时 Sitemap 的价值主要体现在三类情况：新上线还没入链的页面、层级较深且内链稀疏的老页面、以及内容量太大导致蜘蛛一次走不完的部分。

换句话说，它是补漏的工具，不是把整站重新交一遍的仪式。清楚这一点，后面拆分和更新的取舍会容易很多。

索引文件怎么用

单个 Sitemap 一般不超过 5 万条 URL、50MB（未压缩），超过就需要拆分。索引文件（Sitemap index）本身不列页面，只列子 Sitemap 的地址，把它们收在同一个入口下，便于提交和后续更新。

• 索引文件里只放子 Sitemap 地址，不要混进页面 URL；
• 子文件路径改名后要同步更新索引，避免索引指向 404；
• 索引文件本身也要能被正常抓取，别把它挡在 robots 之外；
• 索引层级一般一层就够，套得太深反而增加出错概率。

几种常见的分片切法

1. 按内容类型分：文章、商品、分类各自一个子文件。好处是某一类出问题时不影响其他类，缺点是需要维护多份生成逻辑。
2. 按更新时间分：把最近更新的页面单独放一个子文件，适合内容更新频繁、需要及时被发现的新页面。
3. 按目录或语言分：多语言、多地区站点常用，便于对照 hreflang 关系检查是否漏交。
4. 按数量硬切：维护成本最低，但某一篇出问题会连带整块文件，排查时定位偏慢。

没有哪种切法一定更好，关键是切完之后每块文件都能被单独检查，出问题时能快速缩小范围。

lastmod 别写成“今天全站都改过”

lastmod 的作用是告诉蜘蛛“这条地址的内容真的变了”。如果每天批量刷新成当天时间，它很快就失去参考价值，等于白写。比较稳妥的做法是：只有正文内容发生实质变化时才更新，模板调整、样式改动、广告位替换这类不更新。

页面数量多的时候，lastmod 写准比写勤更有用。

清单和内链对不上会怎样

Sitemap 里列了、但站内没有任何入口指向的地址，蜘蛛抓到之后也未必认为它重要，抓取和收录节奏都会更慢。反过来，内链可达但不在清单里的页面，最终还是靠内链被走到的，只是发现时间可能晚一些。

所以两份材料要一起看：清单负责“有没有”，内链负责“愿不愿意走”。

Sitemap 是清单，内链是路。清单告诉蜘蛛存在什么，路决定它会不会真的过去。

提交后一直没动静，按这个顺序查

• robots.txt 是否把子 Sitemap 路径或目标目录挡掉了；
• 索引文件和各子文件是否都返回 200，返回的是不是 XML；
• 内容是否被 gzip 编码弄坏、解析时读不出地址；
• CDN 或缓存是否还在提供旧版本，导致新地址一直没被看到；
• 清单里的地址是否大量是重定向、404 或参数变体，让蜘蛛走了很多无效路径。

逐条排除之后，多数“提交了但没抓”的情况都能找到原因，剩下的通常只是时间问题。

更新节奏怎么安排

不必每次改内容都重新提交一遍，日常靠 lastmod 变化和站点整体的抓取节奏就够了。值得手动提交一次的场景其实不多：新站上线、新增一个目录或子站、大批量地址结构发生变化。频繁重复提交同一份文件，收益有限。

一个可以照着走的检查顺序

1. 确认索引文件能正常打开，子文件地址没有 404；
2. 抽查几条 URL，看状态码和内容类型是否正常；
3. 核对 lastmod 是否真实反映内容变化；
4. 把清单和站内链接对照一遍，标出没有入链的地址；
5. 给这些孤岛页面补上合理的站内入口，再观察抓取日志里的访问变化。

做完这几步，Sitemap 就从一份“交上去的文件”变成了可以长期对照和维护的地址账本，蜘蛛读起来也更顺。