PerplexityBot PerplexityBot

PerplexityBot 是 Perplexity 的自建索引爬虫，也是其引用池的唯一官方入口：Perplexity 不依赖 Bing 之类的外部搜索索引，内容想被它引用，前提是先被 PerplexityBot 抓到、进入它的自有索引。它声明遵守 robots.txt，站长对它拥有实际控制权——这一点与同厂另一个抓取程序 Perplexity-User 形成鲜明对照。

纯自建索引：一只爬虫就是一个引用池

主流 AI 搜索的内容供给各有底座：有的深度依赖现成搜索索引，有的自有与外部混合，Perplexity 则走纯自建路线（机制详见Perplexity 引擎卡）。这决定了它与其他引擎的引用重合度天然偏低——站内转述的对比口径里，Perplexity 与 ChatGPT 的域名重合约 11%（见三引擎重合数据卡），在头部引擎中处于最低一档。

对内容方的含义很直接：在别的引擎表现好，不会自动兑换成 Perplexity 的可见度；反过来，专门针对它做功——放行抓取、保证可达、维护可摘录的内容结构——回报也主要落在它一家。它是把“分引擎策略”这条 GEO 原则体现得最纯粹的引擎。

与依赖外部索引的引擎对照更能看清这条链路的特殊性。ChatGPT 搜索的引用池有双入口——自家检索爬虫加底层搜索索引的收录，站长要同时伺候两条通道；Perplexity 把索引、排序、生成整条链路握在自己手里，站长只需要面对一只爬虫。通道少不等于门槛低：自建索引的收录节奏、更新频率、去重逻辑都由它一家说了算，你没有第二个可以绕行的入口（双入口引擎的对照见OAI-SearchBot 术语卡）。

自建索引还带来一个常被低估的友好面：引用窗口宽。Perplexity 的答案平均引用约 21.9 个来源，明显宽于窄窗口引擎（见引用窗口数据卡），长尾与中小来源进入答案的机会相对更多。想吃到这个窗口，前提仍然是先被抓到。

这对中小站点是个相对友好的格局。窄窗口引擎里，头部域名占据大半引用席位，新来源很难挤进去；宽窗口加自建索引，意味着只要内容在某个具体问题上足够好，就有机会以长尾身份进入答案。实践中值得专门为 Perplexity 做一批窄而深的问答型内容——不求覆盖大词，只求在具体问题上成为最优解。

顺带一句成本语境：纯自建路线并不轻松——自建索引意味着持续的抓取、存储与排序投入，这也是多数厂商选择复用现成搜索索引的原因。理解各家“轻重资产”的差异，有助于预判它们内容供给政策的稳定性：重资产玩家对索引质量的投资是长期的，站长侧的长期投入也更容易形成复利。

PerplexityBot 与 Perplexity-User：一对必须分清的名字

两个名字对应两类完全不同的抓取行为，混淆它们是站长侧最常见的配置错误。PerplexityBot 为自建索引服务，官方口径声明遵守 robots.txt，放行与禁令对它有效。Perplexity-User 则是用户触发型抓取：用户在对话中要求读取某个页面或实时信息时，它代表用户去抓，官方明言一般忽略 robots.txt——此时执行的是用户的即时意图，而非平台的索引意志。三型爬虫的完整框架见爬虫三型术语卡，遵守与否的总体格局见robots.txt（AI 语境）。

因此“我在 robots 里禁了 Perplexity，为什么答案里还看得到我的页面”这类疑问，多数的答案是：禁令拦住了索引爬虫，拦不住用户触发抓取。想控制后者，robots 不是正确的工具，服务端鉴权、登录墙与内容策略才是。

还有一个方向相反的推论同样成立：放行了 PerplexityBot，也拦不住它家用户触发抓取带来的引用；反过来禁了它，被动索引的入场券作废，但用户在对话里点名你的站点时，页面仍可能被实时抓走并引用。也就是说，对这个引擎不存在彻底的“全有”或“全无”——索引层与用户层是两扇独立的门，robots 只能管其中一扇。想清楚自己要哪一层，再决定写什么。

风波之后：用日志实证代替信任声明

2025 年 Cloudflare 曾公开指认 Perplexity 存在绕过 robots 屏蔽的抓取行为，引发一轮“声明遵守是否等于实际遵守”的争议。我们不复述事件细节，只提炼给站长的教训：UA 字符串可以伪造，厂商声明也只是口径，唯一可靠的证据是自己的访问日志——核对请求是否来自官方公示的 IP 段、行为是否符合爬虫档案，再决定放行或封禁。完整的真伪验证方法见技术规范栏（P2 上线）。

日志实证的另一层价值是区分“没来抓”与“抓了没引”。排查 Perplexity 可见度问题时，顺序应当是：先确认 robots 未误禁、服务器未误拦；再在日志里确认 PerplexityBot 确实到访过目标 URL；最后才轮到内容侧分析（切块结构、即答段、出处标注）。跳过前两步直接改内容，是常见的无效投入。

抓到只是入场券：从索引到引用

被抓取意味着进入候选池，不等于进入答案。答案侧的选择遵循生成式引擎的通用机制：检索按语义相似度取回内容块，生成端再依据语义支持度、权威信号与位置倾向决定转述谁、引用谁。提高“被抓到”到“被引用”的转化，靠的是内容基本功——每个小节自含可懂、结论前置、出处清晰、可整段摘录。

给本站用户的行动清单可以压缩成三句话：robots 里给 PerplexityBot 留出明确的放行组；用日志确认到访与抓取节奏，顺带识别伪装流量；把内容改造成适配宽引用窗口的形态——结构化、可摘录、带来源。三件事按顺序做，前一件没确认，后一件先缓。

站长侧的配置与排查顺序

把上面的讨论压成一份可执行清单。第一步，robots 里写一个显式的 PerplexityBot 组，明确放行，不要依赖通配组的默认行为——具名组只看自己，这是配置语义的硬规则。第二步，在服务器日志里按 UA 聚合观察它的抓取节奏：来的频率、抓的路径深浅、新旧页面比例。抓取节奏直接反映你在它索引里的存在感，长期零到访就是最高优先级的问题。第三步，确认关键内容对纯文本抓取可见——正文要出现在服务端输出的 HTML 里，而不是靠浏览器端脚本事后填充；爬虫拿不到的正文，索引里就不会有。第四步，改版或更新后给一点耐心，自建索引的回访有周期，把“改了没效果”的结论建立在多轮观察上，而不是一两天之内。

排查“抓了但不被引”时，顺序同样是先结构后内容：同题页面在别的引擎是否被引、被引的段落长什么样、自己的页面是否缺即答段与出处。生成式引擎的引用偏向可摘录的事实块，这是站内反复验证过的方向，不值得为单一引擎发明另一套玄学。

监测这个引擎时还有一条口径提醒：Perplexity 提供搜索类 API，但 API 的回答与网页端用户看到的答案存在口径差异——检索范围、界面呈现、会话上下文都可能是变量，两套数字不能互换。做趋势与竞品分析时固定一套采集面，要么都走 API，要么都走网页端；把两套数字混在一张表里，波动归因会立刻失真。我们的纪律是“用户看到什么就采什么”，这在各家引擎上都适用。

另外，抓取节奏还与内容更新频率耦合。长期不更新的站点，回访自然稀疏；持续产出与更新的站点，爬虫会更勤地回来核对。想让引擎知道你的内容在维护，最直接的信号就是维护本身——这比任何提交动作都可靠。