站点地图（sitemap）大概是站点运营里最容易被“建好就不管”的文件。它不像首頁那样每天有人訪問，出了問题也未必有反馈——蜘蛛照样抓別的頁面，訪客毫無感知。等到新栏目上线一两個月還没有動静，或者搜尋资源平台里顯示的已提交數量長期停在两位數，才想起翻出那個 XML 文件，發現里面的地址還停在两年前。
sitemap 上常见的几類問题
覆盖太少，只列了首頁和几個栏目
有些站点只把首頁、几個主栏目寫進 sitemap，大量文章頁、产品頁、标簽聚合頁全靠蜘蛛顺着内鏈自己爬。這些頁面不是抓不到，但被發現的時間會被拉長，新站或者内鏈較浅的頁面尤其明顯。检查方式很直接：把 sitemap 里的 URL 數量和站内“可公開訪問的正文頁”數量做個對比，差距過大就說明覆盖不全。
混進了不该出現的地址
- 已经刪除、返回 404 的頁面；
- 设了 noindex 的頁面，和 sitemap 想表達的意思正好相反；
- 带排序、篩選、會话跟踪參數的重复地址；
- 已经 301 或 302 跳走的舊地址，sitemap 里應尽量寫最终地址；
- 後台、登入頁、站内搜尋结果頁等不希望被收錄的地址。
lastmod 不可信
有的站点给所有 URL 填同一個時間，有的干脆不填，還有的每次重新生成就把全部頁面的 lastmod 刷成目前時間。前两種問题不大，最後一種反而有害：蜘蛛會認為這個字段没有參考價值，之後即使内容真的更新了，也懒得当成更新信号。建议只在正文确實發生實质性修改时才動 lastmod，格式用带时区的完整時間，例如 2025-03-11T09:20:00+08:00。
体积和分片失控
單個 sitemap 文件有上限，通常是 5 萬條 URL 且未压缩不超過 50MB，超過就要拆成多個文件，再用 sitemap 索引文件把它們串起来。不少站点是文章量涨上来以後忘了這件事，结果生成脚本报错，或者只生成了前一半。如果站点規模已经不小，建议一開始就按栏目或按月份分片，後續维護會轻松很多。
一份可以直接照做的自查清單
- 打開 sitemap 地址，確認返回 200 且 Content-Type 是 XML 或纯文本，不是被 CDN 或安全策略拦下的错誤頁。
- 随机抽 10 到 20 條 URL 實际訪問一遍，看是否都能正常打開。
- 確認没有 noindex 頁面、參數重复頁和跳轉地址混在里面。
- 检查 lastmod 是否符合格式，是否只有真正更新的頁面才變化。
- 確認 robots.txt 里寫了 Sitemap 的完整地址，包括分片索引文件。
- 如果站点有多語言或多地区版本，確認對應關系标注清楚，別让蜘蛛把不同語言的頁面当成重复内容。
生成與更新：別靠手工维護
手工维護的 sitemap 基本活不過半年。比較稳妥的做法是让程序在内容發布、下线、改地址时自動更新清單，再由定时任務每天或每周重新生成文件。生成逻辑里最好加两條過滤：狀態碼必须是 200，且頁面不能带 noindex。這样即使某天有人誤操作，也不會把一堆废弃地址推给蜘蛛。
提交之後怎么驗證
提交只是開始。可以在搜尋资源平台里看已提交數量和已收錄數量的大致比例，但更實在的是去翻服務器日誌：搜 sitemap 的文件名，看蜘蛛有没有定期来取、返回碼是不是 200、取完之後有没有顺着里面的地址去抓几個頁面。如果日誌里几乎看不到這個文件的訪問记錄，那再規整的 sitemap 也只是躺在服務器上的一個 XML。
需要說明的是，sitemap 只是给蜘蛛的一條线索。頁面能不能被收錄、排在哪里，取决于内容质量、站点整体情况和用戶需求，sitemap 本身並不保證任何结果。把它做好，是為了减少“新頁面迟迟没人發現”這類本可以避免的损耗。
顺带一提，sitemap 也不能替代内鏈。一個頁面如果只有 sitemap 里的一條记錄，站内没有任何入口指向它，蜘蛛即使抓到了，也很难判断它的重要程度。结构清晰的内鏈，加上一份准确、及时更新的 sitemap，才是比較完整的组合。