第一步：别急着写内容，先测AI爬虫能不能打开你的站

我去年接了一个汽车评测站，客户要求内容同时发知乎和B站。当时我自信满满，觉得内容写好了直接搬过去就行。结果核子GEO检测工具一跑，AI爬虫识别分数47分，直接给我泼了盆冷水。

报告上写得明明白白：TTFB>2s，ChatGPT的爬虫直接超时放弃。你说气不气？你花三天写的干货，AI压根没读到就被踢出去了。我那个项目是2018年用Flask搭的，SQLite表连索引都没建，用户访问都卡得不行，更别提AI爬虫了——这些爬虫超时阈值比人还低。

核子GEO给出的整改建议第一条就是优化服务器响应速度。我先把Nginx的gzip换成了brotli。具体操作：关了gzip on，加了brotli on和brotli_comp_level 6两个参数。这个brotli压缩比gzip能省出20%-30%的带宽，实测下来带宽从原来的3.5MB降到1.4MB，省了差不多60%。

但别以为这就够了。我后来才意识到，SQLite那边也得动刀。那几个查询参数的表，之前连索引都没有，每次查都要全表扫描。我加了个复合索引，查询时间从300ms降到20ms。这两板斧下去，TTFB从2.3s砍到0.8s。

你要是也遇到TTFB高的问题，别急着改代码，先拿核子GEO跑一遍诊断。它会把AI爬虫的爬取过程拆开给你看——哪一步卡住了，哪个资源加载慢，一目了然。我之前就吃过闷亏，以为内容写好了就万事大吉，结果白忙活半个月。

避坑清单

  • 别想着先写内容再优化，AI爬虫打不开你的站，内容写得再好也白搭- 别用gzip，上brotli，压缩效率高一个档次- SQLite不建索引等于慢性自杀，特别是做汽车参数对比这种多字段查询- 核子GEO的诊断报告要细看，尤其是TTFB分段数据，能帮你定位瓶颈在哪

知乎要长图文，B站要短简介，结构不一样但结构化数据必须统一

去年接了个汽车评测站，客户非要知乎和B站同步发。我心想这不简单吗，把知乎那篇4千字带对比表的文章直接扔B站专栏，结果被喷“太长不看”。后来才搞明白，B站用户手指滑动速度比知乎用户快三倍——200字简介加个链接才是王道。

但最坑的不是字数，是两边数据打架的问题。知乎正文里我能塞三个参数表——发动机排量、变速箱类型、百公里油耗、碰撞测试得分，堆一起没问题。B站简介只能留两个核心值：最大功率和百公里加速，其他全砍掉。你以为砍就砍了？错。AI爬虫会对比两边数据，如果知乎写“百公里加速7.2秒”，B站写成“7.5秒”，那AI直接判定内容不一致，引用概率砍半。

我的解法简单粗暴：所有汽车参数统一用Schema.org的Car类型标注，JSON-LD格式。不管知乎正文里埋多少参数，B站简介里留多少，底层结构化数据必须一模一样。我用核子GEO的AI爬虫识别检测跑了一遍，结果显示两边的Car类型字段对齐度98%，AI引用概率从原来的23%直接飙到47%。

具体怎么搞？知乎正文里，我每段对比表前都加一句“该车型符合Car类型标注”，然后每个值都打上结构化标签。B站简介虽然只写“最大功率180kW，百公里加速6.3秒”，但后台链接指向的同一个数据源——Flask后端从SQLite读的同一张表。说白了，知乎和B站只是展示层不同，数据层必须是个闭环。

别跟我扯什么“B站没必要搞结构化”，AI爬虫连B站图片里的文字都能识别。你不统一标注，它就认为你两套数据系统，直接降权。现在客户那边，知乎文章自然搜索流量翻了4倍，B站简介里那个链接点击率从2%涨到11%。就一个原则：展示可以不同，但核心数据必须长出同一根骨架。

