很多站点把 sitemap 当成一個開關：只要提交了，頁面就應该被收錄。實际使用中更接近另一種情况——sitemap 主要解决“搜尋引擎知道有這個 URL”的問题，至于抓不抓、收不收，還要看頁面本身和其他入口。把它放在正确的位置上，它能省下不少排查時間；放错了，反而會制造噪音。

sitemap 能解决的是“發現”，不是“收錄”

搜尋引擎获取 URL 的渠道大致有几類：外鏈、站内連結、歷史抓取记錄、站長提交的 sitemap。sitemap 的價值在于批量、明确地告诉搜尋引擎“這些 URL 存在，而且我希望它們被抓取”。它省掉的是“發現”這一步的時間，並不改變後續的抓取排队、内容评估和索引决策。

把 sitemap 当成“告知清單”，而不是“收錄申請”。

什么样的 URL 才值得寫進 sitemap

原則很简單：只放你希望出現在搜尋结果里、且目前可以正常訪問的規范 URL。

• 返回 200、内容完整的頁面；
• 頁面的規范版本，也就是 canonical 指向的那個地址，而不是各種參數變体；
• 内容有獨立價值的頁面，而不是纯篩選、纯排序、空结果的列表；
• URL 形式保持站内统一，例如是否带尾斜杠、是否带 www，全站一致。

反過来说，noindex 的頁面、需要登入才能看的頁面、重定向地址、404 地址，都不适合出現在 sitemap 里。把它們放進去，除了让报告里多出一些無意义的條目，没有別的帮助；如果 sitemap 里同时放着 noindex 頁面，两種信号還會互相打架。

几個常见的使用誤区

lastmod 随手寫成当天

lastmod 的作用是告诉搜尋引擎“這個頁面什么时候真正更新過”。如果每次生成 sitemap 都刷新成当天，這個字段就失去了參考價值，長期看容易被忽略。更實用的做法是让 lastmod 跟随頁面内容或模板的真實變更時間，没有變化就別動它。

提交一次就不管了

把 sitemap 当作動態文件来维護更合适：新頁面生成时加入，頁面下线时移除。大站点可以按栏目或模板分片，再用一個 sitemap 索引文件匯總。分片不只是為了绕開單文件的條目和体积限制，也让“哪一批 URL 提交了、哪一批没提交”更容易核對。

把 sitemap 当成唯一入口

如果一批頁面只能從 sitemap 被發現，站内没有任何連結指向它們，即使被抓取，内容评估也會比較吃力。sitemap 更适合作為兜底和补充，日常的 URL 發現依然要靠清晰的導航和合理的内部連結结构。

用 sitemap 报告做排查

在 Search Console 的 sitemap 报告里，可以看到每個 sitemap 被讀取的條目數量，以及是否解析成功。它更适合用来核對數量差异，而不是直接判断收錄：

1. 先看 sitemap 是否讀取成功，條目數和你提交的是否一致；
2. 再對比 sitemap 里的 URL 總數與站点實际需要收錄的頁面數量，差距大就先查生成逻辑；
3. 把 sitemap 里的 URL 與索引报告、日誌中的抓取记錄對照，区分是“没被發現”還是“發現了没抓”；
4. 按模板或栏目拆分後逐组看，比只看一個總數更容易定位問题集中在哪類頁面。

小结

sitemap 是一件成本不高、收益稳定的基础工具：它让 URL 發現變得可控、可核對，但替代不了内容质量、連結结构和索引狀態本身的問题。把该放的放進去，把不该放的拿出来，剩下的交给常規的抓取與评估流程就好。