Sitemap 经常被当成一次性任務：上线时生成一個文件，提交到搜尋资源平台，然後就不管了。實际运营中，栏目會調整，内容會下架，URL 規則會變化，新頁面每天都在产生。如果 Sitemap 長期不變，蜘蛛仍然會通過外鏈、内鏈和站内路径發現一部分内容，但發現效率可能變低，尤其是那些入口較浅、内鏈較少的頁面。
需要先明确一点：Sitemap 是给搜尋引擎的參考路线，不是收錄保證。它可以帮助蜘蛛了解站点有哪些 URL、大致什么时候更新，但最终是否抓取、是否索引，仍取决于頁面质量、站点整体情况和搜尋引擎的判断。所以维護 Sitemap 的目标不是“提交後坐等收錄”，而是减少蜘蛛發現和判断的障碍。
Sitemap 维護中常见的問题
- 只提交首頁或几個栏目頁：大量詳情頁没有被列入，蜘蛛只能顺着連結一层层爬。
- 長期不更新：新增文章、新上架頁面没有及时進入 Sitemap，lastmod 也停留在很久以前。
- 把不可索引的 URL 也放進去：比如带參數的篩選頁、已刪除頁面、需要登入的頁面、robots.txt 中禁止抓取的目錄。這會增加蜘蛛的無效訪問。
- 全站塞進一個文件：單個 Sitemap 文件有 URL 數量和大小限制，太大时應该拆分。
- 提交後不驗證：文件返回 404、格式错誤、域名寫错，自己却不知道。
一份可执行的 Sitemap 自查清單
1. 確認文件能正常訪問
在浏览器和命令行中分別訪問 Sitemap 地址，確認返回 200 狀態碼，内容類型正确。常见位置是根目錄下的 /sitemap.xml，也可以是 /sitemap_index.xml。如果使用了 CDN 或缓存，注意缓存是否導致舊文件一直被返回。
2. 只放希望被索引的 URL
Sitemap 不是站点所有 URL 的备份。應该只包含 canonical 版本、返回 200 狀態碼、且允许被索引的頁面。已经設定 noindex 的頁面、重定向地址、404 頁面、带會话 ID 或排序參數的 URL，都不适合放進去。否則蜘蛛可能把抓取预算花在低價值地址上。
3. 按内容類型拆分 Sitemap
当站点規模變大时，可以把文章、产品、栏目、标簽等分別生成 Sitemap，再用一個索引文件匯總。這样便于在搜尋资源平台中單獨观察抓取和索引情况，也方便排查某一類 URL 的問题。
4. lastmod 要诚實
lastmod 表示頁面最後實质更新的時間，不是每次發布或同步的時間。如果只是改了發布時間、換了模板样式，内容主体没有變化，不建议批量刷新 lastmod。频繁造假會让搜尋引擎逐渐不信任這個字段。
5. 在 robots.txt 中声明
可以在 robots.txt 里加上 Sitemap 地址，方便蜘蛛找到。注意 robots.txt 中的 Sitemap 指令只是声明位置，不會替代搜尋资源平台中的提交。如果站点有多個子域或獨立移動端，應该分別声明對應的 Sitemap。
6. 用服務器日誌驗證
提交後不要只看“已提交”狀態。過一段時間检查服務器日誌，看看蜘蛛是否真的抓取了 Sitemap 文件，以及是否顺着其中的 URL 進行了訪問。如果 Sitemap 被抓取但頁面訪問很少，可能需要检查頁面质量、内鏈结构或抓取频率設定。
维護节奏怎么定
不需要每天手動改 Sitemap，但可以让它跟随内容系統自動更新。對于更新频繁的站点，建议每次發布内容时自動追加或重新生成；對于更新較少的站点，至少每周或每两周检查一次。每次大改版、栏目調整、URL 規則變化後，都應该重新生成並提交。
可以建立一個简單的检查习惯：打開 Sitemap 地址是否能訪問；随机点几個 URL 是否正常；在搜尋资源平台看已提交和已索引的數量是否明顯異常；對照日誌看蜘蛛是否在抓取新頁面。
把 Sitemap 当成站点运营的常規配置，而不是上线时才想起来的一次性動作。它不能保證收錄，但可以减少新頁面被發現的随机性。
最後提醒：Sitemap 只是 URL 發現体系中的一环。内鏈、導航、栏目頁、站内搜尋、外部連結同样重要。如果站点结构本身混乱，Sitemap 寫得再全，蜘蛛也未必愿意深入抓取。先把可索引的 URL 整理清楚，再谈提交和更新，效果會更實际。