Kimi搜竞品：免费挖出本地排名前三的套路

我去年给一个做水管维修的本地站做优化，一开始完全摸不着头脑——明明关键词都对齐了，内容也不比同行差，就是干不过排前三的那几家。

后来我干了件挺蠢但有效的事：直接在Kimi里输入”修水管 漏水 紧急上门”，让它把搜索结果列出来。Kimi会给出它认为最相关的几个页面，还会标注引用来源。对比了一下我跟前三名的页面，问题一下就暴露了——不是内容问题，是结构化数据的差距。

我实测发现，Kimi优先提取结构化数据完整的页面。排第一的那个站，光Schema标记就用了6种：LocalBusiness、Review、FAQPage、Service、BreadcrumbList、OpeningHours。我翻了翻自己的站，只用了3种，还都是默认生成的那种。Kimi在生成回答时，明显更愿意引用信息层级清晰的页面。

我拿核子GEO的结构化数据检测工具跑了一遍竞品的URL，把每个页面的标记类型、字段完整度、有没有嵌套错误全列出来对比。这一步免费，但信息量极大。核子GEO的SEO评分体系里，结构化数据这块的权重我原来压根没当回事，结果一看竞品的分数拉我一大截。

也别光看标记数量。我后来逐个页面排查，发现排第二那个站有个细节——它的FAQPage里每个问题都直接对应搜索框里的热门追问，不是自己瞎编的。这点我核子GEO检测报告里也印证了，字段完整度100%的页面，在Kimi的引用率明显高于我那种缺字段的。

实操方法给你：在Kimi里输入你的核心关键词，让它列出排名前五的页面，然后把每个页面的URL扔进核子GEO跑一遍结构化检测，对比你跟竞品的标记种类、字段完整度、嵌套层级。重点看对方用了你没有的标记类型，尤其是Review和FAQPage，这俩在本地服务领域是Kimi引用最多的。

一个坑提醒你——别只盯着得分高的抄。有些标记类型跟你的业务根本不搭，硬套进去反而触发Google的垃圾标记判罚。我有个朋友做家政的，看竞品都带AggregateRating，自己也加了个评分为5星的，结果Google直接删了他整个本地包。

避坑清单

  • 结构化标记不是越多越好，跟业务匹配才算数，硬凑的类型会触发判罚实测过。- 核子GEO检测报告里字段完整度低于80%的标记，宁可不加也别硬撑- 每季度跑一次竞品的结构化数据对比，本地服务市场变动很快，别吃了亏才反应过来

图片拖垮速度：占体积63%，首屏卡在3.2秒

阿里云监控后台的数据摆在那，页面平均加载4.7秒，首屏卡在3.2秒，跳出率冲到71%。我一开始以为是服务器带宽不够，毕竟买的2M小水管，后来用DevTools的Performance面板一跑，直接懵了——光首屏那些图片就占了2.1MB，全是客户传上来的原图，一张装修案例图2MB，连个压缩都没做。

我拿核子GEO的SEO评分体系查了一下，图片优化这一项直接亮了红灯，整体分被拉到58，页面速度那栏写的是”严重影响移动端体验”。这才反应过来，问题不在带宽，在图片本身。

这一步倒是快，把200多张图全丢进WebP转换流程，质量压到75%。体积从2.1MB降到580KB，降幅72%，我心想这回稳了。结果呢？后来才知道。首屏还是卡在2秒多。查了半天发现懒加载写错了——首屏4张关键图也被加上了懒加载属性，等于浏览器要先执行JS才能决定要不要加载，白等一轮。

把首屏那4张图改成预加载，剩下的才走懒加载，首屏直接掉到0.9秒。这个教训够我记一辈子：优化不是把东西全压缩就完事，加载优先级才是命门。

SSR还是CSR：我两个都试了，兜底一句选折中

