很多人核对收录时会做一个动作：在搜索框里敲 site:自己的域名，看返回的结果条数，然后把这个数字记成“索引量”。过几天数字掉了就紧张，涨了就觉得收录变好。这个数字确实有参考价值，但它和索引量不是一回事，两个口径混用，后面的判断几乎都会偏。
site 查询返回的是什么
site: 是一种检索式，它触发的是搜索系统的查询结果，而不是后台的索引统计。结果页顶部那个数字，是系统针对这次查询给出的估算结果，通常经过抽样、去重和取舍，而不是把库里所有符合条件的 URL 逐条数给你。
所以它天然带着几个特征：同一时刻不同人查、不同地区查、不同设备查，数字可能不一样；同一批 URL，检索式稍微变一下，数字也会变。它更像一个“大概有多少相关结果”的体感值，而不是一份准确的台账。
把它当索引量，会踩哪几个坑
- 数字被估算和截断。量级越大，展示的数字越接近一个粗略值，末尾几位往往不是真实计数。
- 只统计能被检索到的部分。索引里存在、但因质量或策略原因不参与展示的页面，不会体现在这个数字里。
- 受检索式写法影响。带不带 www、用主域还是子域、加不加路径，命中的集合完全不同。
- 受结果去重影响。高度相似的页面在结果里会被折叠，数量自然偏少。
- 受地域与语言影响。不同节点返回的集合范围可能不同，跨时间对比时基准就变了。
结果就是：数字变了，你无法判断是索引真的增减了，还是查询口径、去重策略、节点差异发生了变化。用这样的数字做决策，容易把正常波动当成问题，也容易把真正的问题盖过去。
核对收录，应该用哪几个口径
更稳的做法是分层对账，每个口径解决一个问题：
- 后台索引报告：看整体趋势和原因分类，回答“有多少 URL 处在什么状态”。
- 单条 URL 检查工具：抽样式验证具体页面的当前状态、抓取时间和使用的 canonical，回答“这一条到底怎么了”。
- 站点日志：看蜘蛛实际抓了哪些地址、返回什么状态码，回答“它有没有来、拿走了什么”。
- sitemap 与站内 URL 总表：把自己的清单和后台数字对齐，回答“差在哪些模板、哪些目录”。
- 站内检索或抽样查询：只用来做定性确认，比如某个页面是否还能被找到，不作为数量依据。
把“我搜到多少条”和“系统索引了多少条”分开记录，是收录核对里成本最低、收益最明显的一步。
site 查询仍然有用的场景
不用完全弃用它，只是别把它当尺子。它比较适合做这些事：确认一个具体页面是否还在结果里；看某个子域或目录大概有没有被纳入；粗略感知某类内容的收录方向。这些都属于定性判断，对绝对数字不敏感。
如果一定要记录数字，建议固定检索式、固定地区、固定时间点，并且只和自己比，不跨口径比。同时把当天后台的实际数字一起记下来，两条线并排放，时间一长就能看出哪些波动来自查询口径、哪些来自真实变化。
一个小习惯
每次核对前先问一句：这次要回答的是“有没有被收录”，还是“收录了多少”。前者可以用检索式快速确认，后者必须回到后台和日志。口径先统一，后面关于页面质量、重复内容和 URL 规范的判断才有意义，否则很容易在一堆会变的数字上反复打转。