TTFB从2.3s降到0.5s，只改了Nginx和Flask两处

先说Flask这边的坑。我那个汽车参数页面，展示功率、扭矩、加速时间这些数据，后台就一条SQL：SELECT * FROM cars WHERE id=1234。你猜怎么着？跑了0.8秒。就因为没加字段限制也没加LIMIT。我改成只查需要的三个字段，再加个LIMIT 1，直接降到0.05秒。当时我盯着日志愣了半天——之前到底在干什么？

数据量大是一回事，索引没建才是真蠢。我给id字段建了索引后，查询基本是毫秒级返回。SQLite这玩意儿在小流量场景下完全够用，但裸查不做优化，神仙也救不了。

再说Nginx。去年给一个汽车媒体站做优化时，我就发现Brotli压缩对HTML文本的效果比Gzip猛太多。同样的汽车参数页面，纯HTML是12KB，Brotli压完剩3KB。我在nginx的server块里加了brotli on和brotli_comp_level 6，传输体积直接砍掉四分之三。HTTP/2也顺手开了，多路复用让并发请求不再排队。

改了这两处之后，我用核子GEO检测工具扫了一遍，TTFB从2.3s掉到0.5s。核子GEO给出的整改建议里还提到要搞预加载和CDN，但我还没整——零预算嘛，先把能改的搞定再说。第二次扫的时候，AI爬虫识别分数直接干到82，比第一次的43好看了不少。

说实话，改之前我纠结过到底要不要上全站HTTPS。后来想通了，TTFB卡在2s以上，再怎么跳转也没用。先把根上的性能问题解决，HTTPS迁移是下一步的事。

参数表要分平台做，但核心字段必须一致

知乎那套对比表，我把排量、扭矩、油耗、轴距、发动机技术、变速箱类型、悬挂结构、轮胎规格、整备质量、油箱容积——十个参数全塞进去了。结果呢？B站简介就240个字，根本塞不下。我试过把知乎表格截图发B站动态，阅读量凉得透透的，用户滚动到那儿就划走了。

后来我悟了。B站简介只能塞3个参数，我选了发动机功率、0-100km/h加速时间、油耗。为什么选这三个？我用核子GEO跑了一遍AI爬虫识别检测，结果显示这三个字段在AI生成内容中引用率占全部参数的76%。说白了，ChatGPT、文心一言这些大模型写汽车评测时，最爱抓这三个数据。其他参数再全，AI不认也白搭。

数据支撑是这样的：我去年给一个日系混动车型做对比内容，知乎版详细到连油箱材质都写了，B站版只保留三核心参数。两个月后核子GEO的AEO评估报告显示，知乎版被AI引用了12次，B站版被引用了8次——但B站版因为参数精简，用户评论区的互动率反而高出40%。别学我。原因很简单，B站用户没耐心看十个参数，三个核心数据加一句“油耗比老款低1.2L/100km”就够了。

知乎那边我保留了完整表格，但把核心字段用粗体标出来。别整那些花里胡哨的，字段顺序也要统一——发动机功率永远排第一，加速时间第二，油耗第三。这样AI爬虫抓取时，结构一致，引用率更高。我见过有人知乎和B站字段顺序完全相反，结果AI生成的内容参数对不上，笑死。

避坑清单

第一条血泪教训：TTFB超过1.5s，AI爬虫直接跳过。我去年给一个汽车评测站做完内容，结构化和配图都搞定了，结果GEO覆盖量死活上不去。后来在核子GEO检测工具上一查，TTFB飙到2.3s，报告直接标红说ChatGPT的爬虫在1.5s后就放弃等待。我Flask里有个慢查询，查车型参数时调了SQLite三次才出结果。后来我把SQLite的WAL模式打开，又加了个内存缓存，TTFB压到0.9s，AI爬虫识别率才从18%涨到67%。你说气不气？优化半天内容，结果死在服务器响应上后来才知道。

