站点上的 URL 一般有两套入口：一套是頁面上可以点到的内鏈，一套是文件里主動声明的 Sitemap。很多运营者會預設两者應当完全重合，實际上它們更像是两個不同来源的清單，覆盖范围几乎不可能天然一致。與其追求嚴丝合缝，不如把两邊的清單定期做一次差集，看清哪些 URL 只出現在其中一個入口，再判断這是不是一個需要處理的問题。
两套入口的职责並不相同
内鏈反映的是站点的實际可達性：蜘蛛顺着頁面一层层爬行，能不能走到某個 URL，取决于模板、導航、分頁和前端渲染方式。Sitemap 則是主動提交的声明清單，作用更多是补充那些内鏈难以覆盖、或者层級較深的地址。
因為来源不同，两者的更新节奏也不同。内鏈會随着頁面改版、栏目調整即时變化；Sitemap 往往由脚本按固定周期生成，模板改了、頁面下线了，文件可能還停留在上一版。差异大多来自這里，而不是某一邊「出错」了。
常见的差异類型
- 只在 Sitemap 里出現：多為孤岛頁、需要通過交互才能展開的内容，或者 Sitemap 生成时把跳轉地址、noindex 頁面也寫了進去。
- 只在内鏈里出現：常见于分頁序列深處的列表頁、時間較早的归档頁，以及 Sitemap 脚本按栏目規則抓取时漏掉的部分。
- 两邊都像有、却對不上：大小寫、尾斜杠、預設端口、參數顺序的寫法不一致，看起来是两個 URL，實际指向同一頁。
- 數量級差异：一邊是几萬條，另一邊只有几千條，通常意味着 Sitemap 包含了大量參數化 URL，或内鏈结构被前端渲染切断。
核對的具体做法
- 從服務器日誌或抓取工具里導出最近一段時間被抓取的 URL 集合，顺便留意每個 URL 的返回狀態碼。
- 解析 Sitemap 文件，包括索引文件和各個分片，得到完整的声明清單。
- 對站点做一次站内連結抓取，记錄每個 URL 的入鏈數量，而不只是记錄它是否存在。
- 把三份資料做差集：只在 Sitemap、只在内鏈、两邊都有但寫法不同。
- 對差异項逐個判断，而不是批量清理。判断依據是頁面本身是否有價值、是否可正常訪問。
差集结果本身不是结论。比如一個 URL 只在 Sitemap 里出現，如果日誌顯示它長期被抓取，說明声明和發現都在正常工作；如果從来没被抓過，才需要回头检查 Sitemap 是否被正确讀取、文件是否可訪問、頁面是否設定了阻碍抓取的規則。
建议的處理顺序
差异項的處理有先後之分，顺序反了容易制造新的重复。
- 先统一地址寫法。規范地址、大小寫、尾斜杠、參數取舍先在站内達成一致，這是後面所有核對的基础。
- 再补内鏈。對確認有價值的頁面，從相關栏目或内容頁加入稳定入口，让它不依赖 Sitemap 也能被發現。
- 最後修 Sitemap 生成逻辑。把不该出現的跳轉頁、無價值參數頁排除掉，同时确保新栏目上线後能自動進入文件。
当地址寫法對不上时，先修地址，再讨论這個 URL 该不该放進 Sitemap。
不要把 Sitemap 当成内鏈的替代品
有些站点把大量頁面的發現完全交给 Sitemap，站内几乎没有指向它們的連結。這類頁面即便被發現，也缺少内鏈提供的上下文和權重传递，抓取频率通常偏低，内容更新後回訪也比較慢。Sitemap 更适合作為补充入口，而不是唯一路径。
一個容易被忽略的前提
核對過程中，如果 Sitemap 文件拉取频繁超时，或者站内抓取反复遇到 5xx，先確認服務器响應是否稳定，再判断 URL 是否真的失效。否則容易把临时的服務波動誤讀成頁面被刪除，做出错誤的清理動作。
节奏上，建议每月做一次差集核對，另外在改版、批量上下线頁面、調整栏目结构之後各补做一次。差异清單不必追求归零，重点是知道每條差异為什么存在，以及它會不會影响正常抓取。