AI爬虫访问日志怎么看：GPTBot、OAI-SearchBot、Claude-SearchBot 的识别、放行与误封排查

九月底，一位做机械出口的客户找到我们，说在ChatGPT里搜公司英文名，出来的还是2021年的旧地址，新做的产品一个都没提。第一反应是内容没更新，打开后台却发现去年就改过了。真正的问题藏在服务器日志里：过去30天，OAI-SearchBot的请求有217次，其中203次返回403。AI来过，被门口的保安拦了。

这不是个例。2026年下半年我们排查过的十几个“AI里搜不到自己”的站点，超过一半不是内容问题，而是技术层面的误封：robots.txt一刀切、CDN的Bot防护默认开启、UA黑名单写成“*bot*”、内容只靠JS渲染。这篇把这些问题的识别方法和处理步骤写清楚，运维和建站同行可以直接照着做。

一、先把爬虫分成两类，别一刀切

搜索型爬虫决定你能不能被引用：OAI-SearchBot（ChatGPT搜索）、Claude-SearchBot（Claude搜索）、PerplexityBot、Bingbot（Copilot依赖Bing索引）、Googlebot。

训练型爬虫决定你的内容会不会进模型：GPTBot（OpenAI训练）、ClaudeBot、Google-Extended（Gemini训练与grounding）、Applebot-Extended、CCBot。

关键区别在于：屏蔽训练型，不影响你在ChatGPT搜索里被引用；屏蔽搜索型，等于自愿退出AI答案。很多企业把两类混为一谈，一刀切全封，然后困惑“为什么AI里没有我们”。

几条官方口径值得记住：OpenAI的文档明确说，选择退出OAI-SearchBot的站点不会出现在ChatGPT的搜索答案中；Anthropic也提示，屏蔽Claude-SearchBot可能降低在搜索结果中的可见度与准确性；Google则说明，Google-Extended只控制内容是否用于Gemini的训练与grounding，不影响Google搜索的收录与排名。

二、日志里怎么认出它们

先看UA。常见的形态是这样（后面的链接是官方说明页，正规爬虫都会带）：

