Perplexity

Perplexity 是主流 AI 搜索里唯一走纯自建索引路线的产品：自研爬虫 PerplexityBot 抓取、自建索引、自家生成，答案附来源列表，学术与多源取向。这条链路决定了它的两个性格——引用池与其他引擎重合度最低，内容想被引用必须先被 PerplexityBot 抓到；引用窗口又是头部引擎里最宽的（平均约 21.9 源），对中小来源相对友好。它的知识面板直接拉取 Wikidata，实体工程在这台引擎上的回报也因此最直接。

一只爬虫就是一个引用池

多数 AI 搜索的检索底座是「自有加外部」的混合：自建索引之外再借现成搜索索引补量。Perplexity 把索引、排序、生成整条链路握在自己手里，站长要面对的入口只有一只爬虫——PerplexityBot，官方声明遵守 robots.txt，档案与验证方法见PerplexityBot。通道少不等于门槛低：自建索引的收录节奏、更新频率、去重逻辑都由它一家说了算，没有第二个可以绕行的入口；但通道唯一也让排障异常干净——先查 robots 有没有误禁，再查日志里它来没来，两步过了再看内容，断点无处藏身。

纯自建路线的代价由厂商自己扛：抓取、存储、排序的常年投入，这也是多数竞品选择复用现成索引的原因。对站长的推论是正面的——重资产玩家对索引质量的投资是长期的，你在它索引里的积累不太会被一次「换上游」清零，站方侧的长期投入更容易形成复利。

可抓取性上还有一个技术前提常被漏掉：主流 AI 爬虫不执行 JavaScript。若站点正文靠浏览器端脚本事后填充，PerplexityBot 抓到的只是空壳模板——你以为放行了，实际上什么都没交出去。正文要出现在服务端输出的 HTML 里，服务端渲染或静态生成是让爬虫真正拿到内容的第一步，技术选型的展开见SSR / SSG（服务端渲染/静态生成）。这类问题在日志里最难发现：抓取记录一切正常，索引里却没有你的内容，因为「抓到了」与「抓到了正文」是两件事。

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

与其他引擎的引用重合度数据给这条独立性提供了刻度：三引擎同题对比口径下，ChatGPT、Perplexity、Google 的引用重合仅约 2.4%，91% 的引用只出现在单一引擎；另一口径下 ChatGPT 与 Perplexity 的引用域名重合约 11%（均未复验）——见三引擎引用重合仅 2.4%。数字的读法很朴素：在别的引擎表现好，不会自动兑换成 Perplexity 的可见度；反过来，专门对它做功——放行、可达、可摘录——回报也主要落在它一家。它是「分引擎策略」这条 GEO 原则体现得最纯粹的样本。

宽窗口：中小来源的相对友好

Perplexity 的引用窗口平均约 21.9 个来源，对照 ChatGPT 的约 7.9 源与 Copilot 的约 2.5 源，是头部引擎里最宽的一档（Semrush 口径，未复验），量级差见引用窗口：ChatGPT 平均引 7.9 源。宽窗口改变竞争结构：窄窗口近似零和，多进一个就挤掉一个；宽窗口里长尾来源有真实席位，「在某个具体问题上足够好」的内容能以长尾身份进入答案，不必先成为大域。

这给中小站点指了一条务实的路：为 Perplexity 做一批窄而深的问答型内容，不求覆盖大词，只求在具体子问题上成为最优解。配合它学术与多源的取向，带出处、可核验、结构化的内容在窗口里更有竞争力——每个小节自含可懂、结论前置、引用谁的数据写明谁。被引用的门槛从「域名权威」往「单题最优」移动，这是宽窗口引擎给弱者的结构性让利。

窗口宽也要防误读：宽窗口说的是席位数，不是保证——窗口再宽，头部域名仍然占据显要位次，长尾席位对应的是长尾问题。指望一条普通内容挤进热门问题的宽窗口，与指望它排进搜索首页没有区别；宽窗口的红利只对「问题匹配精准」的内容兑现。

学术与多源取向还给了内容方一个可复用的写法模板。Perplexity 的答案带来源列表、行文接近综述体，这暗示它对「综述友好型」内容的亲和：有明确的问题陈述、有分维度的对比、有可核验的出处、有克制的结论。写产品对比就老实分维度列表，写方法就给步骤与边界条件，写观点就标注依据来自谁——这类内容在它的切块与摘录两端都占便宜。反过来，「营销话术密度高、事实密度低」的内容在宽窗口里也抢不到席位，窗口宽竞争的维度就多，每一维都要拿事实说话。

Wikidata 是它的实体口径

Perplexity 的知识面板拉取 Wikidata，这使它成为实体工程回报最直接的引擎：你在 Wikidata 里的条目，很可能就是它眼中「官方版本的你」。实体层的动作沿图谱展开——确认品牌的中文名、英文名、简称、旧名都挂在同一实体下，标签与别名齐备；检查关联实体（母公司、子品牌、核心产品）没有错挂；官网的规范名称与结构化数据把官方口径立住。方法展开见知识面板（Knowledge Panel）。

实体工作的失败模式不是没有条目，而是条目对不上号：同名品牌共用或错挂实体，答案就会张冠李戴；中英双名没建立别名关系，两种问法得到两套答案。自查的方法朴素——把品牌的各种名称变体分别拿去问，看每次被介绍的是不是同一个「你」。这层工作在 Perplexity 上的可见回报最快，做完对其他引擎同样是净收益，实体消歧的机制背景见实体消歧（Entity Disambiguation）。

放行、验证与监测

配置侧的第一件事是给 PerplexityBot 写显式放行组——具名爬虫组不继承通配组，全站有禁令时必须单独开组。第二个名字要一起记住：Perplexity-User 是用户触发型，官方明言一般忽略 robots.txt，用户在对话里点名你的页面时它照样会实时抓取。因此对这个引擎不存在彻底的「全有」或「全无」——robots 只能管索引层那扇门；想管用户层，正确的工具是服务端鉴权与内容策略，不是 robots。

声明的遵守要用日志实证。UA 字符串可以伪造，厂商声明也只是口径，可靠的证据是自己的访问日志：按 UA 过滤出候选请求，再对照官方公示的 IP 段核对，未匹配的残量单独归档观察。排查「抓了但不被引」时，顺序是先结构后内容——robots、日志都通了，再去研究同题下被引页面长什么样，跳过前两步直接改内容是常见的无效投入。

监测侧它给出了一条少见的便利：Search API（Sonar 系列）可用，引用监测可以 API 与网页端并行。但两套口径有差异，不能并表混比——API 用于批量探针与趋势，网页端用于确认「用户真实看到的答案」，两轨分开记账。改版或更新后给自建索引一点回访耐心，把「改了没效果」的结论建立在多轮观察上，而不是一两天之内。

双轨并行时还有一条采样纪律：同一问句在两轨的提问时间要靠近，避免把时间差误读成口径差。Perplexity 的宽窗口让长尾名单天然多变，判断「内容改造有没有效果」不能看单次名单，要看目标域名在多轮采样里的进入频率——频率稳定上升才是真信号，偶发进入只是窗口宽度的噪声。