做收錄核對时，大多數人的流程是固定的：從 sitemap 或站内地址表里導出一批 URL，逐個去搜尋引擎查是否被收錄，然後統計一個比例。這個方向没错，但它只能回答“我提交的地址有没有進”，回答不了“索引里為什么多了這些地址”。
把方向反過来做一遍，往往能挖出更多問题：以索引里的地址為起点，去比對站内地址表，看哪些地址不在表里。差集越大，說明站点的 URL 产出和索引里的 URL 集合已经脱节。
為什么反向比對更容易發現問题
- 索引里的地址来源不止一個：站内連結、sitemap、外鏈、歷史版本、图片與附件、被合並的變体地址，都可能落進去。
- 正向核對預設“站内地址表是完整的”，但很多站点的地址表只覆盖主流程頁面，漏掉了篩選頁、參數頁、附件頁。
- 反向差集里的每一條，通常都對應一個具体的产出环节或歷史遗留問题，比正向的“未收錄”更好定位。
反向比對的操作顺序
- 從索引侧拉一份地址清單。可以用站点查询指令粗略統計，也可以用站長工具的索引报表導出，注意尽量取全量而不是只看第一頁。
- 做 URL 归一：统一协议與主机大小寫、去掉片段标识與跟踪參數、把带斜杠和不带斜杠的地址视為同一類，否則差集里會混進大量無意义的重复項。
- 和站内地址表做差集，只留下“索引里有、表里没有”的地址。
- 按来源與類型给差集分组，再决定每條地址的去留。
差集里常见的几類地址
- 歷史遗留地址：改版、換目錄、換參數结构後留下的舊地址。確認它是否做了跳轉、跳轉最终落在哪個地址，別只看第一跳。
- 带跟踪或會话參數的變体：canonical 只是提示，不是阻止收錄的命令。要收敛就配合連結改造，而不是指望标簽立刻生效。
- 非 HTML 资源：图片、PDF、附件、接口返回的 JSON。先明确這些资源是否需要出現在搜尋结果里，再决定用 404、目錄級屏蔽還是保留。
- 站内搜尋與篩選生成的地址：這類地址數量可以無限增長，通常是索引膨胀的主要来源。按模板統計一遍，再统一收敛。
- 外部連結指向的错誤地址：拼错的路径、過期活動頁。若還有價值就补跳轉，若已废弃就返回明确的 404 或 410，不要让它長期返回 200 空頁。
- 子域、镜像域或測試域：確認它是否應该獨立存在，還是應该整体跳回主域。
三個容易踩的坑
把“抓取”当成“收錄”：robots.txt 里屏蔽了抓取，地址仍然可能因為外鏈而進入索引，只是缺少摘要。核對时要把這两件事分開看。
用實时索引資料下结论：索引有更新延迟，刚删掉的地址可能還會出現一段時間。核對时最好隔一周再看一次，避免反复修改。
看见差集就一律删：差集里有一部分可能是被索引合並後仍保留的變体，處理前先確認它是不是某個正式地址的另一版本。
收錄核對不是統計一個比例，而是维護两份清單的一致性：站内希望被索引的地址，和索引里實际存在的地址。
核對结果怎么落地
把差集地址分成三類寫進清單：需要保留並补進站内地址表的、需要收敛或跳轉的、明确不需要並要返回错誤狀態的。每類标明负责人和處理時間，處理完再跑一次反向比對，看差集是否缩小。這個動作按季度做一次，比每次收錄波動时临时排查要省力得多。