为什么要做两套入口的交叉核对
Sitemap 和内链是搜索蜘蛛发现 URL 的两条主要路径。前者是站点主动声明的清单，后者是蜘蛛顺着链接爬出来的实际路径。日常运营中常见的情况是：Sitemap 里的 URL 早就随改版删掉了，内链里却还有一批页面从未进入过 Sitemap，两边各说各话。只看其中一份数据，很容易得出“入口很全”或“抓取很少”的错误结论。
交叉核对的目的是找出几份清单之间的差集，判断每个差集属于正常现象，还是需要处理的入口问题。
三份数据从哪来
- Sitemap 清单：线上 Sitemap 文件（含索引文件展开后的全部 URL）去重后的集合。
- 内链可达集：从首页出发、按站内链接逐层抓取，得到的返回 200 的 URL 集合。多数站内爬虫工具都能导出。
- 实际抓取集：服务器访问日志中搜索蜘蛛 UA 访问过的 URL 集合。注意日志要覆盖足够长的周期，并做好 URL 归一化，去掉片段标识与追踪参数、统一大小写。
三份数据的时间窗口要尽量对齐。拿上个月的内链抓取结果去比对本周的 Sitemap，差集里会混入大量改版噪声。
四类差集的解读
只在 Sitemap 中、内链不可达
这是最需要优先看的一类。可能是页面已删除、被 robots 拦截，或者根本没在任何页面里出现，也就是常说的孤岛页。如果 URL 本身还返回 200 且有内容，说明入口断了，应补内链；如果已经返回 404 或 410，应从 Sitemap 中移除，避免持续占用抓取配额。
只在内链中、不在 Sitemap 里
不一定有问题，但值得分类。分页、标签聚合、筛选结果这类页面通常不需要进 Sitemap；而文章详情、产品页如果长期不在 Sitemap 中，可能说明生成逻辑有遗漏。
只在日志中、两边都没有
常见来源是外部链接、旧版 URL、参数拼接页。重点看这类 URL 是否返回 200 且有独立内容：有的话就是真实入口缺口；返回 404 或重定向的，属于历史噪音，观察即可。
业务期望有、三份都没有
真正的内容缺口。多半是发布流程里漏了推送，或者页面只通过 JavaScript 渲染出链接，静态 HTML 里看不到。
核对流程
- 导出 Sitemap URL 清单，展开索引并去重。
- 跑一次站内爬虫，导出状态码为 200 的可达 URL。
- 从服务器日志中提取搜索蜘蛛访问过的 URL，按周期切片。
- 统一 URL 格式后做集合运算，得到四个差集。
- 按是否返回 200 且有独立内容给差集打标，区分待修复与可忽略。
- 修复后记录日期，在下一次核对时观察差集是否收敛。
几个容易误判的点
- 归一化不做干净：结尾斜杠、大小写、URL 编码、追踪参数会让同一个页面被算成多个 URL，差集立刻膨胀。
- 日志不完整：CDN 或反向代理只保留了部分日志，抓取集会偏小，容易误判成没有被抓取。
- 把 Sitemap 当补漏工具：Sitemap 只能声明入口，不能替代内链。孤岛页即使出现在 Sitemap 中，后续被发现和被重新访问的机会通常也不理想。
- 只做一次性核对：入口问题会随改版、发布、下架反复出现，按季度或半年做定期核对更实际。
和抓取观察配合使用
差集核对解决的是入口有没有，抓取日志与状态码分布解决的是抓得怎么样。两者结合，才能判断是该补入口、清入口，还是该调整服务器响应。核对结果建议同步给内容发布和前端同学，避免同样的缺口在下一次改版里重复出现。