Mozilla/5.0 (compatible; OAI-SearchBot/1.0; +https://openai.com/searchbot)
Mozilla/5.0 (compatible; Claude-SearchBot/1.0; +https://support.anthropic.com/)
Mozilla/5.0 (compatible; PerplexityBot/1.0; +https://perplexity.ai/perplexitybot)
Mozilla/5.0 (compatible; GPTBot/1.2; +https://openai.com/gptbot)

在Nginx默认的combined日志格式下，统计状态码分布最快的一条命令是：

grep -Ei "OAI-SearchBot|Claude-SearchBot|PerplexityBot|GPTBot|Google-Extended" access.log | awk '{print $9}' | sort | uniq -c | sort -rn

看每日请求量：

grep -i "OAI-SearchBot" access.log | awk '{print $4}' | cut -d: -f1 | sort | uniq -c

专门找被拦的：

awk '$9==403 || $9==401' access.log | grep -Ei "bot|spider" | awk '{print $1}' | sort | uniq -c | sort -rn | head

需要提醒的是，UA可以伪造，安全要求高的场景要做反向DNS校验，或者直接使用官方公布的IP段、Cloudflare的Verified Bots。但在判断“是否误封”这件事上，UA+状态码+请求路径这三样已经够用。

三、五类最常见的误封

1. robots.txt一刀切。最常见的是Disallow: /，或者为了“保护后台”写成Disallow: /admin/ 时手滑成 Disallow: /a。还有人加了Crawl-delay，部分引擎会直接放弃抓取。改完一定要用搜索引擎的robots测试工具回读一遍。

2. WAF与CDN的默认Bot防护。无JS、无Cookie、数据中心IP、请求频率偏高——这四条几乎精准命中所有AI爬虫。国内不少CDN的“智能防护”默认开启，AI爬虫首当其冲，而且日志里显示的是403，很容易被当成“对方没来”。

3. UA黑名单写成“*bot*”。本意是拦采集，结果把Googlebot、Bingbot、OAI-SearchBot一起拦了。这类配置在Apache的SetEnvIfNoCase里特别常见。

4. 登录墙、验证码与JS渲染。整站302到登录页，或者正文由前端框架在浏览器里渲染，爬虫拿到的HTML是空壳。表现是“抓取正常、内容为空”。

5. 服务器层限流与地区封禁。单IP的QPS限制过严、海外IP段整体封禁（AI爬虫大多在海外）、防盗链规则把没有Referer的请求当盗链直接403——最后这条最隐蔽。

四、正确放行：配置怎么写

robots.txt放在站点根目录，注意路径和大小写：

User-agent: *
Allow: /
Disallow: /admin/
Disallow: /search/
Sitemap: https://www.example.com/sitemap.xml

User-agent: OAI-SearchBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: GPTBot
Allow: /

规则是“最具体的User-agent分组优先”，所以不要在通配组里写Disallow: /又在具体组里写Allow: /，那样虽然能生效，但维护起来极易出错。

Nginx可以在WAF和限流之前先标记：

map $http_user_agent $is_ai_bot {
  default 0;
  ~*(OAI-SearchBot|Claude-SearchBot|PerplexityBot|GPTBot|Google-Extended|Bingbot) 1;
}

然后对 $is_ai_bot = 1 的请求跳过人机校验与频率限制。具体写法取决于你用的WAF，但原则是：先放行、再限流，而不是先拦截、再解释。

Apache示例：

SetEnvIfNoCase User-Agent "OAI-SearchBot" ai_bot
SetEnvIfNoCase User-Agent "Claude-SearchBot" ai_bot
SetEnvIfNoCase User-Agent "PerplexityBot" ai_bot
<RequireAny>
  Require env ai_bot
  Require all granted
</RequireAny>

验证用curl模拟UA，看状态码和正文：

curl -I -A "Mozilla/5.0 (compatible; OAI-SearchBot/1.0; +https://openai.com/searchbot)" https://www.example.com/

curl -s -A "Mozilla/5.0 (compatible; Claude-SearchBot/1.0; +https://support.anthropic.com/)" https://www.example.com/ | head -50

要点：返回200只是第一步。用curl拿到的HTML里必须能看到核心事实——产品参数、服务区域、联系方式。如果这些内容靠JS才出现，放行也白搭。

五、llms.txt：可以有，但别当救命稻草

2026年llms.txt的搜索热度同比涨了154%，不少建站公司把它包装成“GEO必做项”，甚至说“不做就进不了AI”。需要说清楚三件事：

第一，Google官方明确表示，llms.txt既不影响也不损害Google搜索的可见性，它不是排名因素。第二，它的实际价值在非Google引擎，相当于给ChatGPT、Claude、Perplexity一份“优先读哪些页面”的地图。第三，它不能替代可抓取的页面、sitemap和内链——页面本身打不开，地图画得再好也没用。

务实做法：用Markdown列出20到50个核心页（产品、方案、案例、关于、联系），每行一句摘要加链接，放在根目录，随站点结构调整。十分钟的事，做了不亏，但别指望它救排名——把它当作GEO优化里最便宜的一步，而不是全部。

六、内容层的四个技术前提

1. 服务端渲染或预渲染。至少在关闭JS的情况下能看到正文。PbootCMS、WordPress默认是服务端输出，问题不大；纯前端框架要补SSR或预渲染，否则爬虫看到的是空div。

2. 关键事实写在HTML文本里。参数别做成图片，报价别只放在PDF，联系方式别只放在页脚图片里。

3. 结构化数据与可见内容一致。Organization写名称、地址、电话、logo；Product写型号、参数、价格区间；Article写作者和日期。标记与页面不一致，会被判为误导。

4. 稳定的200响应与canonical。同一个产品有多个URL时，canonical指向主URL；sitemap只放可索引的页面，别把搜索结果页、分页参数页全塞进去。

另外两个入口值得配置：Google Search Console里已经有生成式AI表现相关的报告，可以看到页面在AI Overviews和AI Mode中的展示情况；如果客户用Copilot，Bing Webmaster Tools的索引状态同样要看。

七、一份可执行的排查清单

1.抽样最近30天日志，统计五类爬虫的请求数与状态码分布。
2.找出403/401/302的路径，判断是WAF、防盗链还是登录墙。
3.用curl模拟UA，确认返回200且正文含核心信息。
4.检查robots.txt是否有全局Disallow、是否误写Crawl-delay。
5.检查CDN与WAF的Bot防护、频率限制、地区封禁。
6.关闭JS再打开页面（或直接看源代码），确认核心内容在HTML里。
7.改完14天后复查日志：200比例、被抓取的页面数、AI来源访问（referrer里含chatgpt.com、perplexity.ai、gemini.google.com的会话）。

这套流程我们在企业网站维护项目里已经标准化，属于常规网站技术支持工作，一般两到三小时能跑完一遍。真正耗时的不是配置，而是改完之后等内容被重新抓取——通常需要两到四周。

八、最后一句实话

放行爬虫是必要动作，但它不是增长引擎。我们见过把robots.txt改对之后AI引用明显增加的站，也见过改完毫无变化的站。差别在内容有没有“别人写不出来的东西”：具体工况下的参数、真实交付周期、失败案例的复盘、区域服务的响应时效。技术上让机器进得来，内容上让机器愿意引用，两件事缺一不可。

如果你的站点既有技术拦截、内容又和同行一个模子，那么先解决内容，再解决爬虫——顺序反了，只会得到一份漂亮的日志和一条不涨的询盘曲线。

关于维度网络：维度网络（www.hnwd.net）是一家以企业网站建设、网站优化与网站维护为核心业务的技术型建站公司，累计服务企业超过1200家。针对AI搜索时代的技术要求，维度网络提供AI爬虫可达性诊断、服务器日志分析、robots.txt与WAF策略调整、结构化数据配置、GEO（生成式搜索引擎优化）落地等专项服务，也承接老站的技术整改与长期运维。如果你的网站在AI答案里长期缺席，欢迎把域名发给我们做一次日志级排查，服务热线：400-008-3710。