很多人把 sitemap 当成一個“提交就收錄”的按钮，實际它更像递给蜘蛛的一張路线图：告诉它站里還有哪些 URL 可以来看看。至于蜘蛛来不来、来了收不收，取决于頁面本身和站点的整体情况。所以当 sitemap 提交之後迟迟没動静，先別急着怀疑平台，問题往往就寫在文件本身。

先分清它解决的是哪一环

URL 進入索引大致要過三關：被發現、被抓取、被判断值得收錄。sitemap 主要作用在第一關。它帮蜘蛛绕過内鏈不足、层級太深、入口單一這些障碍，把 URL 送到抓取队列门口。後面两關它基本插不上手，頁面质量、可抓取性、重复程度這些才是决定因素。把這個前提摆正，排查时才不會把“没被收錄”和“sitemap 没用”混成一件事。

几個常见的寫法問题

1. 把不该出現的 URL 塞進去

sitemap 里最忌讳的是放那些明摆着不该進索引的地址：

• 返回 301、302 的跳轉 URL；
• 返回 404、410 的死鏈；
• 頁面上寫了 noindex 的 URL；
• 被 robots.txt 禁止抓取的路径；
• 带會话 ID、跟踪參數的一次性地址。

這些地址混在文件里，會让蜘蛛白跑一趟，浪費抓取額度，也會让 sitemap 本身的可用性打折扣。放進去的應该是可以正常打開、返回 200、並且你希望它進索引的規范 URL。

2. lastmod 常年不動或者天天都變

lastmod 是给蜘蛛判断“要不要重爬”的參考。如果所有頁面都挂着一個從建站起就没改過的時間，它逐渐會被忽略；反過来，如果每次生成都寫成目前時間，等于告诉蜘蛛全站天天更新，同样會失去可信度。比較省事的做法是让程序在正文真正變動时才更新這個字段，模板、導航、頁脚變化不算。

3. 分片文件寫好了，索引文件没對上

URL 數量多的时候會把 sitemap 切成多個文件，再用一個索引文件串起来。常见疏漏是：分片更新了，索引文件還是舊列表；或者索引里寫了分片地址，但分片本身返回 404。提交前手動打開几個分片看一眼，能省掉很多反复。

4. 只放首頁和栏目頁

sitemap 最有價值的场景恰恰是那些内鏈少、藏得深的頁面——詳情頁、歷史文章、翻頁之後的内容。如果文件里翻来覆去只有首頁、几個栏目和最新的十几條，那它對發現环节的帮助非常有限。理想狀態是让 sitemap 覆盖你希望被索引的全部規范 URL，同时用站内連結把重要頁面再串一遍。

提交之後怎么驗證

• 在服務器日誌里搜 sitemap 文件名，確認蜘蛛确實来取過；
• 看日誌中蜘蛛顺着 sitemap 抓了哪些 URL，有没有大量 404 或跳轉；
• 用站長平台的抓取與索引报告看這些 URL 的後續狀態；
• 抽查几條 URL，看它們是否出現在搜尋结果里。

把這四步串起来看，基本能判断卡在哪一环：文件没被取走、取走但没抓、抓了但没進索引，對應的處理方式完全不同。

什么时候该重新提交

不需要每次發文章都手動提交一次。让 sitemap 由程序自動更新，在站点结构變動、批量新增頁面、迁移 URL 之後，再主動去平台点一次比較合适。如果換了域名或改了路径規則，记得同时更新 sitemap 里的地址，否則蜘蛛拿到的還是舊清單。

sitemap 能提高發現的效率，但它不改變頁面的质量。一份干净、准确、覆盖完整的文件，加上站内合理的連結结构，才是让 URL 稳定進入索引的基础。