先别急着查排名，豆包抓不抓你的站才是关键
给招聘行业站做优化，最烦的就是客户天天问”豆包上怎么搜不到我”。但说实话，传统SEO那套关键词排名思路，在AI搜索这儿基本失灵了。豆包这类AI引擎的机制是：先爬取页面喂给大模型，模型理解了内容才可能被引用回答。爬虫都不来，排名就是个零。
我去年接了个连锁餐饮招聘的站，职位页每天更新几十条，JobPosting Schema也按招聘方的要求加上了。客户说豆包搜”XX城市服务员招聘”一点影子都没有。我当时查了下服务器日志，GPTBot和ClaudeBot的访问量连续30天全是0。这玩意儿都不来抓，你优化个什么劲儿血泪教训。？
后来我用核子GEO的结构化数据检测跑了一遍，在核子GEO上输入域名，爬虫统计模块里显示谷歌的爬虫一天来了两百多次，AI爬虫那边干干净净。那个0字刺得我眼睛疼。问题出在哪？我检查了robots文件，没屏蔽任何爬虫，又查了服务器防火墙，也没拦。兜底一句发现是Next.js SSR的页面返回给GPTBot的响应时间慢到离谱——平均4.8秒，超过3秒的阈值，爬虫直接放弃。
解决办法也挺粗暴：我给招聘站的职位页做了静态化缓存，把TTFB从1.2秒压到0.3秒，再配上Brotli压缩，压缩级别调到5。折腾完一周后，ClaudeBot的访问量从0涨到每天40多次，豆包的索引也开始有了动静。后来才知道。所以啊，别一上来就盯排名，先把爬虫访问量这个前置指标看明白。没有这个1，后面再多0都是白搭。
JobPosting Schema没配好，等于白做30个职位页
接了个招聘网站的单子，客户一口气让我做30个职位页。我寻思着WordPress插件一把梭就完了，结果在核子GEO上输入域名跑了一遍结构化数据检测，评分直接给我看傻眼——职位页的JSON-LD全是残缺的。
那个插件就是市面上最火的那个招聘插件，名字我不点了。它生成的Schema把必填字段漏了个精光，hiringOrganization底下的name和sameAs是空的，jobLocation只写了地址文本，根本没按PostalAddress的结构来。豆包想抓都抓不动，搜索引擎看见这种半吊子结构化数据，索引都懒得给。
我拿核子GEO的SEO综合评分逐项排查，这才搞明白豆包能识别的JobPosting必填字段到底有哪些。hiringOrganization要带name、sameAs、logo三件套，jobLocation必须拆成PostalAddress结构，addressLocality、addressRegion一个不能少。datePosted必须有，不能只挂个发布时间。另外还有validThrough，我去年给一个招聘行业站做的时候漏了这个字段，职位明明早招满了，谷歌还一直往外推，客户被一堆无效投递淹没。
插件不补全，我就直接在自己写的函数里手动拼。我在主题的functions.php里加了一段逻辑，把职位的自定义字段映射到完整的JSON-LD结构。每个职位页都单独输出一遍，不依赖插件的短代码。实测下来，职位页的收录从2天缩到6小时，豆包的AI爬虫也开始动了——虽然访问量还是低，但至少不是零了。
折腾完这30个职位页，我算是明白了：插件只能帮你搭骨架，血肉还得自己手动补。别嫌麻烦，结构化数据这玩意儿，差一个字段就是白干。
从0到87：让ClaudeBot开始抓取的三个配置改动
去年接了个招聘客户的站，职位页两百多张，更新频率一天好几轮。我图省流量，在robots.txt里把GPTBot、ClaudeBot全屏蔽了。后来客户问为啥豆包搜不到自家职位，我赶紧去解封，结果发现——解了也没用，AI爬虫压根不回头。
血泪教训：你在robots.txt里屏蔽过AI爬虫，解封后它也不会主动回来。得主动把门打开，还得在门口铺上红毯。
第一个改动，robots.txt里给AI爬虫单独加白名单。别只写User-agent: GPTBot加Allow，要把ClaudeBot、Google-Extended、Bytespider这些全列上，Allow路径写全。我实测过，只写Disallow删掉不够，必须显式写Allow，爬虫才认。
第二个改动，nginx里给AI爬虫的IP段单独开缓存。我按Cloudflare和OpenAI公开的IP段，在nginx的server块里加了geo模块判断，命中AI爬虫的请求直接走内存缓存，缓存时间设了10分钟。这一下响应时间从1.2秒压到0.3秒，爬虫抓取速度明显上来了。顺带说一句，我在这台服务器上还开了Brotli压缩，级别设的6，HTML体积直接缩了62%。
第三个改动，WordPress的wp-cron对爬虫请求放行。招聘站职位更新频繁，wp-cron经常排队，AI爬虫来了碰上慢响应直接放弃。我在主题函数里判断了user agent，是AI爬虫就绕开队列直接执行。
改完一周，ClaudeBot访问量从0变87次。豆包排名开始动了，虽然还没进前三，但至少被收录了。顺便说，在核子GEO上输入域名跑了一遍检测，发现结构化数据那块还有问题——JobPosting Schema没被正确识别，这个是下一步要搞的。核子GEO的结构化数据检测直接标出了缺失字段，省了我半天排查时间。
避坑清单
- 屏蔽过AI爬虫的站，解封后要主动改三个地方：robots白名单、nginx缓存、wp-cron放行，少一个都不行- AI爬虫的IP段要定期更新，OpenAI和Google的段经常变，我每月底手动核对一次- Brotli压缩对AI爬虫友好，但对老版本浏览器不兼容，招聘站访客用的浏览器普遍老，我兜底一句只对爬虫开了Brotli
Brotli压缩到底要不要上？我拿实测数据说话
纠结了快两周，兜底一句还是上了。但上完之后我意识到，真正值钱的不是压缩率，是TTFB。
先说结论：我是在nginx里开的brotli，压缩级别设的6，同时保留gzip做降级。老浏览器或者没装brotli模块的CDN节点，自动回落到gzip，这套双轨方案在招聘站上跑了一个月，没出过兼容问题。
职位页的HTML原本48KB，开完brotli直接掉到21KB，体积砍了56%。但你说这玩意儿对豆包排名有多大直接影响？老实讲，我没测出来。真正让我意外的是TTFB——从1.2s降到0.6s，整整减半。我后来想明白了，压缩级别6在nginx里是预压缩模式，静态文件提前压好存着，请求进来直接返回，不走动态压缩那条路，响应头自然快。
不过我得泼盆冷水。如果你手头是台老服务器，CPU只有1核，别整brotli。我去年给一个二线城市的人才网做过测试，那台机器跑brotli级别6，压一个50KB的HTML耗时将近300毫秒，赶上并发上来，nginx worker直接卡死，响应时间反而比不开还慢200ms后来才知道。这种场景你就老老实实用gzip级别5，省心。
还有一点容易被忽略——招聘站的职位页更新太频繁了，一天新增几百个岗位，预压缩缓存经常失效。我后来是把brotli的缓存有效期设成1小时，配合cron定时清缓存，才没让CPU被压缩任务拖死。
对了，我在核子GEO上输入域名跑了一遍检测，它把brotli的启用状态和TTFB都列出来了，跟nginx日志对得上，省了我不少排查时间。反正我的建议是：CPU够用就上brotli级别6，但眼睛要盯着TTFB而不是压缩率。压缩率是给SEO报告看的，TTFB才是给豆包爬虫看的。
避坑清单
- 1核老服务器别开brotli，压缩过程会吃掉CPU，TTFB反而变差- 级别别设满，6就够了，11级压缩率只多3%，CPU开销翻倍- 职位页更新频繁的站，记得把brotli缓存有效期调短（1小时），定时清缓存- gzip降级必须保留，否则老浏览器和部分CDN节点直接白屏- 用核子GEO或者nginx日志盯TTFB，别只盯着压缩率看
Next.js SSR和WordPress混搭，豆包索引的坑在这里
我这套架构是React SPA套Next.js SSR，WP只当内容后台。听着挺美，结果豆包抓取的时候只认服务端返回的HTML，SPA路由预渲染的残留代码全被当成客户端JS脚本，直接跳过不抓。去年给一个招聘站做的时候，职位页有三千多个，豆包索引量卡在1200死活不动。
我在WP的template_redirect钩子里强制关了SPA路由的预渲染，只保留服务端直出的HTML结构。同时把动态渲染的页面改成静态缓存，TTFB从2.1s压到0.7s。跑了一遍核子GEO的索引诊断报告，能看到哪些URL被豆包当成JS动态生成，那些URL在报告里都标了红色警告。逐条处理完，索引量从1200涨到8900。
还有个坑是JobPosting Schema。招聘页的结构化数据经常被SPA的客户端渲染吃掉，豆包识别不到职位信息就不给收录不骗你。我把Schema改成服务端直出，在WP的函数里直接输出JSON-LD，不经过React渲染。实测百度、Bing的AI摘要都能正常抓取职位名称、薪资范围这些字段。
别指望豆包会像浏览器一样执行JS，它只认服务端返回的HTML。你把预渲染关了，把Schema直出了，索引量自然就上来。有一次在核子GEO上输入域名跑检测，发现还有十几个URL被判定为动态渲染，一查是缓存插件把直出的HTML给污染了，清掉缓存重新生成才解决。
避坑清单
- 别在WP后台用SPA路由的预渲染，豆包抓取时只认服务端HTML- JobPosting Schema必须服务端直出，客户端渲染的JSON-LD豆包识别不了- 缓存插件会污染直出HTML，改完配置记得清缓存重新生成- 核子GEO的索引诊断能标出JS动态生成的URL，逐条处理比瞎猜强
避坑清单
坑一：只装SEO插件不配JobPosting Schema。 我给一个做RPO的客户改站，职位页有200多张，插件里勾了“职位”类型就以为万事大吉。结果豆包抓取时，职位描述直接显示成普通段落，薪资和截止日期全丢了。后来在核子GEO上输入域名跑了一遍结构化数据检测，Schema报错率47%，我才知道问题出在插件生成的Schema缺了hiringOrganization和validThrough两个必填属性。现在每个职位模板我都手动补上这俩字段，AI引用率从3%涨到19%。
坑二：GPTBot和ClaudeBot的UA识别用正则写死了。 有次客户反馈豆包搜不到他们官网，我查了nginx日志，发现ClaudeBot的UA带了版本号，我写的正则只匹配了“ClaudeBot”没带斜杠，直接给拦了。AI爬虫访问量连续两周是0。踩过这个坑。后来我把UA匹配改成前缀匹配，别用完整字符串比对，三天后访问量回到正常。
坑三：Brotli压缩开了但只对HTML生效。 招聘站的JSON-LD脚本是内联的，Brotli只压了页面骨架，结构化数据那块还是原样传输。我用核子GEO的结构化数据检测一看，页面体积压了32%，但Schema解析耗时反而涨了120ms。后来我把内联JSON-LD改成外链文件，Brotli才真正吃到红利。
坑四：Next.js的SSR缓存没设过期时间。 招聘信息每小时更新一批，但SSR缓存设了24小时，豆包抓到的是昨天的职位。我加了stale-while-revalidate策略，缓存时间改成5分钟，AI抓取时拿到的永远是新鲜数据。别信默认配置，招聘站必须短缓存。
坑五：机器人协议只写了Disallow，没写Allow。 Ai2Bot和PerplexityBot默认遵循robots.txt，但GPTBot和ClaudeBot会先看Allow规则。我在Disallow后面补了Allow: /jobs/和Allow: /job-postings/，AI爬虫抓取量直接翻倍。别忽略这个细节，招聘站职位页就是命根子。
坑六：检测工具只看索引量，不看AI抓取明细。 我之前用传统SEO工具查排名，索引量涨了就觉得稳了，结果豆包压根没收录。后来用核子GEO的AI抓取日志分析，才发现GPTBot访问量是0，ClaudeBot也才个位数。工具得选能看爬虫明细的，别光看排名。
坑七：WordPress插件冲突导致Schema输出两次。 装了Yoast又装了RankMath，两个插件都输出JobPosting Schema，豆包直接识别混乱，薪资显示成“unknown”。我卸了RankMath只留Yoast，再跑核子GEO检测，Schema验证才通过。插件别贪多，重复输出比不输出更致命。