把 sitemap 提交上去，並不等于頁面會被抓取，更不等于會進索引。它更像一份地址清單，负责告诉搜尋引擎站内有哪些地址存在。收錄没動静时，很多人的第一反應是再提交一次，其實更值得做的是從文件本身往上查一层——文件有没有被讀到、里面放的地址合不合格、站内還有没有別的入口。這三层里任何一层出問题，提交多少次都不會有變化。
第一层：先確認 sitemap 本身被讀到了
提交動作顯示成功，不代表文件被正常解析。先確認這几件事：
- 可訪問性：用無痕窗口直接打開 sitemap 地址，看是否返回 200，有没有被登入墙、CDN 規則或訪問控制挡住。如果 robots.txt 里把 sitemap 所在目錄 Disallow 了，抓取也會受影响。
- 格式與编碼：必须是合法 XML，声明 UTF-8；特殊字符需要轉义，例如 & 要寫成實体形式。用校驗工具過一遍，比肉眼掃一遍靠谱。
- 声明位置：在 robots.txt 里加一行 Sitemap 指向完整地址，同时也在後台提交。两者不冲突，覆盖的是不同讀取路径。
- 後台的讀取记錄：看上次讀取時間和讀取到的條數。如果時間一直停在几周前，說明讀取端根本没来，需要回头查服務器日誌和訪問控制。
- 体量限制：單個文件不超過 5 萬條 URL、50MB（未压缩）。超了就拆成多個，再用 sitemap index 匯總成一個入口。
如果這一步就不通過，後面的排查都没有意义。
第二层：清單里的 URL 是不是该出現的地址
sitemap 是規范地址的清單，不是站内所有連結的备份。放错地址不但起不到作用，還可能把抓取引向不该去的地方。
- 只放返回 200、允许被索引的正式頁面。
- 不要放 301 跳轉地址、404 頁面、被 robots 屏蔽的地址。
- 不要放标注了 noindex 的頁面，两個信号互相打架。
- 带參數的地址、篩選頁、排序頁，除非確認要單獨收錄，否則不要放進去。
- 同一内容的多個地址，只保留 canonical 指向的那一個。
- 翻頁與分頁地址按實际策略决定，不要一股脑全塞進去。
還要確認清單里的 URL 與頁面上 canonical 寫的一致。批量生成时经常出現模板改了、sitemap 生成脚本没跟着改的情况，两邊對不上，提交上去也等于白交。
第三层：sitemap 之外，頁面還有没有別的入口
sitemap 解决的是發現，抓取和收錄還要看頁面本身與站内结构。常见的情况是：清單里的地址早就被抓過了，但迟迟不進索引，這說明問题不在提交环节。
- 入口深度：頁面能不能從首頁顺着正常内鏈点到？只能靠 sitemap 触達的地址，抓取優先級通常很低。
- 内鏈數量與质量：同一批頁面里，被内鏈指向更多的往往收錄更快。完全孤立的地址即使提交了也很难推進。
- 内容是否值得單獨成一個頁面：模板套壳、信息量明顯不足的頁面，收錄困难往往出在這里，而不是提交方式。
- 服務器响應：抓取时超时、频繁返回 5xx、大量重定向，都會被视為负面信号。
一個可执行的核對顺序
- 打開 sitemap 地址，確認返回 200、XML 合法、能被公開訪問。
- 去後台看上次讀取時間和讀取到的條數，判断文件有没有被解析到。
- 抽样十几條 URL，逐條检查狀態碼、canonical、robots 與 noindex 标记。
- 核對 sitemap 生成逻辑與頁面模板是否同源，避免两邊不一致。
- 回到站内，检查這些頁面有没有正常内鏈入口、能否從栏目頁点到。
- 查服務器日誌，確認抓取端来過没有；来過却没收錄，重点就轉向頁面质量本身。
把 sitemap 当成一份地址清單，而不是一個收錄開關，排查思路會清晰很多。它负责让頁面被看见；能不能被留下，取决于地址是否規范、入口是否通畅、内容是否站得住。
提交之後没有動静，先別急着重复提交。按文件、URL、入口這三层從上往下走一遍，多數問题在前两层就能定位。