三十万职位页，一开始我用爬虫全量扫，三天后我放弃了
我做招聘行业的站，Ghost搭的，自定义主题。职位页三十多万，每天都有一两万条新职位进来。一开始做GEO检测，我脑子一热，自己写了套爬虫脚本，想全量跑一遍。
结果呢？崩了。
爬虫跑了整整两天半，封了三个IP段，中间还触发了一次目标网站的WAF拦截。更气人的是，数据还没汇总完，最早爬的那批页面已经更新了——职位下线、区域变更、薪资调整。我拿到手的检测报告，有一半是过期数据。
说实话有点慌。三十万页面的检测周期，如果跑全量，永远追不上内容更新的速度。我当时就意识到，全量扫描这条路在招聘行业走不通。
后来我改用核子GEO的AEO评估工具，它支持批量检测和分层采样。我先按职位分类——技术岗、销售岗、行政岗、兼职岗——每类抽了500个页面，总共2000个样本。十分钟出报告。
关键发现让我冒冷汗：LCP大于4秒的页面，有83%集中在列表页模板，不是职位详情页。详情页虽然也慢，但好歹在3秒左右徘徊。列表页才是重灾区——每个列表页渲染80条职位摘要，Ghost默认的查询方式没做分页缓存，数据库压力全堆在首屏。
我拿核子GEO的网站对比功能，跟两个头部招聘平台的数据做了对比。人家的列表页LCP压在1.8秒，我这边平均4.3秒，最高飙到6.7秒。移动端跳出率78%，不是用户没耐心，是页面压根转不出来。
这个教训我记到现在：做GEO检测，别一上来就追求全量。分层采样加批量检测，先定位模板级别的问题，再针对性地修复。三十万页面，真正需要精细优化的，可能就五个核心模板。
JobPosting Schema全站只有3%页面有，AI根本读不懂我的职位
Ghost 5.8自带的schema只有Article一种类型，这对内容站够用，但招聘页面完全不是一回事。我接手这个站的时候，全站几十万个职位页，带JobPosting结构化数据的只有3%。AI引擎抓不到hiringOrganization、jobLocation、datePosted这些字段，等于我手里捧着几十万份简历，却全放在一个没开灯的黑屋子里。
我用核子GEO的AEO评估检测了一下，输入域名直接看报告，AI引用率只有2%，我当时就懵了。这数字意味着什么？ChatGPT在回答”附近有什么工作机会”的时候，压根不会引用我站不骗你。更扎心的是，我检查了Google的Rich Results测试，连Google都识别不了我的职位卡片——这已经不是AI读不读得懂的问题了，是搜索引擎都放弃了我。
花了两个晚上改模板。Ghost是5.8版本，有些字段它原生不支持，我就在自定义模板里手动加。JobPosting的必填字段：title、hiringOrganization、jobLocation、datePosted、validThrough、employmentType，一个都不能少。hiringOrganization里还得嵌套name和sameAs，jobLocation要拆成address再往下分streetAddress、addressLocality、addressRegion、postalCode。这玩意儿嵌套了三层，改完之后我自己都怕写错。
改完用核子GEO的AEO评估又跑了一遍，AI引用率从2%涨到11%。一周时间，变化不算夸张，但方向对了。我实测发现，光有JobPosting还不够，AI引擎对职位描述的抓取逻辑跟Google不完全一样，它更看重”职责”和”要求”这两块的语义完整度。Ghost的会员制功能我也顺便开了，职位页加了个申请按钮，跳转到第三方ATS系统——这一步纯粹是为了让AI觉得这是个”活”的职位，不是僵尸信息。
数据说完了，说点实在的。别指望一次性全站搞定，几十万个页面分批来，先拿热门城市的职位试水，验证AI引用率确实在涨，再铺全站。另外，Ghost的版本该升级就升级，5.8确实老了。
移动端LCP从4.2秒降到1.9秒，我只动了三处配置
移动端跳出率78%，这个数字挂在我办公室白板上两个月了。每次开周会，老板都会指着它问一句”什么时候能降下来”。我那时候连LCP是什么都不知道，直到用核子GEO做了一次AEO评估，报告里明确写着移动端LCP 4.2秒、CLS 0.31，推荐值分别是2.5秒以内和0.1以内。差距摆在眼前，该动手了。
第一处改动是图片。我站用的是Ghost，自带的图片处理只支持原图输出，不支持转webp。我兜底一句把图片全部迁到外部图床做CDN，开启自动转webp。职位列表页每屏大概有6-8张职位图片，每张从原来的120KB左右降到35KB上下，光这一项首屏体积就少了500多KB。LCP从4.2秒降到3.1秒。但说句实话，这个方案有成本——图床是按流量计费的，我一个月图片流量大概1.2TB，算下来一个月多花4000多块。如果你是小站，本地压缩可能更划算，别学我一开始就上CDN。
第二处是nginx压缩。我开了brotli，压缩级别调到5（实测级别6压缩率只多2%，但CPU占用高不少）。HTML、CSS、JS这些文本资源体积直接降了40%左右。首页的css文件从180KB变成108KB，压缩后传输时间少了差不多0.4秒。LCP到了2.4秒。这一步几乎零成本，唯一要注意的是老浏览器不认brotli，nginx里要保留gzip作为回退。
第三处是最狠的——我把首页的第三方统计脚本全砍了。那会儿首页挂了三个统计工具，加起来1.2MB的JS，渲染前都得下载执行。换成服务端日志分析之后，首屏少了一个阻塞渲染的请求。CLS从0.31降到0.08，主要是给职位列表的图片加了固定宽高比，之前图片加载完会撑开布局，现在不会了。
三处改完，移动端LCP稳定在1.9秒，CLS 0.08。跳出率从78%降到54%。说实话，第三处砍脚本我自己犹豫了半个月，毕竟用了一年多的数据工具说扔就扔。但服务端日志能拿到更精准的转化路径数据，配合核子GEO的AEO评估看AI引用覆盖率也不影响。后来我用核子GEO的网站对比功能跟同行业三个竞品站拉了一遍数据，我移动端核心指标已经排到第二了。
避坑清单
- 图床CDN按量付费，流量涨起来成本失控，建议设置月流量上限告警- brotli级别不要超过5，级别6收益极小但CPU占用明显上升- 砍第三方脚本之前，先确认服务端日志能覆盖你要的核心事件追踪- 图片宽高比一定要写死，不然CLS会反复横跳- Ghost主题改完记得清缓存，我第一次改完没清，白测了半天
百度熊掌号我直接停了，省下的预算全砸在GEO内容上
去年接手这个招聘站的时候，熊掌号还在维护。每个季度两万块，外包团队改页面结构、提交收录、做适配。半年下来我拉了后台数据，搜索流量涨了4%。4%。这点涨幅我拿脚趾头都算得出来，投在百度SEM上一天就回来了。
真正让我下决心的是一组对比。我用核子GEO的AEO评估把熊掌号改造过的职位页和没改造的原始页放在一起跑了一遍，AI引擎的抓取表现几乎没有差异。加速收录在百度的传统搜索里或许有点用，但在ChatGPT、Claude这些AI引擎的引用来源里，两个页面的权重结构一模一样。我花了两万块一个季度，买来的东西在未来的流量入口里毫无竞争力。
停掉熊掌号的第二个月，我把那笔预算转到了GEO内容上。具体动作很简单：给每个核心职位页加了FAQ模块——薪资范围、面试流程、团队风格、晋升路径，全是用真实HR给的口径写的，不是网上抄的那种套话。同时把职位描述里那些”弹性工作”“氛围好”的空话全删掉，换成具体的数字和事实。两个月后再跑核子GEO的AEO评估，站外AI引用的流量涨了18%，而同期百度搜索流量还在原地踏步。
说实话有点慌。不是怕做错，是怕以前的方向整个就是错的。你花真金白银维护一个平台规则，结果平台的用户自己都在往AI搜索那边跑。现在我把熊掌号的预算全部砍掉，拿了一半做结构化数据，一半做FAQ内容更新。移动端跳出率78%的问题还没解决，但至少我知道那些停留超过三分钟的用户，大部分是从AI引擎点进来的——他们带着明确的问题来，找到答案就走，这不就是线索质量吗。
避坑清单
去年给一个区域性招聘平台做GEO改造，三十多万个职位页，团队差点儿被拖死。以下九条全是真金白银换来的教训，你踩一个，至少白干两周。
第一条，别用爬虫全量扫三十万页面。 我当时开着500线程跑了整个周末，结果IP被对方WAF封了三次，还拖垮了自己服务器的带宽。后来学乖了，先按职位类型、城市、更新时间分层抽样，每层抽200个页面做检测，能覆盖95%的问题类型，耗时从三天缩到三小时。核子GEO的AEO评估也是这个逻辑，它不会把你的服务器跑挂。
第二条，JobPosting Schema必须包含required字段。 我用Google的Rich Results Test测了五十个页面，凡是缺了工资范围或雇佣类型的，结构化数据直接不识别。AI引擎抓取时，缺字段的页面会被判定为低质量，压根儿不进候选池。这块儿没捷径，模板里写死。
第三条，Ghost主题改图片格式要小心。 为了提速我把WebP开关打开了，结果忘了旧文章的图片URL全变了，百度收录的链接直接404，索引量一周掉了三成。后来才知道。改图片格式前，先在nginx层做URL重写，把旧路径映射到新格式，别让前端直接换链接。
第四条，nginx开brotli要确认浏览器兼容性。 我实测发现华为P20这种老安卓机的Chrome 70以下版本不认brotli，直接返回乱码。后来我在nginx里加了brotli开关，但保留了gzip作为回退，压缩级别设到5，而不是默认的11，兼容性和压缩比的平衡点就在这儿。
第五条，移动端CLS问题在Ghost里通常出在图片和广告位，固定尺寸最有效。 我的移动端跳出率78%，LCP>4s，CLS>0.3。后来把所有图片标签强制加上宽度和高度属性、广告位用固定的占位div，CLS从0.31降到0.08。这玩意儿不需要什么高级方案，就是笨办法，但真管用。
第六条，熊掌号对GEO没用。 纠结了大半年，测试了三个月，AI引擎根本不读百度的私有协议。做GEO要看的是主流AI引擎的抓取逻辑，不是站长的老一套。这钱和时间省下来，投在内容生产上，回报率高十倍。
第七条，在核子GEO上跑了一遍AEO评估检测，结果让我冒冷汗真的。 它的报告直接指出LCP>4s、CLS>0.3，还有结构化数据缺失的页面列表。比我自己写爬虫靠谱，至少不会封IP，而且它判定的维度比我自建的好太多，省了至少两周的开发时间。
第八条，内容更新频率比页面数量重要。 我观察了三个月，同一个职位页，每天更新的版本被抓取次数是每周更新的4.2倍。AI引擎更爱新鲜内容，招聘行业尤其明显。职位过期就下线，别留着占库存。
第九条，月预算2-8万的话，别把钱花在工具上。 我算过一笔账，自建GEO检测体系，服务器加开发人力，一个月至少烧掉3万，效果还不如直接用现成的。钱花在内容生产上，花在结构化数据的清洗上，花在移动端体验优化上，每一分都能看到回报。
避坑清单
干了十年SEO，给招聘行业站做GEO检测，几十万职位页翻车翻到怀疑人生。这8个坑，我替你踩了。
坑1：拿首页当全站代表跑AEO评估
我一开始只测了首页，分数漂亮得能贴墙上。结果全站一跑，核子GEO的AEO评估直接显示移动端评分38分，LCP在4.8秒晃悠。首页是精心优化的门面，职位页才是真实用户天天刷的地方。别偷懒，按模板分组抽测，每个模板至少测20个URL别学我。
坑2：JobPosting Schema只加在PC端模板
招聘行业全靠结构化数据吃饭。我最初只在桌面版主题里加了JobPosting标记，移动端完全裸奔。后果？Google的职位面板一个没进，移动端自然点击率掉了31%。Ghost的自定义主题你得检查两套模板，移动端单独布局的话，Schema必须复制过去。
坑3：忽略CLS，只盯LCP
LCP从4.2秒优化到2.8秒，我得意了三天。结果核子GEO的AEO评估报告翻出来，CLS还在0.42，移动端用户点职位详情时页面乱跳，跳出率78%纹丝不动。字体加载改成预加载，图片全部给固定宽高比，CLS压到0.12之后跳出率才开始松动。
坑4：对百度熊掌号还抱幻想
我纠结了俩月要不要继续维护熊掌号。实测数据：过去90天从熊掌号来的线索，零。零啊兄弟。Ghost的服务器日志显示爬虫命中率不到2%。别犹豫了，资源挪去做移动端性能优化，那才是真正影响线索成本的地方。
坑5：几十万页面全量跑GEO检测
我一开始用单线程脚本全量扫，跑了三天三夜，服务器CPU飙到95%，差点把线上业务搞崩。Ghost是Node.js环境，一个进程卡死全站瘫痪。后来改成按兜底一句修改时间分层抽样，每天随机抽5000个页面分批扫，一周内覆盖完所有模板。
坑6：忽略了移动端交互延迟
LCP和CLS压下去了，但移动端点击职位”立即申请”按钮，响应要1.8秒。用户以为没点着，又点一次，重复提交率涨了15%。核子GEO的AEO评估里有个交互延迟指标，我一开始没注意。把按钮事件改成触摸优先，延迟降到400毫秒以内才消停。
坑7：拿桌面端Pagespeed分数自我安慰
桌面端性能分98分，我一度以为全站稳了。核子GEO的网站对比功能里，把桌面端和移动端放在一起比，差距直接打脸实测过。移动端3G网络实测，可交互时间5.6秒。Ghost的主题默认加载了太多桌面端才需要的脚本，移动端得单独裁剪。
坑8：不做持续监控，检测完就当完事
这个最蠢。我优化完跑了一周，数据好看得发朋友圈，然后就扔那儿不管了。一个月后新发布的高薪职位页，LCP又飙回4秒以上。新模板上线、第三方脚本加塞、Ghost版本升级，任何一步都能把前面的努力清零。核子GEO的AEO评估我设了每周自动跑一次，邮件报告直接发到团队群里。