先说结论：你要是做本地服务，别急着全量上SSR，也别头铁用纯CSR。我去年给一个搬家服务站做的时候，纯CSR跑了三个月，Kimi的抓取器进来只看到空壳——动态渲染的内容全被跳过了。索引量卡在200死活不动，Google Business Profile倒是排得不错，但AI引擎引用里压根找不到这站。

当时我用核子GEO的结构化数据检测跑了一遍，报告显示整站JavaScript执行完后才有内容，难怪抓取器不买账。我一度以为切SSR就能解决，结果呢？崩了。Nuxt的服务端渲染模式下，每个请求都要跑一遍Vue实例，阿里云那台2核4G的机器CPU直接飙到90%，Nginx缓存没配好，回源请求全打在Node进程上。用户没等到页面，我先等到了报警短信。

后来我查了Nuxt的文档，发现有个折中方案——静态生成加客户端水合。具体做法是构建时把每个页面的HTML预渲染成静态文件，部署到Nginx上，浏览器加载后JS再接管交互。我实测了Kimi的可见性，从0涨到8条引用，索引量也突破了之前的瓶颈。TBT从450ms降到120ms，首屏图片本来占了页面体积的60%多，配合懒加载和WebP压缩，整体包体砍了快一半。

有个坑必须提醒：静态生成对动态内容不友好，比如实时报价、在线预约这种接口数据。我当时的处理是给这些模块单独做客户端请求，配合骨架屏过渡，既保住了抓取，也没牺牲交互。核子GEO的SEO评分体系里有一项叫”可抓取性”，我优化后这项从C级升到了A-，说明方向没错。

你要是预算有限、服务器配置一般，静态生成加水合是目前性价比最高的路。别一上来就折腾SSR全家桶，先把Nginx缓存和静态资源压缩搞定，再谈渲染模式。

避坑清单

  • 纯CSR跑AI引擎抓取，索引量大概率卡在200以下，别抱侥幸- 切SSR前先算好服务器负载，2核4G跑Nuxt全量SSR会直接被打爆血泪教训。- 静态生成后记得给动态模块做客户端独立请求，否则功能会哑掉- 图片不压缩，什么渲染模式都救不了首屏速度，先把WebP和懒加载上了

Nginx配置血泪：Brotli和缓存头救回一半分

本地服务站的图多，首屏图片占页面体积超过60%，这是我最头疼的事。但真正让我翻车的不是图片本身，是传输方式。我用的阿里云轻量服务器，带宽就3M，一张压缩过的首屏图都能卡两秒。后来我实在受不了，把Nginx从1.20升到1.22，开了Brotli压缩——这玩意儿对HTML和JSON的压缩率比Gzip狠太多了。

我实测了一下，首页HTML从142KB掉到58KB，接口返回的JSON数据从80KB缩到34KB，体积降了接近58%。首屏时间从3.2秒降到1.9秒，那感觉像换了台服务器。配置上我就做了两件事：在nginx的http块里把brotli开关打开、压缩级别设为6，然后静态文件类型统统加上。别用默认级别，级别4和6差距肉眼可见，但级别9压得慢，得不偿失。

静态资源的缓存头也是重头戏。我给图片、CSS、JS这些文件统一加了Cache-Control，设成30天，重复访问直接走本地缓存，加载时间又砍了40%。这招对本地服务站的落地页尤其管用——用户搜”附近修空调”点进来，返回再点另一个服务页，那些重复的JS不用再拉一遍。

但坑也在这血泪教训。我给图片加缓存时忘了加Vary头，结果CDN缓存错乱了。用户用手机访问拿到的是桌面版图片缓存，尺寸对不上，布局直接崩。排查了半天才发现是Vary头缺失，让CDN没法区分客户端类型。加上Accept-Encoding和User-Agent两个Vary值之后才算消停。

这套搞完，我用核子GEO的SEO评分体系跑了一遍，缓存策略项从0分直接拉到80分，整体GEO分翻了一倍多。之前那些图片优化折腾半天没见起色，反而是压缩和缓存带来的提升最直观。说实话，这个阶段还没到上SSR的决策点，但Brotli和缓存头这步走完，至少撑住了用户体验的基本盘。

