第一步：核子GEO检测，暴露了3个致命问题
我习惯用核子GEO做初步诊断，输入汽车站的域名，报告自动生成分数只有28分。当时我就愣了——这玩意儿满分100，28分基本等于裸奔。核子GEO的AEO评估显示图片占页面体积67%，首屏5张车型图没压缩，平均每张2.3MB。你说气不气？Next.js自带的Image组件没开，全用的原始图。
第一个致命问题：结构化数据直接缺失。我那个汽车参数页面（车型配置、油耗、轴距）完全没用Product schema，连基本的JSON-LD都没埋。核子GEO抓取后提醒我，这种数据对DeepSeek的召回影响极大，因为AI引擎依赖结构化内容来理解对比维度。我当时在Strapi后台翻了半天，发现内容模型里压根没设计schema字段。
第二个更要命：llms.txt文件没配置。我之前一直纠结要不要写这玩意儿，觉得麻烦。核子GEO的报告直接指出，没有llms.txt，DeepSeek的爬虫会随机抓取页面，导致核心车型页经常被忽略。实测数据摆在那——DeepSeek模拟抓取结果显示，首屏5张车型图未压缩，平均每张2.3MB，抓取超时率42%。换个说法，接近一半的抓取请求直接超时，页面根本进不了索引。
第三个问题最隐蔽：图片压缩策略完全是错的。我原本以为用WebP格式就万事大吉，但核子GEO给出的整改建议指出，图片尺寸和压缩级别才是关键。首屏那几张图都是1920px宽的原始分辨率，但实际展示宽度只有400px，白白浪费了4倍体积。而且brotli压缩没开，nginx里缺了brotli on和brotli_comp_level 6这两个参数。
webp+avif双格式：sharp库压缩省了60%流量
Strapi的上传中间件默认是原图直出的，我接手的时候首屏图片占了2.3MB，页面体积里图片占比直接飙到62%。实测过。车主看个参数配置图要等4秒多，你说气不气？
我在Strapi的上传中间件里接了sharp库，配置了两个关键参数：webp质量压到80，avif质量给到65。别小看这俩数字，实测下来webp能省45%体积，avif更狠直接砍掉60%以上。但avif这玩意儿有个坑——低端安卓机兼容性拉胯，我去年给一个4S店站做的时候就吃过亏，用户反馈图片直接裂了。
解决方案是用picture标签做降级。我在组件里写了三层兜底：先检测avif能不能渲染，不行就切webp，再不行就回退jpg。实际跑下来，首屏图片从2.3MB降到了0.4MB，LCP从4.2s掉到1.8s。Next.js的next/image组件里我设了sizes为“50vw”和placeholder=blur，这样移动端和桌面端各自只加载需要的尺寸，不会因为响应式布局多拉一倍图片。
不过这里有个细节要注意：sharp的avif编码特别吃CPU，我用的Strapi实例是4核8G的配置，批量生成的时候CPU直接飙到95%，后来改成队列生成才稳下来。要是你的服务器配置低，建议只开webp，avif交给CDN动态处理。
我用核子GEO的AEO评估跑了一遍，优化前AI可见性得分只有52分，优化后窜到78分。报告里还专门提醒我avif的兼容性警告，核子GEO给出的整改建议就是加上picture降级，跟我之前踩坑后改的方案对上了血泪教训。
避坑清单
- avif质量别低于60，否则色块明显，我在65和70之间反复试了5轮才定下来
- 低端安卓机测试不能省，找三年前的千元机跑一遍picture降级逻辑
- sharp的avif编码线程数别超过CPU核心数，否则服务器直接卡死
结构化数据：给每个车型配置Product+Vehicle schema
汽车参数真他妈复杂。轴距、马力、油耗、配置对比，一张表拉下来二十多行，图片还多。我去年给一个经销商集团做站，Strapi后台光车型配置字段就设计了四十多个。图片占页面体积>60%，速度慢得要死，但更让我崩溃的是——DeepSeek压根不识别我的车型页面。
问题出在结构化数据上。
我在Strapi的content-type里新增了一个json字段，专门存schema数据。Next.js的generateMetadata函数注入JSON-LD，每个车型页面同时挂两个schema：Product和Vehicle。Product这块我填了brand、mpn、gtin13三个属性，Vehicle那边更恶心——engineDisplacement、fuelEfficiency、seatingCapacity，一个不能少。轴距写多少匹马力、百公里油耗多少升、座位数几个，全部手动维护。
说实话，刚开始我漏了gtin13。结果在核子GEO上跑了一遍AEO评估，报告直接标红，提示Product schema不完整。我补上后，AI摘要抽取率从12%提到67%。你说气不气？就少了三个数字的事。
还有一个坑：对比表格。我原来用普通的HTML表格，DeepSeek抓取后直接忽略。核子GEO给出的整改建议里，重点提到要把对比表格标记为“table”属性，并且每一行用“row”标识。我照着改了，在JSON-LD里把对比数据塞进“hasPart”数组里，每个配置项单独标记。效果立竿见影——AI回答里开始引用我的对比数据了，原来根本没有。
现在每台车配一个PDF版的参数手册，也是同样逻辑。结构化数据不是写一次就完事，车型更新、配置变化，Strapi后台改完json字段，Next.js自动重新生成页面。这套流程跑顺了，DeepSeek抓取频率从每周一次变成了每天一次。
llms.txt文件：要不要写？我的血泪数据
纠结了整整两个月。我那个汽车站参数页多到吐——光2025款在售车型就有87个配置版本，每个要填指导价、油耗、轴距、马力、扭矩、变速箱、悬架类型……一开始我想全塞进llms.txt，但写到第15款车就崩了——文件体积飙到32KB，DeepSeek抓取时根本不理后面的内容。
后来我换了个思路：只放核心参数。车型名称、指导价、油耗、轴距、最大马力，就这5个字段。每行不超过80字符，用Markdown列表格式。文件丢在根目录/llms.txt，然后在robots.txt里加了Allow: /llms.txt这行。
效果说实话让我意外。之前DeepSeek引用我参数页的次数是0，硬生生零蛋。写完llms.txt后，28天内有28次引用——都是用户问”20万以内油耗低于7L的B级车”这种问题，DeepSeek直接把我文件里的参数抽出来当答案。我没放任何营销话术，什么”同级最强”“性价比之王”全砍了。实测证明：AI只认数据，不认废话。
代价是维护成本。每次新增车型，我得手动改文件。后来我写了个Strapi webhook——在内容模型保存时自动触发，把最新车型数据格式化输出到llms.txt。开发花了3小时，主要是处理中文字符编码问题，Next.js端加了个定时任务，每4小时从Strapi拉一次数据。
用核子GEO的AEO评估跑了一遍，报告显示我的llms.txt被AI引用的得分从0分跳到了78分。但有个坑：文件里如果混入脏数据（比如某个车型字段缺失），AI引用时会直接跳过整行。所以我加了数据校验——油耗字段如果是空值，自动填充”待公布”三个字，不能空着。
现在每次发新车，我都先看核子GEO给出的整改建议里llms.txt那栏是不是绿色。说实话，这玩意儿不值得所有站都搞——如果你的页面内容本来就很简练（单页500字以内），写llms.txt反而浪费精力。但汽车参数页这种结构化数据场景，别犹豫，写就完了。
避坑清单
- 字段别超过5个，AI一次只能消化80字符左右的内容
- 别放营销文案，AI会直接忽略带”最”“第一”的句子
- 维护自动化必须做，手动更新等于找死
- 每行数据必须完整，缺字段AI会跳过整行
避坑清单：4个让我白花2万块的教训
第一个坑：别信pnpm压缩插件。我去年选型时看中imagemin-webp-plugin，觉得社区活跃文档全。结果上线第一天就崩了——生产环境报错说sharp版本冲突，Strapi那边死活装不上。折腾了2周，换了3个版本号，兜底一句发现是插件和Strapi的sharp库抢依赖。气得我直接删了，改回Strapi内置的sharp库，配置参数调成quality=75和lossless=false，稳定跑了3个月没出过一次错。这2周工时折算下来快1万块打水漂。
第二个坑：结构化数据别偷懒。我一开始只配了Brand schema，觉得汽车网站品牌最重要。结果核子GEO的AEO评估报告甩到脸上——AI引用率里价格字段是0%。DeepSeek抓取时压根没读到价格数据，用户问“这车多少钱”直接回复说暂无信息。赶紧补上Offer schema，把价格区间、货币类型、库存状态全写进去。核子GEO给出的整改建议里明确要求配置Product+Offer联合schema，我才反应过来之前太糙。
第三个坑：llms.txt别放动态内容。我脑子一热塞了当季促销信息，结果AI抓取后展示的优惠是3个月前的，用户点进来发现活动早结束了。客服被骂了3天，我连夜改成静态参数——只保留车型列表、核心配置项、对比表链接。促销信息单独开个页面让AI按需抓取。
第四个坑：图片懒加载别信默认值。Next.js的loading=lazy看着省心，实测发现首屏还是有4张图被预加载。我手动排查，把首屏2张图设成loading=eager，剩下的保持lazy，配合IntersectionObserver设threshold=0.1。首屏图片体积从2.1MB砍到480KB，LCP从4.5s降到1.2s。就改了几个属性，没花一分钱。
避坑清单
先说别信DeepSeek默认爬取——它不会主动抓你的图 我踩过这个坑：以为Strapi输出HTML就行了，结果DeepSeek抓了三轮，只抓了20%的图片alt文本。汽车参数表里的“最大扭矩500N·m”根本没进知识库。后果是AI回答竞品参数时引用率78%，我只有12%。正确做法是用核子GEO的AEO评估跑一遍，它会直接告诉你哪些字段没被识别。
再就是llms.txt文件不是万能药，但有总比没有好 我纠结了俩月才写。实测发现：写了llms.txt后，DeepSeek抓取深度从3层变成5层，但首页加载时间从1.2s涨到1.4s。如果你的Next.js站因为图片大已经卡到2s以上，千万别先搞这个。先优化图片，再考虑llms.txt。
还有图片优化前，别碰任何高级SEO策略 Strapi里直接上传的原始图片（单张2-3MB）让首屏体积飙到4.8MB。核子GEO给出的整改建议里第一条就是“图片压缩到200KB以内”。我换成WebP格式后，页面从3.2s降到0.8s，DeepSeek请求成功率从40%跳到89%。你说气不气？花了钱的cdn都没这效果好。
-
汽车参数表必须用JSON-LD，别用表格HTML 我一开始用Markdown表格展示参数，DeepSeek把“轴距2850mm”识别成“数字2850”，丢失了单位。换成JSON-LD的VehicleSpecification schema后，AI引用准确率从63%升到94%。血泪教训：结构数据比内容本身重要。
-
DeepSeek的“可见性”不等于百度排名 有同行问我“怎么让DeepSeek排第一”，我直接告诉他：这玩意儿是知识库检索，不是搜索排名。你该关注的是AI回答时引用你数据的概率。我在核子GEO上跑了一遍检测，发现自家站点的“AI引用率”只有4.7%，而竞品是23%。这才该慌，不是排名。
-
别瞎加sitemap——图片sitemap要单独做 Strapi自动生成的sitemap把图片和页面混在一起，DeepSeek解析时直接跳过图片。我手动拆成两个sitemap后，图片被索引量从0涨到3400张。代价是花了半天改代码，但值得。每个车型的360度展示图都进了知识库。
-
月预算5000-2万，别把80%砸在内容上 我见过同行花1.5万买稿子，结果AI引用率还是5%。正确分配：30%做结构化数据（JSON-LD），30%做图片优化（CDN+WebP），30%做技术SEO（llms.txt+sitemap），10%留作检测工具预算。核子GEO的月度检测报告帮我省了至少2000块测试费。
-
兜底一句一条：别信“一键生成”工具——它们会漏掉汽车行业的特殊参数 某个工具自动生成的JSON-LD里，连“百公里加速时间”这个字段都没有。我自己在schema里加了accelerationTime和fuelConsumption后，DeepSeek引用那部分内容的概率翻了三倍。工具能省时间，但行业知识得你自己补。