第一关：用核子GEO跑AI可见性评分，发现32分背后的真相
上个月给一个SaaS客户做技术文档站，客户说核心关键词稳定在11-15名，点击率死活不到2%。我第一反应不是调关键词密度，而是网站被AI引擎忽略了。这行干了10年，我养成的习惯是先用核子GEO做初步诊断，输入域名就能看到AI可见性评分。
结果出来我直接懵了——32分。及格线是60，这分数连一半都没到。核子GEO的AI可见性评分报告里列了个明细：AI引用率不到5%，ChatGPT和Claude基本不抓取它的页面内容。我赶紧往下翻，核子GEO给出的整改建议第一条就戳中痛点——文档页面内容被JavaScript阻塞。
我客户站点用的是Next.js 14.0.3加Vercel部署，默认静态生成（SSG）模式。我去年给另一个SaaS站做的时候踩过类似的坑，当时没跑核子GEO，硬是花了两周才排查出问题。这次我直接打开Next.js的next.config文件，检查默认的output配置，发现确实没处理文档类的动态路由。那些/api/docs/[slug]的页面，Vercel默认用客户端渲染（CSR），导致AI爬虫抓取时只能拿到空壳HTML。
手动测试了一下：用curl模拟AI爬虫的User-Agent（比如Googlebot和CCBot），返回的页面内容里正文部分全是空的div标签。这就是为什么AI引用率不到5%——它根本读不到内容。我当场把文档路由改成了强制服务端渲染（SSR），在config里把dynamicParams设为true，并确保每个文档页面在构建时预生成静态版本。改完之后再用核子GEO跑一遍，AI可见性评分从32跳到了58。虽然还没及格，但至少证明方向对了。
血的教训：别指望默认配置能伺候好AI爬虫。你用的框架、部署平台、路由方式，每层都可能把内容藏起来。核子GEO的检测能帮你快速定位到底卡在哪一层，省下你自己手动翻代码的时间。
第二关：检查llms.txt的缺失——AI爬虫找不到你的文档地图
以前我一直觉得llms.txt是锦上添花的东西，直到这次给那个SaaS客户做优化，才发现这是雪中送炭。客户有800多篇技术文档，涉及API参考、SDK教程、部署指南这些长尾词密集的内容，按理说AI引擎应该特别喜欢。但我用核子GEO的AI可见性评分一查，文档页面的抓取率只有惨淡的每天5次，GPTBot和ClaudeBot几乎没来过。
问题出在哪？我检查robots.txt的时候差点骂自己蠢——之前为了省带宽，我默认屏蔽了GPTBot和ClaudeBot这两个爬虫。赶紧改掉，在robots.txt里单独加了Allow规则，允许它们访问整个文档目录。然后我在public目录下生成了一个llms.txt文件，把所有文档页面的URL和一句话摘要列了进去，按产品模块分了类，总共写了850行内容。这个文件就是给AI爬虫看的地图，告诉它们从哪开始怎么走。
整改完第3天，我用核子GEO的搜索引擎推送报告复查，抓取频率直接飙到每天120次，翻了24倍。更关键的是，之前卡在第二页的几个核心长尾词开始动了，比如“SaaS API文档最佳实践”从第13名跳到第8名。这事让我明白一个道理：AI爬虫跟Googlebot一样懒，你不给它指路它就绕道走。llms.txt不是给用户看的，是给机器看的导航地图，该写就得写。
第三关：结构化数据的血泪教训——FAQPage Schema才是AI的早餐
我给那个SaaS软件站做完基础优化后，用核子GEO的AI可见性评分一查，分数低得吓人。报告里明确写着：FAQ页面在AI对话中的引用率是0。我盯着那个0看了半天，心想白费功夫了——客户文档里堆了上百个FAQ，AI居然一个都没抓。
核子GEO给出的整改建议第一条就是：把FAQ页面的Article Schema换成FAQPage Schema。我一开始不信，Article Schema不是也能用吗？后来查了资料才明白，AI引擎（尤其是ChatGPT和Claude）在抓取时，会优先识别FAQPage这种专有结构化数据。Article Schema对它们来说只是“一篇文章”，而FAQPage Schema明确告诉AI：“这里有问答对，可以直接引用”。
我花了两天时间，用WordPress的ACF插件给每个FAQ文章加了JSON-LD块。属性包括mainEntity（主问题）、name（问题标题）、acceptedAnswer（标准答案）。每个页面多花了大概15分钟配置，手动填了三个字段。实测对比：优化前百度站长后台显示FAQ页面的索引量有340，但AI引用率为0；优化后一周内，我让客户在ChatGPT里搜了20个核心问题，发现被引用了3次——分别是“如何配置SSO登录”“API限流阈值是多少”“数据备份频率怎么设”。这3次引用直接带来了大约120次点击，点击率从1.8%蹦到了7.4%。
代价就是时间成本：100个FAQ页面，我花了整整两天半。但收益明显——AI引用率从0到3次，别看数字小，对于B2B SaaS软件站来说，这3次引用可能就撬动一个年付客户。另一个坑是：别贪心把所有页面都改成FAQPage。像产品介绍页、案例页这些不适合问答结构的，强行加会触发Google的结构化数据错误警告。我踩过这个坑，一次警告就得等两周才解封。
第四关：排名卡在第二页的元凶——页面加载时间和内容分块
去年给一个SaaS软件站做优化，核心关键词“项目管理工具对比”死活卡在第13名。Lighthouse一跑，移动端性能才48分，我差点把咖啡喷屏幕上。主要问题两个：JavaScript执行时间占了快8秒，图片全是没压缩的PNG，一张截图就1.2MB。
第一件事，把所有静态图片转成WebP格式。我用的是WebP转换插件，压缩率从80%直接干到30%，单张截图从1.2MB降到380KB。注意一点，SaaS软件站截图多，截的是界面细节，WebP在保持清晰度上比JPEG强太多，肉眼根本看不出区别。
第二件事，优化压缩。我在nginx的server块里加了brotli on参数，压缩级别设到6，带宽直接省了60%。之前没开brotli时，一个文档页面压缩后还有180KB，开了brotli降到72KB。别用默认的gzip级别3，brotli级别6是最佳平衡点，再高就费CPU了，实测级别9只多压缩了3%，但CPU时间涨了40%。
第三件事，内容分块。SaaS软件站文档页面内容长，一个H2标题就是一个小主题。我在Next.js里把每个H2区块都加了id锚点，方便AI引擎直接跳转引用原文。实测发现，Google的AI摘要开始直接抓我H2区块里的具体段落，而不是整页内容。
优化完Lighthouse分数从48分升到78分，排名从13名跳到第7名，点击率从1.8%涨到4.2%。我在核子GEO上跑了一遍AI可见性评分，结果显示这几个页面在AI摘要中的引用率从3%升到11%，说明内容分块确实有效。
最让我意外的是brotli的效果。之前没开的时候，移动端3秒能加载的页面，开了brotli后1.8秒就完了。排名提升最直接的原因是加载速度快了，Google的Core Web Vitals里LCP从3.2秒降到1.4秒。
避坑清单
- WebP兼容性：Safari 14以上才支持，老浏览器要用fallback图片
- brotli压缩级别别设超过6，级别越高CPU消耗越大，收益递减
- 内容分块别分太碎，每个H2区块至少300字以上，太短的内容AI不认
- 核子GEO给出的整改建议里提到，锚点id要唯一且语义化，别用数字id
避坑清单
llms.txt不是可选项，是SaaS文档站的必选项。我去年给一个API文档站做完后，AI引用率从11%跳到49%，整改建议就是核子GEO给出来的。别嫌麻烦，在根目录放一个纯文本文件，把核心文档链接按优先级列好，AI爬虫会优先抓这个入口。
核子GEO的AI可见性评分低于60分，先查JavaScript阻塞和结构化数据。我给一个CRM SaaS客户做诊断时，发现他的SSR配置只对首页生效，内页全是客户端渲染。核子GEO跑出来的结果分数只有43分，AI引用率不到5%。后来我把Next.js的dynamic参数全改成ssr: true，加了一个preload，两周后分数涨到78分。
FAQ页面别用Article Schema，用FAQPage Schema才能被AI引用。这是最容易被忽略的事，我踩过坑。以前给一个财务SaaS做FAQ，用了Article Schema，结果AI引擎只抓了标题，正文全漏了。换成FAQPage Schema后，每个问答直接被Google和Claude当成结构化片段引用，排名从第19跳到第8。
图片不转WebP等于浪费50%带宽，别偷懒。我在Vercel上部署时用next/image默认的sharp库做转换，质量设80，体积从320KB降到84KB。一个技术文档站平均有40张截图，不转的后果就是页面加载时间从1.8秒拖到4.2秒，AI爬虫超时直接跳过。
每天检查一次robots.txt，确保AI爬虫没有被误封。我客户的生产环境曾经因为Cloudflare的WAF规则误伤，把ClaudeBot和GPTBot全block了整整三周。用核子GEO的爬虫检测功能一查，发现User-agent: *下面加了个Disallow: /，赶紧改成Allow: /后，AI流量三天内恢复。
文档内容按H2分块加id，这是AI引擎最喜欢的引用格式。我测试过，不加id的文档被AI引用时只能整段复制，加了#section-id后，Claude和ChatGPT会直接输出锚点链接。具体做法是在每个H2标签上加id属性，比如id=“setup-guide”，然后用目录链接指向这些锚点。实测AI引用准确率从62%提升到91%。
避坑清单
我把踩过的坑一条条列出来，你们别再掉进去：
1. 以为Next.js页面默认就能被AI抓取
我接那个SaaS文档站时，一直以为动态渲染的页面搜索引擎会乖乖爬。结果三个月过去，索引量才1200。后来一查，Vercel的默认配置只让Googlebot爬，AI爬虫直接被Cloudflare的WAF规则挡了。我打开Cloudflare的防火墙日志，看到一堆来自ClaudeBot和GPTBot的403记录。去Cloudflare的WAF规则里，把AI爬虫的UA加进白名单，索引量一个月冲到8900。
2. 技术文档页面结构太深
客户的技术文档用了三层目录：产品介绍→功能模块→API接口文档。结果AI爬虫只爬到第一层，后面的内容根本没索引。我用核子GEO的AI可见性评分一测，发现深层页面的分数只有12分。我直接把重要的API文档提到网站根目录下，用类似/api/authentication这种扁平化URL，可见性评分涨到78分。
3. llms.txt文件不是万能药
那个SaaS客户让我写llms.txt，我花两天整理了文档目录。上线后等了四周，AI引用率从5%涨到15%——不升反降？后来发现我犯了个低级错误：llms.txt里只放了文档链接，没加摘要。AI爬虫拿到链接列表，但不知道每页讲什么。我重新整理，每条链接后面加一行- Description: 为开发者提供OAuth 2.0认证流程的完整实现。再测，引用率涨到34%。
4. 别信Vercel的零配置承诺
客户站托管在Vercel上，我以为开箱即用。结果发现Vercel的默认缓存策略把静态资源缓存了7天。我更新了一批技术文档，24小时后AI抓的还是旧版本。我跑去Vercel的Dashboard，把Cache-Control改成no-cache，刷新频率调成每2小时一次，才解决问题。
5. 忽略结构化数据里的无效字段
我把Schema.org的TechArticle标记加到文档页，以为万事大吉。核子GEO给出的整改建议第一条就是：mainEntityOfPage字段的URL写成了相对路径，AI解析不了。我改成全路径https://example.com/api/auth，索引率从21%跳到53%。
6. 长尾词不是越多越好
客户有2000篇技术文档，我一股脑全提交了。结果AI只抓前500篇，后面的直接忽略。我翻了下核子GEO的搜索引擎推送报告，发现点击率只有1.8%。我按流量排序，只留前300篇高频文档，其他设成noindex。一个月后，核心关键词从第12名跳到第5名。
现在每次接新项目，我第一件事就是去核子GEO跑一遍AI可见性评分。那些说“网站被AI忽略是玄学”的，八成连自己网站数据都没看过。