判断官网有没有被 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$9200 {print $7,$10,$NF}access.log|grep-iEbot|spider|sort|uniq-c|sort-rn|head跑完能看到哪些路径被反复抓、抓走多少字节。字段一User-AgentUA 是身份声明。主流检索系统的抓取 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 月服务范围、平台清单与交付内容以合同约定为准。
判断官网有没有被 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$9200 {print $7,$10,$NF}access.log|grep-iEbot|spider|sort|uniq-c|sort-rn|head跑完能看到哪些路径被反复抓、抓走多少字节。字段一User-AgentUA 是身份声明。主流检索系统的抓取 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 月服务范围、平台清单与交付内容以合同约定为准。
