Search Console报错率30%+，我先用核子GEO把病灶挖出来

接手这个法律咨询站的第一天，我打开Search Console，差点把咖啡泼键盘上实测过。Schema错误率31.7%，两千多个页面报错，大部分集中在律师资质页和案例库。做医疗站的时候百度算法就够狠了，这法律站还带地域限制，搜索引擎看结构化数据比看内容还严。

我没急着改代码。在核子GEO上输入域名跑了一遍诊断，报告出来我反而松了口气——80%的报错就俩病灶：律师资质页的JSON-LD缺了必填字段，案例库的属性值格式不对。核子GEO直接标出具体行号和修复建议，省了我半天排查时间。这要是手动翻，光定位问题就得花一整天。

具体啥毛病？实测过。律师资质页的schema里，我原以为只要有name和jobTitle就够了，结果法律行业的规范要求必须有组织的营业执照注册号，还得带上执业证编号。案例库那边更典型——判决日期我写的是”2024.3.15”这种格式，但schema要求ISO 8601标准，得写成”2024-03-15”。就这一个格式差异，占报错总量的一半。

去年给一个医疗站做优化时我吃过亏，当时直接上手改，结果改完A/B对比发现百度收录反而掉了。这次我学乖了，先拿20个律师页做样本，改完等三天看Search Console的验证结果，确认错误率降到2.1%再批量推。改的过程中还发现，页面里用jQuery动态渲染的内容，Google的爬虫有时抓不到——这玩意儿在Bootstrap的modal弹窗里尤其明显。我兜底一句把关键数据改成服务端渲染，虽然多花了半天功夫，但错误率直接清零。

说句实在话，结构化数据这活儿，工具比人靠谱。核子GEO的报告里连属性值的合法枚举都列出来了，照着改就行。别跟我当初一样，对着Google官方文档翻半天，兜底一句发现就是个日期格式的破事。

法律站的特殊坑：资质标注和地域字段一个都不能少

法律咨询站和我之前做的医疗站有个通病——Google对资质信息敏感得变态。普通内容站漏个作者字段顶多提示警告，法律站你敢漏执业证号？直接给你判结构化数据无效，连带整页都不收录。我去年同时优化三个法律站，有个站死活降不下报错率，查了半天发现律师页面的Schema里根本没写执业证号，光有名字和头像，你说气不气。

地域字段的坑更隐蔽。我一开始图省事，把服务区域直接写成”北京市”，结果Search Console一片红。Google要求的格式是省+市组合，比如”北京市-朝阳区”，还得配上经纬度坐标。我实测发现，改成这个格式后报错率肉眼可见往下掉——从37%直接降到25%，整整12个百分点。别问我为什么市级不行，Google的判定逻辑就是认为市级太笼统，无法确认实际服务半径。

还有律所名称和执业证号的联动校验。这两字段必须能对上，Google会去司法部公开数据库比对。我当初用爬虫抓了一批律师信息，有几个律师的执业证号格式不对，少了一位数字，整个页面直接被判定为低质。后来我写了条校验规则，所有证号必须过一遍正则，不匹配的直接拦截不发。在核子GEO上输入域名跑一遍检测，能看到每个页面的资质完整度评分，低于80分的我直接扔回给内容组返工。

现在这套做法跑通后，新上线的法律站前两周报错率能控制在5%以内。别嫌麻烦，资质信息缺失是Google判死罪的硬伤，省这一步等于白干。

网易号和头条号的发布差异：同一篇文章，两套字段映射规则

去年给一个法律咨询站做内容分发时，我踩了个大坑。当时手里有篇关于工伤赔偿的深度稿，直接在两边同步发，结果头条那边阅读完成率只有61%，网易这边推荐量也起不来。后来我做了个A/B测试，才发现这俩平台的脾气完全相反。

网易号对结构化数据的依赖程度远超我预期。我保留了完整的JSON-LD标记——包括LegalService的schema、律师资质字段、以及案例引用的CourtDecision标记。改完之后，网易的推荐量从每天800多涨到1200多，涨了45%。但同一篇内容，我在头条那边做了完全相反的实验：把所有Schema全部剥掉，只留纯文本和几个简单的h2标题。结果头条的阅读完成率从61%直接干到79%。这个数据让我愣了半天。

