不少站点把 Sitemap 当成一份“提交完就等蜘蛛来抓”的清單，但蜘蛛對它的使用方式更接近“參考线索”。寫進去的 URL 和真正被抓的 URL，中間隔着好几道篩選：清單本身的格式、URL 的價值、站点的响應速度、内鏈是否给了入口。把這些搞明白，Sitemap 才不至于變成一份没人讀的名單。
Sitemap 解决的是發現，不是抓取
Sitemap 的主要價值，是让蜘蛛知道“這個站点還有這些 URL 存在”，尤其是那些内鏈层級深、站内入口少的頁面。但它不决定抓取時間，也不决定是否收錄。抓不抓、什么时候抓，取决于蜘蛛自己的調度，以及站点在它訪問时的响應表現。換句话说，它是一條兜底通道，而不是主力通道。心態摆正，後面很多判断會简單得多。
该放進去的 URL
- 返回 200 且可索引的頁面，使用規范地址，不带多余的跟踪參數；
- 内鏈較深、曝光机會少的頁面，比如詳情頁、歷史文章、長尾列表；
- 新發布、希望尽快被發現的頁面；
- 分類頁、分頁等有獨立價值的列表頁，前提是它們本身可索引。
判断标准其實只有一條：這個 URL 打開後是正经内容頁，並且你希望它出現在搜尋结果里。不符合這條的，先別急着往里加。
通常不该放進去的 URL
- 被 noindex 的頁面：一邊告诉蜘蛛別收錄，一邊让它来抓，信号是矛盾的；
- 301、302 跳轉的舊地址：直接寫跳轉後的目标地址更省事；
- 已经 404 或 410 的失效頁面；
- 篩選、排序、會话等參數组合出来的 URL，很容易把清單撑大；
- 後台、登入、购物车一類没有索引價值的路径。
清單臃肿最直接的後果，是蜘蛛把有限的時間花在低價值 URL 上，真正需要的頁面反而排在後面。
分片與索引文件
單個 Sitemap 有容量上限，通常是 5 萬個 URL 或 50MB 未压缩体积，两者先到為准。超過之後要拆成多個子文件，再用一個索引文件把它們列出来。
- 按類型拆：文章、商品、分類各自一份，便于分別观察；
- 按目錄或語言拆，出問题时影响范围可控；
- 子文件地址必须是完整可訪問的 URL，索引文件里不能寫相對路径。
拆分不是麻烦，而是让排查更具体。某個子文件讀取異常时，你至少知道問题出在哪一類頁面上。
lastmod 要寫實话
lastmod 是蜘蛛判断“這個頁面值不值得重訪”的參考之一。如果每次生成都刷成目前時間，而内容其實没變，這個字段很快會失去可信度。内容真正改動时再更新，是更稳妥的做法。為了看起来新鲜而频繁改動，通常得不偿失。
Sitemap 替代不了内鏈
Sitemap 能让 URL 被發現，但頁面被抓到之後能不能繼續往外走，靠的是頁面里的連結。一個只在 Sitemap 里出現、站内没有任何入口的頁面，抓取往往不稳定，重訪也少。Sitemap 是补充，内鏈是主干，两者不该互相顶替。重要的頁面，两條路都留着更稳。
怎么驗證有没有起作用
- 在搜尋後台查看 Sitemap 的讀取狀態，以及已被發現的 URL 數量；
- 對比提交數量和實际被抓的數量，差距大的那部分通常就是低價值頁面；
- 在服務器日誌里筛出 Sitemap 相關請求，看蜘蛛多久来讀一次；
- 观察被發現的 URL 里，有多少是被内鏈先發現的，有多少是靠 Sitemap。
如果發現大部分 URL 都靠 Sitemap 才被發現，說明内鏈结构還有需要补的地方，而不是 Sitemap 寫得不够多。
维護节奏
Sitemap 不需要频繁重建，但上新快、下架也快的站点，保持它和站点實际狀態一致會更省事：刪除的頁面及时從清單里去掉，新增的及时加進来，別让失效地址長期堆着。频率稳定，比偶尔集中更新一次更實用。
Sitemap 是一份线索清單，不是抓取指令。寫得准，比寫得多有用。
把它当成 URL 發現鏈條中的一环，和内鏈、日誌观察配合起来用，比單獨指望它更接近實际情况。