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 就從一份“交上去的文件”變成了可以長期對照和维護的地址帳本，蜘蛛讀起来也更顺。