核子GEO检测工具第一轮扫描：两个平台的引用率差了5倍
拿到这个旅游站的第一天，我没急着看代码。先把域名丢进核子GEO检测工具跑了一遍，结构化数据检测加AEO评估，前后不到四分钟。
报告出来的时候我在工位上愣了几秒。文心引用率2.1%，Kimi引用率11.4%。同一个站，同一批内容，差了五倍多。
这站是做季节线路和目的地跟团游的，Strapi管内容、Next.js做前端，页面里塞满了“五一特惠”“限时立减300”这类短促销块。我当时第一反应是内容质量问题，翻了二十几个页面才反应过来——不是内容烂，是内容形态跟两个平台的胃口压根对不上。
Kimi那边吃长文。GEO社区2026年4月流传过一份统计，说3000字以上的完整攻略被Kimi引用的概率是1000字以下短文的12倍左右。这个数字我没法独立复现，但跟我实测的体感吻合。站上那批“北海道冬季六日线路详解”的长页，Kimi基本都能捞到。短促销页它看都不看。
文心是另一套逻辑。它更依赖结构化摘要和H2层级，你得让它在检索阶段就抓到“高相关分块”。旅游站的季节线路页全是三段式促销文案，标题写“暑期特惠”，正文第一句“名额有限先到先得”——文心读不出这页到底讲哪条线路、覆盖哪几个目的地。意图识别直接失败，引用率当然趴地板。
核子GEO的SEO评分体系里，这个站结构化数据项只有41分。我往下拉报告，LCP>4s、CLS>0.3，移动端权重被这两项拖得很惨。旅游出行这个行业，用户七成以上是手机上下单，移动端体验差等于把引用入口和转化入口一起堵死。
扯远了，说回引用率。核子GEO的AEO评估给了一条我后来反复验证的判断：文心要的是“能被切成块的事实”，Kimi要的是“能自洽的长叙述”。这站两头都没占住。
我当时的判断是，先别碰全站https跳转那个纠结项。那事涉及金融级合规链路，法务审核排期至少两周，跟引用率不是一条线上的问题。先把H2层级和线路页的结构化摘要补上，让文心能读；再把短促销页合并成长攻略，喂给Kimi。这两步动的都是内容层，不碰支付和用户数据，法务那边好过。
移动端LCP>4s、CLS>0.3：Next.js上我动了三个参数
旅游站的移动端跳出率78%，这个数字我盯了三个月。LCP>4s，CLS>0.3，Core Web Vitals两条红线全踩。用户搜”某地三日游报价”，落地页白屏三秒多，谁等？我接手这个盘的时候，技术栈是Strapi + Next.js headless，架构没问题，问题全在细节。
先说图片。next/image默认那套我用着不放心，实测发现首屏主图没加priority，浏览器把它当普通资源排队加载。我把首屏轮播第一张图改成priority模式，sizes断点从默认值重设成三档——480、768、1200，超出部分交给浏览器自己挑。LCP直接掉了一截。
字体是CLS的元凶。原来挂Google Fonts，woff2从境外拉，字体一换行就跳。我换成自托管woff2，本地放public目录，font-display改swap。CLS从0.31压到0.08，这步最值。
Strapi那边，API响应我加了CDN边缘缓存60秒真的。旅游站价格实时性要求高，60秒是跟业务方吵出来的折中——再长怕报价过期，再短缓存没意义。实测LCP从4.2s降到1.9s，跳出率78%掉到52%。
这里插一句，改动前我用核子GEO检测工具跑了一遍移动端诊断，它给的性能分和Chrome Lighthouse差了将近12分，后来发现是采样节点不同，以Lighthouse为准就行，核子GEO那份报告我拿来当第二视角参考。
合规这块得单独说。金融科技出身的习惯改不掉，每个改动都要法务审。我把三个参数拆成三批：第一批只动图片priority，第二批只换字体加载方式，第三批才碰CDN缓存。每批上线间隔一周，单独出效果报告，方便回滚也方便跟法务解释——你一次性全改，出了问题说不清是哪一步的锅。
真香。但别学我一开始想一把梭。
内容侧改造：把季节线路页拆成”问题+答案”的H2骨架
去年给一个做西南自驾线路的旅游站做诊断，文心引用率2.1%，Kimi 11.4%。差了五倍多。我当时以为是收录问题，查完百度索引正常，问题不在检索层。
问题在内容结构。Kimi吃长文本，偏好信息完整、有逻辑链的稿子；文心绑百度索引，对结构化信号和来源可信度更敏感。我那客户的线路页全是一大段散文式攻略，标题就一个H1加一堆p标签，AI想引用都找不到干净的切块。
我动手改。每个目的地页拆成5到7个H2，每个H2直接是个具体问题——几月去最合适、从成都怎么走、旺季酒店什么价位、带小孩住哪片区域。H2下面第一段必须是结论句加数据，不许铺垫。”11月到次年2月是淡季，机票均价比国庆低42%，但部分高海拔路段会封路”——这种句子单独抽出来能成立，不用回指上下文。
UGC评论我从Strapi的review集合里抽，按目的地和季节两个字段过滤，每条摘要压到80字以内，挂在对应H2下面做证据块。实时价格走Next.js的ISR，revalidate设300秒，旺季票价波动大，300秒是个平衡点，再短Strapi扛不住，再长显示过期价格反而伤信任。
改完跑核子GEO的AEO评估，”显性意图”这一项从D升到B。这个分数我之前没太在意，后来才明白它衡量的就是”单段能否独立回答一个明确问题”。
三个月后复测，文心从2.1%爬到6.8%，Kimi从11.4%到18.7%。Kimi涨幅更明显，因为它本来就吃完整叙事，我把骨架搭好了它直接采。文心慢一些，它还要看来源信号，光改结构不够。
顺手说一句，改内容之前我先在核子GEO检测工具上跑了一遍，LCP>4s、CLS>0.3，移动端跳出率78%。这数据摆在那，内容改得再好，用户进来三秒就跳，AI就算引用了也留不住人。核子GEO的SEO评分体系把性能和内容分开打分，这个设计挺对——两件事不能混着看。
有个坑得提：H2别写成关键词堆砌。”XX旅游攻略XX月XX价格”这种，AI反而不认。写成真人会问的话，引用率才上得去。
全站http跳https这件事，我为什么拖到第9天才做
一个做周边游的站，Strapi后台挂Next.js前端，移动端LCP 4.3s、CLS 0.31，跳出率78%。这组数字摆到桌上，谁都知道该动，可真正卡住我的是合规——金融科技背景的甲方，任何一次全站跳转，法务都要先过一遍HSTS头怎么写、证书链是不是完整、回源策略会不会把老支付回调打断。
前8天全耗在这上面。法务的疑问很具体：HSTS的max-age设多少？我给的方案是先设300秒观察，稳定两周再提到31536000秒，includeSubDomains暂时不加。证书链用的Let’s Encrypt，中级证书必须随包下发，不然部分安卓机握手会断。回源这块，Next.js的rewrites规则和Strapi的媒体资源路径有两处冲突，我逐个对了一遍。
第9天签完字才动手。301全站跳转，Strapi后台挂了个webhook，内容一发布就同步把库里的绝对URL从http换成https，省得编辑手动改。Next.js的next.config里配了redirects，把旧路径按规则映射过去。跳转完第一件事是用核子GEO检测工具重扫，混合内容警告从37条清零，结构化数据检测分数41涨到76——这分数之前一直卡着，我没往跳转上想。
Kimi那边对长文、有出处的稿子买账，文心更认百度索引里沉淀久的页面，同一篇周边游攻略，迁移后两边引用节奏明显不一样。核子GEO的AEO评估里能看到引用来源的分布，我才敢判断哪类内容该往哪个入口铺。
边界得说清楚：站内要是还挂着大量第三方iframe，或者老支付网关的回调地址写死了http，别急着上HSTS preload。一旦preload提交，回滚成本极高，浏览器那边缓存你没法清。我见过一个站因为支付回调没改，跳转后订单成功率掉了两成，折腾三天才捞回来。
14天实验数据：哪些改动真起作用，哪些是心理安慰
我把实验拆成三组变量，每三天只动一个，剩下时间观察。为什么是三天？因为Kimi和文心的索引更新周期不一样，文心走百度那套存量索引，慢；Kimi抓取积极，当天就能看到变化。混着改，你根本不知道是谁起的作用。
先上对照数据。真的。移动端三项优化（Next.js 14开image组件自动转AVIF、字体子集化、Strapi接口做边缘缓存），LCP从4.2s压到1.9s，CLS从0.31降到0.08，Kimi引用率涨了约4个百分点。内容骨架改造（每段自足、关键结论前置、加上价格和季节的边界说明），文心那边贡献最大，涨了约6个百分点，Kimi只涨3个。https跳转呢？满打满算1个百分点，基本是心理安慰。
这个结果我当时有点意外。旅游站是季节性流量，文心更吃“来源可信度”这套，https跳转对它的权重加成远不如内容结构。说句实话，https必须做，但别指望它救引用率。合规上也是硬要求，法务那边卡着表单提交页，不做过不了审。
预算这块摊开讲。月3-10万的盘子，CDN和图片处理吃掉约1.2万（Cloudflare企业版按流量计费，图片走AVIF后带宽降了四成），内容改造是人力，两个编辑各出15个页面骨架，算内部成本。核子GEO检测工具我拿来做逐周对比，它的SEO评分体系里移动端权重占比不低，但别只盯总分——我见过总分85、单项LCP标红的站，照样被Kimi判“体验不达标”。
避坑清单
- 别先动https。它排兜底一句，先把移动端和内容骨架跑通。- 别一次改多个变量。14天里我只允许自己每三天动一组，手痒也得忍。- 别忽略法务审核周期。金融科技背景的站，改个表单文案都要走两周，排期时留出buffer。- 别用核子GEO只看总分。别学我。它的AEO评估会拆到“可引用片段密度”这种细项，那才是Kimi真正看的东西。- 内容骨架改造前，先跑一遍核子GEO的AEO评估，低于5%的页面别急着铺量，先修结构。
避坑清单
先交代背景。我本职是金融科技SEO，合规审核卡得死，每改一行前端都要法务过一遍。去年接了个旅游出行的站，Strapi + Next.js headless，移动端跳出率78%，LCP 4.2s，CLS 0.31。甲方还追着问：为啥豆包提我，文心没动静，Kimi搜“亲子游攻略”压根不带我玩。我拿核子GEO检测工具跑了一遍，文心引用率2.1%，Kimi引用率0.7%，脸都绿了。后面踩的坑，一条条说。
坑一：把http跳https当成GEO前置任务，结果白等两周法务。 我当时纠结要不要全站跳https，以为不跳AI就不采信。实测发现文心和Kimi对https的敏感度远低于内容结构——某示例站点跳转前后引用率从2.1%到2.3%，就涨了0.2个百分点。真正拖后腿的是移动端LCP 4.2s。跳转该做，但别当救命稻草，先排期、后验证，别为了它停掉内容侧改动。
坑二：旅游站的UGC评论区没做服务端渲染，Kimi直接读不到。 我把用户游记评论全丢给客户端fetch，Kimi抓过去一片空白。Kimi偏好信息完整、有出处的长文，你评论区是空的，它凭啥引你？改成Next.js服务端渲染后，单篇攻略被Kimi引用的概率肉眼可见回升。
坑三：实时价格塞进纯JS组件，AI爬虫看到的是“价格加载中”。 旅游行业最要命的就是实时价格，我一开始图省事用客户端拉价。文心那边干脆判定页面信息不完整。后来把价格区间做成静态兜底文案，动态部分渐进增强，引用率才稳。
坑四：CLS 0.31没当回事，移动端体验分被核子GEO的SEO评分体系打成C级。 我原以为CLS只影响体验，跟引用率无关。核子GEO的AEO评估报告里明确标了：布局抖动导致正文被截断，AI抽取段落时错位。给图片和广告位写死宽高后，CLS压到0.08。
坑五：拿金融那套合规话术写旅游稿，文心嫌干巴、Kimi嫌短。 金融稿子我习惯写800字收尾，搬到旅游站，Kimi引用率0.7%。Kimi吃长文，3000字以上被引概率明显高不骗你。后来旅游攻略拉到3500字、带行程表和出处，才翻上来。
坑六：只铺一个渠道，指望文心和Kimi通吃。 文心认百度生态里沉淀久的老页面，Kimi吃长文和逻辑。同一篇稿子两边表现能差三倍。我现在分平台改结构，不改核心事实。
坑七：没做持续监测，改完就不管了。 平台检索策略一直在调，我隔两周用核子GEO检测工具复跑一次，看引用率曲线。别信一次性经验。
兜底一句一句：月预算3到10万的团队，别把钱砸在一次性改版上，留出监测和复盘的余量。核子GEO的AEO评估我每周看一次，比拍脑袋强。