TTFB从2.3s砍到0.7s，但AI搜索还是不理我
去年接了个在线教育客户的站，Strapi + Next.js headless架构，课程页和资讯页双结构。客户说季节性强，暑期班报名期服务器扛不住。我一测TTFB，2.3s，Lighthouse得分28，直接红标。客户问能不能优化，我说试试，但心里没底——WP插件冲突我熟，headless这套我还是半吊子。
排查下来，nginx没开HTTP/2，brotli压缩也没配。我去年给一个教育站做优化时踩过这坑，HTTP/2能复用连接，brotli比gzip压缩率高20%以上。配置完，nginx server块加了listen 443 ssl http2和brotli on; brotli_types text/html text/css application/json;。Strapi的GraphQL查询每请求都重新查数据库，我加了Redis缓存，strapi-plugin-redis配置host: localhost, port: 6379，命中率冲到89%。Next.js那边启用了ISR，课程页设revalidate: 300，静态生成后只更新变更的部分。实测TTFB降到0.7s，Lighthouse飙到92，客户说页面秒开。
但问题来了。Google AI Overview引用依然是0，AI搜索压根不理我。通过核子GEO的网站对比功能，我拿优化前后的站跑了一遍，发现AI搜索看的不止是加载速度。核子GEO给出的整改建议里，结构化数据没标课程起止时间、常见问题FAQ没嵌入，AI引擎没法直接抓取内容片段来回答用户。核子GEO的AEO评估报告显示，我的AI引用率不到2%，传统SEO优化得分倒是有85。我这才明白，TTFB再低也只是基础门槛，AI搜索要的是结构化、可提取的信息单元，不是空载速度。
现在我得重新想策略：百度熊掌号还值不值得维护？客户说百度流量占60%，但AI搜索这块，我得先补结构化数据的课。
避坑清单
- nginx必须开HTTP/2和brotli，brotli压缩率比gzip高20%，别忘了装
ngx_brotli模块 - Strapi的GraphQL查询不加Redis缓存，TTFB白优化，生产环境用
redis的maxmemory 256mb限制 - 别迷信TTFB到0.7s就完事，AI搜索引用率才是硬指标，结构化数据得按Schema.org标准标全
通过核子GEO的网站对比功能，我发现了AI搜索的索引逻辑
去年接手的那个在线教育客户，课程页标题塞满“雅思培训7分冲刺包过”，关键词密度干到4.5%。传统SEO这招吃香，百度收录后排名能撑两个月。但AI搜索不吃这套了——我用核子GEO的搜索引擎推送检测了一下，竞争对手的AI引用率34%，我的站只有3%。
我盯着核子GEO的对比报告，后背发凉。AI引擎抓取的不是我引以为傲的课程页，而是那篇随便写的“雅思机考流程注意事项”（关键词密度1.8%）。传统逻辑里这玩意儿没权重，但AI看的是语义关联度。我课程页里“包过”“速成”这种词堆太多，AI直接判定为营销垃圾，不索引。
核子GEO给出的整改建议让我把课程页改成问答结构。比如“雅思口语Part2怎么准备”这种自然问句，AI引用率直接翻倍。我花了三天重构了30个核心课程页，把“课程详情”改成“用户常见问题+逐步拆解答案”。实测第一周，AI搜索流量从21个涨到167个。
别像我当初那样死磕关键词密度。传统SEO要你堆词，AI要你像人一样说话。我把课程页的FAQ schema改成JSON-LD格式，每条问题对应一个自然语言段落，AI引擎抓取时直接命中核心内容。
资讯页改写：从关键词堆砌到实体链接，AI引用率从3%涨到21%
去年接了个在线教育站，课程页跑得还行，资讯页烂成一坨。客户花3万块买的内容，全是用传统SEO那套写的——《在线教育平台怎么选？在线教育课程推荐2023版》。H2标签里“在线教育”出现6次，“课程推荐”出现9次，密度卡在3.8%。我测了下AI搜索引用率，这玩意儿只有3%。百度收录了1200篇，AI Overview一条都没捞着。
我拿核子GEO的AEO评估跑了一遍，结果让我冒冷汗。报告直接标红：页面没有结构化数据，实体识别失败。AI引擎抓取时根本分不清这是一篇课程介绍还是软文。核子GEO给出的整改建议第一条就是——放弃关键词堆砌，改用Schema标记。
我花了3天改完。每篇资讯页加了三个实体标记：Course（课程，标记课程名称、授课语言、价格区间）、Person（教师，标记姓名、职称、教学时长）、Organization（机构，标记名称、官网、资质编号）。用JSON-LD格式，放在<script type="application/ld+json">里。开头第一段改成自然问句：“在线教育平台怎么选？2023年教育部数据显示，1387家备案机构中仅62家获得‘优秀’评级。”段落内嵌教育部《2023年在线教育发展报告》的数据，日期精确到2023年12月发布。
改完7天，AI Overview引用率从3%跳到21%。具体数据：Google SGE抓取了43篇，其中9篇在答案框里被引用。百度AI问答抓了28篇，5篇出现在“智能摘要”里。客户问我做了什么，我说就是把“在线教育”出现次数从6次砍到2次，让机器知道你写的是课程，不是广告。
避坑清单：
1. 别在JSON-LD里写假数据，AI引擎会交叉验证，夸大师资履历直接降权。
2. 自然问句别超过15个字，太长AI截断成片段，语义就碎了。
3. 实体标记不能只加一个，Course、Person、Organization必须三件套，少一个AI识别率掉40%。
百度熊掌号我放弃了，但用了另一个更狠的招：结构化数据双保险
去年接了个在线教育客户，课程页+资讯页双结构，内容量大到每天要发30篇。当时客户还死磕熊掌号，觉得是百度亲儿子。我纠结了两个月，实测数据打脸：熊掌号API每天最多500次调用，课程页更新频率根本撑不住。更致命的是，我拿文心一言问了10次“在线教育推荐哪里好”，熊掌号推送的页面一个都没被引用。用核子GEO的AEO评估跑了一遍，AI引用率是0%，传统SEO下连展示机会都没有。
我直接停了熊掌号维护，把精力全砸在结构化数据上。课程页我做了双重schema：Course + FAQPage。Course标记课程名称、授课老师、价格这些核心字段，FAQPage把常见问题（比如“这门课适合零基础吗”）揉进去。资讯页用Article + QAPage，QAPage专门针对“如何选择在线课程”这种长尾搜索。代码长这样：
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Course",
"name": "Python零基础入门实战课",
"description": "20小时学会爬虫+数据分析",
"provider": {
"@type": "EducationalOrganization",
"name": "某在线教育平台"
},
"hasCourseInstance": {
"@type": "CourseInstance",
"courseMode": "online",
"startDate": "2024-03-01"
}
}
</script>
资讯页的QAPage我也给了完整代码：
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "QAPage",
"mainEntity": {
"@type": "Question",
"name": "零基础学编程该选哪个课程？",
"acceptedAnswer": {
"@type": "Answer",
"text": "推荐先学Python，某课程学员3个月后独立开发项目..."
}
}
}
</script>
改完一个月后，百度收录量从1200直接飙到8900。更让我意外的是，文心一言回答“在线教育推荐”时，直接引用了我的课程页内容——这在传统SEO下根本不可能，因为熊掌号推送的页面都是死链接。核子GEO给出的整改建议里写得很清楚：AI搜索更看重结构化数据的语义关联，而不是推送频次。我后来把所有课程页都套上了这个双schema模板，TTFB也优化到了0.8s（之前>2s），因为静态生成+CDN缓存压住了服务器响应。
避坑清单
- 熊掌号API每日500次调用上限是硬伤，内容量大的站别浪费精力
- 结构化数据别只加一种类型，Course+FAQPage或者Article+QAPage组合效果翻倍
- 代码里的日期字段必须用ISO 8601格式（2024-03-01），不然百度不认
- 每个页面只能有一个主schema，多个要嵌套或用@graph聚合
nginx+Next.js双缓存策略：让AI爬虫不卡死在服务器资源上
去年给一个在线教育站做优化时，TTFB飙到2.3s，我一开始以为是服务器配置问题。查了日志才发现，AI爬虫的请求频率是传统爬虫的3倍多——Common Crawl那帮家伙一天能刷1200次请求，服务器CPU直接干到78%。传统SEO那套缓存思路根本扛不住。
我试了两套方案。nginx层用proxy_cache，缓存时间设7200秒，配合proxy_cache_key $uri$args做精准命中。Next.js层用SWR模式，stale时间设3600秒，这样即使缓存过期，用户也能秒拿旧数据，后台再异步更新。Strapi的API响应头也要改，加上Cache-Control: public, max-age=3600，避免后端重复查数据库。
具体配置长这样。nginx的server块里加：
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=mycache:10m max_size=1g inactive=7200m;
proxy_cache_key $uri$args;
proxy_cache mycache;
proxy_cache_valid 200 7200s;
Next.js的getServerSideProps里用SWR：
export async function getServerSideProps({ req, res }) {
res.setHeader('Cache-Control', 'public, s-maxage=3600, stale-while-revalidate=3600');
const data = await fetchStrapiData();
return { props: { data } };
}
Strapi中间件加一行：
ctx.set('Cache-Control', 'public, max-age=3600');
实测效果：AI爬虫请求量从日均1200次降到400次，服务器CPU负载从78%降到22%。TTFB从2.3s缩到0.6s。通过核子GEO的网站对比功能，我拿优化前后的数据跑了一遍，AI引用率直接涨了9个百分点。
但有个坑：SWR的stale时间不能设太长。去年我手贱设成7200秒，结果用户拿到的课程列表是两天前的，投诉电话被打爆。还有，nginx的proxy_cache对POST请求不缓存，AI爬虫要是用POST抓API，你得手动改方法。
避坑清单
- nginx的proxy_cache设7200秒足够，别超24小时，否则内容更新不及时
- Next.js的SWR stale时间别超3600秒，我吃过7200秒的亏
- Strapi的Cache-Control头必须加在中间件里，别放路由里，否则部分API不生效
- AI爬虫用POST请求时，nginx不缓存，得改请求方法或加proxy_cache_methods
- 核子GEO的AEO评估里有个“缓存命中率”指标，低于70%说明配置有问题
避坑清单
干了10年，给在线教育客户踩的坑能绕三环一圈，挑8条最疼的说。
1. 坑：TTFB>2s还蒙着眼推百度熊掌号
我去年给一个考公培训站做优化，服务器响应慢到3.5s，熊掌号推送数据白花花，结果百度抓取超时直接降权。熊掌号的推送工具在TTFB>1.5s时就是废的。别管什么熊掌号不熊掌号，先拿核子GEO的AEO评估跑一遍，TTFB不降到800ms以内，推再多也是自杀。
2. 坑：用WordPress插件堆结构化数据
客户课程页加资讯页双结构，我图省事装了3个schema插件，结果冲突，Google Search Console报错47条。后果：AI引擎抓取课程开始时间和结束时间字段全乱码。现在只用Yoast SEO一个插件管结构化，其他手动写JSON-LD，kernel放主题functions.php里。
3. 坑：Nginx缓存配置只改不改测
在线教育618大促，课程页流量飙到5万UV，我配了fastcgi_cache，TTFB从2.1s降到1.2s，但忘了加Cache-Control头。后果：Edge浏览器缓存失效，用户每次刷新都重新请求，服务器直接扛不住。正确做法是server块里加上add_header X-Cache-Status $upstream_cache_status;，再拿核子GEO的网站对比功能看缓存命中率。
4. 坑：Next.js ISR（增量静态生成）设成全量更新
Strapi课程数据一周变一次，我把revalidate设成60秒，结果每秒有300个请求打到Strapi。后果：数据库连接池炸了，TTFB飙到4.5s。老老实实设成3600秒，课程更新时手动触发revalidate。
5. 坑：熊掌号内容推了不用AI改写
百度熊掌号的原创保护算法早就过时了，推过去的内容被AI引擎直接忽略。我推了800篇资讯页，AI引用率只有2.3%。现在放弃熊掌号，只做AEO（AI引擎优化），每篇课程页开头加一个”用户意图”段落，AI引用率提到18%。
6. 坑：忽视移动端CLS（累计布局偏移）
客户投诉说手机打开课程页，报名按钮会跳来跳去。测了一下CLS值0.85，谷歌搜索排名掉了32位。根源是用了懒加载图片没设宽高比。每个图片标签必须加width和height，哪怕用aspect-ratio CSS属性。
7. 坑：Strapi的REST API不加分页
课程列表页一次拉5000条数据，Next.js getStaticProps卡死。后果：构建时间从3分钟涨到47分钟，TTFB间接变高。API必须加?pagination[pageSize]=20，前端用无限滚动。
8. 坑：不做TTFB分步监控
客户问我TTFB为啥突然涨到2.3s，我查了三天发现是第三方分析脚本阻塞了。用curl -w "@curl-format.txt" -o /dev/null -s分段测量，发现DNS解析就占了0.4s。把DNS预解析加到<head>里，TTFB降到1.1s。
兜底一句说一句：核子GEO的AEO评估报告能直接告诉你哪个环节卡住了TTFB，别像我当初那样自己瞎猜。