做收录核对时，大多数人的流程是固定的：从 sitemap 或站内地址表里导出一批 URL，逐个去搜索引擎查是否被收录，然后统计一个比例。这个方向没错，但它只能回答“我提交的地址有没有进”，回答不了“索引里为什么多了这些地址”。
把方向反过来做一遍，往往能挖出更多问题：以索引里的地址为起点，去比对站内地址表，看哪些地址不在表里。差集越大，说明站点的 URL 产出和索引里的 URL 集合已经脱节。
为什么反向比对更容易发现问题
- 索引里的地址来源不止一个：站内链接、sitemap、外链、历史版本、图片与附件、被合并的变体地址，都可能落进去。
- 正向核对默认“站内地址表是完整的”，但很多站点的地址表只覆盖主流程页面，漏掉了筛选页、参数页、附件页。
- 反向差集里的每一条，通常都对应一个具体的产出环节或历史遗留问题，比正向的“未收录”更好定位。
反向比对的操作顺序
- 从索引侧拉一份地址清单。可以用站点查询指令粗略统计，也可以用站长工具的索引报表导出，注意尽量取全量而不是只看第一页。
- 做 URL 归一：统一协议与主机大小写、去掉片段标识与跟踪参数、把带斜杠和不带斜杠的地址视为同一类，否则差集里会混进大量无意义的重复项。
- 和站内地址表做差集，只留下“索引里有、表里没有”的地址。
- 按来源与类型给差集分组，再决定每条地址的去留。
差集里常见的几类地址
- 历史遗留地址：改版、换目录、换参数结构后留下的旧地址。确认它是否做了跳转、跳转最终落在哪个地址，别只看第一跳。
- 带跟踪或会话参数的变体：canonical 只是提示，不是阻止收录的命令。要收敛就配合链接改造，而不是指望标签立刻生效。
- 非 HTML 资源：图片、PDF、附件、接口返回的 JSON。先明确这些资源是否需要出现在搜索结果里，再决定用 404、目录级屏蔽还是保留。
- 站内搜索与筛选生成的地址：这类地址数量可以无限增长，通常是索引膨胀的主要来源。按模板统计一遍，再统一收敛。
- 外部链接指向的错误地址：拼错的路径、过期活动页。若还有价值就补跳转，若已废弃就返回明确的 404 或 410，不要让它长期返回 200 空页。
- 子域、镜像域或测试域：确认它是否应该独立存在，还是应该整体跳回主域。
三个容易踩的坑
把“抓取”当成“收录”：robots.txt 里屏蔽了抓取，地址仍然可能因为外链而进入索引，只是缺少摘要。核对时要把这两件事分开看。
用实时索引数据下结论：索引有更新延迟，刚删掉的地址可能还会出现一段时间。核对时最好隔一周再看一次，避免反复修改。
看见差集就一律删：差集里有一部分可能是被索引合并后仍保留的变体，处理前先确认它是不是某个正式地址的另一版本。
收录核对不是统计一个比例，而是维护两份清单的一致性：站内希望被索引的地址，和索引里实际存在的地址。
核对结果怎么落地
把差集地址分成三类写进清单：需要保留并补进站内地址表的、需要收敛或跳转的、明确不需要并要返回错误状态的。每类标明负责人和处理时间，处理完再跑一次反向比对，看差集是否缩小。这个动作按季度做一次，比每次收录波动时临时排查要省力得多。