很多站長把 sitemap 当成收錄開關：文件提交上去，就等着頁面進索引。等了一两周没動静，又怀疑是 sitemap 没被讀到。實际上 sitemap 只是一份候選清單，它影响 URL 被發現的速度和覆盖面，不决定蜘蛛是否来抓，更不决定最终是否進入索引。
sitemap 能做什么，不能做什么
它能做的事很明确：告诉搜尋引擎這些 URL 存在，给站内連結之外的頁面一個入口，尤其是新建頁面和层級較深的頁面。它不能做的事同样明确：不保證抓取，不保證收錄，也不參與排名。把這些期待压在 sitemap 上，後面判断問题时就容易找错方向。
一條 URL 的完整鏈路
從提交到出現在索引里，中間大致要经過這几步，任何一步卡住，结果都是“没收錄”。
- 發現：sitemap、站内連結、外部連結或提交接口中的任意一種，让 URL 進入候選集合。
- 抓取排队：结合站点抓取预算和頁面優先級，决定什么时候来抓。
- 抓取：返回狀態碼是否 200、响應是否超时、robots 是否允许。
- 渲染：如果正文依赖 JS 生成，需要確認渲染後内容是否拿得到。
- 索引判断：内容质量、是否與已有頁面高度相似、canonical 指向哪里。
- 结果：進入索引，或停留在“已抓取未编入索引”“已排除”等狀態。
問题通常卡在哪一步
卡在發現
sitemap 長期没更新，新頁面既不在 sitemap 里，也没有任何站内連結指向，蜘蛛自然没有理由知道它存在。這類 URL 需要先解决入口問题，再谈收錄。
卡在抓取
服務器返回 5xx、响應過慢、或者被 robots.txt 挡住，都會让抓取直接失敗。此时索引报表里往往看不到该 URL，或者顯示為抓取異常。
卡在索引判断
抓取正常但一直停在“已抓取但未编入索引”，通常指向内容层面的問题：正文過薄、模板重复度高、與其他頁面相似，或者 canonical 指向了另一個地址。這一步和 sitemap 已经没有關系了。
提交之後的合理自查顺序
- 確認 sitemap 可以正常訪問，格式無誤，里面放的是最终規范地址，且都返回 200。
- 用抓取工具或渲染後的 HTML，看蜘蛛實际能拿到什么正文。
- 查看服務端日誌，確認蜘蛛是否真的訪問過，訪問频率如何。
- 對照索引狀態，区分是“未抓取”“已抓取未索引”還是“已排除”，不同類別處理方式不同。
- 给新頁面补上至少一條站内連結入口，別让 sitemap 成為唯一通道。
提交只是通知，收錄是判断结果。把這两件事分開看，排查會清楚很多。
几個容易踩的坑
- sitemap 里混入 404、重定向、noindex 的 URL，浪費抓取額度。
- sitemap 体量巨大却長期不變，新增頁面没能及时進去。
- 只依赖 sitemap，站内没有任何連結指向新頁面。
- 同一批未收錄 URL 反复提交，却不检查内容和狀態碼。
把 sitemap 放回它本来的位置：它是發現渠道之一，需要和内鏈、内容质量、正确的狀態碼配合使用。至于多久能被收錄，不同站点差异很大，不必盯着某個具体天數反复折腾，把能控制的部分做對更實际。