准备正确的查询对象,核心只有一句话:先确定你要查的是“一个可被搜索引擎识别的站点根域”,还是“站点下的某个目录、子域或具体页面”。很多人把带路径的完整网址、带参数的页面地址,甚至把后台或内网地址直接丢给 site 查询,结果自然对不上。正确做法是把查询对象收敛为搜索引擎已经抓取并归入同一站点的范围,再用路径限定逐步缩小。
最常见的错误是认为 site 后面跟什么,搜索引擎就会精确返回什么。实际上 site 查询表达的是“限定在某个站点或站点范围内匹配”,它不是一个精确的网址定位器。你输入一条带 ? 参数、带会话 ID、带 # 锚点的地址,搜索引擎通常不会把它当作独立可查对象,而是归回所属的规范网址或直接忽略参数部分。
这解释了一个典型现象:同一批人用同一个后台导出的链接清单去查,有人能查到,有人查不到。差别往往不在查询语法,而在清单里的链接是否属于同一个站点范围,以及这些链接是否被允许抓取。
第一步,确认站点边界。把候选地址统一成协议加主机名的形式,例如 https://www.example.com/。这里要判断的是:带 www 和不带 www 是否被搜索引擎视为同一站点。判断方法是分别查询两个形式,观察返回结果是否指向同一批内容;如果明显分成两套,就说明它们被当作不同站点,需要按实际使用的那个来查。
第二步,确认目录层级。如果只想看某个栏目,就在站点后面接目录,例如 https://www.example.com/blog/。判断依据是目录是否真实存在、是否有独立入口页面。把不存在的目录当作查询对象,返回为空是正常结果,不代表内容丢失。
第三步,剔除不该进入查询对象的地址。以下类型通常不适合直接作为查询对象:
sessionid、token 的链接。# 之后的部分,搜索引擎一般只处理锚点前的地址。协作返工多半来自“每个人理解的查询对象不一样”。交付时不要只写一句“查一下这个站”,而要给出结构化清单,让执行人不需要再猜。
建议清单包含四列:查询对象(站点根域或目录)、限定条件(是否需要加路径或关键词)、预期判断(有结果表示什么、无结果表示什么)、负责人。示例可以这样写:
https://www.example.com/blog/,限定该目录,预期判断为“有结果说明该目录已被抓取并归入该站点”,负责人甲。这里的域名和路径仅为假设示例,实际填写时替换为你的真实对象。
这样写的好处是:执行人拿到的是明确的查询对象和判断标准,而不是一个需要二次解释的网址。出现空结果时,也能立刻区分是对象准备错了,还是内容确实未被抓取。
可以用一个简单对照来验证。先查站点根域,再查你准备的目录对象。如果根域有结果、目录无结果,可能原因是该目录未被抓取、被规则屏蔽,或目录路径写错;如果两者都无结果,更可能是主机名写错、站点整体未被抓取,或查询对象根本不属于公开可抓取范围。
注意这里说的是“可能原因”,不是已经定位的原因。同一个空结果有多种解释,需要逐项排除,而不是直接下结论。判断顺序建议是:先核对主机名拼写,再核对协议与 www 形式,最后核对目录是否存在独立入口。
下一步,把你当前要交付的查询对象按上面的四列清单整理出来,先查站点根域确认边界,再逐个查目录对象并记录结果,这样多人协作时就能减少因对象不一致造成的返工。