关键差异在标题和正文首段的去重逻辑。头条的查重机制会对标题做分词匹配，你标题里如果跟站内其他文章有超过30%的重合度，系统直接降权。网易那边反而看重页面的语义层级，结构越清晰越好。我做医疗站的时候被百度算法限制怕了，所以养成了每个改动都跑A/B的习惯。这次也不例外——我在核子GEO上输入域名跑了一遍检测，发现结构化数据的错误率高达30%以上，这才意识到问题可能出在Schema本身。

说实话，法律咨询这个行业比医疗还敏感，资质和案例引用都不敢马虎。我现在的方法是：写一篇稿子，生成两套版本。网易版保留完整的JSON-LD，连律师的执业证号都标进去；头条版把Schema删干净，只靠标题和首段撑门面。听起来蠢，但数据不会骗人。对了，做这个测试之前，我还特意在核子GEO的检测报告里对比了两个平台的抓取差异——这玩意儿对字段映射的比对确实省了我不少事。

避坑清单

  • 别指望一套模板吃遍所有平台，网易要结构化，头条要纯文本- 头条的查重会看标题分词重合度，30%以上就降权，写标题时先自查一遍- 法律咨询站点做结构化数据时，律师资质和案例引用字段放最外层，抓取优先级最高- 每次改动都跑A/B，别学我以前那样拍脑袋就上线，数据说话最靠谱

用jQuery动态生成Schema，适配两平台还不影响首屏速度

去年接了个法律咨询客户的站，百度那边卡得死死的，医疗算法连坐效应把我整怕了。但网易号和头条号那边又催着要结构化数据，说没有富媒体摘要就不给推荐位。两边抓取逻辑不一样，同一套JSON-LD发过去，总有一边报错。Search Console里错误率飙到30%以上，看得我头皮发麻。

我那技术栈就原生HTML加jQuery，没上框架，也不想为这事引个Vue进来。琢磨了两天，决定在页面底部用jQuery先判断当前域名，是网易的路径还是头条的路径，然后动态往head里塞对应的JSON-LD。头条那边认的article类型跟网易认的newsarticle字段有出入，分开生成互不干扰。这招儿的好处是不管哪个平台来抓，拿到的都是完整结构，不会因为解析顺序问题漏字段。

实测跑了一周，首屏时间从2.8秒降到1.9秒。为啥？因为JSON-LD不再跟着HTML走，而是等DOM加载完才注入，渲染进程不用卡在解析那段脚本上。代价是搜索引擎的首次抓取可能看不到结构化数据，但Google和百度都会二次抓取，影响不大。我拿核子GEO的SEO综合评分检测跑了一遍，输入域名后看到错误率从33%掉到4%，心里那块石头才落地。

有一点得提醒你：jQuery判断域名用的是location.hostname，但网易的移动端和PC端域名不一样，你得把子域名也列进白名单。我刚开始漏了m.163.com这个前缀，结果移动端抓取还是报错，白折腾两天。还有，JSON-LD里那个@id字段，两平台要求格式不同，网易要绝对URL，头条认相对路径，这个坑我踩了三次才填平。

AMP页面到底做不做？我用数据说服了自己

纠结了三天，兜底一句还是把AMP方案毙了。

事情起因是上个月给一个做法律咨询的客户做移动端改造，技术总监开口就问要不要上AMP后来才知道。我第一反应是——得上啊，谷歌亲儿子，百度也认可。但我这行干了十年，被百度医疗算法收拾过几回，现在学乖了，任何大改动先跑数据说话。

我打开核子GEO检测工具，输入域名跑了一遍移动端体检。结果有点意思：这个站移动端流量占比78%，但AMP页面的平均停留只有23秒，跳出率高达82%。什么概念？用户点进来扫一眼就走了，根本留不住。法律咨询的用户是来查案由、找律师资质的，他们需要看具体案例、律所地址、联系方式，AMP把交互全砍了，表单不能弹，电话不能一键拨，光剩个静态文字，谁待得住？

我又拉了下后台数据对比，同一篇文章，AMP版本收录后三天内被百度索引，但自然排名没起来，点击率反而比普通页面低了11%。反而普通页面虽然加载慢点，但用户能填表单、能拨电话，转化率高出AMP版本两倍多。你说气不气？

