很多站点把 sitemap 当成“提交收錄”的開關：文件生成好、在後台点一下提交，就等着收錄上涨。實际观察下来，sitemap 能做的只是把 URL 主動放進蜘蛛的候選队列，它既不改變頁面质量，也不保證抓取和索引。所以“提交了没反應”往往不是 sitemap 失效，而是文件里塞了蜘蛛不该抓的東西，或者頁面本身還不满足收錄條件。
先分清 sitemap 解决的是哪一步
URL 從被發現到進入索引，中間至少有三步：被發現、被抓取、被建索引。sitemap 只對第一步有直接帮助，而且只是众多發現渠道之一，内鏈、外鏈、歷史抓取记錄同样會贡献新 URL。把 sitemap 当作“加速收錄”的工具，预期一開始就偏了。
文件本身要能被正常讀到
這一步最简單，也最容易被忽略。建议逐個確認：
- 地址可公開訪問，返回 200，不是 301 跳轉、不是登入後才能看到。
- 内容是合法的 XML，编碼统一，不要出現半截截断的标簽。
- 在 robots.txt 里用 Sitemap 字段声明绝對地址，方便蜘蛛顺带發現。
- 單個文件不超過 5 萬條 URL、未压缩体积不超過 50MB，超了就拆成 sitemap index。
- 如果用了 gzip，文件名和响應头要一致，別让抓取端解压失敗。
文件里该放什么 URL
sitemap 的定位是“這些地址我希望被收錄”。只要混入不该收錄的地址，整份文件的可信度就會下降，抓取量也會被浪費。
- 只放返回 200 且允许索引的頁面；不要把 301、404、410 的地址留在里面。
- 被 robots.txt 屏蔽或被 meta robots 标為 noindex 的 URL 不要放，两者信号互相矛盾。
- canonical 指向別的頁面的地址，尽量換成規范版本本身。
- 带 session、排序、篩選等參數的重复變体，先做归一化再决定是否收錄。
lastmod 別随手寫
lastmod 是一個“可選但容易被滥用”的字段。如果每次生成 sitemap 都把全站時間戳刷成当天，蜘蛛很快會学會忽略它，真正更新的頁面反而得不到優先抓取。
lastmod 只在頁面正文或主要结构确實變化时更新；模板改動、導航調整、頁脚換文案，都不算。
提交之後该看什么
提交完就別盯着“收錄數”看了，先看更靠前的信号：
- 服務器日誌里，抓取端有没有按预期訪問 sitemap 文件本身，频率是否正常。
- 日誌中新出現的 URL 是不是来自 sitemap，還是主要靠内鏈带動。
- 後台的 sitemap 报告里，是否存在“無法讀取”“包含被屏蔽地址”等提示。
- 索引覆盖率里，這些 URL 是停在“已發現”，還是進入了“已抓取未索引”。
後面两種狀態的排查方向完全不同：前者是發現與预算問题，後者更多是頁面质量與重复内容問题。
sitemap 替代不了内鏈
蜘蛛顺着内鏈走，能同时获得上下文和层級信息；sitemap 给不出這些。一個只存在于 sitemap、站内没有任何入口的地址，即使被抓過一次，後續也很难持續获得抓取。重要頁面應该同时具备内鏈入口和 sitemap 记錄，而不是二選一。
一份可用的自查顺序
- 直接打開 sitemap 地址，確認狀態碼、格式和内容完整。
- 抽查若干 URL，逐個看返回碼、robots 狀態、canonical 指向。
- 核對 lastmod 是否與實际更新時間一致。
- 確認文件條數和体积在上限内，必要时拆分。
- 提交後用日誌驗證抓取端确實来過，再判断問题出在發現、抓取還是索引环节。
把這几步走完，多數“提交了没動静”的情况都能定位到具体环节。至于最终是否收錄，仍然取决于頁面本身能不能回答用戶的搜尋需求，這一点没有任何提交入口可以替代。