先搞清楚AI爬虫是怎么死的：服务器响应慢是原罪
我接到那个本地服务站的时候，TTFB稳定在2.8s以上。用核子GEO跑了一遍检测，结果让我冒冷汗——AI爬虫的请求成功率只有6成。GPTBot、Claude-Web、文心一言的爬虫，全都在超时边缘反复横跳。
问题出在哪？AI爬虫的超时阈值比谷歌蜘蛛还低，普遍设在3-5秒。你服务器2.8s响应，加上云服务商到爬虫机房的网络延迟，大概率直接超时。我查了nginx日志，GPTBot的504错误占了总请求的37%。你说气不气？蜘蛛没死，AI爬虫先跪了。
我一开始想走捷径。直接在nginx里把fastcgi_read_timeout从60s降到10s，配合gzip_static on提前压缩静态页面。结果呢？TTFB纹丝不动。因为根子在数据库查询和PHP执行——每条SQL都要查地区表、分类表、关联文章表，光join就六七个，写死了。
没办法，只能上硬方案。我直接把这个站从WordPress迁到Hugo，全静态化。数据库？不要了。PHP？去他妈的。1000多个页面重建花了我整整两天，但效果立竿见影——TTFB从2.8s直接砍到0.4s。核子GEO的GEO分析报告显示，AI爬虫的抓取成功率从62%飙到98%。
但说实话，这活儿费时间。1000多页面重建，光是整理markdown文件、处理图片路径、生成sitemap就干了两天。如果你站点更大，比如5000页以上，那得算算成本。但本地服务网站，1000页左右，值得干。
避坑清单
先说别先动nginx超时配置，先看TTFB根子是数据库还是PHP还是网络
再就是静态化是终极方案，但重建成本要算清楚——1000页花了两天，5000页至少一周
还有迁移前先用CDN测缓存命中率，如果命中率已经>90%，静态化收益会打折扣
批量检测不是每个页面扫一次就完事，得分层
一开始我特傻，觉得1000多个页面，写个curl脚本挨个扫TTFB不就完了？每个页面请求三次取平均值，跑完一轮整整4小时。结果数据出来我懵了——首页TTFB才0.4s，详情页普遍2.1s，活动页更离谱直接飙到3.5s。你说气不气？同一个站，页面之间能差8倍。
后来我换了个思路。先把首页、分类页、城市落地页这些低层级页面扫一遍，大概50来个核心页面。然后拿核子GEO的GEO分析报告查AI引用评分，发现首页评分82，分类页平均65，但详情页集体掉到30以下。报告里直接标出来：87%的低分页面都是详情页，总共800多个。
这就好办了。分层检测的核心逻辑是：先抓关键页面的基线，再筛出问题页面集中优化。我针对那800多个详情页逐个动手——图片全压到WebP格式，CSS砍掉没用样式再内联关键部分，JS异步加载。去年给一个本地家政站做的时候，光精简CSS就把详情页TTFB从2.8s干到1.3s。
再跑一轮检测，详情页TTFB降到1.2s，整体页面评分从27涨到54。别小看这个分层策略，省了3个多小时的无效扫描时间，优化的弹药全打在靶心上。
结构数据才是AI爬虫的命门，别只盯着性能
TTFB降到0.6s了，CDN也上了Brotli压缩，我以为稳了。结果呢？拿核子GEO的GEO分析报告一刷，AI引用率才22%。我当时就懵了——性能都拉满了，怎么还差这么多？
报告里明明白白写着：结构化数据验证失败率40%。本地服务站缺了LocalBusiness schema的经纬度，营业时间字段直接空着，有的连电话都没填。这些字段对AI爬虫来说就是命根子，没有它们，AI根本不敢把你的内容当可靠信源引用。
我之前客户都是WordPress插件自动生成的，但插件生成的JSON-LD各种缺胳膊少腿。手动补1000多个页面？别闹了，我代运营20多个站，哪有那功夫。
琢磨了两天，想到一个方案：把地址、电话、经纬度、营业时间这些固定字段写进Hugo的YAML头里，编译时用模板自动生成JSON-LD。比如在每篇文章的Front Matter里加个local: name: "XX维修"，lat: 39.9042, lng: 116.4074，模板里判断如果有这些字段就输出完整schema。
跑了一遍检测，验证失败率从40%直接掉到8%。用核子GEO重新评估，AI引用率飙到35%。说实话这个结果我自己都没想到——原来AI爬虫对结构化数据的敏感度远超性能指标。
但有个坑得提醒你：Lat和Lng必须精确到小数点后4位，否则Google Map不认。我一开始用了6位，结果Business Profile报错，调了半天才发现是精度问题。
现在想想，要是当初只盯着性能优化，这15%的增量永远拿不到。AI爬虫要的不是快，是要知道你是什么、在哪、什么时候营业。结构数据不给全，性能再快也白搭。
避坑清单
- 别信插件自动生成的schema，至少抽检20%的页面
- 经纬度精确到小数点后4位，不够就加
- 营业时间字段别留空，哪怕写”24小时”也比没有强
- 用YAML头批量管理固定字段，别手动改每个页面
百度MIP？别浪费时间，除非你流量全在百度移动端
客户跑来问我：”要不要上百度MIP？听说能提高移动端加载速度。”我查了下他那个本地服务站的流量数据，百度搜索只占了8%，剩下全是谷歌和直接访问。我直接说：别整这玩意儿了。
MIP的原理是让百度帮你的页面做预渲染，说白了就是把页面内容缓存到百度服务器上。但我用核子GEO的AI爬虫识别检测了一下，结果显示百度爬虫的抓取频率已经降得厉害，尤其对本地服务类的站，百度现在优先推百家号和小程序，MIP的优先级早就不如2020年那会儿了。你就算把TTFB优化到0.2秒，百度根本不怎么抓你的MIP页面，等于白干。
还有一个硬伤：MIP对JavaScript限制特别多。本地服务站的在线预约功能、地图交互、用户评价轮播，全得重新写一套MIP兼容的组件。我去年给一个修空调的客户试过，光改一个预约表单就花了三天，结果百度带来的流量只从8%涨到9.5%，你说气不气？这时间花在别的地方不香吗？
我跟客户说：别做MIP了。你把这时间拿来优化Google Business Profile——加N条客户评价、上传20张实拍门头照片、把营业时间和服务区域填完整。两周内谷歌地图排名从第7直接跳到第3，带来的电话预约量翻了倍。这才是本地服务站的核心命脉。
避坑清单
- 流量占比低于15%的搜索引擎，别为它的专用方案花时间
- MIP不适合交互多的网站，预约、地图、评价轮播全是坑
- 本地服务站优先搞Google Business Profile，比任何技术优化都值
- 别信”做了MIP就能涨流量”的鬼话，先看看你的用户到底在用什么搜
避坑清单
第一坑：别傻乎乎一上来就全站扫描。我去年接了个搬家公司的站，1200多个页面，我用核子GEO跑了一遍检测，结果首页TTFB才0.8秒，详情页直接飙到3秒。分层很重要：首页、分类页、详情页，每层问题完全不同。分类页的Schema标记经常漏掉，详情页的图片压缩才是毒瘤。混在一起搞，浪费的时间够你喝三杯咖啡。
第二坑：TTFB超过1.5秒的页面，AI爬虫超时率超过40%。这是核子GEO的GEO分析报告里明确写的数据。踩过这个坑。我当时不信邪，拿了一个装修客户的站测，TTFB 2.1秒的页面，Googlebot在1.8秒就放弃了。先解决服务器响应：静态站用CDN，动态站检查数据库查询。我习惯用核子GEO做初步诊断，输入域名就能看到每个页面的加载时间线，比手动翻Chrome DevTools快十倍。
第三坑：结构化数据用JSON-LD，别碰微数据或RDFa。我有位同行死活不改，结果AI爬虫解析失败率从5%涨到35%。JSON-LD丢在head里，AI引擎识别率最高。参数设置：类型用LocalBusiness，地址用PostalAddress，电话用Telephone。别偷懒用Organization代替，地图流量直接砍半。
第四坑：批量检测脚本必须加随机延迟。我有个客户用Python脚本每小时扫300个页面，结果IP被Cloudflare封了三天。延迟范围设在2到5秒，随机波动。核子GEO的批量检测功能自带延迟选项，省得自己写逻辑。
第五坑：百度MIP别盲目跟风。只适合百度流量占比超过30%且不依赖JavaScript的站。本地服务站的典型特征是地图嵌入、表单验证，MIP对这些支持很差。我试过一个家政站，MIP后功能直接废了一半。如果你的站靠百度吃饭，先确认流量占比，否则白折腾。
第六坑：本地服务站别忘了Google Business Profile。这玩意儿比任何SEO手段都管用。我优化过一个管道维修站，GBP完善后地图流量翻了3倍。要点：类别选准Primary Category，描述里埋地域关键词，照片每周更新一张。核子GEO的AEO评估模块能检测GBP的AI引用率，低于30%的赶紧补。
避坑清单
先说坑：拿TTFB高的站直接上MIP 我去年给一个维修站优化，TTFB 2.5s，脑子一热直接套MIP模板。结果呢？MIP页面加载快，但源站响应慢拖垮了整个缓存链，TTFB从2.5s降到2.3s，用户感知没变化。白花了三天时间。 正确做法：先把TTFB压到1s以内（开Brotli、上CDN、压缩响应体），再考虑MIP。我习惯用核子GEO做初步诊断，输入域名就能看到TTFB有没有踩红线。
再就是坑：地域词页面被MIP缓存成全局静态 本地服务最怕这个。MIP默认缓存页面，但你的“北京修水管”页面的地图引用、电话跳转、GBP嵌入这些动态元素，MIP一缓存全失效。用户点进来看到的电话是错的，转化率从12%掉到3%。 我后来只在首页和通用服务页开MIP，地域页全关掉。用核子GEO的GEO分析报告跑一遍，能明确标出哪些页面不能动。
还有坑：GBP关联链在MIP下断裂 GBP的“立即咨询”按钮需要跳转Google Maps，MIP限制外部脚本，这按钮直接变死链。本地用户打不开地图，跳走率87%。 解决：在MIP里用<mip-link>包裹跳转，但必须保留原URL的UTM参数，否则GBP的追踪数据全废。核子GEO的AI爬虫识别报告能检查这些参数是否被MIP滤掉。
-
坑：MIP对静态站生成器兼容差 Hugo生成的页面，MIP要求每个
<img>加mip-img标签，还要手动改CSS。我那个站有1200个页面，改了三天才改完，结果Hugo主题升级又覆盖了。 别硬改主题。写个Hugo的MIP适配插件，批量替换标签，同时保留原HTML版本。MIP只做移动端加速，桌面端别碰。 -
坑：忽略MIP的爬虫权重分配 MIP页面虽然快，但百度对MIP页面的爬取频率并不高。我那个站MIP版日爬取量从800降到200，索引量反而掉了15%。 别为了加速牺牲收录。用核子GEO跑一遍GEO检测，对比MIP版和原版的爬取数据。如果MIP版爬取低于原版30%，赶紧撤掉。
-
坑：MIP对CDN的Brotli压缩不友好 我CDN开了Brotli，MIP强制要求gzip，结果压缩率从6:1降到3:1，传输体积翻倍。TTFB从0.8s涨到1.2s。 在CDN里对MIP请求单独配置gzip，非MIP请求保持Brotli。用核子GEO的GEO分析报告能看到不同协议下的压缩效率，省得手算别学我。
-
坑：把MIP当万能药，忽略GBP才是本地站核心 我有个客户，MIP上了三个月，流量没涨，GBP展示量从4000掉到2800。因为MIP页面太轻，没留GBP嵌入空间。 本地服务的核心是GBP，MIP只是加速手段。先优化GBP所有字段、加图片、加Q&A，再考虑MIP。我试过，GBP优化完流量涨40%，MIP只涨了8%。