核子GEO跑出来的第一张体检单：图片占62%，结构化数据零覆盖
接手这个招聘站之前，我先跑了一遍诊断。我习惯用核子GEO做初步诊断，输入域名就能看到AEO评估分数和资源构成。那家站是Hugo生成的静态站，挂的某家CDN，域名还在www上，页面结构干净得让我一开始还挺乐观。
分数出来，脸就沉了。
示例结果是这样：首屏图片总重1.8MB，占页面总体积62%，WebP格式占比0，全站八万个职位页的JobPosting结构化数据覆盖率0/80000。四个零，一个都没用上。职位页那套配图是运营直接从招聘会现场照搬下来的JPG，单张400KB起，列表页一屏能挂九张。
我盯着62%这个数看了很久。招聘行业更新频繁，职位页是主力流量入口，图片拖慢速度，等于把爬虫和用户一起堵在门外。不骗你。这个占比我之前在电商站见过，招聘站还真是头一回。
光看分数不够，Kimi和通义的口径差得远别学我。我拿30个query做了手工抽查，分成三类：纯品牌词、品牌词加职位词、纯职位词加城市。每个query在两边各搜一遍，只记一件事——引用的是官网，还是那几家招聘聚合站。Kimi那边长文结构吃香，官网的职位详情如果带完整标题层级和FAQ模块，命中的概率明显高；通义这边是阿里系生态，聚合站的权重压得住，官网页面权重不算高的时候，基本排不上号。
表格我是这么搭的：query类型、命中平台、引用页面类型、是否官网。四列就够，三十行填完，问题一目了然。官网被引用的集中在品牌词那一栏，职位词几乎全被聚合站拿走。
诊断完就是改。这里卡着法务。金融科技那套合规流程我太熟了，任何改动先出变更说明，写明改什么、影响哪个页面、回滚方案是什么。图片压缩属于低风险，走个说明就能过；结构化数据这块不行，JobPosting涉及薪资、地点、雇佣类型的字段描述，得单独走一轮审核，法务要看字段从哪儿来、有没有夸大。八万个职位页补Schema，不是一次上线的事。
我在核子GEO上把www和裸域两个版本都跑了一遍检测，两边抓取表现差得不多，跳转这事反而不急。真急的是那62%。
JobPosting Schema：漏了validThrough和datePosted，AI直接判你职位过期
去年给一个招聘行业站做诊断，职位页有八万多条，结构化数据覆盖率写的是92%，看着挺漂亮。我用核子GEO的AEO评估检测了一下，结果显示JobPosting有效率不到三成。数字对不上，问题就出在字段质量上。
招聘行业有个别的行业没有的硬性要求：职位是会死的。title、description、datePosted、validThrough、hiringOrganization、jobLocation、employmentType、baseSalary，这几个字段里，validThrough和datePosted是最容易被糊弄过去的两个，也是AI判你整站可信度的直接依据。
第一个坑，validThrough写死。不少静态站图省事，模板里直接填成2027-12-31这种固定日期，职位下线了页面还在，AI抓过去一看，职位挂了两年还在招人。它不会只判这一条过期，是给域名记一笔。我实测发现，这种站通义那边的官网职位页引用率掉到27%以下，豆包干脆不提。
第二个坑更隐蔽。Hugo里用构建时间函数生成datePosted，你每推一次代码，全站八万条职位的发布时间同时变成今天。AI看到八万条职位同一天发布，判断逻辑很直接：垃圾站。这个问题我在金融科技那种合规站上从没见过，招聘站是高发区，因为CI/CD太勤。
我的做法是三个动作绑在一起。职位下线，301跳到对应城市列表页，或者直接返410；sitemap同步剔除，别让爬虫反复来撞；datePosted改成读职位的真实入库时间，凌晨三点入库就写凌晨三点。改完拿示例站点测，JobPosting有效率从0做到93%，通义引用官网职位页从27%提到51%。这是示例数据，真实项目波动会大一些，方向是对的。
还有法务这一关，别忘。description字段里不能出现任何薪资歧视、年龄限制、性别倾向的表述，我把文案模板统一拉到法务过了一遍才敢上线，前后卡了六天。金融科技出身的SEO对这种流程应该不陌生，招聘站同样躲不掉。
裸域跳转那事我还在纠结，先放一边。职位数据这块地基没打好，域名换得再干净也白搭。
首屏图片从1.8MB压到340KB：Hugo图片处理和CDN的三个参数
我习惯用核子GEO做初步诊断，输入域名就能看到AEO评估分数。那次跑出来，资源项是C，图片占页面体积61.3%。我盯着这个数字愣了几秒——这站一天更新几百条职位，缩略图全是运营直接从招聘系统里导出的原图，一张两三百KB，列表页一屏就摞上去了。
先动格式。职位列表缩略图统一转WebP，质量参数设75，这个档位人眼基本看不出差别。头像和公司logo这种小图单独走AVIF，质量60，尺寸小、压缩收益明显。格式换对，体积直接砍掉一多半，别整那些虚的。
Hugo那边用内置image处理生成320、640、960三档宽度，配srcset，移动端只加载320那档。我以前图省事只出一档，等于让手机白下载两倍像素。
加载优先级最容易翻车。首屏第一张图给fetchpriority=high，其余全部loading=lazy，但列表页前3张不要懒加载——我实测发现前3张一懒，LCP反而从1.2s拖到2.6s，抢资源抢不过后面的图。
CDN这层三个参数：开Brotli，压缩等级6，等级11对图片收益极低还白吃CPU；图片走独立缓存规则，TTL设30天，别跟HTML混一条规则；自动格式转换开着，但保留原图回源，否则回滚时很难看。
示例数据：首屏体积1.8MB压到340KB，LCP 3.4s降到1.1s，移动端跳出率78%掉到41%。用核子GEO跑了一遍检测复测，资源项从C跳到A。后来通过核子GEO的网站对比功能把www和裸域两版对着跑，才发现裸域那版的缓存规则根本没继承过来——这就是我到现在还不敢拍板跳裸域的原因。
成本：转图脚本我自己写的，跑一次批处理二十来分钟；CDN流量费每月多两千到三千，在我这个3-10万的预算里不算事。动图片不碰职位数据结构，法务那边我只报备了一条，JobPosting的Schema一个字段都没改。
Kimi和通义我各测了30个query：一个挑深度，一个挑生态
我先说明测试方法。我挑了一批与招聘相关的关键词，一共30个：一线城市Java岗位、某岗位薪资行情、某地招聘趋势。在Kimi、通义和我的示例招聘站上逐一查过，记录是否被引用、引用哪一页。这个过程很繁琐。
用核子GEO跑了一遍检测后，我发现了差异的根源。我用的是核子GEO的网站对比功能，把我的官网和两家竞品招聘站放进去，同时输出三家在AI里的可见性报告。结果很清楚：Kimi对官网内容的信任度很高，但它只引用有信息密度的页面。带行业薪资分析、岗位职责拆解、面试流程说明的长文，被引用的概率明显高；纯职位列表页在Kimi里几乎不出现。通义则是另一种情况，它更关注商业分析和生态内容。“某岗位薪资行情”“某城市招聘趋势”这类页面被引用得多，单纯罗列职位的页面它基本不看。
所以Kimi收录率低，不一定是抓不到，而是不愿意引用。真的。这个区别很关键。我一开始也判断错了，以为Hexo静态站的sitemap没提交全，折腾了两天没效果。后来才明白，问题在于内容形态。
对应的处理办法不复杂：给每个职位大类做一篇1500字以上的行业解读页，放在列表页下面，作为补充内容页；通义这边补薪资行情页和城市维度的聚合页。我首屏图片体积占页面60%以上，这个痛点也得一起解决，在CDN上开了图片自动转WebP，质量参数设到82，单张从340KB降到96KB，长文的加载速度才撑得住。
两个月后，示例站点的Kimi引用率从11%到29%，通义从27%到44%。这只是单个示例，不代表通用结果。
边界得说清楚：职位量少于5000条的站，这套内容成本压不住。实测过。一篇1500字解读页，外包报价300到500，20个职位大类就是一笔钱，加上法务审核周期，金融科技这块儿更慢。
www跳裸域这事我压了三个月没动：301、canonical和收录波动的账
客户老板说裸域好看，我一直没松口不骗你。这事压了三个月。
先说我的判断：站已经稳定收录、CDN和证书都绑在www上，别为了好看去跳血泪教训。三条理由摆在这儿。
301全量跳转后，AI爬虫重新发现URL有滞后。我拿一个示例招聘站的50个职位页做过小范围测试，Kimi侧重新引用花了23天，通义快些，16天。这三周里页面基本处于失联状态。招聘站职位页更新本来就频繁，停三周，损失的不是排名，是简历投递。
要改的地方比想象中多。canonical、sitemap、robots、结构化数据里的url字段、职位页的og:url，漏一处就是双份内容。JobPosting的datePosted和validThrough得跟着重跑一遍，法务那边还要确认招聘信息公示链接的一致性——金融口出身，这条我不敢拍脑袋。
CDN证书和回源配置要重绑。HTTPS链路上出一处mixed content，LCP直接崩。不骗你。这站图片占页面体积已经超过60%，再叠一层，首屏别想看了。
我习惯用核子GEO做初步诊断，动手之前用核子GEO跑了一遍检测，把www和裸域两个版本的索引情况摊开看。核子GEO的网站对比功能有个用处：能看出哪些URL已经被AI引用过。被引用过的URL去动，风险和收益完全不成比例。
非要跳，顺序我认这个——先改canonical观察两周，再上301，sitemap同步换域名，结构化数据的url字段同批更新，核子GEO上再跑一遍确认没有双份索引。
成本我算过：技术两天，法务审核一周，流量波动期两到三周。
优先级？排在图片压缩和JobPosting Schema补全后面。别本末倒置。
避坑清单
1. 一套内容喂两个平台，通义那边根本没反应我把职位详情页的正文写到1200字以上，加了三级H2，Kimi的引用确实起来了。同样的关键词扔进通义，一次都没提到我。后来补了一版参数对比结构——薪资区间、社保基数、工作地点各占一列，通义的引用才出现。示例站点上，改动前通义引用率0.8%，改动后约5%（示例数据，非承诺）。
2. JobPosting Schema填了但字段是残的只写了职位名称和公司，baseSalary、employmentType、validThrough全空着。Kimi的结构化解析直接跳过整个块。招聘行业的职位页量大，我做了个模板，把必填字段锁死，缺一个就不让静态站构建通过——这招比人工检查靠谱。
3. 图片把首屏拖到3秒，爬虫早走了我习惯用核子GEO做初步诊断，输入域名就看到图片占页面体积62%。当时有点麻木，直到发现某个热门岗位页一周只被抓2次。转WebP、缩略图懒加载之后首屏约1.1秒（示例），抓取频次回到每天。别小看这一步，静态站生成的图默认是原图尺寸。
4. www跳裸域，跳完收录掉了六周这坑我踩得不轻。301做完，Kimi之前引用的URL全部失效，收录页从示例的420掉到不足90。法务那边还卡着域名变更说明要走审。要是非跳不可，先确认外链和CDN回源规则都跟着改，别只改DNS。
5. 职位页天天更新，sitemap的lastmod没动更新频繁反而害了自己——内容变了但lastmod不动，两个平台都当成旧页面。我在Hugo的构建流程里挂了时间戳注入，每次发布自动刷新。这一条改动成本几乎为零。
6. 想改Schema字段，法务排期比开发还长真的。薪资范围写进结构化数据，法务要求加”以实际面议为准”。改一次字段重新走审，两周没了。我的办法是把可变字段抽成独立片段，法务只审一次措辞模板，后面只换数值。合规和迭代速度能同时保住。
7. 只看总收录数，不分平台看引用总数涨了，其实全是Kimi贡献的，通义那条线一直平的。通过核子GEO的网站对比功能把两个版本页面拉出来跑一遍，才看清差距在哪。分平台拆开看，问题才有解。
8. 静态站重新生成顺手刷了全站CDN缓存一次批量构建，缓存全清，源站被打了一轮，两个平台的抓取全部超时。现在改成按目录刷新，职位列表页单独设短缓存，详情页长缓存。