sitemap 常被当成“提交即收錄”的開關，但它只解决一件事：告诉爬虫站点上存在哪些 URL。至于這些 URL 會不會被抓、抓完會不會進索引，取决于頁面狀態、站内结构和内容本身。所以当 sitemap 提交後迟迟没有反應，先別反复提交同一個文件，按下面的顺序從文件本身查到入口和内鏈。
先確認爬虫有没有讀過這個文件
第一步不是看收錄量，而是看抓取日誌里有没有對 sitemap 地址的請求。如果完全没有记錄，問题多半出在入口上：
- robots.txt 里的 Sitemap 行容易寫错，需要完整绝對地址，例如 https://example.com/sitemap.xml，不要寫成相對路径。
- 检查 robots.txt 有没有顺手把 sitemap 文件本身 Disallow 掉。文件被禁止抓取，自然讀不到里面的 URL。
- 文件地址要能直接訪問，返回 200，Content-Type 為 xml（.xml.gz 則為 gzip），不要先跳一跳再返回内容。
- 用工具後台上传的文件，注意是否被放到了需要登入才能訪問的目錄。
如果日誌顯示爬虫确實来讀了几次，說明發現渠道是通的，接下来要排查的是 URL 质量和優先級。
文件里放的 URL 是否都值得被收錄
sitemap 里混進不可收錄的地址，會稀释這份名單的可用性，爬虫讀到的無效條目越多，對整份文件的信任就越低。以下類型建议先清理：
- 返回 3xx 的地址：直接寫跳轉後的最终地址。
- 404、410 或長期打不開的地址。
- 带 noindex、被 robots 屏蔽、canonical 指向其他頁面的地址。
- 會话參數、時間戳參數、排序篩選參數生成的大量變体。
- 需要登入、需要加购或需要提交表單才能看到正文的頁面。
一個简單判断：如果你不希望這個 URL 出現在搜尋结果里，就不要放進 sitemap。另外，线上地址要和文件里的寫法完全一致，包括协议、主机名（www 與否）、大小寫和末尾斜杠，任何不一致都可能被当成另一個 URL 處理。
格式與体量上的硬性限制
- 單個 sitemap 文件上限 5 萬條 URL、50MB 未压缩体积。
- 超過上限要拆分成多個子文件，再用 sitemap index 匯總，索引文件本身同样有 5 萬個條目的上限。
- URL 要用绝對地址，& 等特殊字符需要轉义，否則文件會解析失敗。
- lastmod 填真實修改時間。全站批量刷成当天、或長期一動不動，都會让這個字段失去參考價值。
入口位置與提交方式
常见做法是把文件放在根目錄，並在 robots.txt 中用 Sitemap 行声明，同时在搜尋资源平台的 sitemap 报告里提交一次。报告能告诉你文件是否讀取成功、發現了多少條 URL，但它衡量的是發現，不是收錄，不要拿這里的資料当成收錄结果。更新文件内容後，保持地址不變即可，不需要每次改動都重复提交；真正需要检查的是文件是否仍可訪問、是否仍返回 200。
sitemap 之外還缺什么
發現和抓取是两回事。sitemap 只提高 URL 被知道的概率，不传递權重，也不决定抓取顺序。如果新頁面除了 sitemap 之外没有任何内鏈指向它，通常還是要等很久，甚至一直等不到。更稳的做法是让新頁面從已经被抓取的頁面鏈出，並尽量控制在一两跳以内到達。
抓取预算有限时，往 sitemap 里堆大量低價值地址，反而會分散爬虫對真正重要頁面的注意力。名單越精简，越容易看出問题出在哪。
一份可执行的核對清單
- 日誌中是否有對 sitemap 地址的請求记錄，响應碼是否為 200。
- robots.txt 的 Sitemap 行是否寫對，文件本身未被 Disallow。
- 抽样訪問文件里的 URL，確認全部是最终地址、可正常打開。
- 排查 noindex、canonical、參數變体是否混入名單。
- 核對文件体积、條目數和 lastmod 的寫法。
- 確認新增頁面有内鏈入口，而不是只靠 sitemap 等待發現。
按這個顺序走一遍，通常能定位到是文件没被讀到、名單本身有問题，還是頁面缺少站内入口。至于多久能看到變化，取决于抓取节奏和頁面质量，没有可以承诺的時間表。