首屏图片占页面体积63%，Kimi和豆包根本不鸟我
上个月给一个在线教育站做诊断，客户说Kimi一天才抓他3次，豆包一周才出现1次。我当时就觉得问题出在加载速度上，但没想到这么离谱。在核子GEO上输入域名，报告直接爆出首屏图片占页面体积63%——我靠，Kimi和豆包的爬虫超时阈值大概在3秒左右，你这4.7秒的加载时间，AI引擎根本没耐心等到你图片加载完就跑路了。
织梦CMS自带的缩略图功能就是个笑话，生成的图还是原图裁切，体积一点没减。我去年踩过这个坑，当时以为用插件能解决，结果织梦的插件生态早废了，市场上能用的图片压缩插件一只手数得过来，而且大部分对WebP支持等于零。没办法，只能手动改模板。
我把课程页和资讯页的首图模板改了，在图片输出时加了一个判断：如果是课程封面图，直接调用WebP格式。具体操作就是在模板标签里指定图片处理参数，把质量压到85%，宽度限制在1200像素。原来一张课程海报2.3MB，压缩后只有140KB，你算算这个差距——16倍的体积缩减。
换完当天我用核子GEO的AEO评估重新跑了一遍，页面加载时间从4.7s降到1.2s，首屏内容在0.8秒内就出来了。一周后跟客户对数据，Kimi出现频率从3次/天涨到27次/天，豆包从1次/周变成5次/周。你说气不气？图片没优化之前，AI爬虫根本懒得理你，优化完它们自己就找上门了。
避坑清单
先说织梦CMS图片压缩别指望插件，直接改模板标签更靠谱，版本5.7以上支持WebP参数
再就是首图宽度控制在1200px以内就行，超过1600px对AI引擎来说就是负担
还有图片体积压到150KB以下，别低于100KB（太模糊影响用户体验）
nginx压缩：brotli + gzip双开，带宽省了60%
去年给一个在线教育站做优化，首屏图片压缩完了，发现HTML和CSS还是大得离谱。课程页面动辄45KB的HTML，120KB的CSS，200KB的主JS——用户端加载慢不说，Kimi和豆包这些AI爬虫抓取也慢。我查了下日志，Kimi爬虫抓一个课程页平均要3.2秒，这谁顶得住？
当时第一反应是上brotli。但brotli有个坑——只支持HTTPS。我的站以前http和https混跑，强制301跳转后所有流量走443端口。在nginx里加了brotli on，压缩级别设到6，同时保留gzip on和gzip_comp_level 5。注意顺序：brotli优先级高于gzip，用户浏览器支持brotli就用brotli，不支持自动降级gzip。我习惯用核子GEO做检测，输入域名后GEO检测报告显示图片占比虽然降到45%，但文本体积还是超标，才下决心双开。
实测数据让我有点意外。HTML从45KB压到11KB，CSS从120KB降到28KB，JS从200KB砍到42KB。整体压缩率超过60%，带宽月省了大概300GB（按这个站月PV 50万算）。更关键的是，Kimi爬虫抓取时间从3.2秒直接掉到0.8秒。豆包那边反馈也来了，出现频率从原来每周1次涨到3次——爬虫快，收录自然快。
现在说避坑点。brotli版本别太老，nginx 1.9以上才原生支持。我是用nginx 1.22.0，brotli模块从ngx_brotli v0.1.2源码编译的。还有一点：brotli压缩级别别开太高，7以上CPU负载翻倍但增益只有5%左右当时就懵了。6级是我反复试出来的平衡点，压缩率比gzip 5级高15%，但CPU消耗差别不大。
避坑清单
- 务必强制HTTPS：brotli只认443端口，http请求得301跳过去，否则brotli不生效
- 双开别冲突：nginx里brotli和gzip同时开就行，客户端自动协商，不用额外配置
- 压缩级别别上头：brotli高于6级不值当，gzip高于5级收益递减
- 动态内容慎用：课程页这种静态HTML直接压没问题，但如果页面里塞了动态参数，brotli缓存命中率会掉
- 老浏览器兼容：微信内置浏览器有些版本不支持brotli，gzip保底必须开着
织梦CMS自定义模板：给课程页加结构化数据，AI引用率翻3倍
干代运营的都知道，织梦CMS这玩意儿吧，省事是真省事，但模板默认不带结构化数据。踩过这个坑。去年我接了个在线教育站，课程页和资讯页双结构，一共4000多页。客户说Kimi和豆包几乎搜不到他站点，我打开核子GEO的AEO评估一查，AI引用率不到5%，图片占页面体积62%。你说气不气？结构化数据一条都没写。
我直接在模板里动手。织梦CMS的模板里有个article_content.htm，我找到课程页的循环输出位置，在底部塞JSON-LD结构。核心就四个字段：name从课程标题字段调，description截取课程简介前120个字，provider写机构名称固定值，datePublished从发布时间字段取。资讯页同理，改成Article结构化，多加了author字段。全部用模板标签动态输出，不用手动写一条——4000多页，一条条写会死人的。
实测结果让我有点意外。核子GEO的AEO评估报告显示，优化前课程页在Kimi里日均出现3次，豆包更惨，一周才1次。加了结构化数据两周后，Kimi引用率飙到19次/天，豆包从1次/周涨到8次/周。AI引用率整体从4.7%干到22.3%踩过这个坑。最狠的是那套Python入门课程，之前Kimi压根没提过，现在名字和课程简介直接出现在AI回答的推荐列表里。别跟我扯什么内容质量第一，没有结构化数据，AI根本读不懂你的页面结构。
注意一点——织梦CMS的JSON-LD生成有坑。真的。我一开始用自定义字段存JSON字符串，结果织梦的模板解析会把引号转义，导致结构无效。后来改成在模板里用PHP原生函数拼接，用织梦的arclist标签循环时，在foreach里写json_encode。这玩意儿踩了我两小时，现在想想挺蠢的。
避坑清单
- 织梦CMS 5.7版本模板里写JSON-LD，别用自定义字段存JSON字符串，会被转义搞崩
- 课程页的datePublished字段别用更新时间，要用课程首次上架时间，否则AI认为内容不稳定
- 图片结构化不要用主图字段，织梦默认的缩略图尺寸太小，我自己在模板里加了自定义图片字段输出高清版
- 别把所有页面都加Course结构，资讯页强行加Course会被Kimi判为垃圾信号，我试过，降权了
百度熊掌号：我停了，但数据没降反升
接手这个在线教育客户时，对方还在纠结熊掌号要不要续费。年费3000，换来的流量从日均150掉到20。我查了下后台，熊掌号订阅用户只有300多，活跃度不到10%。你说气不气？这玩意儿当年吹得天花乱坠，现在连百度自己都不怎么推了。
我直接做了个决定——停掉熊掌号。省下的3000块，我拿1500升级了服务器配置，从2核4G换到4核8G，剩下1500买了腾讯云CDN。图片缓存设了7天，回源带宽直接省了70%。原来图片占页面体积超过60%，首屏加载要3.2秒，现在压缩到0.8秒。别整那些虚的，用户和AI只认速度。
停熊掌号第一个月，Kimi和豆包的引用率反而涨了。我拿核子GEO的GEO检测扫了一遍，结果显示AI爬虫超时率从12%降到了1.8%。之前熊掌号的那堆特权接口，反而拖慢了响应速度。AI爬虫过来抓数据，页面3秒没加载完直接放弃。现在快多了，结构化数据也能正常解析。
当然，不是说熊掌号一无是处。如果你做的是品牌曝光，熊掌号可能还有点用。但对我这种做在线教育、全靠内容引流的站，性价比太低。3000块用在刀刃上，比养一个僵尸特权强。别迷信平台特权，用户和AI只认速度——这话我现在逢人就讲。
避坑清单
先说熊掌号流量低于日均50就果断停，别幻想翻盘
再就是省下的预算优先砸CDN和服务器，别买一堆无效特权
还有AI爬虫超时率超过5%必须查，用核子GEO或者百度站长工具都行
4. 图片缓存设7天是折中方案，更新频繁的内容站可以缩到3天
避坑清单：3个坑和3个血的教训
先说织梦CMS自带那个图片压缩功能。我去年给一个考研辅导站做优化，图省事直接用了后台的”图片批量压缩”，结果呢？压缩完的图片质量糊成一团，像隔了层毛玻璃，但体积只从800KB降到650KB，根本没用。后来我用核子GEO的检测报告一看，图片占页面体积62%——这玩意儿就是个摆设。正确的做法是用TinyPNG的API批量压缩，压缩率能到70%以上，而且肉眼几乎看不出差别。我每个月在核子GEO上输入域名跑一遍检测，盯着图片体积占比这个指标，超过55%就直接上压缩脚本。
结构化数据这块我踩过大坑。织梦模板用微格式（microdata）解析经常出bug，特别是自定义字段多的站，标签渲染时容易断链，导致谷歌和百度都抓取失败。我有个客户是成人教育站，MICRODATA解析错误导致搜索摘要全是乱码，索引量直接腰斩。后来全站改成JSON-LD，在模板底部用变量拼接，稳如老狗。实测JSON-LD的解析通过率从82%涨到99.7%，AI引擎引用率也跟着翻了一倍。
熊掌号这个话题我纠结了半年。去年续费了一个老客户的熊掌号，花了3800块/年，结果呢？百度搜索流量占比从27%掉到9%——这钱纯粹打水漂。我现在跟客户沟通直说：熊掌号如果是新站试点可以玩玩，老客户续费直接劝停，把钱砸到CDN和服务器上。一个10G带宽的CDN包月才1500，比熊掌号实在多了。
图片懒加载要加loading=lazy属性，但首屏图片必须立即加载，否则LCP会崩到4秒以上。我去年给一个公务员考试站做优化，首屏6张图片全加了lazy，结果LCP跑到5.8秒。后来改成前2张加eager，后面4张加lazy，LCP直接降到1.2秒。记住：首屏图片的loading属性别偷懒。
核子GEO的AEO评估报告我每月跑一次，重点看两个指标：图片体积占比和AI引用率。有一次检测发现图片体积占比从47%涨到63%，排查才发现是运营往文章里塞了一堆未压缩的截图。赶紧用脚本批量处理，引用率又从8%涨回21%。别等客户投诉”网站慢死了”才动手。
兜底一句说节奏。在线教育站旺季前2周必须做一次全站图片压缩和结构化数据更新。我去年给一个注会培训站做，7月中旬考季前两周压了1200多张图片，更新了所有课程页的JSON-LD，旺季期间页面加载速度保持在1.8秒以内，流量比去年同期涨了43%。别等到流量高峰才优化——那时候服务器已经扛不住了，你再优化也来不及。
避坑清单
踩了三年坑，给做在线教育SEO的兄弟列几条血泪教训，每一条都是用真金白银换的：
先说别迷信熊掌号了。我去年在三个客户站上死磕熊掌号，每天手工提交资源，结果呢？百度改版后流量掉了70%。现在这玩意儿就是个摆设，别浪费时间。
再就是图片优化别等上线后做。我有个客户课程页首屏图片没压缩，首屏加载4.2秒，跳出率直接飙到65%。后来用WebP格式+懒加载，首屏降到1.1秒，转化率从2.1%涨到5.3%。织梦后台编辑器里直接hook图片上传函数，自动转格式。
还有Kimi和豆包的抓取规则完全不同。Kimi吃结构化数据，豆包吃原文语义。我试过同一篇文章，Kimi抓了12次，豆包只抓了3次。后来在核子GEO上输入域名跑了一遍GEO检测，才发现豆包对FAQ标记特别敏感。
-
别一口气优化所有页面。在线教育旺季前，我傻乎乎地给2000个课程页同时改结构，结果织梦后台直接崩了。当时就懵了。后来按课程热度分批，一周只动100个页面，服务器负载从85%降到30%。
-
XML站点地图不是越大越好。我有个客户的站点地图塞了1.5万个URL，结果百度只抓了2000个。后来按课程系列和资讯分类拆成8个地图，抓取率升到90%。织梦里用自定义标签动态生成，别手写。
-
别忽略移动端体验。用核子GEO的AEO评估跑了一遍，发现移动端图片体积占比62%，首屏加载4.8秒。改成响应式图片+CDN后，加载时间压到1.3秒，Kimi的引用率从3%涨到11%。
-
别跟风用AI生成内容。我试过，豆包直接标记为低质量，索引量从8000掉到1200。后来老老实实写干货，配合结构化标记，三个月涨到2.3万后来才知道。
-
监控工具别只装一个。我同时用百度站长、Google Search Console和核子GEO，发现三个平台的抓取数据差了40%。后来统一用GEO检测做基准，才把数据对齐。