由 URL采集专家 
查收录的时候大家都会敲 site:，敲完看一眼数字，心里默念「哦，收录了八千条」，然后就关掉了。这个用法只用了 site 三成的能力。真正省时间的是把它和 inurl、intitle 拼起来——前者限定目录，后者限定标题关键词，一组合，一个站的目录结构、每个目录被收录了多少页、哪些目录全是参数垃圾，一个小时就能盘清楚。
site 单用只能看个总数
site:example.com 返回的是这个域名下被索引的页面总量，但这个数字本身并不靠谱：它是估算值，会随查询词变化，同一个站在不同时间查能差好几千。所以别拿它当 KPI，把它当「有没有被收录」的开关更合适。真正有价值的信息在结果列表里——哪些 URL 出现了、它们长什么样。可结果一页只给十条，几千个页面靠翻页看到天亮也看不完，这才是需要 inurl 的原因。
inurl 到底在限定什么
inurl: 后面跟的字符串要求 URL 里包含它。注意是「包含」，不是「以它开头」，也不区分大小写。这意味着 inurl:tag 能同时命中 /tag/ 和 /tags/，也会顺手命中 /article/tag-list 这种无关路径。写规则的时候把两边的斜杠带上（inurl:/tag/），精确度高很多，误伤能少一半。同理，想限定开头就用 inurl:https://域名/tag 这种写法，虽然啰嗦但边界清楚。
四个真正好用的组合
| 查询组合 | 能看到什么 | 怎么判断 |
|---|---|---|
| site:域名 inurl:/tag/ | 标签聚合页被收录的数量 | 数量远超文章数，说明聚合页在稀释权重 |
| site:域名 inurl:? | 带参数的筛选页、排序页 | 大批出现就是重复内容，该封就封 |
| site:域名 inurl:/page/ | 列表分页的收录情况 | 翻了二十页还在索引里，属于抓取预算浪费 |
| site:域名 intitle:关键词 | 某个主题到底有多少页 | 和实际策划的数量对不上，就是漏页了 |
这四条的思路是一样的：先猜目录规则，再用 inurl 去验证，最后看返回条数和结果质量。一个站跑十几条查询，目录有没有被搜素引擎吃透，心里就有数了。查询语法本身还有不少花样，站内那篇Google 高级搜索语法整理得比较全，配合着看更省事。
批量跑才叫盘完
一个站十几条查询，十个站就是一百多条。手动一条条敲既慢又容易触发验证码，敲到第五条就开始被要求验证，节奏全断。可行做法是把查询语句写成一行一条的纯文本清单，用采集软件批量提交、自动翻页、统一导出成表格。
跑完拿到的是原始 URL 列表，接下来必然要做归类：把首页、栏目页、详情页分开，才知道每个目录的真实页面基数，进而算出收录比例。按 URL 层级批量归类的做法之前单独写过，配合这里用正合适。至于收录量本身怎么查更准、site 与 GSC 的差别，谷歌收录的三种查法那篇讲得更细。
四个容易踩的坑
- 把 site 的数字当真实收录量。它只是估算，趋势比绝对值有用；
- 以为百度也吃 inurl。百度对这类语法的支持一直很弱，同样的语句在百度上结果基本不可用，别拿百度的结果下结论；
- 查询太频繁。同一个 IP 连着跑几百条 site 查询，验证码是必然的，控制频率、分批跑；
- 只看总数不看 URL。真正的信息在 URL 形态里，不在那个数字上。
需要说明的是，所有这些查询针对的都是公开索引，抓取结果时同样要遵守目标站点规则与相关法律法规。这套活在自己软件里跑最省事，查询清单、翻页、导出、按目录归类一条龙，软件工具一览里有对应模块，想先试的可以直接用免费的在线查询凑合一轮。
相关推荐
关键词网址采集器：始于2007年的原创采集软件，支持百度、搜狗、360、神马、谷歌、必应。微信/QQ：13327215，飞机：gjcwzcjq