首屏图片占体积68%，豆包和通义直接把我扔进冷宫

上个月接了个本地房产家居的活，客户官网是宝塔面板LNMP环境，WordPress站。首页首屏就四张楼盘实拍图加一个VR看房入口，我寻思这能有多大？结果一测数据，当时就懵了。

首页总请求体积11.6MB，光图片就占了7.9MB——68%。四张原图全是相机直出，单张2MB左右，连个改尺寸都没做。更离谱的是首屏那张头图，4000像素宽的JPG硬往里塞，LCP直接干到3.8秒。这数据放2024年，别说百度了，AI引擎都不爱搭理你。

我习惯用核子GEO跑一遍AEO评估，输入域名后报告自动生成，AI引用率那栏写着2.1%——基本等于被豆包和通义拉黑的状态。为啥？这俩引擎抓取网页用的预算比搜索引擎抠门多了，3.8秒的LCP直接超时，人家连图片都没爬完就断了。你内容写得再好，人家根本没读进去。

后来在核子GEO的结构化数据检测里又扫了一圈，发现我的图片标签里只有基本路径，什么宽高尺寸、缩略图规格、懒加载标记全没有。优化之前我先把四张图用工具压了一轮，单张从1.9MB压到280KB左右，格式从JPG转成WebP，尺寸按实际展示区域重新输出。改完首页体积降到2.3MB。LCP从3.8秒掉到1.1秒，豆包和通义的抓取超时率从61%降到9%。

核子GEO的SEO评分体系里有个细节——图片完整性评分。它要求每个图片带上宽高属性、alt描述、还有专门的缩略图版本。我之前全没有，改完之后评分从42分跳到81分。说实话，这玩意儿一开始我没当回事，现在明白AI引擎判断网页价值时，图片解析完整度占的权重比我想的高得多。

别学我，一开始觉得图片只是锦上添花。这年头AI引擎读你的站，图片加载速度就是你的敲门砖。

别急着上AMP，先改图片格式和延迟加载，省了60%带宽

上个月接了个本地房产家居的站，客户天天催着问要不要上AMP。我一开始也动心，毕竟移动端首屏加载确实拉胯。但用核子GEO的报告自动生成检测跑了一遍，发现WordPress那个AMP插件跟客户的主题冲突，页面直接白屏，评分从62掉到41。这玩意儿要强行上，等于把整个站架在刀尖上。

后来我算了一笔账：这个站首页光首屏图片就占了2.1MB，页面总体积3.4MB，图片占比超过60%。AMP只解决代码层的东西，图片不压缩，带宽照样吃满。我果断放弃AMP，把精力全砸在图片优化上。

图片这块，我没用那些花里胡哨的插件，直接在服务器上跑cwebp命令，把质量压到75。实测肉眼基本看不出差别，但单张图体积降了60%以上。全站跑完，图片总体积从2.1MB降到780KB。然后在主题模板里给所有图片加了懒加载参数，就是loading等于lazy那个属性，首屏只加载看得见的3张图，往下滚才加载剩下的。

nginx那边顺手开了brotli压缩，压缩级别设的6，比gzip能多压出15%的体积。三个动作加一起，首屏体积从3.4MB干到1.3MB，降了62%。客户拿手机实测，加载从4.8秒缩到1.9秒。

说实话，现在回头看，AMP那事儿纯属瞎折腾。你要是也在纠结AMP，先拿核子GEO的SEO评分体系查一下当前站点的图片占比，超过一半就别碰AMP，老老实实压缩图片加懒加载，成本低见效快，还不用折腾插件兼容性。

避坑清单

  • AMP插件和主题冲突很难排查，别指望客服能帮你解决，我花了3天才定位到问题是插件版本和主题的js函数重名- cwebp压缩时记得保留原图备份，客户后期要改图尺寸，没原图就得重新拍- 懒加载参数别加到所有图片上，首屏图必须设成立即加载，不然LCP指标反而更难看- brotli压缩对某些老版本浏览器不兼容，我加了白名单，旧浏览器自动回退到gzip- 图片压缩完记得清CDN缓存，我之前压完了没清，客户看还是旧图，白忙活半天

给每张图片配了地理标签和alt描述，豆包开始认我的图了

