很多运营者把 sitemap 当成“提交了就等着收錄”的通道。等到索引报告出来，發現提交了几千條，實际被索引的只有一成，于是開始怀疑抓取出了問题。實际情况通常更琐碎：sitemap 只是帮助搜尋引擎發現 URL 的入口之一，它既不决定抓取，也不决定頁面能否進入索引。当提交量和收錄量對不上时，按下面几层逐級核對，大多能找到原因。
先把三個數字分開看
很多人一上来就比對“提交數”和“收錄數”，這两個數字本来就不是一回事。中間至少還要拆出抓取量。
- 提交量：sitemap 里声明的 URL 總數，如果用了 sitemap 索引文件，要把子文件展開後統計。
- 被抓取量：從服務器日誌或抓取統計里看，代表蜘蛛确實訪問過的 URL。
- 被索引量：索引报告或站内查询的结果，這個數字本身波動較大，不适合每天盯着比對。
三者依次递减属于正常現象。真正值得關注的是某一段出現断崖，比如抓取量正常但索引极少，或者提交了大量 URL 却几乎没有被訪問。
第一层：sitemap 文件自身的問题
先確認這份清單本身是干净可用的，否則後面的判断都會被带偏。
- URL 是否全部返回 200，有没有混進 301、404、410 之類的舊地址；
- 單個文件是否超出 50MB 或 5 萬條的限額，超了就拆成 sitemap 索引文件；
- 是否包含被 robots.txt 屏蔽、或頁面自带 noindex 的 URL，這两類提交了也不會被索引；
- lastmod 是否真實反映内容更新，長期不變的假時間戳會让蜘蛛降低對這個字段的信任；
- 协议、主机名、结尾斜杠是否统一，別把同一批頁面用两種寫法各寫一遍。
第二层：URL 层面的冲突
這一层最容易被忽略，因為它看起来像是“没收錄”，其實是索引被算到了別的地址名下。
典型情况包括：頁面 canonical 指向了另一個版本；URL 带一串無意义參數，每次生成都不一样；同一份内容存在三個地址，而 sitemap 把三份都提交了。這时你在原地址上查询，自然看不到结果，但索引總量並没有减少。
處理办法是先确定每個頁面唯一希望被索引的地址，再让 sitemap、canonical、站内連結指向同一個版本，而不是三套寫法並存。
第三层：頁面本身能不能進索引
抓取正常、URL 無冲突，仍然没被索引，就要回到頁面本身看。
- 主体内容是否足够：模板、導航、推荐位占比過高时，正文容易被判定為信息量不足；
- 是否與站内已有頁面高度相似，例如同一产品的不同規格各做一個頁面，文字几乎一样；
- 是否存在可訪問性障碍：强制登入、地区限制、内容完全依赖 JS 渲染而首屏為空；
- 时效性頁面是否已经過期，過期内容保留在索引里的優先級本来就偏低。
一條實际可用的核對顺序
- 從 sitemap 里随机抽 20 到 30 條 URL，逐條確認狀態碼和 meta robots；
- 用站内搜尋或日誌確認這些 URL 是否被抓取過，以及抓取時間距今多久；
- 對已抓取但未索引的頁面，检查 canonical 归属與站内重复度；
- 把整批 URL 按栏目归類，看是某一類整体表現差，還是随机分布；
- 修正後观察 2 到 4 周再下结论，不要在上线第二天就判定無效。
sitemap 的價值在于帮助發現和清点 URL，它不能代替頁面质量，也不能承诺收錄。把它当成一份需要定期维護的清單，比当成一個提交按钮更有用。
另一個常见誤区是反复重新提交同一份 sitemap。如果 URL 没有變化，重复提交並不會加快處理，反而让你更难判断哪次調整起了作用。保持内容更新、保持清單准确、保持一個版本對應一個地址，比频繁提交更有意义。