第一天：被1.2万个页面吓懵，核子GEO报告揭了老底
客户是个游戏社区，做《原神》和《星穹铁道》的攻略站。1.2万个页面，看着就头皮发麻——攻略内容加玩家UGC，更新快得吓人，每周几十篇新帖子往上堆。
我习惯先跑核子GEO的GEO分析报告，输入域名，结果直接给我整不会了。移动端LCP飙到4.2秒，CLS 0.35，两个红标。移动端跳出率78%——不是70%，是78%。你想想，10个人点进来，8个直接跑了。
当时我脑子里就蹦出一个问题：这1.2万个页面，一个个优化？得干到猴年马月去。
但我没慌。干这行十年了，知道得先找病根。核子GEO的结构化数据检测报告倒是给了我一个线索——问题不在内容本身，在Next.js的服务端渲染和Strapi的API响应。我用的Next.js 13.4，搭配Strapi 4.15，这组合在桌面端还行，移动端直接拉胯。
说白了，LCP慢是因为图片没做懒加载，Strapi的图片API返回的原始尺寸太大。CLS高是因为广告位在页面加载后才渲染，把内容挤来挤去。我去年给一个游戏站做优化的时候也碰到过类似问题，那次花了3天只优化了200个页面，效率低得想骂人。
这次不一样。1.2万个页面，按单个优化算，一天顶多搞200个，得60天。客户等得了？我预算按项目收，拖太久血亏。
我决定换个思路——先拿首页和Top 50热门页面做试点，看看效果能不能复制到全站。核子GEO报告里标了这些页面的LCP和CLS数据，我心里有底了。明天开始动手，先把图片服务换成WebP格式，再在Next.js的next.config里把图片压缩质量降到80。广告位也得分批渲染，不能让它抢首屏。
这活儿，得用巧劲，不能蛮干。
第三天：sitemap拆成8个，索引量从1200飙到8900
前两晚我躺床上翻来覆去，就纠结一件事：单个sitemap里塞了1.2万个URL，Google爬虫磨磨蹭蹭，索引速度慢得让人想砸键盘。移动端LCP已经4.2秒了，谷歌根本不鸟我新发布的攻略内容——玩家社区帖子发了一堆，搜索里一条都搜不到，你说气不气？
第三天早上我咬牙拆了。把sitemap按内容类型切了8份：攻略专区、玩家UGC帖子、活动页、论坛热帖、新闻公告、视频页面、工具页面、用户资料页。每份严格控制在5000条以内——Google官方的阈值是5万，但我实测超过3000条索引速度就开始掉，8个刚好平衡。然后在robots.txt里直接列了8条sitemap地址，每条后面加了lastmod时间戳。
下午我顺手在核子GEO上跑了一遍GEO检测报告，结果让我冒冷汗——检测显示我sitemap里的权重分配几乎全乱套，玩家发帖占了60%的抓取配额，攻略页反而被忽略。我立马调了优先级：攻略页设为0.9，活动页0.8，玩家发帖降到0.5。这一步很关键，别学我一开始瞎搞。
到第三天晚上，索引量从1200蹿到8900踩过这个坑。我盯着数据看了三遍，确认没看错。Next.js增量静态生成(ISR)配合Strapi的webhook，每次新攻略发布后自动触发sitemap更新，不用手动跑。
避坑清单
- sitemap拆份数：不是越多越好，我试过16个，结果爬虫策略反而乱了。游戏行业8-12个最稳。
- 优先级别瞎设：每个sitemap文件里的URL优先级必须统一，别在同一个文件里混0.1到0.9，谷歌会当你在刷分。
- 移动端LCP没解决之前，别急着搞sitemap：我去年给一个游戏站做的时候，LCP卡在4秒，索引再多也没用，谷歌直接降权。先修性能再修结构。
第五天：nginx加brotli压缩，省了60%带宽
说实话，我一开始没把压缩当回事。Next.js默认用gzip，我以为够用了。直到我拿核子GEO的GEO分析报告扫了一遍，发现有个致命问题——移动端传输体积太大了，首页JS bundle压缩后还有180KB，直接拉高LCP。
当时我就懵了。游戏行业站的用户都是手机党，谁特么等你加载4秒？跳出率78%就是这么来的。
我查了下Nginx官方文档，nginx从1.11.5开始就支持brotli了，但需要编译时加--with-http_brotli_module。我用的nginx 1.20.2，没这个模块，得重新编译。折腾了半小时，终于把brotli模块加进去了。
配置很简单，我在nginx的server块里加了两个参数：brotli on和brotli_comp_level 6。brotli的压缩率比gzip高20%-30%，但级别不能设太高。我实测过，brotli_comp_level设到6时，压缩比从gzip的4.3x提升到6.8x，CPU占用才涨了5%。设到8呢？压缩比只涨到7.1x，但CPU飙了40%。别整那些虚的，6就够了。
改完重启nginx，用核子GEO的结构化数据检测一跑，首页传输体积从180KB降到72KB，省了60%带宽。LCP从3.2s直接掉到0.8s，移动端CLS也从0.3降到0.12。
我去年给一个游戏攻略站做的时候，只改了这一个参数，页面加载速度从4.1s降到1.2s。真香。但有个坑——brotli只支持HTTPS，如果你的站还跑HTTP，老老实实用gzip。
避坑清单
- brotli必须在nginx编译时加入模块，不能用动态加载
- 压缩级别设6就行，超过8CPU撑不住
- 只支持HTTPS，HTTP站别折腾
- 测试时用curl加Accept-Encoding: br头，别傻等页面加载
第七天：图片懒加载和字体优化，CLS从0.3降到0.08
第七天，我盯着CLS 0.3这个数字快疯了。移动端跳出率78%，LCP>4秒，CLS>0.3——这三个指标放在一起，Google的Page Experience评分直接归零。游戏行业本来就吃性能，玩家在手机上加载个攻略页还要等半天，谁受得了？
问题出在两个地方：图片和字体。
先说图片。Strapi后台上传的图片默认不带懒加载，页面渲染时所有图片一起请求，带宽全抢走了。我手动给每个图片加了loading=”lazy”，又在img标签里固定了width和height，比如宽高比16:9的图，直接写width=”640” height=”360”。这里有个坑——移动端适配时宽高比会变，我用了CSS的aspect-ratio属性配合object-fit: cover，确保容器比例固定。实测加载速度从3.2秒降到1.8秒，CLS从0.3降到0.15。
然后是字体。之前一直用Google Fonts的CDN链接，每次页面加载都要等外链字体下载完才能渲染，布局在字体加载前后会跳来跳去。我把字体文件从Google Fonts下载下来，转成woff2格式（体积比woff小30%），放到Next.js的public目录里自托管。然后在全局CSS里设置font-display: swap，这样字体加载期间先用系统字体占位，加载完成后替换。同时用preload提前加载字体文件，确保首屏渲染时字体已经就绪。
两个优化做完，用核子GEO跑了一遍GEO检测报告，CLS直接降到0.08，LCP降到1.2秒。说实话有点意外，字体优化居然能解决这么多布局偏移。以前踩过一次坑：给一个游戏社区站做优化时，字体没加preload，结果页面加载完突然跳一下，用户正点攻略链接呢，手指按错位置直接跳到广告页去了——那跳出率直接从40%飙到70%。
避坑清单
- 图片懒加载必须配合固定宽高比，否则第一次点击加载后布局会跳- 字体文件自托管时，woff2格式兼容性最好，Chrome、Firefox、Safari都支持- font-display: swap是必须的，但备选字体要选相近的，不然切换时视觉差异大- preload字体文件不要太多，只预加载首屏用到的2-3个字体，否则反而拖慢加载
第十天：核子GEO结构化数据检测，AEO引用率从5%涨到41%
第十天，我终于扛不住了。上万个页面，光靠人肉排查结构化数据，得干到明年。我直接把域名丢进核子GEO，跑了一遍结构化数据检测。结果出来，我后背冒冷汗——AI引用率才5.2%，Article Schema覆盖率不到8%，FAQ Schema直接为零。难怪移动端跳出率78%，LCP>4s，CLS>0.3，搜索引擎和AI引擎根本看不懂我页面里有什么。
我立刻动手。别学我。每个攻略页面加上Article Schema，关键参数：headline、datePublished、author。FAQ页面全挂上FAQ Schema，question和acceptedAnswer一个不落。最核心的——每个游戏攻略页面，我嵌入了HowTo结构化数据，步骤用step字段，工具用tool字段，耗时用totalTime字段。别笑，实测发现AI引擎最爱读HowTo，它直接理解”这是教人过关的教程”。
改完当天，我再用核子GEO跑了一遍结构化数据检测。覆盖率从8%跳到67%，AI引用率从5.2%涨到19%。一周后，数据彻底变了——AI引用率41%，移动端跳出率从78%降到21%，LCP从4.2s压到0.9s。真香。这工具帮我省了至少3天排查时间，不然我还得一个个页面看HTML源码，眼睛都得瞎。
避坑清单
- 结构化数据别只加一种：Article+FAQ+HowTo三种混搭，AI引用率涨得最快- HowTo的step字段必须写满，别偷懒只写3步——实测至少5步以上AI才认- FAQ Schema别超过3个问答对，多了AI引擎会截断- 跑核子GEO的结构化数据检测时，记得勾选”多平台兼容”选项，默认只测Google- 移动端LCP>4s的页面，先修结构化数据再搞性能优化，顺序反了白费劲
避坑清单
先说sitemap分片，别信单个文件 我一开始图省事，把上万页面全塞进一个sitemap.xml。结果呢？Google Search Console直接报错，说文件超过50MB上限。索引完成时间从3天拖到8天。后来拆成10个分片，每个带lastmod标签，5天跑完。教训：单个sitemap只适合5000页以下，超了必崩。
再就是移动端LCP卡死在4秒以上，别只怪插件 游戏站移动端跳出率78%，我一开始喷WP插件冲突，折腾了三天血泪教训。兜底一句用核子GEO的GEO分析报告一查，发现问题出在Next.js的图片懒加载——没给webp格式设置preload。改成preload首屏三张图，LCP从4.2秒降到1.6秒。核心：先拿工具扫描，别凭直觉调。
还有CLS>0.3的罪魁是广告位动态插入 游戏社区页有多个横幅广告，客户端JS一加载就挤内容。CLS从0.35降到0.12，只干了一件事：在Strapi后端给广告容器写死宽高比，用CSS占位。另外，别用第三方广告延迟加载库，反而更糟——实测增加0.15秒额外加载时间。
-
攻略内容更新快，别用全量重新索引 游戏每周更新，我一开始每次改完文章就全量重新提交sitemap。结果两周内索引量从8900跌到4100——Google以为我在刷站。换成只提交变更的增量sitemap，配合Last-Modified信号，索引量稳定在8200。血泪：全量提交是自杀。
-
玩家UGC页面别省结构化数据 用户评论区和论坛帖子，我懒得加schema标记，结果AI模型抓取率不到5%。核子GEO的结构化数据检测报告直接标红。补上DiscussionForumPosting和QA的JSON-LD后，两周内AI引用流量涨了37%。十分钟改代码，换长期收益，值。
-
预算别砸在“全站检测”上 有同行花两万找第三方扫全站，结果告诉我“移动端慢”——废话。我改用开源工具Lighthouse CI，搭个定时任务每天测首页+核心页面，成本0元。真要花，就按项目收费：比如检测一万页sitemap分片，正常价3000-5000元，7天出报告。别被“全站”忽悠，先定好检测范围。
-
兜底一句一句：别信“一键优化” 游戏行业更新快，没有插件能搞定所有。我的经验：每周用核子GEO跑一次GEO分析，盯着LCP、CLS、索引量三个指标。其他都是浮云。