同一份 access log 里,
PerplexityBot、Perplexity-User、Googlebot、bingbot不能混着看。前两者要按 Perplexity 的官方用途分开,后两者是普通搜索抓取基础;只看 User-Agent 字符串,不足以判断真实身份。
外贸 SEO 团队拿到日志后,最容易犯的错是把所有 bot 都归成“搜索爬虫”,然后只看访问次数。
真正可复盘的做法是:先分组,再验证,再看核心 URL 和状态码。
先分清四类访问
| User-Agent token | 适合怎么分组 | 主要复盘问题 |
|---|---|---|
PerplexityBot |
Perplexity 搜索相关 crawler | 是否访问了产品、FAQ、案例等核心页 |
Perplexity-User |
用户触发访问 | 是否来自用户查询或页面请求场景 |
Googlebot |
Google 搜索 crawler | Google 侧抓取基础是否正常 |
bingbot |
Bing 搜索 crawler | Bing 侧抓取基础是否正常 |
这里的重点不是谁更高级,而是用途不同。
PerplexityBot 和普通搜索爬虫不能直接放在同一个指标里比较。
第一步:先从日志里分组筛选
Nginx 日志可以先这样初筛:
sudo grep -Eai \
'PerplexityBot|Perplexity-User|Googlebot|bingbot' \
/var/log/nginx/access.log*
压缩日志用:
sudo zgrep -Eai \
'PerplexityBot|Perplexity-User|Googlebot|bingbot' \
/var/log/nginx/access.log*.gz
Apache 常见路径可以这样看:
sudo grep -Eai \
'PerplexityBot|Perplexity-User|Googlebot|bingbot' \
/var/log/apache2/access.log*
这一步只回答一个问题:日志里有没有这些 User-Agent token。
它不能直接回答“是不是官方爬虫”“有没有被引用”“有没有进入 AI 回答”。
第二步:用混合日志样例练判断
下面是脱敏示例,不是真实访问数据:
66.249.66.1 - - [13/Aug/2026:11:02:14 +0800] "GET /sitemap.xml HTTP/1.1" 200 23456 "-" "Googlebot"
157.55.39.1 - - [13/Aug/2026:11:04:40 +0800] "GET /products/ HTTP/1.1" 200 12033 "-" "bingbot"
203.0.113.20 - - [13/Aug/2026:11:08:09 +0800] "GET /faq/ HTTP/1.1" 200 15678 "-" "PerplexityBot"
203.0.113.21 - - [13/Aug/2026:11:10:31 +0800] "GET /products/industrial-valve/ HTTP/1.1" 200 8432 "-" "Perplexity-User"
203.0.113.22 - - [13/Aug/2026:11:12:02 +0800] "GET /private/quote.pdf HTTP/1.1" 403 128 "-" "PerplexityBot"
这组日志至少要拆成四层看:
| 观察点 | 怎么判断 |
|---|---|
只访问 /robots.txt 或 /sitemap.xml |
说明来过入口,不等于核心页面已被读取 |
访问产品页并返回 200 |
说明页面可访问,下一步看内容是否可读 |
访问隐私或报价文件返回 403 |
可能是合理保护,不要为了 SEO 放开 |
| User-Agent 看起来像官方 bot | 仍要做 IP / DNS / 官方 JSON 验证 |
第三步:把 PerplexityBot 和 Perplexity-User 分开
Perplexity 官方把两类访问分开说明。
复盘表里也要分开:
| 字段 | PerplexityBot |
Perplexity-User |
|---|---|---|
| 复盘定位 | Perplexity 搜索结果发现和链接相关 | 用户触发访问 |
| 是否当成常规 crawler | 可以作为 crawler 单独看 | 不适合当常规 crawler 统计 |
| robots.txt 口径 | 可按官方说明配置 | 官方说明里属于用户触发访问场景 |
| 外贸站重点 | 是否访问核心公开页面 | 是否访问用户正在请求的具体页面 |
如果把 Perplexity-User 和 PerplexityBot 合并,就容易误判“Perplexity 已经系统性抓取了很多页面”。
实际可能只是用户触发访问了某几个 URL。
第四步:普通搜索爬虫也要验证身份
Googlebot 和 bingbot 也会被伪造。
所以看到字符串,不等于一定是真官方爬虫。
Google 官方建议验证 crawler 请求;Bing 也提供验证工具和 IP JSON。可以把这些动作交给技术或运维。
curl -s https://www.bing.com/toolbox/bingbot.json | head
Googlebot 更稳妥的做法是按 Google 官方文档做反向 DNS / 正向 DNS 验证,或结合官方发布的 crawler IP 范围。不要把某个固定 IP 段写死到 SOP 里。
第五步:按平台生成一个简表
先做分组统计,不要先下业务判断:
sudo grep -Eai \
'PerplexityBot|Perplexity-User|Googlebot|bingbot' \
/var/log/nginx/access.log* \
| awk -F'"' '{print $6}' \
| sort \
| uniq -c \
| sort -nr
再看 URL 覆盖:
sudo grep -Eai \
'PerplexityBot' \
/var/log/nginx/access.log* \
| awk -F'"' '{print $2}' \
| awk '{print $2}' \
| sort \
| uniq -c \
| sort -nr \
| head -n 50
如果日志格式不是 combined log,这些字段可能不准。
JSON 日志、CDN 日志和安全插件日志,应该优先按字段名过滤,例如 user_agent、status、request_uri。
第六步:外贸 SEO 团队怎么分工
| 角色 | 负责看什么 |
|---|---|
| SEO | 核心 URL 清单、页面类型、是否命中产品 / FAQ / 案例 |
| 技术 | 日志字段、状态码、WAF / CDN、DNS 或官方 JSON 验证 |
| 内容 | 被访问页面是否有可读正文、参数、FAQ、案例证据 |
| 负责人 | 决定哪些页面应该公开,哪些页面必须保护 |
不要让 SEO 一个人凭日志字符串下判断。
日志识别要把页面、技术和内容放在一起看。
常见误判清单
| 看到的现象 | 不要急着判断 | 更稳妥的判断 |
|---|---|---|
PerplexityBot 访问了首页 |
Perplexity 已经引用网站 | 只是首页有访问线索 |
Perplexity-User 访问产品页 |
PerplexityBot 系统性抓取产品页 | 可能是用户触发访问 |
Googlebot 访问了产品页 |
AI Overviews 会展示这个页面 | 只能说明 Google 抓取线索 |
bingbot 访问了页面 |
Copilot 会引用这个页面 | 只能说明 Bing 抓取线索 |
状态码 200 |
页面内容一定有效 | 还要看正文、canonical、noindex 和页面质量 |
状态码 403 |
一定是坏事 | 对后台、报价文件、客户资料可能是正确保护 |
一个更稳的记录口径
可以这样写:
本周日志中分别发现 PerplexityBot、Perplexity-User、Googlebot 和 bingbot 访问记录。
PerplexityBot 主要访问 FAQ 与产品页,Googlebot / bingbot 主要访问 sitemap、分类页和产品页。
所有 User-Agent 记录仍需结合 IP/DNS/官方 JSON 做身份核对。
这些日志不能证明 Perplexity 引用、Google AI Overviews 展示或 Copilot 引用。
这类表述对老板、SEO 和技术都更友好:有证据,有边界,也有下一步动作。