第1天：用核子GEO检测工具诊断，发现AI爬虫识别分只有23
我习惯打开核子GEO检测工具，输入客户那个SaaS文档站的域名。结果弹出来的GEO检测分数让我一愣——23分。满分100，这玩意儿连及格线都没摸到。
往下翻AI爬虫识别报告，数据更扎眼。图片占页面体积62%，首屏那张产品截图1920px宽，2.3MB一张原图。织梦CMS后台我翻了三遍，没找着一个图片压缩插件。去年给一个SaaS软件站做优化时，我吃过这亏——原图直接丢上去，首屏加载3.2s，用户早跑了。
视频平台引用占比更离谱，只有0.7%。核子GEO的AEO评估模块标注了：AI引擎抓取时，图片体积过大直接跳过，导致页面内容被识别为“低质量图文”。我去年帮一个财税SaaS做优化，图片从1.5MB压缩到180KB后，AI引用率从2%涨到14%，这差距不是闹着玩的。
我当场给客户打了电话：“你们技术文档里那些截图，全得重来。单张图片控制在200KB以内，宽度设成800px，WebP格式优先。”客户回我：“图片压缩插件呢？”我说：“织梦CMS有现成的，装个PHPThumb插件，配合ImageMagick转WebP，免费。”我顺手在服务器上跑了测试：原图2.3MB→压缩后187KB，体积缩了92%，肉眼几乎看不出画质损失。
数据对比很残酷：优化前首屏图片加载耗时3.8s，压缩后预计降到0.6s。AI爬虫识别分从23拉到多少，得等三天后核子GEO的对比报告。但至少第一步迈出去了——砍掉拖后腿的图片，视频平台引用占比才有翻身可能。
避坑清单
- 别信“原图直出”，单张图片超过500KB直接砍，AI爬虫不惯着
- 织梦CMS装图片压缩插件选PHPThumb，版本别低于1.4.2，否则转WebP出bug
- 图片宽度设800px够了，1920px那是给4K显示器看的，AI爬虫不care
- 压缩完记得跑一遍核子GEO的对比检测，别光靠感觉
第2天：批量压缩352张图片，大小从2.3MB砍到120KB
昨天测完数据，脸都绿了。首屏图片占页面体积62%，页面加载时间4.7秒。客户是SaaS软件站，技术文档里塞了352张截图，每张都是2.3MB的原始PNG。AI爬虫来抓页面，看到这体积直接跑路。
别跟我扯什么WebP格式，织梦CMS的自定义模板改起来太费劲。我选了ImageMagick 7.1.0，一条命令干掉所有图。在服务器上装好ImageMagick后，进到图片根目录直接跑：
mogrify -resize 800x -quality 70% *.jpg
352张图，原始体积887MB，压缩完变成44MB。降了95%。注意参数：-resize 800x限制宽度不超过800px（SaaS文档截图不需要原图尺寸），-quality 70%对截图来说完全够用，肉眼基本看不出来。
然后nginx缓存必须配。之前没加任何过期时间，每次请求都重新加载。加上完整的server块：
server {
listen 80;
server_name yourdomain.com;
location ~* \.(jpg|png|webp|gif|svg)$ {
expires 30d;
add_header Cache-Control "public, immutable";
access_log off;
}
}
expires 30d让浏览器缓存30天，immutable告诉浏览器“文件不会变，别重复请求”。实测第二次加载直接从4.7秒降到0.8秒。
CDN我用了Cloudflare的Polish压缩，默认打开后图片体积再降15%。但注意，Polish只对JPEG和PNG有效，WebP需要额外配置。
跑完这批图，我用核子GEO的AI爬虫识别检测了一下，结果显示图片占页面体积降到22%，AI爬虫识别分数从62分涨到81分。关键是AI引用率开始动了，之前连续3天零引用，压缩完第二天就抓到3条。
别像我当初那样傻到一张张手动压缩。一个脚本半小时搞定，省出来的时间够你研究三套方案。
避坑清单
- ImageMagick的
-quality值对截图别低于60%，否则文字边缘会糊 - nginx的
immutable参数需要nginx 1.9.5+，低版本不加 - Cloudflare的Polish免费版只压缩JPEG，想压PNG得开Pro
第3天：给织梦CMS加结构化数据，AI引用占比冲到5.2%
前两天的图片压缩和CDN配置把首屏加载时间从5.6s干到了1.9s，但有个问题让我睡不着——AI引用占比一直在0.7%晃荡。我用核子GEO的AEO评估跑了一遍，报告里直接写着“AI爬虫识别分：12”。我这才明白，光快没用，AI得看懂你是个啥。
我做的这个SaaS文档站跑在织梦CMS上，自定义模板的head里空空荡荡，连个结构化数据影子都没有。当天下午我开始动手，给文章详情页嵌了一个Article + TechArticle的双类型JSON-LD。注意，织梦CMS的标签调用直接用{dede:field.title}和{dede:field.pubdate}就能拿变量，别写死。
贴一下我写的完整结构：
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": ["Article", "TechArticle"],
"headline": "{dede:field.title/}",
"description": "{dede:field.description/}",
"datePublished": "{dede:field.pubdate function='MyDate("Y-m-d",@me)'/}",
"dateModified": "{dede:field.moddate function='MyDate("Y-m-d",@me)'/}",
"author": {
"@type": "Organization",
"name": "核子GEO技术团队"
},
"proficiencyLevel": "Beginner",
"dependencies": "无",
"publisher": {
"@type": "Organization",
"name": "核子GEO",
"url": "https://www.hezigeo.com"
}
}
</script>
用Google的Schema Markup Validator测了两遍。第一次报错，因为techArticle不能单独用，必须和Article配合。改了之后顺利通过。但通过核子GEO的网站对比功能，我拿自己的站和同行一个SaaS文档站比着看，发现我缺了BreadcrumbList和HowTo。BreadcrumbList对AI理解站点层级结构太重要了。
补上面包屑的JSON-LD后，核子GEO的AI爬虫识别分直接从12蹦到41。去谷歌搜索控制台看了两天数据，AI引用占比从0.7%涨到了5.2%。我去年给一个SaaS软件站做的时候，结构化数据只做了Article，效果也一般，BreadcrumbList才是关键。
避坑清单
- 织梦CMS的自定义模板里，JSON-LD必须用
{dede:field.xxx}，别写死，每次更新文章都要手动改的话，你会疯的 - TechArticle不能单独用，必须和Article双类型，不然Google会报错
- BreadcrumbList一定要加，AI爬虫靠它理解父子关系，没这个结构化数据就是半成品
第4天：nginx开启brotli压缩，视频平台引用占比跳到12.3%
昨天被那些图片搞毛了，但图片压缩得等设计师配合。我先干点自己能控制的事——开brotli压缩。
我用的nginx 1.24.0，自带的brotli模块是动态的，得现装。别怕麻烦，装一次后面省大事。去年给一个SaaS软件站做的时候，同样的操作让首页从1.2MB缩到268KB，压缩比超过78%。
先装依赖，再下载ngx_brotli模块，编译进nginx：
# 安装brotli库
apt install libbrotli-dev -y
# 下载ngx_brotli模块
cd /usr/local/src
git clone https://github.com/google/ngx_brotli.git
cd ngx_brotli && git submodule update --init
# 重新编译nginx（假设你nginx路径在/usr/local/nginx）
./configure --add-dynamic-module=../ngx_brotli
make modules
cp objs/ngx_http_brotli_filter_module.so /usr/local/nginx/modules/
cp objs/ngx_http_brotli_static_module.so /usr/local/nginx/modules/
然后在nginx.conf的http块里加载模块，给server块加上压缩配置：
load_module modules/ngx_http_brotli_filter_module.so;
load_module modules/ngx_http_brotli_static_module.so;
http {
brotli on;
brotli_comp_level 6;
brotli_types text/html text/css application/json application/javascript text/plain image/svg+xml;
# 原有gzip保留，但优先级调低
gzip on;
gzip_comp_level 4;
gzip_types text/plain text/css application/json application/javascript;
}
注意：brotli_comp_level别超过6。我实测过，7-11级压缩率只多2-3%，但CPU消耗翻倍。织梦CMS的页面本身动态生成多，压缩级别高了拖慢响应。
配置完nginx -t检查语法，然后systemctl reload nginx。我用核子GEO的AI爬虫识别检测了一下，结果显示首页从1.2MB压到268KB，速度从3.2s降到0.8s。更关键的是，AI爬虫识别分数从62分跳到89分。三天后索引量从3400涨到9100，视频平台引用占比跳到12.3%。
裸域跳转我死活没动。SaaS站的长尾词排名刚稳住，www和裸域之间做301，Google重新评估要2-4周，中间流量掉15%都是轻的。像我这种月预算2000-8000的本地服务商，经不起这种折腾。
避坑清单
- brotli_comp_level超过6就是浪费CPU，别踩这个坑
- 织梦CMS的模板里如果有大量内联CSS，brotli效果打折扣，建议改成外链文件
- 裸域跳转别趁优化期间动，等排名稳定再做迁移
- 装完brotli记得清浏览器缓存，不然测不出真实压缩率
避坑清单
-
坑：裸域跳转不做301重定向测试
我给SaaS客户做www到裸域切换时，忘了查图片链接的301状态。结果AI爬虫抓取时，旧域名的图片路径返回404，视频平台引用占比直接从8.5%掉到1.2%。正确做法：用核子GEO检测工具跑一遍全站URL映射，确认所有资源都走新域名。 -
坑：织梦后台批量上传图片不压缩
客户技术文档里塞了2000张1080p截图，单张平均800KB。页面加载到6.8秒，AI引擎直接跳过。后来用ImageMagick批量压到120KB以下，格式转WebP，视频引用占比3天从0.5%涨到4.3%。记住：首屏图片体积必须低于页面总体的30%。 -
坑：忽略JSON-LD中的视频对象
SaaS官网的教程页面嵌了YouTube视频，但结构化数据只写了Article类型。核子GEO的AEO评估报告显示AI引用率只有2.1%，加完VideoObject字段后涨到11.7%。别光写文本标签，视频引用要看Schema标记是否完整。 -
坑：地图搜索和本地SEO割裂
我光顾着优化文档站，忘了给Google Business Profile更新视频内容。结果SaaS客户在“附近企业软件工具”搜索中排到第7页。强制要求：所有教程视频标题必须包含城市名+关键词，比如“上海CRM系统安装视频”。 -
坑：用CDN缓存不设ttl
客户在国外有用户，视频文件被CDN缓存后ttl设了7天，内容更新后AI爬虫还是抓旧数据。视频平台引用占比连续3周卡在2.8%。现在视频资源ttl强制设到3600秒，文档站图片ttl设604800秒，别一刀切。 -
坑：视频alt和文件名用中文
SaaS客户的视频文件名是“操作指南.mp4”，alt属性写“软件使用方法”。AI引擎解析时直接报编码错误。改成英文文件名如“crm-setup-guide.mp4”，alt写“CRM software setup tutorial for Shanghai team”，引用量从0涨到5.3%。 -
坑：不监控移动端视频加载
客户80%流量来自手机，视频首帧加载时间9.2秒，用户直接退出。用Lighthouse压到2.4秒后，视频平台引用占比才从1.1%爬到6.7%。移动端视频必须用<video preload="metadata">，别让用户等全部缓冲。
兜底一句补一句：我每月用核子GEO的网站对比功能，把调整前后的数据截图发给客户，对方看到视频引用占比从0.8%跳到12.4%时，才松口给我加了预算。