Sitemap 是最容易被当成“提交就好”的東西：文件放上去，在 robots.txt 里寫一行，然後就等着。實际排查中更常见的情况是，文件确實存在，但搜尋引擎没有按预期讀取，或者讀到了却用不上。下面按從外到内的顺序，把常见的核對点過一遍。

先看清 Sitemap 的定位

Sitemap 只是 URL 發現的一條补充通道，它负责把地址交出去，既不保證被抓取，也不保證被索引。所以当“提交了但没效果”时，問题往往不在 Sitemap 本身，而在清單里的 URL 狀態。把它当成一份需要维護的“地址清單”来看，判断标准會清楚很多：里面的地址是不是真實、稳定、可抓取。

一、声明與可訪問性

• robots.txt 中的 Sitemap 行要寫完整的绝對地址，包含协议和域名，不要用相對路径。
• 直接訪問该地址，返回碼應為 200，内容确實是 XML，而不是登入頁、驗證頁或错誤頁。
• 站点若存在 www 與非 www、http 與 https 並存的情况，確認声明的是目前主用域名下的地址。
• CDN 或防火墙如果對 XML 路径做了拦截或限速，直接訪問一次就能先暴露出来。

二、文件格式的细节

• XML 语法要合法，标簽閉合完整，一個字符出错整個文件都可能被丢弃。
• 编碼使用 UTF-8，注意不要带 BOM，部分解析器會被開头几個字节卡住。
• 根节点與命名空間按标准书寫，不要自行简化结构。
• 每個 loc 都應為绝對地址並包含协议，且與站点主域一致，跨域地址通常不被接受。
• lastmod 用标准日期格式，不确定时宁可不寫，寫错的時間反而干扰判断。

三、規模與拆分

單個 Sitemap 文件的 URL 數量和体积都有上限，超出後需要拆分，並用索引文件把它們串起来。拆分时按内容類型或目錄来分，不要随机切，方便後續核對哪一部分没被讀到。压缩格式要確認服務器返回的類型與實际内容一致，避免“文件是 gzip、声明却是 xml”這種错配。

四、清單里的 URL 狀態

這一步比前面几步更容易出問题。Sitemap 里應该只保留返回 200、内容有效的地址。以下几類如果混進去，會让整份清單的可信度下降：

• 會 301、302 跳轉到其他地址的 URL；
• 返回 404、410 或软 404 的 URL；
• 被 robots.txt 禁止抓取的路径；
• 带有 noindex 的頁面；
• 參數随机、每次生成都不一样的地址。

定期把清單和實际狀態做一次比對，比一次性堆進大量地址更有意义。

五、看反馈而不是看感觉

搜尋引擎後台的 Sitemap 报告會给出讀取狀態和發現數量，服務器日誌里則能看到抓取记錄。两者结合着看：文件被讀取了却没有後續抓取，說明問题在 URL 层；文件根本没被讀取，才回到前面几步繼續查。這個過程存在延迟，几天内没有變化属于正常現象。

可复用的核對清單

1. robots.txt 里的声明地址能直接打開且返回 200；
2. XML 语法與编碼無異常；
3. loc 全部為绝對地址且為同一主域；
4. 文件未超限，必要时已拆分並建立索引文件；
5. 清單内 URL 均為可抓取的正常頁面；
6. 後台报告與服務器日誌中出現讀取记錄；
7. 與導航、内鏈的實际覆盖情况做交叉核對。

把 Sitemap 当作一份需要持續维護的清單，而不是一次性的提交動作，很多“提交了没反應”的問题會在逐項核對中自然顯現。