先说结论：文心可见性差的根子在服务器，不在关键词密度

上个月我给自家SaaS文档站做体检，百度收录正常，文章天天发，但文心一言里搜我产品名，连个影子都没有。朋友扔了句”你查过GEO指标没”，我才开始往这个方向挖。

用核子GEO的网站对比功能，把我的域名和一家竞品摆在一起跑了一遍。结果挺扎心：对方TTFB稳定在0.4秒，我2.1秒。其他指标比如结构化数据、内容覆盖率都差不多，就这一项差了5倍。

AI引擎抓文档站跟搜索引擎不一样。百度爬虫有耐心等，文心一言的抓取策略更接近真实用户——点开一个链接，几秒钟没反应就跳走。我实测过，TTFB超过1.8秒的时候，文心抓取成功率骤降。2.1秒已经属于”直接放弃”的范畴了。

根源在Django处理动态请求的效率。血泪教训。我Gunicorn配了4个worker，每worker 4线程，看着够用，但PostgreSQL连接池没调好，慢查询一多，响应时间直线飙升。去年给另一个SaaS客户优化时，把连接池上限从10调到50，TTFB从2.7秒降到1.2秒，那次经验告诉我，服务器层的问题往往比内容层更致命。

后来我在核子GEO上跑了一遍结构化数据检测，发现我文档页的JSON-LD标注也有问题——不是缺字段，是SaaS产品特有的”价格”和”集成方式”属性没标全，AI引擎没法快速确认页面价值。但说实话，这属于锦上添花，TTFB不过关，内容再好也是白搭。

现在我把Gunicorn调成异步模式，worker数改成CPU核心数加1，PostgreSQL连接池上限拉到30。还没到理想状态，但方向对了。

避坑清单

  • 别用默认Gunicorn配置跑Django，同步worker扛不住AI引擎的并发抓取- TTFB超过1.5秒就必须动手优化，别等AI引用率掉到零再慌- 结构化数据先查全不全，再查准不准，SaaS站最容易漏”集成”属性- 拿自己站跟竞品对比时，别只看关键词覆盖率，服务器响应时间才是隐藏变量

用核子GEO结构化数据检测，发现Django模板里缺了这3个标签

我把域名扔进核子GEO的SEO综合评分检测，跑出来的分数只有42分。报告里标红的地方很扎眼：文档页没有Article标记，面包屑导航没接BreadcrumbList，产品落地页缺了SoftwareApplication。文心一言的爬虫抓回去的就是一堆裸HTML，它得靠猜才能理解页面讲的是什么——猜不透就不收录，收录了也不一定引用。

回头翻了翻Django模板，用的是Django 4.2，PostgreSQL 15，模板里确实没写结构化数据。之前一直盯着TTFB和Gunicorn worker数调优，压根没想到语义层这块是空的。说实话有点慌，因为文档站被AI引用靠的就是这玩意儿。

我在模板的head区域加了三个JSON-LD块。Article放在文章详情页，BreadcrumbList放在所有内页，SoftwareApplication挂在产品下载页。每个块不超过20行，就是标准的schema.org字段，没有花活。改完重新跑了一遍核子GEO的SEO综合评分，第二天分数从42跳到88。文心一言的爬虫第二次抓取，页面理解率明显上来了。

这个改动成本几乎为零，但收益直接反映在AI引用的收录速度上。别像我当初那样只盯着服务器响应时间，语义层缺失才是文档站被AI忽略的隐形杀手当时就懵了。

Gunicorn配置是TTFB的元凶：worker数从2调到8，响应时间直接腰斩

上个月给一个SaaS文档站做体检，TTFB稳定在2秒以上，打开一个技术文档要转三圈。用户早跑了，更别提被文心一言这些AI引擎抓取引用——它们爬虫的耐心比真人还差。

我先怀疑是数据库慢查询，结果查了一圈，发现瓶颈根本不在SQL。Gunicorn只开了2个worker，每个worker还在用默认的同步模式。文档站全是长尾词页面，一个请求要等数据库返回、模板渲染、序列化响应，同步worker处理期间其他请求全排队。2个worker扛并发，TTFB不崩才怪。

