先把 sitemap 的位置摆正：它管發現，不管收錄
站点地图（sitemap）最直接的作用，是把一批 URL 一次性告诉搜尋引擎，省去它們沿着内鏈和外鏈慢慢爬的過程。它是一份候選清單，不是收錄申請單。搜尋引擎讀完 sitemap 之後，仍然會按自己的判断决定要不要抓、要不要放進索引。
所以当 sitemap 在後台顯示“已成功處理”，而索引里却找不到對應頁面时，這两件事並不矛盾。前者只說明文件被讀到了、格式没出错；後者取决于頁面质量、内容是否重复、站点整体是否值得信任等一堆因素。
哪些 URL 值得放進 sitemap
一份干净的站点地图，應该只包含希望被索引、且本身具备被索引條件的頁面。判断标准可以简單列成几條：
- 返回狀態碼 200，不是 301、302、404、410；
- 頁面自身没有 noindex，也不在 robots.txt 的 Disallow 范围内；
- canonical 指向自己，或者干脆没有指向別處的 canonical；
- 内容是能獨立成頁的，不是纯篩選、排序、會话參數生成的临时地址。
常见反例是把全站連結一股脑導出来：站内搜尋结果頁、带跟踪參數的分享連結、已经被合並的老地址、需要登入才能看的頁面，全都塞進去。文件体积上去了，有效信号反而被稀释，蜘蛛花在低價值地址上的時間也變多。
lastmod 寫不准，比不寫更糟
lastmod 字段的原意是告诉搜尋引擎這個頁面什么时候有過實质改動，方便它優先回抓更新的内容。如果每次生成 sitemap 都把全站 lastmod 刷成当天時間，第一次可能還有效，几次之後搜尋引擎就會開始忽略這個字段。
更稳妥的做法是：只在正文、标题、结构化資料等真正變化时更新 lastmod，與内容無關的模板調整、样式改動不要動它。做不到精确追踪，就干脆不寫，让搜尋引擎自己判断。
數量、拆分和更新节奏
單個 sitemap 文件有條數和体积上限（通常為 5 萬條 URL、未压缩 50MB），超過之後需要用 sitemap 索引文件指向多個子文件。這個限制本身不难處理，麻烦的是拆分方式。
按栏目拆比按時間拆更好维護：文章、商品、专题、帮助中心各自一個文件，某個板块出問题时不至于整份文件推倒重来。子文件的數量也不必刻意堆，几十個頁面能覆盖的站点，没必要拆成上千份。
更新频率上，内容型站点每天或每周生成一次通常够用；更新稀疏的站点，按月甚至更低频也没問题。真正要紧的是別让文件里長期挂着大量 404 或重定向地址，那會让後續几次抓取都浪費在無效地址上。
提交之後没動静，按這個顺序排查
- 先確認文件真的被讀到了：後台有没有报格式错誤、编碼問题，是否被 robots.txt 挡住。這一步没過，後面的排查都没有意义。
- 再抽查 sitemap 里的 URL 本身：随机挑十几個，用抓取工具模拟一次訪問，看狀態碼、canonical、robots meta 是否符合预期。
- 然後看内鏈：如果站点地图里有一批頁面，站内却几乎没有連結指向它們，蜘蛛即便知道地址，也缺少再次回訪的理由。sitemap 是补充通道，内鏈才是主路径。
- 最後才看内容和竞争：頁面是否與其它頁高度重复、是否有足够的獨立信息、是否属于用戶會主動搜尋的類型。這一层的問题，靠調整 sitemap 解决不了。
几個容易踩的细节
- 文件里同时出現 http 和 https、带 www 和不带 www 的版本，會产生大量重复地址，最好只保留正式版本。
- 分頁、篩選、排序參數頁要不要進 sitemap，取决于是否希望它們被索引。不确定的话先放一小部分，观察一段時間再决定。
- 多語言或多地区站点，可以把各語言版本的 URL 放在同一份文件里，用 hreflang 标注關系，不必為每種語言單獨提交一份。
- sitemap 是公開可訪問的，不要往里放内部測試頁、後台地址或只有特定用戶才能訪問的 URL。
把它当基础设施，而不是開關
站点地图更像给搜尋引擎准备的一份目錄，長期保持干净、准确、與站内實际情况一致，它的價值才會慢慢体現。指望它一提交就带来收錄變化，往往會把注意力從真正的問题——頁面质量和站内结构——上移開。