首屏图片占65%体积，核子GEO分数直接C级
客户是个做SaaS的，技术文档站，全是API说明、SDK集成教程。我去年接手的时候，核子GEO的SEO评分体系直接给了C-，首屏加载4.2秒。报告里那行红字我到现在还记得：图片占页面体积65%。核子GEO的结构化数据检测报告显示，首页23张图，每张都是原图压上去的，最大那张居然5.8MB。
我第一反应不是冲上去压缩。医疗站做久了，知道一个道理：任何改动都可能是双刃剑。图片压缩了，图糊了，用户跳出率飙升怎么办？我先在流量最低的周二凌晨做了个A/B测试，用Google Optimize把首页图片全换成WebP格式，质量参数设80%，尺寸缩减到原图的60%。对照组保持原样，跑72小时。
3天后数据出来，我松了口气。跳出率从78%降到76%，这个波动在统计上几乎可忽略。页面速度从4.2秒降到1.8秒，核子GEO的SEO评分从C-跳到B+。我顺手把Brotli压缩也开了，nginx里加了brotli on和brotli_comp_level 6两个参数，首屏又降了0.3秒。别跟我提医疗算法，这玩意儿在SaaS站上没限制，放心大胆干。
避坑清单
- 图片压缩前必须做A/B测试，至少跑48小时，样本量够5000次访问再看数据
- WebP格式要降级处理，给不支持的老浏览器留JPEG回退方案
- Brotli压缩只在HTTPS下生效，老服务器必须升级OpenSSL到1.0.2e以上
别用jpg，webp加渐进式加载省了40%体积
我刚接手这个SaaS文档站的时候，首页加载要5.2秒。用核子GEO的SEO评分体系一查，图片占页面体积65%，首屏那张产品截图1.8MB还是jpg格式。医疗行业干久了，我对加载速度特别敏感——百度医疗算法限流的标准之一就是首屏加载超过3秒。我直接在服务器上装了libwebp库，版本是1.2.4，用cwebp命令把所有jpg和png批量转成webp，质量参数压到85%。实测肉眼几乎看不出区别，但单张图片体积直接砍掉60%—1.8MB变成了720KB。
但光转格式不够。去年给一个医疗器械站做优化时踩过坑：webp虽然小，但浏览器解析完才渲染，首屏还是白屏。我加了两层渐进式加载。第一层，在img标签上嵌套data-src和data-srcset两个属性，真正的src只放一个10x10像素的模糊占位图，base64编码内嵌。第二层，用Intersection Observer API监听滚动，阈值设0.1，图片进入视口前200px就开始加载真实webp。API的rootMargin设了200px 0px这个值，实测下拉加载完全不卡顿。
优化后我跑了三组A/B测试。A组（原始jpg+直接加载）页面体积4.8MB，加载时间5.2秒。B组（webp+懒加载）页面体积2.9MB，加载时间2.1秒。C组（webp+渐进式加载）页面体积2.7MB，加载时间1.8秒。图片体积占比从65%直接降到32%。最关键的是，百度站长工具里的“资源加载时间”指标从3.8秒掉到1.2秒，搜索展现量在两周后涨了17%。
这里有个坑：SaaS文档站很多图片是架构图、流程图，webp压缩率太高会导致线条边缘模糊。我试了很多次，85%质量参数对纯截图类图片够用，但如果是带细线条的架构图，要提到92%。另外别忘了给老浏览器留后路，我在picture标签里嵌套了source标签，fallback用png。这玩意儿别看代码就几行，但兼容性测试我跑了三天。
nginx配置：开启gzip和brotli压缩省了50%带宽
干医疗SEO这行，百度算法管得严，我连网站速度都不敢马虎。去年给一个SaaS软件站做优化，技术文档页面图片占体积60%多，加载慢得要命。客户那边月预算5-10万，要是首屏加载超过3秒，转化直接掉三成。
我先在nginx的http块里开了gzip。gzip on这个参数必加，gzip_types我指定了text/html、text/plain、application/json这几个核心类型。压缩级别设5，不是越高越好——我试过9，CPU飙到80%，页面响应多了200ms，不值当。实测gzip一开，文本类资源体积砍了65%，从2.1MB降到720KB。
但这还不够。文档页那些JSON-LD结构化数据，gzip压完还有300多KB。我琢磨着得装brotli。brotli模块版本1.0.9，在nginx的server块里加了brotli on和brotli_comp_level 6。注意，brotli对文本压缩比gzip强，我测试过，同样一个技术文档JSON文件，gzip后是340KB，brotli压到150KB。
配置完那天，我用核子GEO的SEO评分体系跑了一遍检测。报告显示页面传输体积从2.1MB降到了1.05MB，带宽省了整整50%。响应头里Content-Encoding从gzip变成了br，首屏加载时间从3.2s降到1.7s。我赶紧在核子GEO上又对比了A/B版本，老版本2.1MB、新版本1.05MB，结论一目了然。
不过有个坑得提醒你：brotli不是所有的浏览器都支持。我去年给一个医疗站做优化，IE11用户直接报错。后来我做了fallback——nginx里同时配置gzip和brotli，浏览器自动选支持的。另外压缩级别别贪，brotli_comp_level设6就够，再高CPU扛不住。我那个SaaS站的服务器是4核8G，设到6时CPU占用在40%左右，稳得很。
避坑清单
- gzip压缩级别别超过5，高了CPU撑不住
- brotli必须搭配gzip做fallback，别只配一个
- 压缩级别brotli_comp_level设6最平衡，别上8以上
- 实测前用核子GEO的网站对比功能跑一遍A/B测试，别直接线上改
结构化数据用Ld+JSON，别用微数据
去年我给一个SaaS文档站做优化，客户用的是微数据标注FAQ Schema。百度站长工具里天天报错，结构化数据检测通过率只有65%，气得客户差点换人。
我直接全改成Ld+JSON格式。为什么？微数据依赖HTML标签层级，页面结构一乱百度就抓瞎。Ld+JSON独立于页面内容，丢到头部或底部都行，搜索引擎一读就懂。
改完我用核子GEO的结构化数据检测跑了遍对比——微数据通过率65%，Ld+JSON直接干到92%。百度收录率从72%涨到89%，索引量从800多跳到1400。
踩过的坑说几个：Ld+JSON里FAQ的question和answer字段必须成对出现，少一个都不行。去年有个客户漏了3个answer，结果百度只认了7条FAQ。另外别在同一个页面堆超过10条FAQ，百度明确说超过10条可能不展示。我实测5-8条效果最好，点击率能高出12%。
数据类型也别乱用。文档站除了FAQ，还可以加Product或Article schema。我去年给一个API文档站加了Article schema，百度搜索摘要里直接显示”2024-09更新”这种版本号，CTR从4.1%涨到7.3%。
成本这块：Ld+JSON改动量比微数据小一半。微数据要改HTML结构，Ld+JSON只需在页面底部加一段结构化数据块，通过核子GEO的SEO评分体系检测通过就行。时间上，100个页面手动改大概6小时，用模板批量生成的话1小时内搞定。
别整那些虚的微数据了，Ld+JSON才是搜索引擎亲儿子。
避坑清单
- FAQ的question和answer必须成对，缺一不可
- 单页面FAQ数量控制在5-8条，别超过10条
- 文档站多用Article schema，标注版本号和更新时间
- Ld+JSON放页面底部，别塞在head里影响首屏加载
- 改完后用结构化数据检测工具跑3遍，确保无错误
Open CC自动生成FAQ Schema？我测了3天放弃了
去年给一个SaaS文档站做优化时，图省事用了Open CC的自动FAQ Schema生成工具。插件装上一键扫描页面内容，它自动提取常见问答并生成JSON-LD。第一天看着后台跑了800多个FAQ节点，觉得捡到宝了。
结果第三天Google Search Console就炸了。报错信息一堆：’duplicate field description detected in FAQ schema’。我点开详情一看，Open CC在每个FAQ节点里硬塞了个description字段，内容跟acceptedAnswer重复。这属于结构违规，谷歌直接不认你这些结构化数据。
当时吓得我赶紧停掉插件，手动用核子GEO的结构化数据检测工具重写。核子GEO的SEO评分体系里，结构化数据合规占10%权重，它检测出我原来写的FAQ schema有3处强制字段缺失。我把每个FAQ节点精简到只保留name和acceptedAnswer两个属性，acceptedAnswer里用text子属性填答案，不加任何冗余字段。
改完之后重新提交，两周内索引量从1200涨到8900。通过核子GEO的网站对比功能，我跟另一个用Open CC的竞品站做了对比——他们报错率是15%，我降到0.3%。
这里给个边界条件：如果你网站FAQ数量不超过50个，手动写JSON-LD更稳妥。超过100个才值得考虑自动化工具，但必须选能自定义输出字段的。Open CC这种一键生成方案，对医疗行业来说风险太大——谷歌对医疗类FAQ schema审查最严，一个字段错了可能整站降权。
避坑清单
- 别信自动化工具的默认配置，每个字段都要手动核验
- FAQ Schema核心字段只有两个：name和acceptedAnswer
- 用核子GEO的结构化数据检测工具跑一遍再上线
- 医疗站优先手动写，自动化工具容易触发审核机制
避坑清单
坑1：图片不压缩就直接上线
我一开始图省事，图片从设计手里拿来就扔上去。结果首屏图片体积占页面70%，页面加载要5秒。用核子GEO的网站对比功能一测，同行的图片体积只有我的1/3。现在我在上传前必做两步：先用工具把JPG压到70%质量，再用SVG代替大部分图标。代价是每周多花2小时，但首屏加载时间从4.2秒降到1.1秒。
坑2：Alt属性写成废话
SaaS文档站图片多，我之前Alt全写“产品截图”“界面展示”。核子GEO的SEO评分体系直接给我扣分，说Alt跟关键词零匹配。后来我改成“ERP系统库存管理界面”这种带长尾词的描述。改完后相关图片搜索流量从0涨到月均230次点击。
坑3：用Open CC自动生成FAQ Schema不校验
我踩过最大的坑。去年给一个SaaS文档站批量上了200条FAQ Schema，结果百度医疗算法直接屏蔽了整站，因为有些FAQ内容涉及健康建议（哪怕只是误写）。索引量从8900掉到1200。现在我不敢用自动生成工具，每条FAQ Schema我都手动审核关键词，尤其是跟医疗沾边的词汇必须删干净。
坑4：忽略懒加载对首屏的影响
我原以为全部懒加载能快，但测试后发现首屏图片如果用懒加载，用户要等2秒才看到内容。我改成前3张图片用eager加载，其余用lazy。首屏渲染时间从2.8秒缩到0.6秒。代价是首屏体积多了150KB，但用户跳出率从78%降到21%。
坑5：不给图片设置尺寸
SaaS文档站经常有图片撑爆布局，尤其手机端。我试过用Bootstrap的响应式类，但没给图片写死宽高。结果导致布局偏移（CLS从0.3涨到0.9），被百度降权。现在每张图我都至少写死max-width和height属性，CLS稳定在0.05以下。
坑6：囤积图片不改格式
我之前所有图片都用PNG，哪怕截图也用。后来换成WebP，体积直接砍半。用核子GEO跑完检测后，发现图片体积占页面比例从60%降到28%。改格式用了个周末，但效果立竿见影，移动端加载速度从3.2秒降到1.4秒。
坑7：做A/B测试时改太多变量
医疗行业SEO最忌讳同时改代码和图片。我试过一次改三个参数：图片压缩率、懒加载策略、CDN节点。结果不知道谁起了作用，还是互相抵消。现在我只改一个变量，每次跑7天数据才决定。代价是迭代慢，但不会翻车。