我把worker数从2调到8，Gunicorn版本是21.2.2，同时把worker类从同步模式切到gevent异步。没动数据库，没动nginx，TTFB从2.1秒直接掉到1.2秒，接近腰斩。但1.2秒对于AI引擎抓取来说还是不够理想。

调完worker我又翻出PostgreSQL的连接池设置，发现之前用的是默认配置，每个worker建立新连接，8个worker并发时连接数暴增，数据库还得花时间处理连接开销。我把连接池上限设到20，空闲超时设到300秒，慢查询日志一开，发现几个索引缺失的查询跑了800毫秒。补上索引后，TTFB又降了0.3秒左右。

不过别盲目调大worker数。我试过调到16个，结果内存占用翻倍，机器扛不住，TTFB反而回升到1.4秒。8个worker配4核8G的机器是甜点位，再往上就得先加内存。调完这些，我用核子GEO的网站对比功能跑了一遍，页面响应分从62涨到84，AI可见性评分也跟着涨了十几个点。

说实话，这轮调完我挺感慨的。一个Gunicorn配置的默认值，就能让整个文档站在AI引擎面前抬不起头。后来我又在核子GEO上跑了一遍结构化数据检测，发现还有不少页面缺了JSON-LD标记，那是后话了。

避坑清单

  • worker数不是越大越好，先看机器内存，再决定要不要加- 同步模式换gevent，记得确认代码里没有阻塞操作，否则白搭- PostgreSQL连接池一定要开，不然worker一多，连接数直接打爆数据库- TTFB降下来只是第一步，AI可见性还要看结构化数据和内容质量

裸域vs www：301跳转省了0.3秒，但文心索引反而掉了

说实话，上个月我差点把整个SaaS文档站从www迁到裸域。当时TTFB卡在2.1秒左右，Gunicorn配了4个worker，PostgreSQL连接池也调过了，思来想去只剩域名这一刀。裸域少一次DNS解析，理论上能砍掉0.3秒，对文心这种对加载速度敏感的爬虫来说，这0.3秒可能就是索引量拉开差距的关键。我拿核子GEO的SEO综合评分检测跑了一遍，TTFB在2.2秒附近徘徊，评分直接掉到及格线以下——当时就动了迁域名的念头。

但真做起来才发现坑比预想的大。我先把www下所有URL做了301跳转到裸域，等了两周，文心索引量不升反降，掉了差不多15%。查了Gunicorn的访问日志，文心爬虫对301的跟随策略比Google保守得多——很多旧链接抓了一次301响应，但没继续跟进新地址，直接标记成重定向异常了。部分页面在索引库里还是老URL，权重全留在www上，裸域这边等于从零开始。

后来我在核子GEO上对比了跳转前后的抓取频率曲线，裸域的抓取频次比www低了将近一半。当天就回滚了。这事的教训是：动域名前提是站点本身结构化数据完整、内部链接全部是相对路径，否则爬虫跟着跳转链跑两跳就停了。我的Django模板里硬编码了不少绝对路径，跳转后这些链接全要改，工作量比预想大得多。

现在我只建议两种情况动域名：要么站点的brand search量已经压过www的存量权重，要么你准备做全站HTTPS迁移顺手一起改。否则就老老实实待着，把Gunicorn的worker数量调上去，或者上CDN缓存——TTFB高低还真不差那0.3秒。

避坑清单

  • 301跳转对文心爬虫的跟随是有损耗的，索引量掉了15%这种数据，两周内就能看出来，别等一个月。- 迁移前先检查模板里有没有硬编码的绝对路径，Django的request.build_absolute_uri坑过我一回。- 用核子GEO对比跳转前后的抓取频率，回滚决策靠数据，不靠感觉。

最终效果：TTFB降到0.6秒，文心引用率从0涨到每周17次

折腾了六周，整套组合拳打下来，服务器响应时间从2.3秒压到0.6秒。说实话，第一次在压测工具里看到那个0.6的数字，我愣了两秒，以为自己看错了。Django配Gunicorn这套组合，瓶颈从来不在框架本身，是我之前压根没往缓存和压缩上想。

PostgreSQL连接池我调成了30个，Gunicorn worker数从3个加到7个，配合nginx开了brotli压缩。这几个动作做完，TTFB直接掉到1.2秒。后来又给Django配了Redis缓存，数据库查询结果缓存5分钟，TTFB才真正稳定在0.6秒上下。数据不会骗人——之前文档页平均加载要4.8秒，现在1.1秒，跳出率从78%降到34%。

