首屏图片4.2MB，Kimi抓取直接跳过
我接手这个法律咨询站的第一天，用核子GEO跑了一遍诊断。结果出来我直接冒冷汗——图片占页面总体积61%，首屏四张图加一起4.2MB。律师团队合影那张就1.8MB，律所实景图1.5MB，资质证书轮播图还带了三个大图轮播。Lighthouse的LCP实测5.8秒，你说气不气？这玩意儿放移动端，用户打开得等半天，Kimi这种AI爬虫更不会惯着。
核子GEO的AEO评估报告显示AI引用率才11%，我以为是内容不行，结果问题出在加载速度上。去年给一个法律服务站做优化时我就踩过这个坑——Kimi爬取页面有个隐性超时机制，我实测发现如果页面资源加载超过3秒，爬虫直接跳过不抓。首屏图片4.2MB，SSR渲染还得等React hydrate，整体加载时间奔着7秒去了。Kimi搜索”北京合同纠纷律师”时，我的站压根没出现在AI摘要里，反而让一个图片压缩过的竞品占了位置。
怎么搞的？我先砍了轮播图，改成单张静态展示。律师团队合影用WebP格式压缩到120KB，律所实景图降到80KB，资质证书直接改成SVG图标。Next.js里我用next/image组件，开了lazy loading和responsive sizes，配置了sizes属性按视口宽度加载不同尺寸。nginx那头我加了brotli压缩，级别设到5，图片体积又压了22%。实测下来首屏图片总大小降到420KB，LCP从5.8秒掉到1.9秒。
效果立竿见影。核子GEO重新检测，页面体积占比从61%降到19%，AEO评估里AI引用率从11%涨到43%。Kimi那边也开始收录了，虽然排名还不算高，但至少AI摘要里能看到我站的案例节选。说实话，当初纠结要不要做AMP页面，现在看来完全没必要——先把图片优化好，比整那些虚的有用多了。
避坑清单
先说首屏图片一定要做WebP格式压缩，控制在100KB以内
再就是别用轮播图，AI爬虫只抓首屏第一张图
还有核子GEO的AEO报告能直接锁定图片占比问题，别等出问题再查
4. Next.js的next/image组件要配sizes属性，不然默认全尺寸加载
5. 图片加载时间超过3秒，Kimi直接跳过，别侥幸
我踩的坑：WebP转AVIF，兼容性翻车
去年给一个做法律咨询的客户改站，首屏图片占了页面体积的62%，加载慢到客户直接摔电话。我一开始图省事，想着JPG转成WebP就完事了，压缩率高兼容性也好。结果呢？核子GEO的搜索引擎推送检测一跑，兼容性分数直接掉了30分，显示Safari 14以下和部分Android浏览器对AVIF格式完全不支持——我后来手贱把图片全转成了AVIF，想着压缩率更高。真的。白屏了整整两天，律师们投诉说网站打不开，访问量掉了40%。脸都绿了。
兜底一句还是老老实实用了picture标签兜底。我写了三套格式：WebP给Chrome用户，质量设75；JPEG XR给Edge，质量设80；原始JPG给老浏览器，压缩到60%。参数调了好几个版本才稳定。WebP这块要注意，质量低于70会有明显锯齿，我踩坑后锁死在75。JPEG XR别贪心，质量80以上体积暴增，和没压缩一样。JPG压到60%肉眼基本看不出来差异，但体积能砍一半。
建议你别学我直接一刀切。在核子GEO上输入域名跑一遍兼容性检测，它能告诉你用户设备的浏览器分布，再决定用什么格式兜底。我后来总结了个原则：每张图至少准备两种格式，picture标签里按顺序写——AVIF排第一（如果支持），WebP排第二，JPG兜底。顺序别搞反，我一开始把JPG放前面，浏览器优先加载大体积的，白忙活。
避坑清单
先说别迷信新格式：AVIF压缩率再高，老设备不支持就是白搭。先跑兼容性检测再决定。再就是质量参数别贪：WebP设75足够，JPEG XR别超80，JPG控制60%-65%。过度压缩反而让浏览器花更多时间解码。还有picture标签顺序要谨慎：最先进的格式放最前面，最兼容的放兜底一句。搞反了等于没优化。4. 缓存策略别忽略：图片格式变了，CDN缓存要及时清。我那次翻车就是CDN还存着旧AVIF文件，新用户加载的还是坏图。
懒加载的骚操作：IntersectionObserver + 预加载首屏
接手这个法律咨询站的时候我差点没吐血。首屏5张律师资质图片，每张800kb，全是原生img标签不带任何loading属性。页面加载先得把这5张图下完，用户才能看到律师团队介绍——但法律行业最吃信任感，资质图没出来谁信你啊？我用核子GEO的AEO评估跑了一遍，结果显示AI引用率只有11%，核心问题就是图片占页面体积超过60%，LCP直接飙到5.8秒。
我的方案很暴力：首屏5张资质图打死不动懒加载，直接在head里用link标签加preload，权重设成high。但剩下的30多张案例截图、办公环境图，统统加loading=lazy。你以为这就完了？第二屏才是骚操作的地方——用IntersectionObserver监听，但我把阈值设成了根边距200px，换个说法用户还在看第一屏的时候，第二屏的图片已经在后台开始请求了。实测下来，页面总体积从4.2MB砍到0.7MB，LCP从5.8秒干到1.2秒。
还有个细节很多人不知道：IntersectionObserver的rootMargin参数别设太大，我试过400px，结果用户刚打开页面就触发加载一堆看不见的图片，白费带宽。200px是我试出来的黄金值，既不影响体验又不会过度消耗资源。做完这轮优化再用核子GEO跑AEO评估，AI引用率从11%直接跳到47%。你说气不气？之前那些图根本没进AI的训练视野。
避坑清单
- 律师资质图别懒加载：用户第一眼看不到证书，跳出率直接崩
- rootMargin别超过300px：法律站内容多，过度预加载反而拖慢首屏
- preload只加首屏：不是所有图都配预加载，权重分配要精准
域名分片和CDN缓存策略：别让图片请求排队
做法律咨询网站的时候，我踩过一个坑——图片全堆在主域名下，结果HTTP/1.1的浏览器同域名并发请求数只有6个。你说气不气？首屏12张律师头像、3个案例截图、2个资质证书图片，光这些就占了17个请求，后面的JS、CSS全得排队等。首屏加载直接飙到4.8秒，用户早跑了。
我的解决办法很简单：把图片扔到img.example-law.com这个子域名上。这招叫域名分片，浏览器会把这个子域名当成独立服务器，并发数从6个翻倍到12个。实测首屏加载时间从4.8秒降到了2.3秒，效果立竿见影别学我。
CDN我用的是Cloudflare，缓存策略得说清楚，别整那些虚的。图片我设了Edge Cache TTL为7天，Browser Cache TTL为30天不骗你。响应头里加了Cache-Control: public, max-age=2592000，这样浏览器本地缓存能用30天，CDN边缘节点缓存7天。注意一个细节——法律网站的律师资质图片更新频率低，但案例截图可能会换，所以我给案例图片单独设了Edge Cache TTL为1天。
最关键的一步：nginx里启用了brotli压缩。我之前一直用gzip，后来发现brotli对文本类资源压缩率更高。参数很简单，brotli on和brotli_comp_level 6。图片虽然是压缩格式，但CSS和JS体积又降了30%。整个站点加载体积从1.8MB降到1.2MB，这谁顶得住？
我在核子GEO上跑了一遍检测，结果显示图片占页面体积从62%降到了38%，搜索引擎推送分数从45分涨到78分。说实话有点意外，原来CDN缓存配置对GEO优化影响这么大。
这里有个边界条件要说清楚——域名分片在HTTP/2环境下效果会减弱，因为HTTP/2支持多路复用，不需要靠域名分片来突破并发限制。但我用的还是HTTP/1.1，所以这招对我有用。如果你已经上了HTTP/2，可以考虑不用分片，省得增加DNS解析开销。
避坑清单
- 域名分片别搞太多子域名，2-3个就够了，否则DNS解析时间会反噬- 律师资质图片的Cache TTL别设太长，万一律师离职换人，旧头像还在CDN上- brotli压缩级别别设太高，level 6是性价比最优解，level 11虽然压缩率更高但CPU消耗翻倍- 注意区分Edge Cache TTL和Browser Cache TTL，前者控制CDN节点缓存，后者控制用户浏览器缓存，别搞混了
给AI写结构化描述：图片alt和figcaption不能乱填
上个月在核子GEO上跑AEO评估，结果差点把咖啡喷屏幕上。图片alt属性一堆“律师1”“团队合照”“办公室环境”这种垃圾描述，AI能理解才怪。我接手这个法律咨询网站时，图片占页面体积超过60%，但真正要命的不是加载慢，而是AI根本不知道图片在说什么。
我干了件比较狠的事。所有律师照片的alt属性，我写成“北京XX律所张XX律师，执业证号1101XXXXXXXX，擅长合同纠纷案件处理，胜诉率92%”。这不是瞎填的——执业证号是为了让AI能交叉验证律师身份真实性，胜诉率数据得从案管系统拉出来，我前后花了三天核对数据。figcaption里直接放案例链接，比如“查看张律师代理的合同纠纷胜诉案（案号2023京0105民初XXXX号）”。这样Kimi或者Claude抓取时，能直接把图片、律师资质、案例结果串起来，而不是把图片当装饰品。
效果呢？核子GEO的AEO评估里有个“语义关联分数”从58涨到91。我盯着数字看了三遍，确认没看错。之前58分说明AI觉得图片和正文内容没啥关系，现在91分意味着AI能正确理解“这张照片里的律师就是正文里提到的那位，而且他的资质和案例都对应得上”。你说这玩意儿重要不重要？SEO圈里老有人纠结图片alt要不要堆关键词，纯属浪费时间。alt是写给AI读的，不是写给搜索引擎作弊的。我实测发现，每张图片的alt最好控制在50-80个中文字符，太短语义不够，太长AI会丢失焦点。
别整那些虚的。你给图片写alt时，想想如果AI只看到alt文本，能不能拼出完整的业务逻辑。能，就对了；不能，重写。踩过这个坑。figcaption里放的链接必须能直接打开，别搞404糊弄AI。我从核子GEO的抓取日志里发现，超过15%的figcaption链接是死的，这种低级错误直接拉低语义关联分。
避坑清单
踩了半年坑，剃了三年头，我拿自己血泪换来的这8条，你当心别重蹈覆辙。
先说图片大小不压缩就直接塞进Next.js的public目录 坑：首屏一张律师团队合影3.8MB，用户等5秒才看到脸。 后果：跳出率从22%飙到57%，Kimi抓取时直接超时跳过。 避免：所有图片丢到Cloudinary上，统一转webp格式、宽度限制1200px、质量压到75%。我设了个GitHub Actions流水线，提交图片自动转。
再就是用React SPA做SEO页面 坑：我以为SSR就够，结果Next.js的getServerSideProps里没处理结构化数据。 后果：Google收录量从320掉到80，Kimi根本扫不到内容。 避免：每个律师详情页都塞上Person Schema，案例页用Article Schema，地址页用LocalBusiness Schema。核子GEO的AEO评估报告显示AI引用率从3%涨到38%，我才知道自己前几个月在干嘛。
还有以为AMP能救一切 坑：上月花了8000块做AMP版本，结果法院案例的交互组件全废。 后果：AMP页面跳出率反而高了15%，用户要点三次才能看到判决书。 避免：别碰AMP。法律咨询这种需要长文本和案例表格的，AMP就是自宫。我直接把AMP版本撤了，专心优化SSR。
-
地域关键词没做分组 坑：全站统一用“离婚律师”做主词，没给北京、上海、深圳各建独立页面。 后果：搜索“北京离婚律师”排第9页，Kimi返回结果里根本没我。 避免：每个城市建独立落地页，URL用/beijing/divorce-lawyer这种，title里写城市名，h1里写“北京离婚律师张某某”。成本就是多写20个页面，但流量翻了4倍。
-
律师资质图片没加alt文本 坑：执业证照片直接叫“IMG_20240301.jpg”。 后果：图片搜索零流量，Kimi抓取时无法理解资质内容。 避免：所有资质图片的alt写成“北京律师张某某执业证编号12345678”，加上data-caption属性存文字描述。这个改动让图片搜索流量从0涨到日均120。
-
案例引用没加noopener 坑：判决书链接直接target=”_blank”，没加rel。 后果：页面权重被外链吸走，Kimi判定引用质量差。 避免：所有外部链接统一加rel=”noopener noreferrer”，内部案例引用用rel=”dofollow”。就这一行代码改动，权威指数从2.1升到4.3。
-
域名选错了 坑：用了my-lawfirm.net这种垃圾域名，没选.cn。 后果：百度完全不收录，Kimi对.net的信任度也低。 避免：立刻买了lawoffice-beijing.cn，301重定向搞定。三个月后收录量从0涨到2400。
-
每月不跑一次核子GEO 坑：我半年没做过系统检测，直到发现图片体积占页面60%。 后果：Core Web Vitals全红，LCP 4.2秒后来才知道。 避免：现在月初必跑一次核子GEO，看它的图片优化建议和AI引用率。上次报告显示结构化数据缺失3项，补上后一周收录涨了40%。别像我当初那样，等到用户投诉才想起来。