血泪开端：花900块买的Vercel Pro，TTFB反而飙到3.5s
去年十月，我咬牙上了Vercel Pro计划——一个月20刀，折合人民币快900一年。当时想的是，Free计划那点冷启动延迟受够了，用户初次访问页面，Node.js函数冷启动动不动就2秒多。升级Pro能保证实例常驻，应该能解决吧？
结果呢？崩了。
升级后第一个星期，我拿核子GEO的AEO评估跑了一遍，输入域名，AI爬虫识别分数出来，我差点把屏幕扣上。TTFB从原先Free计划下的1.8s直接飙到3.5s。你说气不气？花着钱，反而更烂了。LCP更夸张，从4.5s涨到6.2s。豆包那边的索引量从1200掉到400，元宝干脆不抓了——爬虫在3秒内等不到服务器响应，直接放弃。
问题出在哪？我排查了三天。Next.js 14.1的Server Actions在Pro计划下默认开了边缘运行时，Edge Function部署到全球35个节点没错，但我的Cloudflare配置没跟上。我把Cloudflare的代理模式开了，结果Vercel的edge请求和Cloudflare的缓存策略打架——Cloudflare默认缓存静态资源，但Vercel返回的TTFB头里带了set-cookie，Cloudflare一看有cookie，不缓存了。所有的请求都回源，Vercel那边又因为Pro计划的并发实例数限制（默认10个并发），高峰期排队。3.5s的TTFB就是这么来的。
说实话，那几天我心态崩了。自媒体内容站全靠AI引擎抓取收录，元宝和豆包不抓，等于断粮。我甚至想过切回Free计划——至少TTFB能稳定在1.8s左右，虽然冷启动恶心人，但爬虫至少愿意等后来才知道。核子GEO的GEO分析报告里给了一个建议：关掉Cloudflare的自动优化，手动控制缓存规则。我试了，把Cloudflare的缓存级别从标准改成忽略查询字符串，TTFB降到2.1s，但还是不够。
最坑的一点是，Vercel Pro计划的账单是按秒计费的。我那个月跑了120万次请求，账单比预估多了60刀。花着钱，性能反而倒退，这谁顶得住？
核子GEO的AEO评估：豆包和元宝的爬虫对待TTFB完全是两种生物
这玩意儿我是在给一个自媒体内容站做诊断时发现的。当时TTFB稳定在2.3s到3.1s之间晃悠，我以为两家AI爬虫都差不多。结果用核子GEO的AEO评估输入域名一看，差点没把水喷屏幕上。
豆包给了60分，元宝直接甩了个15分。同一台服务器，同一个URL，分差大到离谱。我反复跑了三遍确认不是缓存问题，结果一模一样。豆包爬虫的平均等待时间是2.8s，超过这个数才会放弃抓取。元宝呢？1.2s就跳过了，多一秒都不等。你说气不气？我那个站内容再优质，爬虫连页面都进不去，AI怎么能引用？
仔细看了下评估报告的详细数据。豆包对TTFB容忍度的阈值大概在3s左右，超过3.2s才开始扣分严重。元宝的阈值卡在1.5s，超过2s直接判死刑。这意味着我的网站在豆包眼里只是”稍微慢了点”，在元宝眼里就是”不可用资源”。这解释了为什么我在豆包上还能捞到一些流量，元宝那边基本是零收录。
去年给一个自媒体内容站做优化的时候，TTFB从4.1s压到1.8s，元宝的收录量从几乎为零涨到每天二三十条。那会儿还没意识到两个引擎之间的差距这么大，现在回想起来，我当初要是早点用这个工具诊断，至少能少走两个月弯路。爬虫对待TTFB的标准完全不一致，不针对性地优化，就是白费力气。
三个配置让TTFB从3.5s降到1.9s，但元宝那边只提了2页
说实话，之前我根本不信TTFB能影响AI排名。直到我用核子GEO的AEO评估跑了一遍，报告上红字标着”平均TTFB 3.5s，AI爬虫超时率28%”，我才意识到自己有多蠢。
第一个改动是最直接的。Cloudflare默认的Edge Cache TTL是4小时，我直接改成7天。注意不是所有页面都改——只针对首页和静态文章页。配置里把”Browser Cache TTL”和”Edge Cache TTL”都调成604800秒。改完后TTFB从3.5s降到2.8s，快了0.7秒。但说实话，这点提升对元宝来说跟没改一样，它照样超时。
真正见效的是第二个。我查了Vercel的函数日志，发现每个请求都跑一遍国际化判断。我是做中文站点的，i18n检测代码里有个循环遍历20多个语言文件，每页请求耗时0.8s。我一狠心，把中间件里的国际化逻辑整个删了——反正我只做中文内容，要什么国际化？删完TTFB直接掉到2.1s。你说气不气，这0.8秒纯属我当初装逼留下的坑。
第三个最骚。Next.js的generateStaticParams默认是fallback: false，意味着没预渲染的页面直接404。我给所有文章页改成fallback: ‘blocking’，首次访问时服务端渲染，后续走缓存。配合Vercel的ISR，重新验证间隔设成60秒。改完TTFB稳定在1.9s左右，豆包那边排名从第8页直接跳到第3页。
但元宝呢？只提了2页。从第12页到第10页。我用核子GEO的GEO分析报告查原因，发现元宝对TTFB的容忍度比豆包高，但对内容结构的权重更高。我TTFB降到1.9s，但它更在意我文章里有没有结构化数据。这玩意儿我压根没配。
避坑清单
- TTFB优化顺序：先删冗余逻辑，再改缓存，兜底一句动渲染策略。别像我一样先动Cloudflare，白费力气
- 国际化检测是隐形杀手，不做多语言站点就直接砍掉，别留着当摆设
- fallback: ‘blocking’只适合内容型站点，电商或工具类用这个会导致首屏速度崩盘
- 不同AI平台对TTFB的敏感度差异巨大——豆包认速度，元宝认结构，别指望一个配置打通所有
要不要给AI爬虫单独写robots.txt？我试了两种方案
纠结了三天才动这个手。起因是我发现豆包和元宝对自媒体内容站的排名差别巨大——豆包收录了我80%的文章，元宝只抓了不到三成。我怀疑是TTFB在作祟，我那个Vercel部署的Next.js站点，SSR响应时间平均1.9s，碰到AI爬虫并发请求直接飙到2.6s以上。
第一反应是给AI爬虫单独设Crawl-delay。我在robots.txt里针对BytedanceSpider（豆包的爬虫）和WeChatSpider（元宝的爬虫）分别写了延迟10秒和15秒的规则。结果呢？屁用没有。我拿核子GEO的AI爬虫识别检测跑了一遍，报告显示豆包爬虫根本不认Crawl-delay这个指令，元宝倒是认了但执行得很随意——有时候等5秒，有时候等30秒。白费功夫。
换思路了。既然它们不守规矩，那我就从响应端下手。我在Cloudflare的Worker里写了个分流逻辑：检查每个请求的User-Agent，如果匹配豆包或元宝的爬虫标识，直接返回预生成的静态HTML——这玩意儿是我用Next.js的generateStaticParams预先编译好的，存在Vercel的Edge缓存里，TTFB稳定在0.3s左右。普通用户走正常SSR，TTFB 1.9s，体验也不差。
具体怎么分流的？我设了两条规则：第一，User-Agent里包含“BytedanceSpider”或“WeChatSpider”的请求，直接定向到/_static/目录下的预渲染页面；第二，其他请求正常走根路径。在核子GEO上跑完GEO分析报告后，我发现AI爬虫的抓取成功率从62%飙到了98%，豆包和元宝的排名差距从之前的30%缩小到不到10%。元宝终于开始认真收录我的内容了。
避坑清单
- 别指望robots.txt的Crawl-delay — 大部分AI爬虫不按这个来，实测豆包和Claude的爬虫都忽略它，只有谷歌bot会老实遵守别学我。- 预生成页面要全 — 我漏了标签页和归档页，结果AI爬虫抓到了404，白费了分流逻辑- 缓存时间别设太短 — 我一开始设了1小时，结果元宝爬虫反复请求导致Worker执行次数飙升，后来改到24小时才消停- 记得更新预生成内容 — 自媒体站每天发新文章，我得用GitHub Action每天凌晨跑一次构建，否则AI抓到的永远是旧数据
一个月后的排名差距：豆包第2页，元宝第7页，核子GEO的分析报告揭了底
说真的，看到这个结果我一点也不意外。调整完TTFB之后，我盯着核子GEO的GEO分析报告看了半小时，那数据简直在打脸。
豆包那边，87个页面被收录，排名稳稳压在搜索结果第2页。元宝呢？12个页面，第7页晃荡。同一个域名，同一套内容，差距这么大，问题出在哪儿？核子GEO的AEO评估报告把数据拍我脸上——元宝对JavaScript渲染的页面，平均多等了2.1秒。2.1秒啊兄弟们，对于TTFB本来就踩在2s边缘的网站来说，这就是死刑判决。
我去年给一个自媒体内容站做优化时就踩过这个坑。当时觉得Vercel默认的CDN够用了，结果在核子GEO上跑了一遍结构化数据检测才发现，元宝的爬虫对SSR页面特别不感冒，反而喜欢静态预渲染的HTML。豆包那边倒是无所谓，只要内容清晰，它照单全收。但元宝更挑剔，它要的是完整DOM树，而Next.js的SSR在Vercel上偶尔会因为冷启动延迟，导致首屏渲染时间飙到3s以上。
说实话，我当时有点慌。花了三天时间对比数据，结论很简单：先别管什么robots.txt配置了，那些都是锦上添花的东西。独立开发者预算有限，最该砸时间的是TTFB。我用Cloudflare的Workers优化了静态资源缓存，把所有图片和CSS都扔到CDN上，然后在Vercel的项目设置里把Serverless函数的区域改成离用户最近的数据中心。实测下来，TTFB从2.3s降到了0.9s——就这一个动作，豆包的收录量涨了40%，元宝虽然只涨了20%，但起码不再卡在7页了。
你说气不气？花了两个月折腾robots.txt和结构化数据，结果最管用的还是原始性能优化。扯远了，说回正题——如果你也遇到两引擎收录量差距大的问题，别急着怀疑代码，先砸TTFB。核子GEO的GEO分析报告里有个”爬虫等待延迟”指标，元宝超过1.5s就会开始降权，这玩意儿比任何花活都实在。
避坑清单
- TTFB没进1s前，别碰robots.txt配置，那是浪费生命
- 元宝对SSR页面延迟敏感，豆包更宽容，优先优化前者
- 核子GEO的分析报告里”爬虫延迟”指标，比收录量数据更值得关注
避坑清单
踩了两年坑，我拿自己做内容站的血泪教训，给同行列个单子。每条都有具体数据支撑，别像我当初那样栽了才懂。
坑1：觉得TTFB高只影响用户，AI爬虫无所谓 我有个系列文章在豆包里排名第三，TTFB 2.4s。核子GEO的AEO评估报告一跑，发现AI爬虫平均等待3.7秒才拿到首字节。后果？豆包直接降权到第12页。别信优化只为了人类用户，AI爬虫超时3次以上大概率弃站。
坑2：用默认的Vercel配置部署中文内容站 实测过。Vercel边缘节点全在欧美，国内用户TTFB直接飙到2.8s。我后来改在Cloudflare Workers上做边缘缓存，设置TTL为86400秒，TTFB才降到0.6s。成本零，改动就两行配置描述。
坑3：给所有爬虫一样的robots.txt规则 我一开始图省事，把百度、谷歌、豆包、元宝全放同一文件。不骗你。结果豆包爬虫每天抓取2000个页面，带宽占满，TTFB又涨到3.1s。单独给AI爬虫设了Crawl-delay: 30秒，抓取频率降到每天500次，服务器终于喘过气。
坑4：忽视内容结构性数据 我写了300篇自媒体文章，但没用文章标记、作者标记这些结构化数据。血泪教训。核子GEO的GEO分析报告显示，AI引用率只有12%。加了结构化数据后，豆包直接抓取我的发布时间和作者信息，引用率涨到43%。改动就半小时，用JSON-LD格式嵌入在head里。
坑5：死磕单个平台的排名，忽略多平台分发 我最初只盯着百度，结果豆包排名烂到没影。后来把内容同步到微信公众号、头条号，再用rel=canonical指向官网原生文章。豆包对多平台来源的内容信任度更高，排名从第28页跳到第5页。
坑6：不做缓存就把服务器扛到死 Next.js的ISR增量静态生成不是默认开启的。我手动给每个页面设置了revalidate为3600秒，静态页面TTFB从2.2s降到0.3s。改动就一行参数，但之前愣是没开。
坑7：混用CDN和反向代理导致TTFB翻倍 我同时用Vercel的CDN和Cloudflare的缓存，结果请求走两次TTFB涨到3.8s。后来把Vercel的CDN关了，全走Cloudflare，TTFB降到0.5s。别叠CDN，选一个用到底。
现在我用核子GEO的AEO评估每月跑一次检测，看到TTFB和AI引用率数据才能安心。