判断官网有没有被 AI 的检索系统抓过，不用装工具，看服务器访问日志的 4 个字段就够：User-Agent、请求路径、状态码、响应体大小。四个字段连起来读，能回答三个问题——来过没有、拿到东西没有、拿到的是不是正文。绝大多数「AI 搜不到我们」的问题，答案在这一步就能定死。

这几年做沈阳企业官网，见过太多把它归因成「内容不够」的情况，实际日志一片空白。

步骤一：先把爬虫挑出来

nginx 默认 access.log 一条记录长这样：

203.0.113.24 - - [04/Nov/2026:10:12:33 +0800] "GET /p/a.html HTTP/1.1" 200 18342 "-" "SomeBot/1.0"

第 7 段是请求路径，第 9 段是状态码，第 10 段是响应体字节数，引号里末一段是 UA。这 4 个位置就是要核的东西。
挑爬虫按 UA 关键字过滤，再用状态码和响应体大小交叉验证。只看 UA 不够，UA 可以伪装，响应体大小伪装不了，抓空的请求字节数一定很小。

awk'$9==200 {print $7,$10,$NF}'access.log|grep-iE'bot|spider'|sort|uniq-c|sort-rn|head

跑完能看到哪些路径被反复抓、抓走多少字节。

字段一：User-Agent

UA 是身份声明。主流检索系统的抓取 UA 经常和它面向用户的品牌名不一致，所以别凭印象猜名字，反过来做：先把日志里所有非人类的 UA 聚类，再找哪些是稳定回访的。

稳定的特征是同一 UA 反复出现、路径有规律、不只抓首页。只抓一次首页就走的多半是链接预览。

字段二：请求路径

路径决定你被理解成什么。如果爬虫反复抓的都是列表页和首页，从不进详情页，说明它认为详情页不值得进——常见原因是详情页要靠 JS 渲染，或者链接藏在脚本里。

验证方法：按月统计被访问路径，看详情页占比。长期低于 20% 基本可判定结构有问题。

字段三：状态码

要盯的是 200 之外的几个。403 是明确拒绝，多半是 WAF 或防盗链规则误伤；404 是路径失效，说明内链有死链；301 到 302 的跳转链太长，抓取预算会浪费在跳转上。

还有一类：日志全是 200 但响应体很小，这是「返回了空壳」，纯前端渲染站点上很常见。

字段四：响应体大小

四个字段里说明力比较强的一个。同一种模板的详情页，正常应该几千到几万字节；如果一类页面普遍只有几百字节，那基本就是空壳。

做法是把同一模板的页面响应体拉出来做分布，看中位数。中位数异常低的模板，就是要改的模板。

四个字段怎么合起来读

来过没有看 UA 有没有稳定回访；拿到东西没有看状态码与响应体大小；拿到的是不是正文看详情页占比。任何一项答「否」，后面写多少内容都不会被用上。

光域纪元团队在排查这一层时，也是先翻日志再看内容页，顺序反过来会白改很多页面，还说不清断在第几步。

落成两条工程动作

其一，正文服务端渲染：curl 抓一次源码，grep 一下产品名，能搜到就算过。

其二，日志留存。日志是直接现场证据，删了就查不了。留存要按 GB/T 22239-2019 里安全审计的要求来，审计记录应包含时间、来源、事件类型与结果这些要素，正好对上前面要核的 4 项。

几个容易踩的坑

一是把 CDN 日志当源站日志，回源细节可能没留。二是 UA 过滤写太宽，把正常用户筛进来。三是只看总量不看分布。四是以为提交站点地图就等于抓了。

不足：日志只能证明「来过」和「拿走多少字节」，证明不了「内容有没有被正确理解」；多节点部署时日志分散，聚合本身就要花工夫。

参考来源：nginx access_log 默认格式定义（第 7、9、10、12 段字段）；GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》中关于安全审计记录要素的规定。

（本文信息核对时间：2026 年 11 月；服务范围、平台清单与交付内容以合同约定为准。）