先把 Sitemap 的定位摆正
不少站点把 Sitemap 当成主要的 URL 發現渠道，结果站内互鏈做得一片稀疏。實际上蜘蛛發現頁面的顺序通常是：先訪問首頁和高频更新的频道頁，再顺着站内連結逐层跟進，Sitemap 更多是补充遗漏。它的價值在于覆盖那些内鏈薄弱、层級較深，或者刚上线還没被鏈到的 URL。如果站内連結本身断得厉害，單靠 Sitemap 也补不回来。
所以讨论字段怎么寫之前，先明确一点：這些字段影响的是判断依據，不是抓取结果的開關。
lastmod 寫准，才有可能被參考
lastmod 表示這個 URL 内容的最後修改時間。它被參考的前提是准确。常见的問题是：改一次模板、批量發布、CMS 自動儲存，全站 lastmod 就變成同一個時間戳。這種「所有頁面同时更新」的信号没有区分度，蜘蛛很难據此判断哪些頁面真的變了，久而久之這類字段就更容易被忽略。
- 只在正文内容發生實质變化时更新，導航、样式調整不要触發
- 時間格式保持统一，带时区，避免同一份文件里混用多種寫法
- 如果维護成本太高，宁可不寫，也不要批量刷一個假時間
對于更新频繁的资讯類頁面，准确的 lastmod 相對更有用；對于長期不動的說明頁，寫不寫差別不大。
changefreq 與 priority：參考價值已经有限
changefreq 描述预期更新频率，priority 表示頁面在站点内的相對重要度。這两個字段的實际影响這些年被大幅稀释，多數情况下不再作為主要依據。寫的时候保持内部逻辑一致就够了：首頁 priority 高一些，更新频繁的栏目 changefreq 偏 daily，但不要指望靠調高數值換来更多抓取。
更常见的坑是自相矛盾：一個 priority 寫 1.0 的頁面，lastmod 却是两年前。這種不一致反而削弱整份文件的可信度。
分片與索引文件：大站要留意邊界
單個 Sitemap 有 URL 條數上限，超過就要拆成多個子文件，再用一個索引文件把子文件列出来。這里容易出現几類問题：
- 新增了子文件，但索引文件没同步更新，蜘蛛根本找不到
- 子文件里混着已经 404 或已经重定向的舊 URL
- 多個分片内容重叠，同一批 URL 被反复提交
分片本身並不复杂，麻烦在長期维護。每次改版、下线栏目、調整 URL 規則，都要回头確認清單和线上是否還一致。過期條目越多，整份文件的參考價值越低。
抓取路径稳不稳，最後還是要看服務器
Sitemap 提交之後，蜘蛛會挑時間去讀取。如果站点响應慢、频繁超时，讀取這個文件本身就會占用抓取配額，反而挤掉正文頁面的抓取机會。同样的道理，Sitemap 文件也要能快速返回，不要走复杂查询，也不要经過多层重定向。
把 Sitemap 做成静態文件，通常比做成實时生成的動態接口更稳。
一份日常检查清單
- Sitemap 地址已在 robots.txt 中声明，且可以正常訪問
- 清單里只保留返回 200、可被索引的頁面
- lastmod 與内容實际更新時間對得上
- 分片與索引文件同步更新，没有死鏈和重复
- 内鏈结构不依赖 Sitemap 兜底，重要頁面都有站内入口
- 定期從服務器日誌里確認清單中的 URL 是否真的被抓過
這些動作不保證任何结果，但能减少「蜘蛛拿到的信息本身就是错的」這一類問题。URL 發現和重抓判断本来就是多個信号叠加的過程，Sitemap 只是其中一环，把它做干净、做准确，剩下的交给連結结构和站点稳定性。