Sitemap 的本质是一份交给蜘蛛的 URL 清單。站点只有几十、几百個頁面时，一個文件就能装下；到了几萬甚至几十萬 URL 的量級，就需要把它拆成分片，再用一個索引文件把它們串起来。這一步做得好不好，直接决定蜘蛛能不能完整、及时地知道你有哪些頁面。

為什么必须拆成索引加分片

單個 Sitemap 有硬性上限：一般不超過 5 萬條 URL，未压缩体积不超過 50MB。超過就得拆。而且拆分本身也有好處——按栏目或内容類型拆開後，某個频道大量更新时，只需要让對應的分片顯示新的時間戳，不必把整站清單的時間都刷新一遍。

索引文件的作用很简單：它是一個只列分片地址的清單文件。你只需要把索引文件地址提交出去，蜘蛛顺着索引就能拿到全部分片。

拆分维度怎么選

• 按栏目拆：新闻、商品、問答各自一個分片，便于追踪各频道的收錄與抓取情况。
• 按内容類型拆：文章、图片、视频頁面分開，不同類型可以带不同字段。
• 按更新時間拆：例如按天或按周生成新的分片，配合 lastmod 使用，适合更新量大的站点。

拆得太碎也不好维護。几十個分片属于正常范围，几千個分片往往說明拆分逻辑失控了。

分片里到底该放什么

這是最容易出错的地方。分片不是备份清單，不是把資料库里所有 URL 導出来就完事。

• 只放返回 200、且允许被索引的規范化 URL。
• 不要放 301、302 的目标之外的舊地址，更不要放 404、410 的地址。
• 不要放被 robots.txt 屏蔽、或頁面上带 noindex 的頁面。清單和頁面上的指令互相矛盾，只會让蜘蛛反复確認。
• 同一頁面只出現一次。带參數的、带會话 ID 的、www 與非 www、尾斜杠變体，都應先统一再寫入。
• 被屏蔽的目錄整段不要出現在清單里，避免制造無意义的抓取請求。

lastmod 別乱寫

lastmod 表示该 URL 内容的最後實质修改時間。如果每次生成清單时都全量刷新成目前時間，蜘蛛很快會發現這個字段不可信，進而忽略它。更稳妥的做法是：只有正文或關键内容真的變了，才更新對應條目的時間；纯粹改模板、改样式，不必動它。

索引文件本身也有一個 lastmod，它指這份分片最後更新的時間，同样不建议無差別刷新。

几個高频的踩坑点

1. 索引里混入頁面 URL：索引文件只能列分片地址，列頁面地址属于格式错誤，整份文件可能被忽略。
2. 压缩與响應头不對：使用 .gz 压缩时，要保證服務器返回正确的類型和编碼，否則蜘蛛讀到的是一串乱碼。
3. 分片長期不變：一個分片生成後再也没更新過，蜘蛛對它的重訪频率自然會慢慢降低。
4. Sitemap 地址没寫進 robots.txt：在 robots.txt 里声明 Sitemap 地址，是最省事的告知方式之一。
5. 分片數量很多，索引只列了一部分：索引和分片之間要能一一對上，拆分逻辑變更後记得同步。

Sitemap 解决發現問题，内鏈解决路径問题

有一点需要说清楚：Sitemap 只负责告诉蜘蛛「有哪些 URL」，它並不保證這些 URL 都會被立刻抓取，也不决定抓取顺序。頁面之間怎么连、連結出現在什么位置、從首頁点几下能到，這些仍然由内鏈结构决定。

比較常见的失衡是：Sitemap 里列了几十萬 URL，但站内几乎没有任何連結指向深层頁面。蜘蛛拿到清單後，仍然可能因為缺少内鏈支撑而只抓走一小部分。清單和内鏈應该是互相印證的两套東西，而不是二選一。

用日誌驗證分片有没有被讀到

想知道分片到底有没有生效，最直接的办法是看服務器日誌：篩選出 Sitemap 分片地址的請求记錄，观察狀態碼是否為 200、抓取频率是否稳定、是否集中在某几個分片上。

如果某個分片長期没有任何抓取记錄，先检查它是不是被索引文件正确引用，再检查响應狀態和响應時間，而不是先去怀疑蜘蛛。

一份可以照着做的检查清單

• 索引文件只列分片，分片只列有效 URL。
• 每個 URL 在整站清單中只出現一次。
• lastmod 反映真實的内容變動。
• 分片按清晰、稳定的维度拆分，數量可控。
• Sitemap 地址已在 robots.txt 中声明。
• 分片的抓取记錄能在日誌里查到。
• 清單中的 URL 在站内都有可達的内鏈路径。

把這些基础工作做扎實，比反复調整字段優先級更有意义。