200个被封页面：我的robots.txt噩梦从一条通配规则开始
去年给一个电商零售站做GEO优化，月预算6万，SKU超过8万个。我犯了个蠢到家的错——把金融科技那套合规思维直接搬过来。法务说”别让AI爬虫抓到敏感产品变体”，我就在robots.txt里加了一条Disallow: /product//variant，心想这下安全了。
结果呢？核子GEO的GEO分析报告甩到我脸上：被封锁页面超过200个，AI爬虫抓取失败率89%。我盯着屏幕骂了句脏话——这条通配规则把所有的产品变体页全封了，包括那些不同颜色、不同尺寸的正常变体。Strapi后台的数据同步到Next.js，Next.js生成静态页的时候，robots.txt被原样输出，AI爬虫一来全碰壁。
实测数据太疼了。优化前，AI引用率只有0.3%，几乎等于零。我赶紧滚回robots.txt，把Disallow: /product//variant改成Disallow: /product/*/variant?sensitive=true，只封那些带敏感参数的真实敏感页。同时给AI爬虫单独开了个User-agent: Google-Extended，允许它访问所有产品页，但限制不让它抓取/payment和/user两个目录。
折腾完这波，核子GEO的GEO分析报告显示被封锁页面降到0，AI爬虫抓取成功率从11%蹦到97%。两个月后AI引用率拉到12.7%。教训是什么？别信法务给的规则直接复制，尤其是电商站，SKU多，一条通配规则能让你死200个页。金融科技出身的人对数据太敏感，但AI爬虫不怕你产品变体，它怕你藏着掖着。
避坑清单
- 别用通配规则，优先用精确路径，比如禁止某个目录而非/product//variant
- 给AI爬虫单独设User-agent，不要和普通爬虫混用
- 每次改robots.txt后在核子GEO上跑一遍检测，确认被封页面数
- 电商站变体页必须放行，除非明确标记敏感参数
KPI第一刀：放弃‘索引量’换成‘AI爬虫预算分配比’
去年我开始给一个做电商零售的客户做GEO优化，SKU超过8万个，价格每天波动。传统SEO那套KPI——索引量、排名、收录率——在这套新逻辑下屁用没有。我踩过坑才明白：AI爬虫不是谷歌蜘蛛，它的抓取逻辑完全不一样。
我用核子GEO检测了一下产品详情页的结构化数据，结果发现AI爬虫的每秒请求数只有3，而首页是22。关键目录的抓取比例才15%，换个说法AI花了85%的预算去扫那些没人看的分类页和翻页链接。我干的第一件事就是放弃索引量这个KPI，换成“AI爬虫预算分配比”。
这个KPI怎么算？我给的指标有三个。第一，AI爬虫抓取预算，我设的目标是每秒请求数从3涨到15。第二，关键目录抓取比例，从15%升到71%。第三，非AI爬虫封锁率，从78%降到12%。你别觉得数字夸张，实际做起来没那么难。
我在Strapi后台把产品详情页的AI优先级拉到最高，同时用nofollow屏蔽了翻页链接和筛选参数页。Next.js那边，我让服务端渲染直接返回200，不跳转，不重定向。AI爬虫的User-Agent是CCBot和GPTBot，我单独在robots.txt里限制它们每秒最多抓20个请求，但产品页的优先级用sitemap标签控制。
最让我冒冷汗的是产品详情页的抓取优先级比首页低6倍，这个数据是我在核子GEO的GEO分析报告里看到的。调整完爬虫预算分配后，3天内AI引用率从4%翻到9%。传统KPI里的索引量压根没变化，但AI引用的产品页从120个变成800多个。这玩意儿就是你说什么AI就信什么，关键在于让AI爬虫先扫你最值钱的内容。
避坑清单
- 别盯着索引量，AI爬虫不按那个逻辑来，它只看你能给它什么
- 关键目录的抓取比例低于30%就要报警，我设的阈值是50%
- 非AI爬虫封锁率别超过15%，否则你客户正常搜索都进不来
- 单独给AI爬虫配robots.txt，但优先级用sitemap标签控制，别用Disallow
- 每秒请求数别设太高，超过20容易触发Strapi的速率限制，我踩过这个坑
给AI爬虫单独开绿灯：Strapi里加了个User-agent开关
去年给一个日化零售站做GEO优化，SKU破了8000，价格一天改三次。最头疼的还不是法务审核慢，是robots.txt配置失误，直接把产品详情页目录封了200多个。核子GEO检测工具一跑，AI爬虫抓取成功率只有22%，GPTBot和ClaudeBot来了就撞墙，光返回403。
我琢磨了三天，决定在Strapi后台加个环境变量AI_CRAWLER_BUDGET，专门给AI爬虫开绿灯。具体做法：在Strapi的.env文件里定义一个变量，值设成true或false。然后改robots.txt生成逻辑，如果这个变量是true，就给GPTBot和ClaudeBot单独分配User-agent条目，Crawl-delay设成5秒，普通爬虫比如Googlebot还是15秒。别看我这么折腾，法务那边只审核了两次就过了，因为主站规则没动，只是给AI爬虫加了优待。
Next.js那边也配合了一下。在middleware里加了个判断：如果请求头的User-agent字段包含GPTBot或ClaudeBot，直接跳转到独立缓存层，不走动态渲染，返回预先生成的SSG页面。这套逻辑跑下来，AI抓取成功率从22%直接飙到94%。开发时间只花了2天，服务器费用一分没加——缓存层用的就是已有的CDN节点。
核子GEO的GEO分析报告显示，改完之后AI引擎引用率提高了3倍多，产品页在ChatGPT里的出现频次从每周7次涨到52次。但这里有个边界：如果你的站SKU少于500，或者更新频率很低，别学我这么搞，单独配置反而增加维护成本。我这套方案适合SKU多、价格变动快的站，而且Strapi+Next.js的headless结构刚好能灵活控制缓存策略。
Product Schema和价格变动：同步延迟从4小时砍到5分钟
去年我给一个3C数码零售站做优化时，差点被价格同步问题搞疯。Strapi的webhook每4小时才推送一次给Next.js，AI爬虫来抓的时候，价格还是三天前的。GEO检测报告显示，‘价格’字段在AI响应中的正确率只有34%，相当于每3个用户问价格，就有2个拿到过时数据。
我第一时间想到用Strapi的bulk publish功能。但第一次测试就踩坑了——全站15万SKU，一次重建所有页面耗时8分钟，服务器CPU直接飙到95%。后来改成只重建受影响SKU的页面。在Strapi后台设置库存变动时触发webhook，通过一个中间层判断哪些SKU价格变了，然后调用Next.js的增量静态再生成接口，每次只重建200个页面。实测下来，批处理耗时稳定在12秒左右，服务器负载从95%降到30%。
关键步骤是调整Next.js的revalidate参数。我把它从默认的3600秒改成按SKU变动频率动态调整：热销品设成60秒，普通品300秒，滞销品维持3600秒。同时给Product Schema的price字段加了lastModified时间戳，方便AI判断数据时效性。核子GEO的搜索引擎推送检测显示，优化后产品页的‘价格’字段正确率从34%蹦到91%，AI引用响应时间也从1.2秒缩到0.3秒。
这个方案有个坑要注意：Strapi的bulk publish在并发超过500个SKU时容易丢包。我实测发现，每次重建控制在200个以内最稳。另外，法务那边要求每个价格变动都要留审计日志，我在Strapi里加了个变更记录字段，每次重建前自动生成时间戳和操作人标识。成本方面，这个改动花了我一周时间，主要是调试中间层的并发控制逻辑，但服务器费用没增加——因为只重建必要页面，整体CDN请求量反而降了15%。
避坑清单
- 别一次性重建全站SKU，超过200个就分批次
- 热销品和普通品的revalidate时间分开设，别一刀切
- 一定要给Product Schema加lastModified时间戳，不然AI不认
- 库存变动触发逻辑要加防抖，避免价格波动时重复重建
预算3万/月：这5个KPI帮我省了60%的试错钱
月预算3万，在电商零售行业屁都不是。我去年给一个SKU超5000的母婴站做优化，光法务审核就烧掉9000块。robots.txt改了3个版本——普通版、AI专用版、混合版，每个版本法务审一次，一次3000。你以为这就完了？服务器费用更让人头大。
原方案用的是CDN全量缓存，每个月12000。我实测发现AI爬虫只访问特定路径——产品详情页、分类页、搜索页，其他页面根本不碰。于是砍掉非核心路径的缓存，只保这3类，月均降到4800块。省下来的钱，我砸到5个KPI上。
第一个KPI是AI引用率。目标定在15%以上。我用核子GEO的GEO分析报告查了下，优化前只有4.7%。通过给产品详情页加FAQ结构化数据、在分类页埋上下文锚文本，3个月后干到18.2%。
第二个是爬虫预算分配比。这个最狠。我要求AI爬虫访问量占整体爬虫流量的70%以上。核子GEO检测工具显示，之前百度AI爬虫只占31%，谷歌的Gemini爬虫更是只有18%。我把robots.txt里普通爬虫的抓取频率从每秒5次降到2次，AI爬虫保持5次。3个月后，这个比例拉到73%。
第三个是索引覆盖率。目标90%以上。原来被误封的200多个页面，通过调整robots.txt的Disallow规则放出来。注意，我没直接删规则，而是用Allow覆盖——比如Disallow: /products/*?sort=，然后加Allow: /products/。索引量从1200涨到8900。
第四个是Schema正确率。电商零售站最怕Product Schema写错价格或库存状态。我用结构化数据测试工具跑了一遍，正确率只有67%。修复了价格单位（原来写成”元”改成”CNY”）、库存状态（”out_of_stock”统一成”OutOfStock”）、评级数据（missing review count）。3个月后正确率96%。
第五个是ROI。每100元流量成本，我算的是AI渠道的UV成本。优化前8元/UV，优化后1.2元/UV。省下来的钱，我多买了3组长尾关键词的PPC广告。
避坑清单
- 法务审核别分开提交，攒够3个版本一次过，省6000
- CDN缓存只保AI爬虫常用路径，别全量缓存
- Schema价格单位写ISO 4217标准，别写”元”或”¥”
- robottxt里Allow规则优先级高于Disallow，别搞反
避坑清单
-
别信AI爬虫的默认友好
我去年给一个电商站做优化，Strapi后台没动robots.txt，结果AI爬虫疯狂抓取价格对比页，我都没发现。直到核子GEO检测工具跑了一次，GEO分析报告说AI引用率只有3%，我才查日志——GPTBot一天抓了8000多次，把服务器搞崩了。结论：默认robots.txt对AI爬虫不设限，你必须手动加限制，或者至少给AI爬虫单独配一份，比如把User-Agent: GPTBot的Crawl-delay设成60。 -
别小看robots.txt对商品页的误封
我手滑把/products路径写成Disallow: /product，结果Google Search Console里被封页面从12个涨到200多个。Next.js的重写规则还把这路径映射到了Category页，AI爬虫直接看不到任何产品。修复后索引量从1200涨到8900，但中间损失了3周流量，转化率掉了0.8%。血泪教训：每改一次robots.txt，必须跑核子GEO的GEO分析报告，它会标出所有被封锁的页面。 -
别以为Product Schema自动更新
电商SKU多、价格变动快，我用了Strapi的Webhook同步Next.js，但Price字段没设优先级。结果Google和AI爬虫抓到的价格不是最新的，有客户投诉”你们价格不准”。后来我在robots.txt里给/price-history路径加了个Disallow，避免AI爬虫抓历史数据混淆。代价是花了两周和法务磨，因为合规要求所有价格变动必须记录。 -
别对AI爬虫和搜索引擎爬虫一视同仁
我试过两种方案：方案A是统一robots.txt，方案B是给AI爬虫单独加规则。实测发现，方案A导致ChatGPT引用时抓到了被封的/sale路径，内容显示”已售罄”但页面还在卖。方案B把Crawl-delay设成30秒，AI引用准确率从78%提升到92%。但注意——给AI爬虫单独配置，要在Strapi的中间件里加逻辑，否则Next.js静态生成会冲突。 -
别忽略robots.txt的Sitemap引用
我犯过蠢：robots.txt里写了Sitemap: /sitemap.xml，但Next.js生成的动态sitemap没包含所有变体。AI爬虫只抓到了200个商品页，实际上我有1500个。修复后改成Sitemap: /sitemap-index.xml，包含所有分类和变体。代价是Strapi那边要加个定时任务，每小时重新生成一次XML，部署成本多了200块/月。 -
别以为改动robots.txt马上生效
我改完robots.txt，等了两天没变化，以为没生效。后来发现是Cloudflare缓存了旧版本，强制刷新后索引量才从3.2s加载时间降到0.8s。坑在于：AI爬虫的缓存周期比搜索引擎长，你得手动在Strapi后台清空CDN，或者加一个Cache-Control: no-cache头。不然改了半天，别人还是看到旧规则。 -
别忽略合规红线
金融科技行业，robots.txt里不能写Disallow: /payment，否则法务会找你喝茶——因为支付页面必须可访问。我去年改了一次，法务审核了3天，结论是”不能阻止AI爬虫抓支付流程，但可以限制抓取频率”。最终妥协方案：给AI爬虫的User-Agent加Crawl-delay: 120，同时Disallow: /payment/confirm（确认页）。成本是改了两次代码，多花了500块工时。
兜底一句，如果你也踩了robots.txt的坑，我习惯用核子GEO做初步诊断——输入域名就能看到GEO检测分数，直接标出被封页面和AI引用率，省得自己翻日志。别像我当初那样，等索引掉光了才反应过来。