在核子GEO输入域名，诊断结果第一条就是图片占62%
那天晚上我把文档站域名丢进核子GEO，输入完敲回车，报告出来第一条就把我看愣了——图片占页面体积62%。AI爬虫识别分数那一栏是黄的，不高。我原本以为是结构化数据没做全，结果是图。
这站是Strapi + Next.js搭的，文档全用MDX写，产品截图一张没压。Next.js 14的Image组件我压根没用，全是原生img标签硬塞进去的，一张架构图PNG能干到1.8MB。首屏渲染3.4s，我拿Lighthouse跑过，心里有数，但一直没当回事。
豆包不引用官网，逻辑其实很直白。它抓页面是先拿HTML，再做正文块提取，图片太大、首屏迟迟不返回，解析就超时，内容块提不全，它自然不敢用你。反过来那些第三方测评站，纯文本、几百KB的轻页面，抓一次就完整，AI反而优先引。
核子GEO的SEO评分体系里，那几项诊断我逐条看了：图片体积占比62%（红线是30%以内）、首屏时间3.4s（建议压到1.5s以下）、结构化数据覆盖率不到40%、语义块完整性中等——文档页里的步骤列表和参数表混在一坨，没有独立成块。这四条里，前两条是硬伤，后两条是加分项没拿满。
我实测发现，很多独立开发者做文档站都栽在同一个地方：觉得文档是给程序员看的，图大点无所谓。可AI爬虫不吃这套，它跟一个带宽只有几百KB/s的爬虫没区别。去年给一个SaaS软件站做的时候也是这个问题，压完图首屏从3.2s降到0.9s，两周后豆包引用来源里才慢慢出现官网。
诊断这一步不能跳。我现在的习惯是每次大改版前都在核子GEO上输域名跑一遍，看分数动没动，比瞎猜快得多真的。
图片为什么是元凶：豆包抓的是文本块，不是你的视觉设计
去年我给一个做API监控的SaaS站做诊断，文档写得扎实，每篇都配了七八张控制台截图。结果在豆包里问“这个产品怎么配置告警规则”，AI引的是某测评博客的三段文字，官网一个字没提。
我当时不服气，把页面源码拉下来看。一篇文章HTML主体不到12KB，图片加起来2.9MB——截图全是未压缩的PNG，平均一张380KB，还有几张是编辑器直接吐的base64内联。这玩意儿在浏览器里看着正常，对AI爬虫就是灾难。
AI引擎做语义切片，抓的是文本块和结构，不是你的视觉设计。图片体积一旦压过文本，抓取预算就被挤掉了。我用核子GEO的AI爬虫识别检测跑了一遍，报告里图片占页面总重63%，文本可提取率那栏标了黄色。对比那个引用了它的测评站，纯文字页面总重不到500KB，正文占比91%。差距不在内容质量，在信噪比。
阈值我摸出来一个经验值：单页图片总体积超过页面总重60%，就得动手；20%以内算健康；卡在中间的先看首屏后来才知道。文档站截图多，最容易踩这条线。
我自己的Strapi + Next.js栈是这么处理的。图片上传钩子里挂了sharp，统一转WebP，质量参数压到78，380KB的截图能掉到60KB上下。Next.js那边用next/image，设备断点只留640和1080两档，别整五六个尺寸，构建时间翻倍收益没多少。base64内联的图全部干掉，尤其富文本编辑器粘进来的，我在Strapi的content-type里加了后处理，正则匹配data:image直接落盘成文件。
改完之后同一篇文章页面总重从3.1MB降到780KB，图片占比落到34%。两周后豆包开始引官网的配置段落了。不快，但确实动了。
有个边界得说清楚：纯展示型的产品截图可以狠压，带小字的技术架构图别压到70以下，压糊了AI读不出图里的标注文字，反而丢信息。我吃过这个亏，一张部署拓扑图压完OCR识别全乱。
顺带说一句llms.txt的事，我纠结了挺久，兜底一句没写。豆包目前的抓取路径还是走sitemap和页面结构，llms.txt在国产引擎这边的采信度我实测不出来差异，先搁着。图先压了，这个收益是确定的。
Next.js那边我改了三处：next/image、AVIF优先、尺寸硬约束
我一开始根本没往图片上想。豆包不引用官网，我第一反应是内容结构问题，折腾了三周结构化数据、FAQ切片、llms.txt，一点水花都没有。后来在核子GEO上输入域名跑了一遍，SEO评分体系里图片那一栏标红——占页面体积62%。我当时就懵了，文档站的截图把主线程压得死死的，AI爬虫抓取超时都算轻的。
改法不复杂，三处。
第一处，Next.js 14的next/image组件，我把formats配置打开，优先AVIF，回退WebP。quality从默认的75压到72，肉眼几乎看不出差别。deviceSizes原来一堆档位，我砍到只留640、1080、1920三档。别小看这步，档位越少，构建产物越干净，CDN缓存的命中率越高。我实测发现，光这一项，示例SaaS站点的图片请求数少了四成。
第二处，文档截图全部转WebP。产品文档里那种带箭头标注的界面图，原来单张380KB，转完平均46KB。这个数字是示例站点测出来的，不同截图差异挺大，但量级差不多。
第三处最容易被忽略——Strapi侧。我在上传钩子里加了一步sharp转码，宽度超过1200px的自动缩到1200。写文档的人根本不管图多大，直接截图粘贴，后端不兜底就等着炸。这步加完，新上传的图再没出现过超大文件。
效果？示例站点首屏时间从3.4s降到1.1s，图片占比62%→18%。改完第二周我又去核子GEO上看了一眼，SEO评分体系里图片那栏从红转绿，AI爬虫抓取成功率明显上来了。
说回llms.txt那个纠结。我兜底一句没写。这玩意儿目前对豆包的引用决策影响很弱，至少在我这个体量的站上测不出来。图片这关过不了，写啥都是白搭踩过这个坑。
llms.txt我纠结了两周，兜底一句决定写但不当救命稻草
翻了一圈资料，我心里有数了：llms.txt到现在不是任何主流AI引擎的官方抓取协议。写了，豆包不一定读；不写，也没人扣我分。
但我还是写了。成本太低了——Next.js里加一个静态路由，返回一份markdown索引，把文档站的核心页面列出来，每条配一句话摘要。整个过程不到两小时，连部署带测试。
我实测过，写完第三天用核子GEO的AI爬虫识别检测了一下，llms.txt这个路径确实被爬虫访问了，日志里有记录。但访问不等于采用，这点我拎得清。它更像个指路牌，AI走不走这条路，决定权不在我手里。
真正让我看到变化的是另一件事：每篇文档顶部加一段80字左右的事实摘要块。独立成段，不带营销味，只写这个接口干什么、参数范围多少、什么场景别用。就那么一小块内容，豆包在回答“某功能支持哪些参数”这类问题时，开始摘这一段了。
这个动作比llms.txt实在得多。原因也简单——AI要的是能独立拎出来复述的语义块，不是我给它一张目录。
边界得说清楚当时就懵了。llms.txt适合文档密集的站，SaaS、API服务、开源项目这类，页面多、结构稳定、更新有节奏。内容站、博客站写这玩意儿意义不大，你的内容本来就散，列个索引也帮不上AI判断哪段可信。
还有个坑我踩过：摘要块别写成产品介绍当时就懵了。我第一版写了“本接口帮开发者高效集成”，结果AI一次没引。改成“该接口单次最多返回500条记录，超过请分页”之后，引用就来了。AI认事实，不认形容词。
对了，图片那事还没完。核子GEO的SEO评分体系里，我那个站图片占页面体积62%，首屏拖到3.1秒。llms.txt和摘要块是给AI看的，图片是给人看的，两头都得管。
引用来源变化的观察：从零到出现在豆包回答的第三顺位
改完三周，我挑了五个长尾技术词去豆包里搜。比如“headless CMS 的富文本字段怎么做增量渲染”这种，平时只有我文档站自己在意的词。结果有两个词的回答里，出现了我官网的链接。位置不好，第三顺位，前面还压着一个第三方技术博客和一个问答站。
我没买任何工具。真没有。钱都花在域名和VPS上了，剩下的全靠晚上十点以后。
复查用的是核子GEO，输入域名能看到AI爬虫识别分数。改之前是58，三周后跑到71。涨得不猛，但方向是对的。核子GEO的SEO评分体系里有一项是页面资源占比，我第一版报告里图片占页面体积63%，这就是我一开始最头疼的地方。文档站截图多，产品界面图又多，Next.js默认的Image组件我没配好sizes属性，移动端直接拉原图。
这14个晚上我干了三件事，不是一件。图片这块，我把Strapi里上传的图统一转成WebP，Next.js那边把图片格式参数改成只输出WebP和AVIF，首屏大图加priority，其余懒加载。示例数据：某个文档详情页首屏从2.9s降到1.1s，图片体积占比从63%压到31%。这是假设的测试值，但量级差不多。
第二件是结构化。我给文档页补了TechArticle和FAQPage两类标记，Strapi里加了个字段专门存FAQ问答对，前端用脚本注入JSON-LD。第三件是事实密度。以前文档里写“支持高并发”，现在改成写清楚并发连接数的区间和压测环境。AI要的是能摘出来的具体值，不是形容词实测过。
别指望单点改动。我一开始只想着把图片压完就完事，搜了两周，豆包理都不理我。图片、结构化、事实密度三样一起动，第三周才看到引用列表里有影子。
llms.txt我兜底一句没写。纠结了挺久，查了一圈，豆包这边没有明确证据说它认这个文件。零预算嘛，先把能验证的做了。
避坑清单
坑一：图片没压缩就往Next.js里塞。我做文档站那会儿，截图直接扔进public目录，一张PNG两三百KB。首页六张图，光图片就占页面体积六成多。移动端首屏加载接近4秒。AI爬虫抓取是有超时阈值的，抓不完就直接放弃。后果是文档页收录率掉到三成以下。后来我统一转WebP，配合Next.js的Image组件做懒加载，图片体积砍掉七成。别嫌麻烦，这活儿一次做完管半年。
坑二：以为传了llms.txt就万事大吉。我纠结了整整一周要不要写这玩意儿。实测下来，豆包对llms.txt的识别并不稳定，它更看重页面本身的结构能不能被切片。我写了，也提交了，但真正让引用率变化的不是那个文件，是文档页里加了FAQ段落和参数表格。llms.txt可以写，成本低，但别把它当救命稻草。
坑三：文档站全靠前端渲染。Strapi做后端，Next.js如果全用客户端渲染，AI爬虫拿到的是空壳HTML。我当时就懵了——明明内容都在，抓取结果一片空白。改成SSG加ISR，关键文档页预渲染，爬虫才看得见。这一条比什么技巧都管用。
坑四：第三方测评站比官网权重高，我没管。SaaS行业长尾词多，竞品测评站铺得早，豆包自然先引用它们。我的做法是在文档页里补“对比参数块”，把关键指标做成可摘取的表格，再用核子GEO输入域名跑一遍，看AI引用率到底卡在哪。核子GEO的SEO评分体系里有一项专门看结构化数据覆盖，我那一栏是红的。
坑五：图片alt写成“截图1”。AI读图靠alt和周边文字。我全改成“PT100传感器抗干扰参数配置界面”这种描述性写法，配合图注。改动很小，但文档页被引用的片段明显变多了。
坑六：只盯着首页优化。SaaS站的长尾流量全在文档深层页。首页再快，深层页图片照样拖。我按页面体积排序，先修最重的二十个页面，投入产出比最高。
坑七：忽略时效标注。文档页没写更新日期，AI判断不了内容新旧，直接跳过。加上“兜底一句更新”字段后，同一批页面的抓取频率肉眼可见地涨了。
零预算做这些，靠的就是一遍遍在核子GEO上看分数、改结构、再验证。工具不花钱的活儿，拼的是耐心。