# WordPress 日志里的 Perplexity 请求，先分清它来做什么

- Author: REBASE-SG
- Published: 2026-11-01 09:56:26
- Modified: 2026-11-01 09:56:26
- Canonical URL: https://rebase-sg.com/perplexity-request-roles-wordpress-access-zh/

---

后台看到一次带有 Perplexity 名字的请求，能说明什么？它可能与搜索发现有关，也可能是有人在提问时触发了一次页面访问。若先把两者合成“AI 爬虫来了”，后面关于收录、引用和流量的判断，就少了一个重要前提。



本文是依据当前官方说明写的实用分析，不把文档内容当成今天的新功能公告。Perplexity 的爬虫文档区分了两种角色：PerplexityBot 用于在其搜索结果中发现并链接网站；Perplexity-User 支持用户操作所触发的访问。文档还说明，后者通常不遵循 robots.txt，因为访问由用户请求触发。



封面将这两类用途并列：搜索发现对应 PerplexityBot，用户触发访问对应 Perplexity-User。这是根据文档绘制的角色示意，没有展示本站日志或一次实际抓取测试。



先问这次请求拿到了什么



对 WordPress 站长，比“有没有 AI 来过”更值得查的是：哪一类请求，在什么时间，访问了哪一个公开页面，最终得到什么响应。若有人希望 AI 帮忙阅读安装指南，而请求停在错误页或验证页，正文写得再完整，也没有解决这一次访问的问题。



但浏览器能打开页面，也不足以证明另一个客户端拿到了同样内容。不同访问可能经过不同缓存、规则或会话状态。排查应围绕具体请求展开，不宜仅凭一次浏览器成功，就认定所有问题都在对方平台。



可以先选择一篇确实希望公开阅读的安装说明，记录它的准确 URL 和问题发生时间，再去查对应的服务器或安全事件。保留响应状态、命中的规则以及请求来源核验结果。若没有找到对应事件，就把这一点留空，不要用猜测补齐。



来源核验也有细节。Perplexity 的同一份文档为两个角色分别提供 IP 地址来源，并在 WAF 示例中组合使用各自的 User-Agent 与地址范围。对站长来说，这意味着不能只看到请求头里有个熟悉名字，就认定身份已经验证。本文不复制一份会过期的地址清单，配置前应读取当前官方来源。



robots.txt 与实际访问权限各有工作



RFC 9309明确说明，robots.txt 规则不是访问授权。它可以表达抓取偏好，却不负责让登录后的资料变成私密内容，也不能替代服务器处理实际请求的规则。



因此，想让公开教程更容易被读取，应先确认访问失败发生在哪一层，再决定是否需要改规则。若日志确实指出某条规则拦住了你希望允许的请求，就围绕那条规则评估调整范围。不要为了排查一个 URL，一次性改变全站的防护策略；也不要把“允许访问”写成“保证引用”。



如果页面包含客户信息，问题则变成谁有权阅读它。这个决定应落在身份验证和授权上，不能依赖工具会不会遵循某个 robots 标签。对于公开文档，访问检查与内容编辑可以分别进行；对于私密资料，先把权限边界确定下来。



一次排查的结果，可以具体到“某个已核验请求在某个时间访问这个 URL，得到某个响应”。这样的结论足够支持下一步维护。至于它是否会成为搜索来源、有没有带来读者或安装，还需要另外的观察，不能从请求名称里直接推出来。



English: Reading Perplexity requests on a WordPress site.