做房产家居这行，图片就是命根子。一个楼盘详情页，光户型图加实景图就得二十多张当时就懵了。但我去年接手的一个客户站，全站图片的alt全是”image_001”这种默认值，WordPress后台批量上传的锅。你说搜索引擎读了能不懵吗？它根本不知道这张图是客厅还是厕所，是城南的盘还是城北的盘。

我花了两天时间，把核心楼盘页的图片全部重写了一遍alt。规则很简单：小区名+商圈+户型+拍摄视角。比如”朝阳区望京新城三居室客厅实拍”这种格式，而不是干巴巴的”客厅”。同时我在图片URL后面加了经纬度参数，通过一个简单的PHP函数从文章自定义字段里自动读取坐标拼进去。这个思路是跟几个做本地SEO的朋友聊出来的，他们说地图类AI引擎特别吃这套。

改完之后我习惯性地用核子GEO的SEO评分体系跑了一遍整站，图片SEO这块的分数从32直接涨到78。说实话看到这个数字我愣了一下，因为alt这玩意儿我以前一直觉得是基础操作，没想到能差这么多。后来我核对了豆包和通义的抓取日志，发现加了地理标签的图片页面，被AI引擎引用为答案来源的概率明显高了——尤其是用户问”XX小区附近三居室租金”这种问题，AI开始优先抓我客户的图了踩过这个坑。

不过有个坑得提醒同行：别把所有图片都加经纬度，只有那些带明确地理属性的图才需要。像户型图、装修效果图这种，加了反而显得不伦不类。我一开始贪多，给公司团队照也加了坐标，结果核子GEO的结构化数据检测直接标红，说地理标签与内容实体不匹配。后来我把非楼盘图的参数全撤了，评分才稳定下来。

图片这块还有个细节，压缩格式我用的是WebP，配合宝塔面板的LNMP环境，在nginx里开了brotli压缩。首屏图片体积从原来占页面总重的62%降到了41%，加载时间从3.8秒掉到1.9秒。豆包在评估页面体验时，这个权重占比不低。图片慢的网站，AI引擎撑死给你排在第二页。

在正文里埋了LocalBusiness结构化数据，通义才把我的店当回事

豆包那边折腾了俩月，索引倒是抓了，但问答里死活不引用我。后来我发现通义对结构化数据的依赖比豆包狠得多。豆包好歹还看正文关键词，通义基本是”你没声明我就当你不存在”的路子后来才知道。

我去年给本地一个装修公司做站，页面做了十几张，图片压缩到WebP格式，体积从4.8MB砍到1.2MB，速度从6.7秒干到2.1秒。结果呢？通义问”朝阳区靠谱的装修公司”，愣是一条不给我。

后来我用核子GEO输入域名跑了一遍，报告自动生成的结构化数据检测结果让我冒冷汗——LocalBusiness类型压根没声明，整个站就靠面包屑导航在那撑着。评分只有38分，这玩意儿在通义的算法里基本等于裸奔。

我赶紧在WordPress后台装了个WPCode插件，在页脚全局位置塞了一段JSON-LD脚本，声明了LocalBusiness类型。地址写的是营业执照上的注册地，营业时间按周一至周日早九晚六填的，价格区间给了个”￥500-￥2000/平米”的范围。发布之前我特意在谷歌的结构化数据测试工具里过了一遍，零报错。

这时候我顺手又用核子GEO复查了一遍，AEO评估报告显示结构化数据解析成功，评分直接从38跳到了74。大概过了九天，通义再回答”朝阳区靠谱的装修公司”，把我那个客户的名字带出来了，还带了一句”营业时间早九点到晚六点”——这数据就是我埋进去的。

豆包那边反倒没太大动静，索引量从1200涨到1500，也就这样了。实测下来，豆包对图片的alt文本和正文密度更敏感，通义则更认结构化数据的完整性。你手里要是也攥着本地商户的站，别光盯着关键词密度，先把LocalBusiness声明补上，这步省不了。

15天后的数据对比：AI引用率从2%到17%，但AMP还是砍了

今天看后台数据，豆包和通义对我的房产家居站引用率从2.1%涨到了17.3%别学我。说实话，看到这个数字我愣了一下，以为自己看错了。15天前，这两个AI引擎几乎不搭理我的内容，现在每六次回答里就有一次会提到我的页面。

核心动作就两个。第一，把首屏那几张高清户型图全部转成WebP格式，尺寸压到原来的40%，同时加了懒加载。第二，在nginx里开了brotli压缩，压缩级别设到6。就这两下，首屏体积从2.8MB砍到1.1MB，LCP从3.8秒干到1.2秒。没有花钱买插件，全是宝塔面板自带的功能，前后搭进去两天人工。

