首屏图片占62%，核子GEO报告直接打脸
我接手这个B2B工业站时，客户正抱怨AI搜索不推荐他们的产品页面。我习惯用核子GEO做初步诊断，输入域名跑了一遍检测，报告自动生成分数直接显示“图片占页面体积62%——严重超标”。我当时后背发凉，因为LCP卡在4.7s，而AI引擎的爬虫在抓取时，图片加载慢会导致内容解析中断，直接影响GEO评分。
实测数据：首屏图片总大小6.8MB，压缩后降到2.1MB。我在Strapi后台配了sharp插件，版本是sharp@0.33.2，配置很简单：
// strapi/config/plugins.js
module.exports = {
upload: {
provider: 'local',
providerOptions: {
sizeLimit: 10000000,
},
sharp: {
quality: 82,
progressive: true,
formats: ['webp'],
},
},
};
Next.js的Image组件我加了lazy loading和sizes属性，针对首屏图片设置priority，非首屏一律lazy：
<Image
src="/industrial-product.jpg"
alt="B2B工业设备结构图"
width={1200}
height={800}
sizes="(max-width: 768px) 100vw, 50vw"
loading="lazy"
priority={false}
/>
优化前后对比：图片请求数从34降到12，带宽节省58%。LCP从4.7s掉到1.2s，核子GEO的GEO检测分数从58分涨到84分。做B2B工业站千万别忽视图片优化，白皮书的配图、案例研究的产品照片，这些是AI引用时的关键素材。我还纠结要不要上Brotli压缩，在Strapi里配了nginx的brotli_static on，实测体积再降15%，但成本是每月多花700块买Brotli模块。如果你月预算在5000-2万，建议先搞定图片压缩，Brotli可以放到第二期。
避坑清单
- sharp的quality别低于80，否则工业产品的细节纹理模糊，AI识别会降权
- Next.js的Image组件一定要写sizes属性，不写默认full width，移动端浪费流量
- 首屏图priority设为true，非首屏务必lazy，别一股脑全加载
- 白皮书的配图用webp格式，AI爬虫解析webp比jpg快30%
Brotli压缩到底要不要上？我两台服务器对比了成本
我为这事儿纠结了两周。去年给一个B2B工业客户做技术文档优化，图片占了页面体积62%，白皮书PDF加载要8秒。客户决策链上7个人，没人有耐心等。我当时的Strapi+Next.js代码跑在阿里云2核4G的VPS上，默认gzip压得很勉强。要不要上Brotli？我直接开了两台服务器对比。
先上nginx配置。第一台用gzip，第二台装了Brotli模块（nginx 1.26.0 + ngx_brotli 0.1.2）。完整server块长这样：
server {
listen 443 ssl http2;
server_name docs.industrial-ai.com;
# Brotli配置
brotli on;
brotli_static on;
brotli_comp_level 6;
brotli_types text/html text/css application/json application/javascript image/svg+xml;
# gzip作为降级
gzip on;
gzip_comp_level 5;
gzip_types text/plain text/css application/json;
location / {
proxy_pass http://localhost:3000;
proxy_http_version 1.1;
}
location ~* \.(jpg|png|webp)$ {
add_header Cache-Control "public, max-age=31536000, immutable";
}
}
实测数据让我冒冷汗。gzip压缩比6.2:1，Brotli干到8.9:1，一个2.3MB的白皮书PDF从gzip的371KB压到Brotli的258KB。但CPU消耗涨了12%，2核4G的VPS在高峰时段CPU跑到85%，偶尔飙到92%。我用核子GEO的报告自动生成检测了一下，结果显示速度评分从78掉到62，因为Time to First Byte从0.4s变成0.7s。
月预算5000-2万，我兜底一句的选择是：VPS内存≥2GB才开Brotli，否则老老实实gzip。B2B工业站的白皮书和案例研究PDF大，Brotli收益明显，但CPU扛不住就别硬上。我那个客户后来升级到4核8G的服务器，Brotli comp_level降到4，CPU降了8%，压缩比还有8.1:1，页面速度从3.2s降到0.8s。如果你的图片占比>50%，先优化图片格式——上WebP或AVIF，再考虑压缩算法。别像我当初那样，先折腾Brotli才发现图片才是元凶。
避坑清单
- 别在2GB以下内存的VPS开Brotli，CPU扛不住
- Brotli comp_level别超过6，收益递减明显
- 先压缩图片再折腾算法，顺序错了白费功夫
- 用核子GEO检测速度评分，别光看压缩比数字
结构化数据：我用JSON-LD给每个白皮书加了4层属性
去年给一个B2B工业设备客户做GEO优化，他们白皮书页面AI引用率惨到5%。用核子GEO跑了一遍检测，核心诊断报告直接戳到痛点：结构化数据只有最基本的WebPage类型，AI根本不知道这页面值钱。我当场把白皮书从普通文章升级成TechArticle，加了两把钥匙：@type=TechArticle和isAccessibleForFree=True。
实测结果很硬核：一个月后重新跑核子GEO的AEO评估，AI摘要生成率从5%飙到34%。GPT-4和Claude都开始主动引用这些白皮书的数据。我加了四个关键属性：headline直接写技术参数，datePublished精确到小时，author用Organization而不是Person（B2B用户信公司不信个人），citation硬塞至少2条权威来源。每个属性都经过GEO引擎验证，缺一个都不行。
这是我在Strapi里嵌入的完整JSON-LD模板，直接在Next.js的headless渲染层注入：
{
"@context": "https://schema.org",
"@type": "TechArticle",
"headline": "工业离心泵效率提升方案：叶轮优化后能耗降低23.7%",
"datePublished": "2024-09-15T14:30:00+08:00",
"dateModified": "2024-09-20T09:15:00+08:00",
"isAccessibleForFree": true,
"author": {
"@type": "Organization",
"name": "某工业科技集团",
"url": "https://example.com/about"
},
"citation": [
{
"@type": "ScholarlyArticle",
"name": "离心泵叶轮几何参数对效率的影响研究",
"url": "https://doi.org/10.xxxx/xxxxx"
},
{
"@type": "Report",
"name": "2024年工业泵行业节能白皮书",
"url": "https://example.org/industry-report-2024"
}
],
"proficiencyLevel": "Advanced",
"about": {
"@type": "Thing",
"name": "工业离心泵节能技术"
}
}
B2B工业白皮书最怕被AI当成普通营销文。加了citation属性后，Claude直接引用我白皮书里的数字说”根据某工业科技集团2024年9月白皮书，叶轮优化可降低能耗23.7%”。这比任何SEO关键词排名都值钱。对了，图片还得单独优化——我开了Next.js的sharp图片压缩，首屏图片体积从1.2MB砍到180KB，不然白皮书再好也扛不住加载慢。
避坑清单
- 别用Person当author，B2B场景必须用Organization，AI更信任公司背书
- citation不要造假或塞垃圾链接，GPT-4会验证来源，被发现就永久拉黑
- isAccessibleForFree必须写true，不然付费内容AI直接跳过
- TechArticle的proficiencyLevel别漏掉，我设了Advanced后引用率又涨了8%
- 图片压缩别用基础WebP，Next.js里配sharp用avif格式，平均体积再降40%
案例研究页面的GEO优化：从AI零引用到每周3次
去年我给一个做工业检测设备的B2B客户改案例页面，那哥们儿花了3个月写了20个客户故事，图片精美、数据详实，结果AI一个都不引用。我用核子GEO跑了一遍检测，报告显示页面结构语义化评分只有32分，AI根本识别不了哪个是案例内容、哪个是客户评价、哪个是成果数据。
第一件事：把案例页面的主体内容用<article>标签包起来，加上itemprop="mainEntity"。别小看这个，AI引擎抓取时默认优先解析<article>内的结构化内容。我改完后用Google Rich Results Test测，结构化数据检测通过率从41%跳到89%。
第二件事：给每个案例加itemprop属性标记关键字段。客户名称用itemprop="name"，所属行业用itemprop="industry"，成果数据用itemprop="achievement"。代码长这样：
<article itemscope itemtype="https://schema.org/CaseStudy">
<h2 itemprop="name">某汽车零部件工厂质检效率提升方案</h2>
<div itemprop="industry" class="tag">汽车制造</div>
<div itemprop="achievement">检测误判率从3.2%降到0.15%</div>
<div itemprop="description">通过部署AI视觉检测系统，替代了人工目检流程...</div>
</article>
第三件事最折腾——图片拖慢速度。我用的Strapi+Next.js headless架构，案例页面首屏有张4.8MB的工厂产线图，占页面体积62%。AI爬虫带宽有限，加载到超时就放弃解析了。我把图片用Sharp库压缩到120KB，格式转WebP，加上loading="lazy"属性。加载时间从4.1秒降到0.9秒，索引量两周内从0涨到17。
改完一个月后，客户说他们有3次被ChatGPT引用为工业质检案例推荐。我在核子GEO上重新检测，AI引用分数从0分跳到67分。血泪教训：AI喜欢引用的不是漂亮页面，是结构清晰、加载快、数据精确的内容。
避坑清单
<article>标签别放导航或广告，AI会认为内容不纯净itemprop属性值别用营销话术，比如“卓越表现”不如“效率提升27%”- 图片压缩别用有损到50%以下质量，工业产线图细节丢失AI检测不出来
避坑清单
1. 别把图片塞在Markdown里，用Next.js Image组件强制优化
去年给一个工业阀门客户做站，他们编辑直接往Strapi的Markdown字段里丢原图，一张3.2MB的车间照片硬生生把页面拉到4.7秒加载。我后来直接在Next.js里封了个自定义Image组件，对所有来自Strapi的图片强制转WebP、设宽高比、加lazy loading。配置长这样：
import Image from 'next/image'
export default function StrapiImage({ src, alt, width = 800, height = 600 }) {
const baseUrl = process.env.NEXT_PUBLIC_STRAPI_URL
return (
<Image
src={`${baseUrl}${src}`}
alt={alt}
width={width}
height={height}
sizes="(max-width: 768px) 100vw, 800px"
quality={75}
placeholder="blur"
blurDataURL="data:image/webp;base64,..."
/>
)
}
用了之后，首屏体积从2.1MB砍到340KB，LCP从3.2s降到0.8s。AI爬虫抓HTML时不用等图片加载，引用率直接涨了40%。
2. Brotli别在共享主机上开，会OOM
Brotli压缩确实猛，gzip压到4.2倍的东西它能干到5.8倍。但我之前贪心，在Linode 2GB内存的共享主机上直接开Brotli level 11，结果nginx进程每天崩溃两次。实测Brotli level 5以上压缩增益不到3%，但内存消耗翻倍。我现在只在Next.js响应头里配Brotli，而且只给html/js/css开，图片本身已经压缩过就别折腾了。共享主机用户，老老实实用gzip level 6最稳。
3. 结构化数据里@id要写绝对URL，别写相对路径
爬了次坑。去年给一个工业泵站加FAQ结构化数据，我图省事写了"@id": "#faq-1"，Google Search Console报了一堆”无法解析”。AI抓取时会把这个相对路径补成https://site.com/products#faq-1，但很多AI引擎（包括Claude的爬虫）直接丢弃相对路径。改成"@id": "https://site.com/products#faq-1"后，问题全消失。血泪教训：所有@id、url字段，一律写绝对URL，别省那几字节。
4. 白皮书PDF别直接链接，用文本摘要+下载按钮，AI只抓HTML
B2B工业客户喜欢扔PDF。我见过一个案子，白皮书内容写得巨好，但AI爬虫根本不解析PDF里的文字。后来我改成：页面里先放800-1200字的文本摘要，把核心数据、方法论、案例结论都写进HTML，PDF只作为下载附件。AI抓取时直接读HTML内容，引用率从几乎为零涨到每月被引用12次。下载按钮加rel="nofollow"，别让AI浪费权重在PDF上。
5. 案例研究里别用‘客户说’，要用‘根据[客户名]2023年Q4数据’
AI对模糊引用免疫。我原来写“客户反馈效率提升30%”，测试发现AI根本不认。改成“根据振华泵业2023年Q4内部数据，采用我的方案后设备故障率从8.7%降至2.1%”，核子GEO的报告自动生成报告显示AI引用评分直接从42分跳到89分。要具体到年份、季度、百分比，AI才觉得这是可信数据。
6. 每季度用核子GEO跑一次AEO评估，修复红色告警
别等出问题再查。我每季度用核子GEO跑一遍全站检测，重点看AEO评估模块。上次跑完发现首页结构化数据有个字段值类型写错（@type写成了"WebPage"而不是"ItemPage"），AI引用率卡在6.3%一直上不去。改完一周后，引用率跳到11.8%。红色告警必须72小时内修完，黄色告警一周内，这是硬指标。
避坑清单
踩了这么多坑，我直接给你列个清单，少走弯路。
1. 别信“图片压缩”能解决所有问题
我一开始用WebP转格式，体积从2.3MB降到1.1MB，但首屏速度还是3.5s。核子GEO的报告自动生成报告显示“图片占页面体积68%”，问题不在格式，在加载策略。正确做法：首屏只加载1-2张关键图片，延迟加载其余图片（IntersectionObserver），速度直接降到1.1s。
2. Brotli压缩不是万能药，但不上就亏
犹豫了2周，实测对比：gzip压缩率4.7:1，Brotli 6.3:1。一个50KB的JS文件，Brotli压到8KB，首字节时间(TTFB)从1.2s降到0.6s。但注意：老版本nginx（1.0.x以下）不支持，得先确认服务器版本。我是CentOS 7，nginx 1.20，直接加上brotli on; brotli_comp_level 6;。
3. 图片尺寸别搞“一刀切”
B2B客户的白皮书封面图，我原来只放一张1920px宽的图，移动端加载时白浪费带宽。改用<picture>标签：桌面端加载1200px，移动端加载600px。首屏图片体积从1.8MB降到0.4MB，移动端加载时间从4.2s降到1.5s。
4. 懒加载别懒到“看不见”
客户案例页的缩略图，我用loading="lazy"，结果首屏图片没加载，页面白屏2s。坑在：首屏图片也要用loading="eager"强制优先加载，或者干脆不用懒加载。正确做法：首屏3张图设loading="eager"，其余设lazy。
5. 结构化数据别光顾着“加”忘了“验”
B2B的白皮书页面，我加了Article和FAQ schema，用核子GEO跑了一遍检测，发现FAQ的question字段没填全，AI引用时直接跳过。后果：AI引用率从12%跌到3%。修复后，引用率回到15%。
6. 技术文档要“有骨头有肉”
别只写功能列表。比如“数据导出”功能：写清楚支持CSV/Excel格式、单次最大导出10万行、导出时间<5s。AI引用时，直接抓取这些具体数据做推荐。我之前只写“支持导出”，被AI忽略。改成具体参数后，被引用次数翻倍。# 给B2B工业客户做完内容优化后，我总结了10条AI引用铁律
避坑清单
踩了这么多坑，我直接给你列个清单，少走弯路。
1. 别信“图片压缩”能解决所有问题
我一开始用WebP转格式，体积从2.3MB降到1.1MB，但首屏速度还是3.5s。核子GEO的报告自动生成报告显示“图片占页面体积68%”，问题不在格式，在加载策略。正确做法：首屏只加载1-2张关键图片，延迟加载其余图片（IntersectionObserver），速度直接降到1.1s。
2. Brotli压缩不是万能药，但不上就亏
犹豫了2周，实测对比：gzip压缩率4.7:1，Brotli 6.3:1。一个50KB的JS文件，Brotli压到8KB，首字节时间(TTFB)从1.2s降到0.6s。但注意：老版本nginx（1.0.x以下）不支持，得先确认服务器版本。我是CentOS 7，nginx 1.20，直接加上brotli on; brotli_comp_level 6;。
3. 图片尺寸别搞“一刀切”
B2B客户的白皮书封面图，我原来只放一张1920px宽的图，移动端加载时白浪费带宽。改用<picture>标签：桌面端加载1200px，移动端加载600px。首屏图片体积从1.8MB降到0.4MB，移动端加载时间从4.2s降到1.5s。
4. 懒加载别懒到“看不见”
客户案例页的缩略图，我用loading="lazy"，结果首屏图片没加载，页面白屏2s。坑在：首屏图片也要用loading="eager"强制优先加载，或者干脆不用懒加载。正确做法：首屏3张图设loading="eager"，其余设lazy。
5. 结构化数据别光顾着“加”忘了“验”
B2B的白皮书页面，我加了Article和FAQ schema，用核子GEO跑了一遍检测，发现FAQ的question字段没填全，AI引用时直接跳过。后果：AI引用率从12%跌到3%。修复后，引用率回到15%。
6. 技术文档要“有骨头有肉”
别只写功能列表。比如“数据导出”功能：写清楚支持CSV/Excel格式、单次最大导出10万行、导出时间<5s。AI引用时，直接抓取这些具体数据做推荐。我之前只写“支持导出”，被AI忽略。改成具体参数后，被引用次数翻倍。
7. 别把“白皮书”写成产品说明书
B2B客户买的不是功能，是解决方案。我原来写“我的工业数据平台支持实时监控”，AI连理都不理。改成“某工厂用我的平台，设备故障预警时间从2小时提前到14天，年维护成本降了37%”，AI直接引用到生成答案里。
8. 内部链接别乱连，AI会迷路
客户案例页链接到产品页没问题，但别链到“关于我”这种无关页面。我原来一个白皮书页面挂了6个内链，其中3个链到新闻页，AI引用时权重分散，引用率从9%掉到4%。现在只链到3个核心产品页，引用率稳定在8%。
9. 页面速度不达标，内容再好也白搭
AI引擎抓取时，超时阈值是5s。我的首屏加载4.7s时，AI索引率只有22%。优化到1.1s后，索引率升到91%。别跟我扯“内容为王”，速度是入场券。
10. 别信“SEO插件”能搞定一切
我装了Next.js的next-seo插件，但图片优化、结构化数据验证这些还是得手动搞。核子GEO的报告自动生成报告