站点上的 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 是否真的失效。否则容易把临时的服务波动误读成页面被删除，做出错误的清理动作。
节奏上，建议每月做一次差集核对，另外在改版、批量上下线页面、调整栏目结构之后各补做一次。差异清单不必追求归零，重点是知道每条差异为什么存在，以及它会不会影响正常抓取。