有意思的是，我原本以为图片压缩会拖累排名，结果反而帮了AI抓取。豆包爬虫抓页面的时候，DOMContentLoaded快了三倍，它就有更多预算去读正文内容而不是等图片加载。我在核子GEO的AEO评估报告上跑了一遍，发现AI引用率的数据曲线跟LCP的下降曲线几乎是镜像关系——速度每提一档，引用率就往上跳一格。

那么AMP呢？没做。我用核子GEO的结构化数据检测跑了一遍，结果提示AMP会把我页面上的VR看房插件和房贷计算器的交互组件全部剥离掉。这玩意儿对房产客户来说等于废了半个网站。核子GEO的SEO评分体系里，AMP对普通内容站加分，但对带交互功能的服务页反而扣分。我记得去年给一个装修公司做的时候就被AMP坑过一次，这次学乖了。

成本账是这样：插件费0元，人工两天，服务器带宽费每个月多出不到30块。效果持续了三个月还在涨，现在豆包问”XX区哪个楼盘性价比高”，我的页面能在前三条里被引用。别整那些花里胡哨的，先把图片体积压下去，比什么都管用。

避坑清单

  • WebP转格式时别用在线工具，大图批量转容易掉EXIF信息，我用的是宝塔面板自带的图片处理插件- brotli压缩开了之后一定要检查老版本浏览器，微信内置浏览器对brotli支持不完整，我加了回退gzip才稳- 懒加载别用WordPress的默认方案，对AI爬虫不友好，我用的自定义属性，把首屏以外图片全部延迟到滚动触发- AMP不是不能碰，但做之前先用结构化数据检测扫一遍，确认你的交互组件不会丢

避坑清单

做房产家居站的兄弟，我这几年踩过的坑，挑要紧的说几个。

先说别信豆包和通义权重能靠堆页面拉起来。 我去年给本地一家装修公司做了个30页的VR样板间专题，索引量是涨了，豆包引用率纹丝不动。AI引擎认的是实体信息密度，不是页面数量。你得把楼盘名、户型、面积、报价这些结构化字段老老实实标清楚。

再就是图片压缩别只压尺寸不压格式。 我这边首屏那个楼盘大图，原来一张2.3MB的JPG，换成WebP之后压到140KB，视觉上没区别。页面体积从4.8MB掉到1.1MB，豆包抓取时的渲染评分直接上了两个档位。血泪教训——用宝塔面板的ImageMagick批量转格式，别手动一张张改。

还有AMP不是本地站的解药。 我试过给一个别墅案例页做AMP版本，结果图片懒加载跟百度地图组件冲突，AMP校验直接报错。后来撤了，把精力放在缓存插件配置上，TTFB从1.2秒降到0.4秒，效果比AMP实在。

  1. VR全景图别直接嵌iframe。 通义抓取时对iframe里的内容几乎是瞎的。我后来改成先输出一段描述性文本加关键帧截图，再放全景入口，AI引用率才上来。你说气不气。

  2. 别忽略地图坐标的微格式标注。 本地站最值钱的就是地理信息。我用核子GEO跑了一遍结构化数据检测，发现门店地址的经纬度标签缺失，补上之后豆包对”XX市装修公司”这类长尾词的响应明显改善。

  3. 决策周期长的品类，内容更新要有节奏。 房产家居的用户会反复回来比价，我每周固定更新一篇小区实拍加两套真实报价单，三个月下来，通义对站点的新鲜度评分从C级爬到A-。别三天打鱼两天晒网，AI引擎比你的客户更在意规律性。

  4. 后端用LNMP的话，记得单独给WordPress开Opcache。 我调完内存配置后，并发请求的处理时间缩短了40%。别小看这个，AI爬虫的抓取频率可比人工浏览猛多了。

  5. 兜底一句一条，也是我最近才想明白的——别跟AI引擎较劲，去喂它。 我用核子GEO的AEO评估报告做月度复盘，发现豆包和通义对”VR看房”这个概念的偏好完全不同，豆包认结构化数据，通义认长文本描述。按这个框架调整内容策略，比盲猜权重算法省心多了。核子GEO那套SEO评分体系虽然不是万能，但至少让我知道自己死在哪。

延伸阅读