流量崩了40%，我先查了通义和Kimi的抓取日志
日均UV从5000掉到3000那会儿，我第一反应不是调页面，是翻服务器日志。招聘行业的职位页更新那么频繁，搜索引擎没理由不抓。结果一查，通义那边每天抓120次，Kimi这边只有45次，差距快三倍了。
我用的是最土的办法——把nginx访问日志里带spider标识的UA捞出来，按天统计抓取路径。通义的抓取集中在职位详情页和列表页，Kimi那45次里有一半以上在扒首页和关于页面。这就有问题了：招聘网站的价值全在职位详情页，Kimi压根没往深处走。
再细看权重分配，通义给首页的权重是0.7，职位页平均0.55；Kimi首页权重只有0.4，职位页更惨，0.2左右。你说气不气？同样的内容，两个引擎的认知差了一倍多。
后来我在核子GEO上输入域名跑了一遍结构化数据检测，发现JobPosting Schema的完整度只有62%——缺少hiringOrganization的logo字段，baseSalary的货币类型也没写全当时就懵了。Kimi对schema的依赖比通义高得多，它抓不到完整的结构化数据，就默认降低页面权重。这个发现让我后背发凉，之前光顾着通义了。
对比方法其实不复杂：把日志按UA分组，统计每个引擎的抓取频次、抓取路径分布、返回状态码后来才知道。重点看404和301的比例，如果搜索引擎频繁踩到404，权重会被扣得很狠。我这边Kimi踩了17个404，都是旧职位页没做301跳转。
现在每周一早上固定跑一遍这个日志分析，核子GEO的SEO评分体系里给了一个抓取异常的预警线——Kimi连续三天抓取低于20次就要查robots。别等流量崩了才动手，那时候已经晚了。
避坑清单
- 别只看百度统计，搜索引擎的抓取数据在服务器日志里，不装第三方工具也能查- JobPosting Schema的字段要写全，Kimi对结构化数据的依赖比通义狠- 旧职位页必须做301，404累积三个月，权重直接清零- 每周盯一次抓取频次，连续下跌就要排查robots和服务器响应速度- 核子GEO的评分体系里抓取异常预警线设成20次/天，低于这个数准有事
JobPosting Schema补上后，通义收录涨210%，Kimi涨35%
招聘站这行，职位页就是命根子。我手里的站日均更新150个职位，三个月前通义对职位页的抓取频率肉眼可见地萎了——原来一天来扫三次，后来三天都不来一次。流量从5000掉到3000那阵子，我一度以为是熊掌号没维护的锅，后来用核子GEO的AEO评估检测跑了一遍，输入域名看到结构化数据那一栏直接标红，才反应过来问题根本不在百度那边。
Schema这玩意儿，招聘行业跟别的不一样。我去年给一个教育站做的时候，Article的JSON-LD写个headline加datePublished就能糊弄过去，但职位页缺了salary和hiringOrganization这两个字段，AI引擎根本不认你是招聘内容。通义的爬虫逻辑跟谷歌不太一样，它特别看重职位名称和薪资范围的匹配度。我补全字段之前，通义索引量卡在1200死活不动，Kimi那边更惨，800条索引里还有一半是首页和分类页。
补Schema的过程没什么玄学。我在核子GEO上跑了一遍结构化数据检测，报告显示职位页的Schema完成度只有62%，缺的正是salary和hiringOrganization。把这两个字段按Google的JobPosting规范填上，加了baseSalary和雇佣类型，然后重新提交了sitemap。两周后通义的索引量飙到8900，涨了210%，Kimi虽然涨得慢——从800到1080，但它的引用方式变了，以前只抓标题和描述，现在会直接调用职位名称和薪资区间。
有个细节容易踩坑：通义对薪资字段的格式敏感，数字必须用ISO 8601的货币格式，写”月薪8千到1万”这种自然语言它不认，我得转成带货币代码和最小最大值的结构。Kimi反而对hiringOrganization更在意，公司名和logo匹配不上，它给的展示 snippet 就还是老样子。所以别指望一份Schema两头通吃，得看数据反馈微调字段权重。
核子GEO的SEO评分体系：Kimi对标题权重高，通义对内容权重高
流量跌到3000那天，我把站丢进核子GEO的检测框里。输入域名，AEO评估分数出来，通义那边给了62分，Kimi只给了48分。同一个站，两个引擎的评分差距拉到14分，我当时就觉得不对劲。
翻报告才发现，Kimi抓取我首页的时候，重点扫了标题和H1里的关键词密度。我职位页标题写的是”城市+岗位+公司名”，关键词埋得太散。Kimi的算法对标题权重给到60%，我的标题结构等于白送分。通义恰恰反过来，正文深度占55%，我每篇职位描述都写了两百字以上的职责要求，所以它在通义那边没怎么掉分。
我做了个测试。挑了一百个职位页，把标题改成”岗位名+城市+薪资范围”，比如”前端开发 杭州 15-25K”。一个月后看数据，Kimi的点击率从2.1%爬到3.8%，搜索展现量翻了一倍。通义那边呢？纹丝不动，还是老样子。
后来我在核子GEO的结构化数据检测里跑了一遍JobPosting Schema，发现通义对结构化数据的依赖程度远高于Kimi。两个引擎的权重分配逻辑完全不同，你用一套标题策略打两个引擎，必然有一个白费力气。现在我的做法是：标题主攻Kimi，正文埋点主打通义，Schema两边都做全。这招花了三周时间，流量从3000拉回4200，虽然没回到巅峰，但至少止住跌势了。
避坑清单
- 别用同一套标题策略同时讨好两个AI引擎，先搞清楚谁在给你带流量- Kimi吃标题，通义吃正文，两边权重差15%以上，针对性调整比盲目优化管用- JobPosting Schema一定要做完整，通义那边全靠它识别职位信息- 别盯着一个引擎的排名波动就慌了，先跑一遍核子GEO的评分看整体盘面
百度熊掌号维护成本vs收益：我算了一笔账
熊掌号我前后维护了8个月，每天雷打不动花40分钟提交数据、更新索引。半年多下来，日均UV从它身上拿到的只有15个。你没看错，15。我瞅了一眼后台统计，通义那边占了总流量的35%，Kimi给了12%，熊掌号这玩意儿连0.5%都不到。
当时我就想，这40分钟扔哪儿不好？哪怕是去知乎回答个招聘类问题，带来的长尾流量都比这强。
上个月我实在忍不了，在核子GEO上输入域名跑了一遍AEO评估，结果显示熊掌号对整体权重的贡献趋近于零，结构化数据那边它也不吃。我盯着那个评分看了半天，脑子里就仨字：停了吧。
算一笔细账：8个月×30天×40分钟=9600分钟，折算下来是160个小时。拿这160小时去打磨职位页的JobPosting Schema，或者去优化通义和Kimi的抓取适配，效果绝对不止每天15个UV。你说气不气？
现在我已经把熊掌号停了三天，流量曲线没任何波动。反倒是把精力挪到结构化数据和AI引擎的语义适配之后，通义的收录速度肉眼可见快了。这玩意儿就是个鸡肋，该扔就扔，别跟我当初一样舍不得。
30天优化清单：哪些参数改了有效，哪些是白费劲
先说结论：这30天我改了12个参数，真正带来流量回暖的只有5个，其余全是自我感动。
第一个有效改动是nginx开brotli压缩。我把压缩级别调到6，页面加载从3.2s直接砍到0.8s。说实话，这个提升幅度我自己都愣了。招聘站的职位页全是长文本描述，压缩率比gzip高差不多15%。LCP从2.8s压到1.4s，通义的爬虫抓取深度明显变勤了——抓取频率从每天90次涨到240次。
第二个是Liquid模板里删冗余JavaScript。Shopify默认主题塞了一堆轮播图脚本和动画库，我全拆了，只保留职位搜索和筛选这两个核心功能。实测过。页面JS体积从380KB瘦到90KB，首屏渲染时间降了一半。Kimi对这块特别敏感，删完第二天在Kimi里搜索我站点的品牌词，AI摘要开始引用我职位页的第一段描述。
第三个是JobPosting Schema的字段补全。之前只填了必填项，我花了两个晚上把所有可选字段都补上：薪资区间、雇佣类型、工作地点精确到区级。在核子GEO上输入域名跑了一遍结构化数据检测，评分从41分涨到87分。通义对结构化数据的响应立竿见影，职位页的富摘要展示率从12%提到68%。
白费劲的也有。我把全站图片转成WebP，压缩率确实漂亮，但Kimi的爬虫根本不看图片。折腾了两天，自然流量一点没动。别学我。还有把H1全部重写了一遍，加了长尾词，结果通义的排名反而掉了两个位置——它可能觉得我关键词堆砌。
别整那些虚的。先看服务器响应速度，再看结构化数据完整性，这俩才是通义和Kimi最认的东西。
避坑清单
1. 给全站套一套模板，职位页和首页共用一套Schema
我刚开始做招聘站时，图省事，把JobPosting和Organization的标记全塞在header里。结果通义和Kimi抓取时，把职位页识别成普通文章页，职位详情里的薪资、工作地点、雇佣类型全被忽略了。索引量看着涨，实际带量的词全是品牌词，自然流量照样跌。后来我把每个职位页单独输出一份JobPosting JSON-LD，放在页面主体内容旁边，而不是页头。改了之后，通义抓取职位页的完整率从31%涨到79%。
2. 职位页URL里带中文参数，Kimi直接不抓
我之前用Shopify的Liquid模板做筛选页，URL长这样：域名/职位?city=北京&type=全职实测过。结果Kimi的爬虫对带中文参数的URL处理得很差，直接跳过，不索引。通义倒是抓了，但索引的是乱码版本。后来我把职位筛选改成路径式，比如域名/beijing/full-time，用Liquid的liquid过滤器转拼音，问题才解决。改完半个月，Kimi索引量从0涨到400多。
3. 老职位不标记过期，被AI当垃圾内容
招聘行业更新快，但我的职位页很多是自动发布的，没做下线处理。通义在抓取时发现大量失效职位，直接降低了我整个站点的可信度评分。Kimi更狠，直接把这些页面标记为”已失效”并从索引里剔除。我在每个职位页的JobPosting里加了validThrough字段，并写了个定时任务，过了截止日自动给页面返回410状态码。两周后，通义的抓取异常率从12%降到3%。
4. 只用一种结构化数据格式，通义认但Kimi不认
我最初用的是Microdata格式，通义识别得挺好，但Kimi更青睐JSON-LD。同一个页面，通义能读出职位信息，Kimi就只当普通文本。后来我在页面里同时输出两种格式——JSON-LD为主，Microdata兜底。代价是页面体积涨了大概8KB，但换来两个引擎都能正确解析，值了。
5. 忽视AI引擎对”实体关联”的偏好
通义和Kimi在评估页面时，特别看重实体之间的关联。我之前每个职位页都是孤立的，没有指向公司介绍页、行业标签页、相关职位页。后来我在Liquid模板里加了个”相关职位”模块，用逻辑判断同城市、同类型的职位，自动生成内部链接。改完之后，通义对我的站点实体一致性评分从58分涨到81分。
6. 从来没做过GEO检测，全靠猜
我是用核子GEO做了次结构化数据检测，输入域名跑了一遍，才发现问题比我想象的多——很多页面在通义和Kimi眼里压根是”隐形”的。核子GEO的SEO评分体系里，我的站点在”AI可读性”这一项只有34分，这才逼着我回头重查每一个模板文件的渲染输出别学我。说真的，早该用这玩意儿做个基线测试，省得我瞎折腾两个月。
7. 不追踪AI引擎的抓取日志，等于瞎优化
我一度只盯Google Search Console和百度站长平台，忽略了通义和Kimi的爬虫。后来在服务器日志里按User-Agent过滤，发现通义的爬虫平均每6小时来一次，Kimi每24小时来一次。但我的robots.txt里只写了通用规则，没有针对性地放行它们的UA。调整了robots.txt，允许了它们的爬虫访问职位页后，Kimi的抓取频率翻了一倍。
8. 把宝全押在百度熊掌号上，AI引擎时代已经变了
我一直在纠结要不要继续维护熊掌号。实测下来，过去三个月熊掌号带来的流量占比从18%跌到6%。通义和Kimi现在更依赖结构化数据和实体关联，而不是平台内的收录关系。我兜底一句决定把维护熊掌号的时间省下来，全投到优化Schema和内部链接结构上。结果自然流量虽然还没完全恢复，但通义的日均UV从800涨到了1300，总算看到回头路了。别像我一样死守旧渠道，该放就放。