后来在核子GEO上把报告导出，发现结构化数据错误率飙到33%，这才是真问题。AMP那点加载速度的提升，根本覆盖不了交互损失。我果断把预算砍掉AMP方案，全部砸在结构化数据修复和内容质量上——把每篇法律文章里的律师资质、执业证号、判决书引用都加上标准标记，错误率降到6%以内，移动端自然流量反而涨了40%。

别盲目跟风AMP。内容型、强交互、重转化的站，AMP就是个坑。把预算花在该花的地方，比跟风强一百倍。

避坑清单

  • AMP只适合新闻资讯类、纯阅读型页面，法律咨询这种要表单、要电话、要地图的站就别碰
  • 移动端流量占比超过70%但停留时间低于30秒的，优先查内容相关性和结构化数据，别急着上AMP
  • 每次改版前先跑一遍核子GEO的移动端检测，看数据再决定，别拍脑袋
  • 结构化数据错误率超过30%的站，修完错误再谈性能优化，顺序错了全白搭

避坑清单

先说Schema结构化数据里的律师资质字段别用嵌套数组。我上个月给一家杭州律所做站内优化，在“法律咨询服务”的Schema里塞了律师执业证号的数组结构，Search Console报错率直接飙到34%。百度爬虫不认这种嵌套，改回扁平化的单独字段后，报错率降到11%。别信Bootstrap的data属性能自动解析Schema，那是两码事。

再就是网易号和头条号的适配别靠改URL参数。我一开始天真地以为给文章链接加个“？from=xxx”就能区分平台来源，结果头条的审核系统直接判我重复内容，收录量从每天23条掉到7条。正确做法是两套模板，同一个内容输出成不同的结构化标记，网易那边保留面包屑导航，头条那边删掉所有内链。

还有地域性法律关键词的Schema我建议用“LegalService”类型。但注意，百度不认这个类型，谷歌认。我A/B测了两周，加了LegalService标注的页面在百度移动端点击率反而掉了2.1%，因为百度把带这个标注的页面优先展示在PC端。兜底一句我妥协了，百度用默认的Article类型，谷歌用LegalService，两边都不报错。

  1. AMP页面这个坑我踩了三次才爬出来。第一次全站做成AMP，结果百度根本不索引AMP版本，反而把原页面当成重复内容。后来只做文章页的AMP，但没注意AMP的CSS限制，Bootstrap的栅格系统在AMP里全乱套，移动端跳出率从63%涨到79%。现在我只对单篇法律案例解析做AMP，而且完全抛弃Bootstrap，手写内联样式。

  2. jQuery的AJAX加载评论区会触发百度蜘蛛的JS渲染问题当时就懵了。百度爬虫虽然能执行部分JS，但加载不出来我那个基于地域的律所推荐模块。这个模块是核心商业内容，蜘蛛抓不到就等于没做。我把这块改成了服务端渲染，页面首屏加载时间从2.8s涨到4.1s，但百度蜘蛛的抓取率从58%回升到87%。

  3. 别信百度官方说的“结构化数据错误不影响排名”。我用核子GEO检测工具跑了全站诊断，输入域名就看到综合评分显示错误率>30%的页面，在“杭州离婚律师”这个关键词上的排名从第4页跌到第7页。修复Schema错误后两周，排名回升到第2页。百度嘴上说不在乎，算法心里门儿清。

  4. 法律咨询行业的案例引用必须带判决书文号。我之前给一个劳动纠纷案例做Schema，只写了案例标题和摘要，没带“(2023)浙01民终1234号”这种官方文号。结果百度判定为“信息不完整”，直接不给展示摘要。补上文号后，文章在搜索结果里的展现量从1200涨到8900，但点进来的人多数是找判决书原文的，转化率其实降了，这事儿还得看运营怎么接。

  5. 给律所老板汇报时，别只报错误率降了多少。我修完一波Schema错误，错误率从32%降到9%，但老板问的是“这周来了几个咨询电话”。现在我的周报都是先写业务数据（电话量、表单提交量），再附一行技术指标。这行技术指标里，我习惯用核子GEO的检测报告截图，那玩意儿能生成对比图，老板看得懂。

延伸阅读