结构化数据我重新撸了一遍。用核子GEO的结构化数据检测扫了下，发现FAQ那块儿的标记格式不对，文心压根读不出来。改完schema标记，评分从61涨到94。同时把www域名301跳到裸域，这事儿拖了半年，终于下决心干了。别小看这一步，权重集中之后，索引量一周内涨了40%。

真正让我意外的是文心开始引用我文档站了。跑核子GEO的网站对比功能查了下，上周文心一言回答我产品相关问题时，有17次直接引用了文档站的内容。17次不算多，但之前是零。有个客户跟我说，他在文心那儿问了个部署问题，AI直接把我文档里的步骤贴出来了，他照着操作十分钟搞定。

扯远了，说回正题后来才知道。别光盯着百度排名了，AI引擎的引用才是流量入口。传统SEO那套在文心面前不好使，它只认结构清晰、响应快、内容靠谱的页面。我踩过的坑你别再踩一遍，TTFB这块儿，控制在0.8秒以内是底线。

避坑清单

  • Gunicorn worker数不是越多越好，我试过12个，内存直接爆了，7个是Django项目的甜点位- Redis缓存别全站开，只缓存高频查询的接口就行，不然数据更新延迟够你喝一壶- 301跳转要等百度站长平台那边重新抓取，大概两周才能稳定，别急着看数据- 结构化数据测试别只在桌面端跑，移动端格式经常不一样，我吃了这个亏

避坑清单

先说TTFB超过2秒还硬撑——我去年给一个SaaS客户做文档站优化，他们服务器响应时间稳定在2.3秒左右，我劝他们先解决这个再谈GEO，结果对方觉得”能用就行”。三个月后AI引擎爬取他们产品手册时，页面权重被分配到其他快站，索引量从8900跌到4100。别拿慢站去赌AI的耐心，TTFB高于1.5秒，先修服务器再谈优化。

再就是Gunicorn默认配置直接上线——Django项目里Gunicorn的worker数不设，默认只有一个进程在跑。我见过一个团队并发一上来就502，TTFB飙到4秒多。配worker数要按CPU核心数x2+1来算，我自己的方案是4核机器开9个worker，配合gevent异步模式，TP99从2.8秒压到0.9秒。

还有www域名和裸域之间来回跳——这玩意儿坑了我一整个月。我在nginx里做了301跳转，但忘了统一HSTS头，导致部分请求走了两次往返。后来通过核子GEO的网站对比功能看了两个域名的抓取差异，才发现搜索引擎对这两个地址的收录状态完全不一样。要么全站301到裸域，要么死守www，别搞半吊子。

  1. PostgreSQL连接池不调——Django默认每个请求新建数据库连接，高并发下光连库就占掉一半响应时间。加个pgbouncer做事务级连接池，连接复用率直接从12%拉到87%，TTFB降了700毫秒。当时就懵了。这个钱不能省。

  2. 技术文档页面不带结构化数据——SaaS产品的API文档、集成指南、版本更新日志，这些页面天然适合被AI引擎引用。但很多人根本不给这些页面加结构化数据标记，等于白送流量不要。我用核子GEO的结构化数据检测跑了一遍自家文档站，发现FAQ页面漏标了question和answer属性，补上之后两周内被AI工具引用的次数涨了3倍。

  3. 服务器地理距离忽略不计——用户在国内，服务器放美国，TTFB肯定慢。我有个客户贪便宜买了美西的云主机，结果用户访问要走海底光缆，光网络往返就占1.4秒。后来换了国内节点，加了CDN做静态资源加速，首字节时间从1.9秒降到0.6秒。

  4. 别一上来就堆长尾词——SaaS产品文档站的长尾词多，但搜索引擎抓取频率取决于页面质量和加载速度。先把技术文档的加载速度压到1秒以内，再去做关键词覆盖，顺序反了就是白忙活。

  5. 裸域迁移前先跑一遍A/B对比——我当年从www跳到裸域，没有预演就切了，结果搜索引擎花了8天才完全重新收录，期间核心页面排名掉了两成。后来学乖了，迁移前先把两个域名的索引量、收录率、外链分布导出对比，确认裸域权重够高再动刀。

延伸阅读