站点地图（sitemap）是很多人做收錄时最先想到的工具，但它的作用经常被高估。它解决的是「告诉搜尋引擎這里還有哪些 URL」，而不是「让搜尋引擎收錄這些 URL」。如果提交之後收錄没有變化，先把 sitemap 能做的事和不能做的事分開看，能省下不少反复折腾的時間。
sitemap 负责發現，不负责收錄
一個 URL 從存在到出現在搜尋结果里，大致要经過發現、抓取、索引、可展現几步。sitemap 能影响的只是最前面那一步：让搜尋蜘蛛更快知道這個地址存在。至于它會不會被抓取、抓取後判断頁面质量够不够、最终進不進索引，取决于頁面本身和站点整体情况。把 sitemap 当成收錄開關，是很多無效排查的起点。
所以判断 sitemap 有没有起作用，不能只看收錄量，而要看：蜘蛛有没有抓取這個文件、文件里的 URL 有没有更快進入待抓队列。這两件事和「是否收錄」是两回事。
几種常见的寫法問题
sitemap 本身寫得不規范时，它甚至连「發現」這一步都做不好。
lastmod 全站寫同一個時間
有些站点每次生成 sitemap 时，把所有 URL 的 lastmod 都刷成目前時間。這样搜尋引擎很快會發現這個字段不可信，之後就不再參考它来判断哪些頁面值得優先回抓。lastmod 應该尽量反映頁面内容的真實變更時間，而不是文件生成時間。
塞進了不该出現的地址
sitemap 里只應该放返回 200、且允许被索引的頁面。以下這些放進去只會制造噪音：
- 會跳轉到別處的 URL，包括站内重定向鏈上的中間地址
- 已经返回 404 或 410 的頁面
- 被 robots.txt 屏蔽或加了 noindex 的頁面
- 參數篩選、排序、追踪參數产生的重复地址
把這些混在里面，等于在告诉搜尋引擎「這些也是正式頁面」，反而淡化了真正想推的 URL。
文件過大或没有分索引
單個 sitemap 文件有數量上限，超過後需要拆成多個文件，再用一個索引文件把它們串起来。如果一直往里塞，最後可能出現文件過大、抓取中断的情况。分文件时按頁型分组比按時間胡乱切更好用，比如列表頁、詳情頁、聚合頁各一份，後續看日誌时也更容易判断哪類頁型被發現的节奏慢。
文件本身没被訪問
提交了地址不代表立刻會被抓。可以在服務器日誌里搜一下 sitemap 的訪問记錄，看看搜尋蜘蛛有没有来取過這個文件、多久来一次。如果连文件都没被抓過，讨论收錄為时過早。
提交之後先確認两件事
- 文件是否被抓取。看日誌里 sitemap 地址的請求记錄和返回狀態。如果一直是異常狀態碼，先修文件。
- URL 是否進入待抓队列。可以挑几個新頁面，看它們的狀態是「已發現」還是完全没出現。如果已经有發現记錄，說明 sitemap 至少在起作用。
這两点確認完，再决定是繼續等，還是去查別的环节。
真正能推進收錄的動作
發現之後的路，sitemap 帮不上太多忙。能起作用的是這些：
- 站内連結。從已被收錄、權重相對高的頁面鏈向新頁面，比只在 sitemap 里列一行更有效。
- 頁面本身的可訪問性。服務器响應是否稳定、内容是否正常渲染、有没有被自己用 robots 規則挡住。
- 减少重复和低质頁面。同一内容多個地址、内容稀薄的頁面铺得太多，會稀释抓取和索引的判断。
- 保持结构稳定。频繁改 URL、加參數、調层級，會让已经积累的發現记錄重新洗牌。
一句话總结：sitemap 是把 URL 摆到台面上的工具，不是收錄的保證。它能帮你少走「頁面還没被發現」這一段路，剩下的路要靠内鏈、頁面质量和站点整体结构来走。提交之後没反應时，先看文件有没有被抓、URL 有没有進入队列，再决定要不要動頁面。