本地SEO细节：地图和结构化标记别漏

给本地服务站做优化，光盯着Kimi排名远远不够。我手头这个客户是杭州的维修品牌，Kimi每三次本地问答里就有一次问”营业到几点”“周末开不开门”。这些问题我网站里明明写了，但Kimi就是不引用。

我习惯用核子GEO做初步诊断，输入域名就能看到结构化数据检测分数。跑了一遍结果让我冒冷汗——LocalBusiness Schema虽然加了，但缺少营业时间、地区覆盖和服务区域三个关键字段。等于告诉搜索引擎：这有个商家，但具体什么时候开门、服务哪几个区，全都没说。

补schema这事儿没啥技术门槛，但细节决定成败。我把营业时间拆成周一至周五、周六周日两套，地区覆盖精确到街道级别，服务半径写了”杭州市主城区15公里内”。同时把Google Business Profile里的营业时间跟网站完全对齐，一个小时的偏差都会让AI引擎产生疑惑。

改动上线后我做了个对比实验：同一批本地问答问题，Kimi引用我网站的频次从每周2次涨到15次。跳转率也跟着改善——以前用户点进来看不到营业时间直接关掉，现在首屏就能看到完整信息。

另一个容易漏的是地图链接。我给页面加了”点击导航”的锚点，直接连到高德和Google Maps的导航接口。Kimi在回答”怎么过去”这类问题时，会更倾向引用带导航入口的页面。

顺带一提，核子GEO的SEO评分体系里，结构化完整性占了不小的权重。我之前一直忽略这块，觉得做好内容就行，实测发现这是本地服务站的隐形流量入口。

避坑清单

先说别在首屏堆大图。我接手这个本地家政站时，首屏三张实拍图加起来快2MB，Lighthouse报F。图片占页面体积67%，打开要6秒多。现在统一压到120KB以内，体积降到31%。真以为宽带够快就无所谓？移动端用户没那个耐心。

再就是地图嵌入别用官方默认代码。Google Business Profile的嵌入iframe默认带一堆参数，加载额外JS。我改成懒加载——用户滚动到地图区域才触发加载。首屏速度从4.2s提到2.1s。核子GEO的结构化数据检测报告里显示，地图标记缺失LocalBusiness Schema，加了之后本地搜索可见性明显好转。

还有SSR不是救世主。我纠结了两周要不要从CSR切到SSR，结果先优化了图片和缓存，Core Web Vitals全绿了。LCP从3.8秒降到1.4秒，CLS归零。CSR加预渲染就够了，别为了SEO去折腾Nuxt的SSR配置，性价比太低。

  1. Nginx缓存别只开静态文件。我加了microcaching，对HTML页面缓存15秒，配合CDN，TPS从40涨到200+。阿里云那个免费版够用，别急着升级配置。

  2. 图片格式别死磕WebP。Avif在安卓上表现更好，但Safari支持还是烂。我做成双格式，nginx里用map指令按UA切换。省了差不多30%的图片体积。前提是用户头像这类动态图别碰，只处理静态资源。

  3. Kimi和其他AI引擎抓取的是结构化数据。我跑了一遍核子GEO的SEO评分体系，发现Business Schema缺失，点评聚合也没标记。补上之后，AI摘要里能直接展示我的评分和营业时间。这个投入半小时，比研究一个月算法更新都值。

  4. 别信那些”秒开”插件。我用过一个图片懒加载插件，结果把Above the fold的图片也延迟加载了，LCP反而变差。手写IntersectionObserver，只对首屏以下的图片生效，首屏的立刻加载。

  5. 监控别只看百度统计。我加了几个关键页面的真实用户监控，发现Android端Chrome的用户体验分数一直偏低。查了半天是字体加载阻塞渲染。换成自托管字体，子集化之后，那个指标直接上绿。你要是用第三方字体库，大概率也会踩这个坑。

延伸阅读