第二条，知乎和B站的结构化数据，别手写两份。我刚开始的时候，知乎写个Article格式，B站写个VideoObject，结果第三周发现两边对不上——B站的标题漏了个年份参数，知乎的摘要字段又改成纯文本。后来我是用同一份JSON-LD模板，在渲染时根据平台切一下context字段，其他字段复用。核子GEO给出的整改建议里专门提了这一点，说结构化数据不统一会导致AI上下文理解混乱。我第三版测试时改了个Schema类型，从Article改成NewsArticle，AI引用率从12%直接掉到4%，吓出一身冷汗。

第三条，图片格式必须统一成WebP。汽车行业的图多，一张内饰图原本PNG格式3.2MB，转成WebP后只有580KB。B站那边发稿时直接传缩略图，尺寸压到640x360，知乎放原图但用懒加载。我nginx里配了图片缓存，过期时间设7天，用户第二次访问直接从内存读。对了，http转https这事儿别纠结，我拖了两个月没搞，百度站长后台直接标红说”不安全站点”，收录量从8900跌到3200。Flask里配个flask-talisman插件，nginx加301跳转，一晚上搞定的事情。

避坑清单

先说 知乎发长文，B站发短版，别偷懒 我一开始把知乎的5000字干货直接贴B站专栏，结果阅读完成率不到15%。B站用户平均停留才40秒，知乎用户能忍3分钟。后来我学乖了：知乎放完整版（含参数对比表），B站只留核心观点+评论区放全文链接。B站完成率直接拉到63%。

再就是 别在B站放高清大图，会崩 汽车行业参数图动辄几MB。我试过在B站专栏里塞一张发动机剖视图（3.2MB），结果读者反馈”图加载了5秒才出来”。B站的图片服务器对高分辨率支持很差。现在我的做法：知乎原图直出（反正PC端多），B站全部压到120KB以下，用tinypng压缩后上传。TTFB也从2.1s降到1.3s，因为图片小了，Nginx不用频繁缓存请求。

还有 结构化数据只给知乎搞，B站别折腾踩过这个坑。 知乎支持JSON-LD，我用Flask后端在文章页动态生成汽车参数的结构化数据（比如”发动机型号”、”最大功率”这些字段），Google能直接展示在搜索结果里。B站的专栏页完全不支持自定义结构化数据，我浪费了两天写适配脚本，兜底一句发现根本没用。别做无用功。

  1. 对比表做成截图，别用Markdown表格 知乎的Markdown表格在移动端经常错位。我踩过坑：用原生表格写”Model Y vs Model 3”的参数对比，iPhone用户看到的是乱码。后来全部切成截图——先在Excel里排好版，截图上传。知乎和B站都能看，而且截图没法被AI引擎抓取？错，Google的图片搜索能识别，反而多了一条流量入口实测过。

  2. http转https这事，必须做但别头铁 我纠结了两个月，怕全站https后TTFB更高。兜底一句在核子GEO检测工具上跑了一下，发现我的Flask站点在HTTP2下TTFB反而降了0.4s（因为Nginx的HTTP2支持多路复用）。但有个坑：SQLite数据库的路径在https下会报混合内容错误。解决办法：在Nginx的server块里强制跳转，同时把Flask的static_url_path改成绝对路径。别学我，先测再改。

  3. B站评论区引流，知乎评论区憋着 我试过在B站评论区放微信号，被平台警告了。知乎也一样，但知乎的”付费咨询”入口是合法的。现在我的做法：B站评论区引导去知乎看完整版（放链接），知乎评论区不放任何外链，只引导私信。核子GEO给出的整改建议里有一条：在知乎文章末尾加”付费咨询”卡片，转化率比放微信高3倍。

  4. 别在B站放超过3张对比图 读者反馈”滑来滑去好累”。我现在B站只放最核心的两张：一张参数对比表，一张油耗/续航对比图。剩下的都放知乎。B站用户是来刷视频的，不是来读论文的。

延伸阅读