很多站点把 sitemap 当成“提交即收錄”的開關，于是出現一種典型落差：文件里列了十萬條 URL，搜尋後台顯示被發現的有一大半，真正進了索引的却只有几千條。這個落差不一定是 sitemap 寫错了，更常见的原因是它的作用被高估了。站点地图只解决“告诉蜘蛛這里有個地址”，後面能不能被抓、抓了之後要不要留，是另外几道關。
站点地图解决的是發現問题，不是收錄問题
一個 URL 從存在到出現在搜尋结果里，大致要经過發現、抓取、索引三步。sitemap 只在前一步起作用，而且不是唯一的發現渠道——内鏈、外鏈、歷史抓取记錄、搜尋後台的提交入口都能起到類似作用。因此 sitemap 里的 URL 數量，和最终收錄數量之間没有固定的比例關系。
反過来也一样：没寫進 sitemap 的頁面，只要内鏈结构正常，照样可能被抓取和收錄。把 sitemap 当作收錄數量的控制手段，方向從一開始就偏了。
检查文件本身有没有問题
能否正常訪問
先確認 sitemap 的地址返回 200，不是 404，中間没有多余的跳轉，也没有被 robots.txt 拦住。用搜尋後台的站点地图报告提交一次，看系統能不能讀到里面的條目數；如果讀不到，多半是格式或訪問层面的問题，而不是内容质量的問题。
分片與索引文件
單文件有 5 萬條 URL 和 50MB 两個上限。超過之後要么压缩成 .gz，要么拆成多個分片，並用一個索引文件把它們串起来。索引文件里只能放分片地址，不能再混頁面 URL，這一点寫错會直接導致後半部分被忽略。
lastmod 不要随手寫
有些程序把 lastmod 统一设為目前時間，每次生成都刷新一遍。這種做法短期看似在提醒蜘蛛来抓，長期會让時間戳失去參考價值，蜘蛛逐渐不再優先處理。修改時間應当和頁面實际内容的變動對應。
別把不该出現的 URL 放進去
重定向地址、返回 404 的舊地址、被 noindex 标记的頁面、带一堆跟踪參數的連結，都不适合出現在 sitemap 里。它們會稀释抓取配額，也會让後台的“已發現”數字虚高，掩盖真正的問题。
收錄數量偏少时的排查顺序
- 確認 sitemap 只包含規范化後的最终地址，没有重定向和參數版本。
- 抽样十几個未收錄的 URL，逐個检查返回碼、meta robots、canonical 指向是否正常。
- 看這些頁面在站内有没有可点的入口。孤岛頁面即使被 sitemap 列出，也可能長期排不上抓取。
- 核對頁面内容是否與其他地址高度重复，或者正文本身太少。
- 對比服務器日誌，確認蜘蛛到底有没有来過這些地址。来過却没收錄，問题在頁面；压根没来，問题在抓取優先級。
用两個資料源交叉看
站点地图报告里的“已發現”和日誌里的實际抓取量，是两個不同的口径。前者只說明文件被讀到了，後者才反映蜘蛛真的訪問過。把這两個數字和索引量放在一起比對，基本能判断卡在哪一步：讀到了却没抓，是抓取調度的問题；抓了却没收錄，要回到頁面本身去找原因。
把 sitemap 当成一份“待確認清單”而不是“應收錄清單”，心態會稳很多。它的價值在于让站点的重要頁面不被漏掉，而不是保證每一個地址都進索引。
最後回到维護习惯
規模較大的站点，建议让 sitemap 由程序按栏目或時間自動分片生成，定期清理失效地址，並且只在頁面真正上线之後才加入。配合清晰的内鏈结构和稳定的服務器响應，站点地图才能發挥它那一部分作用——剩下的，仍然要交给頁面本身。