在站長平台点了提交，sitemap 狀態顯示成功，可等了一两周，索引里的地址數量几乎没有變化。這时候容易得出一個结论：sitemap 没什么用。更接近實际的解释是，sitemap 只是把一批地址送進候選队列，從提交到真正進索引中間隔着好几环，任何一环断了，後面的發現都不會發生。

先把三件事分開看

• 提交：你在平台或 robots.txt 里声明了這份清單，只說明資料传過去了。
• 被讀取：蜘蛛确實下载了這個文件，並且能解析出里面的地址。
• 被收錄：蜘蛛又去抓了這些頁面，判断质量後才决定是否建索引。

平台里的“提交成功”只覆盖第一步。後面两步卡住时，界面上通常不會明说卡在哪里。

第一步核對：sitemap 自己能不能被抓到

几個常被忽略的检查点

• 文件是否返回正常狀態碼，而不是重定向、拒绝訪問或需要登入。
• robots.txt 里有没有把 sitemap 所在目錄或路径屏蔽掉，屏蔽規則的優先級高于 sitemap 声明。
• robots.txt 里的 Sitemap 声明是否寫成完整绝對地址，域名和协议有没有寫错。
• 服務器是否對蜘蛛請求做了频率限制或 UA 拦截，導致下载被拒。

如果 sitemap 挂在需要驗證、带參數或會随會话變化的地址上，蜘蛛拿到的可能是一份空内容。

第二步核對：格式能不能被解析

• 地址必须是绝對 URL，带完整协议和域名，相對路径一般不會被解析。
• 單個文件的地址條數有上限，超出部分會被忽略，需要拆分並做索引文件。
• XML 声明、命名空間、标簽閉合要正确，手工拼接的内容最容易在這里出错。
• 编碼统一用 UTF-8；地址里有特殊字符时需要轉义，而不是直接塞進去。
• 压缩文件要符合约定格式，命名不對可能根本不被讀取。

一個快速驗證方式：把 sitemap 地址丢進浏览器查看源代碼，看列出的地址是否完整、是否和预期一致。你看到的，應当和蜘蛛拿到的一致。

第三步核對：里面的地址本身经不经得起抓

sitemap 只负责“告诉”，不负责“担保”。清單里的地址如果本身有問题，被讀取了也不會進索引：

• 地址返回重定向鏈，蜘蛛要多跳几次才落到目标頁。
• 頁面带 noindex，或者被 robots.txt 屏蔽了抓取。
• 地址里带大量會话、排序、篩選參數，同一份内容散成几十個地址。
• 頁面内容稀薄、與站内其他頁面高度重复，属于典型的质量不足。

所以一份干净的 sitemap，往往比一份很大的 sitemap 更有效。

第四步核對：它到底有没有被讀過

最直接的證據在服務器訪問日誌里。筛出 sitemap 地址的請求，看几件事：狀態碼是不是正常，請求方是不是搜尋蜘蛛，讀取频率是否稳定，以及讀取之後有没有紧接着出現對清單内地址的抓取。

如果日誌里長期看不到 sitemap 請求，問题多半在發現入口，比如 robots 声明、平台提交、外部連結指向；如果 sitemap 被反复讀，但清單里的地址始终没被抓，問题更可能出在地址质量或站点整体的抓取分配上。

把 sitemap 当成一條“發現通道”，而不是收錄開關。它能提高頁面被看到的概率，但不能替頁面解决质量、重复和可抓取的問题。

一次可执行的核對顺序

1. 確認 sitemap 地址返回正常，内容與预期一致。
2. 確認 robots.txt 没有屏蔽，並正确声明了 sitemap 地址。
3. 检查格式、條數上限、绝對地址與编碼。
4. 抽查清單内地址的狀態碼、canonical、noindex 與内容质量。
5. 用日誌驗證蜘蛛是否真的讀過，讀完有没有跟進抓取。
6. 按“發現没生效”和“發現生效但没進索引”两類問题分開處理。