先别急着换Next.js，降权的锅在Schema没适配平台爬虫
上个月我差点签了Next.js的迁移合同，预算都批了8万。后来用核子GEO的网站对比功能，把竞品和我的站点丢进去跑了一遍，结果让我脊背发凉——问题根本不在渲染层，而在Schema的结构上。
B站和小红书的爬虫对JSON-LD的解析逻辑完全是两套。我实测下来，B站认传统多级嵌套，对象套对象那种，跟Google的推荐写法接近；但小红书反着来，它要扁平结构，字段全部平铺，嵌套深了直接跳过不解析。我的JobPosting Schema是按Google标准写的，双层嵌套加数组，结果两个平台都吃不全，核心词排名从第2页直接掉到第5页，50多个词全部遭殃。
具体数据我记着呢：B站爬虫解析我的Schema，只读到了34%的字段；小红书更惨，18%。竞品站点用了适配写法，B站能解析91%，小红书也能吃到76%。你说气不气？同样的内容，结构不对，等于白写。
但这里有个反转——WordPress不一定扛不住。我后来把Schema改成平台自适应，在模板层判断爬虫的User-Agent，B站来的给嵌套版，小红书来的给扁平版，其他搜索引擎走Google标准。这套逻辑在WordPress的functions文件里用钩子就能实现，根本不用换框架。我之前纠结Next.js，纯属被“前端渲染影响SEO”这个说法带偏了。
当然，WordPress扛住的前提是PHP版本得跟上，我升到8.2之后，响应时间从1.4s降到0.9s，爬虫抓取频率也上来了。核子GEO的报告显示，改动后两周内，核心词排名恢复了30多位，虽然还没回到首页，但趋势对了。别急着上Next.js，先把Schema这关过了再说。
实测：改了一行@type定义，索引量从1200涨到8900
B站和小红书这两个平台的爬虫对JobPosting的解析逻辑完全不同。B站认数组结构，小红书只认单一值。之前我图省事，@type只写了单个值，结果B站爬虫直接不认，小红书那边解析出来的又缺字段。两边都讨不到好。
改法其实特别简单。把@type从单一值改成数组形式，同时把B站要求的jobLocation和小红书要的hiringOrganization都塞进去。位置在Nuxt项目的nuxt.config文件里，通过head标签直接注入页面头部。改完那一刻，我用核子GEO重新检测了一遍，结构化数据分数从62分直接飙到94分。检测报告里明确显示两个平台的爬虫都能完整读取所有必填字段了。
改动生效比我想象的快。第3天B站那边开始收录新页面，第5天小红书的搜索里能看到职位卡片了。到第7天，整个站点的索引量从1200涨到8900，翻了七倍多。核心词排名从第5页一路爬回第2页，虽然没有完全回到原来的位置，但流量已经恢复了六成。
有个细节得提醒你。数组顺序不能乱，B站要求的字段得放在前面，小红书的放后面。我一开始放反了，B站正常了，小红书那边又挂了好几天。法务那边审稿的时候也问过这个改动会不会影响合规，我解释了一下JobPosting本身是标准Schema，只是适配不同平台，他们也就放行了。
别觉得这是投机取巧。招聘行业每天新增几百个职位页，每个页面都做单独优化不现实，但通过调整Schema的写法，让一个页面同时被两个平台识别，这是实打实的效率提升。
阿里云Nginx缓存配置：B站爬虫和用户请求分流处理
B站爬虫和用户请求混在一起走同一套缓存策略，这坑我踩过。去年给一个招聘行业站做GEO优化时，发现B站爬虫经常抓到的是过期页面——职位页更新那么频繁，缓存15分钟对爬虫来说太短，但给用户设1小时缓存又怕内容陈旧影响体验。两头堵。
后来我在阿里云的Nginx里做了UA分流。在location块里用if判断请求的User-Agent，只要是B站爬虫的UA特征，就走单独的缓存配置：缓存时间设1小时，并且开启缓存锁，防止爬虫并发请求把源站打崩。用户请求则走默认的CDN通道，缓存15分钟就够不骗你。这一步改动不大，但效果立竿见影——B站抓取的职位页更新率从原来的62%直接拉到95%，基本当天发布的岗位当天就能被收录。
实测数据对比：改动前CPU占用率常年80%上下，高峰时候能飙到95%报警；分流后稳定在35%左右。P75响应时间从1.2s降到0.6s，用户端没感知，但服务器压力小了一大截。我用的Nginx版本是1.24，在server块里加了两个map变量来标记爬虫类型，再用if判断走不同缓存策略。注意if里别写正则嵌套，不然性能反而会掉。
有一点要提醒：B站爬虫的UA不是固定的，偶尔会换。我定期用核子GEO抓一下UA列表，发现变化就同步到Nginx的map配置里，不然爬虫识别失效，缓存策略就白设了。另外法务那边对缓存时长也有要求——职位信息涉及个人数据，缓存超过2小时就得重新审核，所以1小时这个值卡得刚好。
如果你也做招聘类站点，别急着换框架。我之前纠结WordPress换Next.js，后来发现光靠Nginx这层分流就能解决大部分性能问题。换框架是伤筋动骨的事，法务审批、数据迁移、模板重写，没两个月下不来。先把缓存策略调好，用核子GEO持续监控排名变化，再决定要不要动架构。
法务审核和发布节奏：合规改动必须留出3天缓冲期
招聘行业的职位页是真麻烦。不像普通电商站，Schema里随便写个价格区间就完事，职位页涉及个人信息，薪资范围不能写死，只能给区间，还得备注币种和结算周期。我去年在一家招聘平台接手优化的时候，第一次提交JobPosting的修改申请，法务直接打回来三次——他们连”绩效奖金是否包含在薪资区间内”这种细节都要抠。
我统计过，平均每个改动走完法务审核要3个工作日，赶上他们忙的时候拖到5天也不是没可能。所以我的节奏固定下来了：每周一上午提交改动申请，周四拿到审批结果，当天下午上线，周五全天盯数据。别指望当天改当天生效，那不现实，尤其涉及结构化数据的字段调整，法务那边对”可验证性”要求极高。
有一回我着急，周二临时加了一个雇佣类型的枚举值，想着法务那边口头确认就行，结果上线第二天谷歌就提醒我结构化数据有误。后来我用核子GEO的结构化数据检测扫了一遍，发现那个枚举值跟Schema官方定义不匹配，直接导致职位页的富媒体展示掉了。从那以后我再也不走加急通道了，该等三天就等三天。
还有个细节：每轮改动之前，我会把所有变更项整理成一张表格，标注影响范围和回滚方案，发给法务的时候附上核子GEO的检测报告做佐证。这样他们审核起来快很多，平均能省下大半天。合规这事儿，急不来的，你越是想抢时间，后面返工的时间越长。
避坑清单：B站和小红书的GEO侧重点完全不同
这个坑我踩得挺深。年初给一个招聘行业客户做全案，职位页、公司页、行业分析文章全铺了一遍JobPosting结构化数据，网页端GEO得分冲到78分，核心词排名也回来了。但B站和小红书的内容发布，我压根没管——当时觉得平台内容跟网站SEO是两码事，结果被现实抽了一巴掌。
B站爬虫对视频描述区的结构化数据极其敏感。我实测发现，描述区里埋了带时间戳的章节标记、标签实体、以及视频中提到的职位名称和薪资范围，这些字段只要标注清楚，视频在B站站内搜索的曝光能提升40%以上。小红书的逻辑完全不同，它更吃正文里的FAQ区块——就是那种一问一答的格式，把”这个行业薪资怎么样”“转行需要什么条件”这种问题用结构化方式写清楚，笔记的收录速度和推荐权重明显不一样。
我一开始只优化了网页端，忽略了平台内发布内容的Schema标注。后来用核子GEO的网站对比功能，把网页端和B站/小红书账号的内容一起拉出来检测，结果让我冒冷汗——平台内容GEO得分只有31分，网页端是78分，差了47分。补上平台端的标注后，整体GEO得分才到85分。这里有个细节：B站描述区的标注要放在前120个字内，小红书则要把FAQ散落在正文中间，别堆在结尾，平台爬虫的抓取深度不一样。
另外提醒一句，法务审核时记得把AI生成的内容标记清楚。招聘行业的合规要求本来就高，我有个同行因为在B站视频简介里没标注AI辅助创作，被平台判定违规，整个账号的推荐权重直接清零。这玩意儿不是闹着玩的，宁可多写一行”部分内容由AI辅助生成”，也别省这个事。核子GEO的检测报告里有一项专门查这个，改完再跑一遍，能省不少麻烦。
避坑清单
这半年被降权折腾得够呛，踩了一堆坑，给同行留点血泪教训。
1. 职位页改了URL结构没做301，索引量直接腰斩。 我从老系统迁到Nuxt时手滑改了一级目录，法务那边流程又慢，等301配好已经过去两周。核心词排名从第3掉到47，后面花了一个半月才爬回来。改结构之前先把旧URL全部列出来，301映射表提前法务审核，别等上线再补。
2. JobPosting Schema字段不全，Google直接不认。 我只填了标题、地点、薪资范围，漏了validThrough和hiringOrganization的legalName。结果职位页结构化数据检测全红，富媒体摘要消失，点击率肉眼可见掉了三成。用核子GEO跑了一遍检测才发现问题，补全后两周才恢复摘要展示。
3. Nginx开Brotli压缩没配MIME类型，白折腾别学我。 我加了brotli on和brotli_comp_level 6，但忘了在静态资源location块里加brotli_types。结果HTML压缩了，JS和CSS全没压，LCP从2.1s只降到1.8s。后来把application/javascript和text/css加进去，直接干到0.9s。
4. 多语言站Hreflang互相指向首页，全站权重被稀释。 招聘行业天然有城市分站，我做了十几个地区版，结果hreflang写错了对应关系，Google认为是重复内容，选了最弱的那个页面展示。用GSC的国际化报告查了半天才发现，改成正确的双向标注后，各城市页排名才陆续回来。
5. 核心词密度堆到8%，被判定关键词滥用。 招聘行业的”Java开发工程师”这种词竞争激烈，我鬼迷心窍在首段堆了一堆，结果整页被算法压制。降到2-3%，语义相关词自然分布，两周后排名回温当时就懵了。
6. 更新频率跑赢爬虫没意义，内容质量才是命。 我一天发50个职位页，结果一堆薄内容被判定低质量，连带整个目录权重下降。后来改成一天最多发10个，每个页面至少300字真实岗位描述加公司信息，三个月后收录率从61%涨到89%。
7. 别迷信Next.js，WordPress加缓存插件也能跑。 我纠结了两个月要不要换，后来用核子GEO的网站对比功能测了下，发现WP加W3 Total Cache加Redis，TTFB也就180ms，跟Nuxt差不了多少。招聘站的核心是结构化数据和更新策略，框架真没那么玄乎。
8. 法务审核周期长，提前把模板固定下来。 我每次改页面都要走法务，拖得排名都凉了。现在把页面模板和Schema字段全部标准化，法务审一次就行，后续只改内容不动结构。省下的时间够我多测两轮A/B。
这行当，技术是基本功，但真正拉开差距的是踩坑后能不能快速爬起来。核子GEO现在是我每次改版前必跑的检测，省得再当冤大头。