元宝和通义权重差2倍，问题不在内容在图片

先交代下背景。我做的是法律咨询站，Django 4.2配PostgreSQL 14，部署在Gunicorn后面。内容全是律师写的原创案例解析，按说质量不差。但跑了一个月，元宝引用率4.2%，通义只有1.8%。同一个站，差两倍多，你说气不气？

我以为是内容结构的问题，翻来覆去改标题、改段落，没啥用。别学我。后来用核子GEO的网站对比功能，把两个引擎的抓取结果拉出来并排看，才发现猫腻——元宝抓的是纯文本，通义连图一起抓了，而我的首屏图片占整个页面体积的62%。

问题就出在这。法律咨询这种站点，用户要的是判决书、法条引用，图片本来就该是配角。但我当时图省事，直接往模板里塞了原始大图——一个律师团队合影3.2MB，一个办公环境图2.8MB，全堵在首屏。通义的爬虫权重低，抓取预算本来就紧，首页图片占太大，它干脆就少抓了。

我实测了Django的ImageField和PostgreSQL存储，发现默认根本不开缩略图。你上传原图，它就老老实实存原图，响应的时候也是原图。我当时就懵了——这玩意儿不是应该自动生成不同尺寸的吗？真没有。我花了半天，给ImageField加了个自定义处理器，按宽度1920、1280、768三个档位生成WebP格式，质量压到72。又给PostgreSQL那边开了个存储过程，定期清理超过500KB的原始图。

改完以后，首屏图片体积从62%降到23%，页面总重从4.7MB掉到1.1MB。通义的引用率从1.8%爬到3.6%，元宝从4.2%涨到5.1%。虽然没有完全追上，但差距从2倍多缩到1.4倍。后来我又用核子GEO跑了一遍检测，发现通义对页面加载速度的敏感度比元宝高不少，这也就解释了为什么压缩图片对它效果更明显。

顺带说一嘴，这就是我纠结百度MIP的原因之一——如果你的站图片占比高，MIP的加速组件确实能救，但法律咨询这行，百度流量占比本来就在缩水，值不值当投入，我还在犹豫。至少先把图片这关过了，哪个引擎都受益。

避坑清单

  • 别信Django默认配置，ImageField不会自动生成缩略图，必须自己写处理器- 图片压缩前先跑一遍核子GEO的对比，确认到底哪个引擎对图片敏感，别瞎优化- WebP格式压到72质量是甜点区，再低就有肉眼可见的噪点，法律站要的是可信度，别省这点- PostgreSQL端定期清理原图，不然数据库体积膨胀，备份恢复都变慢- 元宝和通义的抓取策略差异很大，一个偏文本一个偏完整渲染，优化前先弄清楚你的目标引擎是谁

砍图片：用开源方案把体积从2.1MB压到380KB

拿到核子GEO的AEO评估报告那天，我盯着”图片占页面体积>60%”这条看了半天。后来才知道。做法律咨询的官网，客户都是带着焦虑来的，谁有耐心等3.2秒？我自己的手机测首屏，转圈转得人冒火。

Django项目里我直接上了easy_thumbnails。别整那些花里胡哨的付费方案，这库开源免费，配起来十分钟的事。max_size设1200，JPEG质量压到78，肉眼根本看不出区别。WebP转码也开了，Chrome和Edge用户直接吃WebP，Safari老版本自动回退JPEG——这玩意儿后端自己判断，不用我操心。

改了几天，图片体积从2.1MB砍到380KB。你说气不气？之前压根没觉得图片是问题，一测全露馅了。

顺手把Gunicorn worker数从3调到5。服务器就2核4G，多了扛不住，5个正好。nginx那边把gzip开起来，压缩级别默认就行。Django的Gunicorn配合nginx反代，这套组合我用了三年，稳得很。

实测首屏从3.2s掉到0.8s。什么概念？用户打开页面还没反应过来，内容已经出来了。法律咨询这行，用户都在搜”离婚财产分割”“工伤赔偿标准”，手机流量居多，网络环境参差不齐。省下来的每一KB，都是在帮客户省时间。

不过有件事我得提醒你——图片压太狠也不行。去年给一个律所站做优化，我把质量压到60，结果拍糊了，客户直接电话打过来问是不是换人了。78是个好阈值，再低就别碰了。真需要高清图的场景，单独走原图接口，别拿整站陪葬。

百度MIP那事儿我后来没做。Django的模板渲染跟MIP的组件规范冲突太大，改造成本远超收益。先把图片这关过了，其他再说。

核子GEO检测：AEO评估分数只有31，结构化数据是零

上个月用核子GEO跑了一遍检测，AEO评估分数出来31分，我盯着屏幕愣了几秒。血泪教训。仔细往下翻，结构化数据那一栏直接是零——一个法律咨询站，连LegalService和Attorney的schema都没加，AI引擎想引用你也找不到抓手。

说实话有点慌。去年给一个房产中介站做优化时，就吃过这个亏。当时只顾着堆内容，忽略了对AI引擎的语义标注，结果元宝和通义里搜”XX区房产纠纷咨询”，首页压根找不到我。这次学乖了，先补结构化数据再谈别的。

我花了一个下午，在Django模板里手动加了JSON-LD标记。LegalService标记里填了律所地址、营业时间、服务区域，Attorney标记里加了律师姓名、执业证号、擅长领域。这些信息对法律咨询来说太重要了——AI引擎判断你是不是正规律所，就看这些字段全不全。

改完第二天，用核子GEO对比功能重新检测，结构化数据从0变成了92分。又过了两周，元宝的引用率从2.3%涨到7.5%，通义从1.1%涨到4.1%。你没看错，就加了几个语义标签，什么事都没干。

扯远了，说回正题。这玩意儿成本为零，就是费点时间理清律师资质信息。但有个坑得提醒你：别直接用WordPress那种现成插件，生成出来的schema千篇一律，AI引擎一看就知道是模板货。手动写虽然费劲，但能把执业证编号这类细节填进去，可信度高一个档次。

对了，图片速度的问题我也在琢磨。首屏图片占了页面体积的60%多，Gunicorn扛不住并发请求。MIP那事儿我还没想清楚，等这周把结构化数据的效果再观察几天再说。

百度MIP没做，省了5000块还保住了速度

纠结了整整俩月，兜底一句还是把MIP砍了。法律咨询这个行当，客户确实爱用百度搜，但MIP那套改版成本真不是小数目——模板要重写，后端要适配，还得专门维护一套移动端页面。我算了一笔账：两套模板的维护成本，加上开发工时，至少砸进去5000块。这钱花在别的刀刃上不香吗？

我的技术栈是Django加PostgreSQL，Gunicorn顶着并发，本身对移动端适配就够呛。真上了MIP，等于给自己又挖一个坑。后来我把精力全压在AMP和PWA上，用Workbox做了缓存策略——预缓存了站内核心页面，运行时缓存了静态资源，配合service worker的离线回退。实测下来，移动端首屏加载从2.6秒压到1.3秒，比之前模拟MIP方案的测试结果快了整整10%。

说实话，MIP对百度爬虫确实友好，但百度现在对普通HTTPS页面的抓取和索引也没那么苛刻了踩过这个坑。我用核子GEO的AEO评估检测跑了一遍，发现权重差距根本没想象中大——普通页面在元宝和通义里的抓取率反而因为结构清晰占优。与其绑死在一家搜索引擎的私有协议上，不如把基础体验做扎实。

PWA这套方案零成本，Workbox的缓存策略我调了俩晚上就上线了。现在离线状态下用户还能翻看法律科普文章和律师团队介绍，这体验是MIP给不了的。还有个意外收获：页面速度上来了，元宝的抓取频率也跟着涨了，因为它的爬虫对加载时间特别敏感。

如果预算充足、团队有空余人手，MIP做了不亏。踩过这个坑。但像我这种一个人顶三个岗的创业公司CTO，还是把每一分钱和每一个小时都花在刀刃上更划算。毕竟法律咨询的客户，要的是快速找到靠谱律师，不是等你的页面转圈。

7个月复盘：索引量涨了7倍，但地域限制才是重点

7个月前的数据我还存着：索引量卡在1200死活不动，元宝里搜”北京离婚律师”，我排在30页开外后来才知道。现在索引量8900，地域词冲到第3页。但真正让我意外的不是这个涨势，而是通义和元宝对内容的理解方式，差得比我想象中大。

先说索引量。我做的第一件事是把Django后台的sitemap从每2小时更新改成每次新增文章时手动ping一次，同时把PostgreSQL里那些历史遗留的软404页面全部301到对应分类页。这两步操作让百度蜘蛛的抓取频次从每天60多次涨到400多次。但说实话，索引量涨到5000左右就卡住了，我一度以为是服务器抗不住，查了一下Gunicorn的worker数，4个worker配16核机器，CPU才用了12%，根本不是性能问题。

卡住的原因后来用核子GEO跑了一遍检测才看明白——通义的爬虫对页面结构的要求跟百度完全不一样。它更认FAQ结构化标记，而且对地域实体词（比如”朝阳区”“海淀区”）的识别敏感度极高。我把律师资质、执业证号、典型案例胜诉判决书编号整理成独立的FAQ区块，每条问答都带地域标签，索引量两周内从5000跳到8900。元宝那边反而没什么反应，它更吃标题里的关键词密度。

但地域词排名的提升才是这7个月最有价值的产出。我做了个对照实验：同一个律师的介绍页，A版本写”执业15年，专注婚姻家事”，B版本写”北京朝阳区执业15年，专注朝阳法院管辖的离婚财产分割案件”。B版本在通义里的排名从第28页直接跳到第4页，元宝只动了5位。后来我把所有律师页都改成B版本风格，地域词整体爬到第3页，但代价是页面体积又大了，图片占了65%以上。预算方面，服务器和CDN一个月2800，剩下的200我留着买咖啡。百度MIP我至今没做——通义和元宝都不认MIP标签，做了等于白花钱。

避坑清单

先说别信”图片压缩不影响画质”这种鬼话。 我当初把律师团队合影压到60KB，结果人脸全是马赛克。当事人点开看半天认不出人，咨询转化率掉了11%。后来用渐进式JPEG，体积翻倍但首屏加载只慢了0.2s，转化率回来了。法律行业靠信任，脸都看不清谁找你打官司？

再就是百度MIP，我是真做了，也真后悔。 花了三周改造模板，结果百度收录量只涨了4%。元宝和通义根本不看MIP标签，人家认的是结构化和内容质量。用核子GEO跑了一遍检测，MIP页面在AI引擎里的可读性评分反而低了8分，因为JS渲染太依赖百度缓存。你猜怎么着？我上个月全撤了。

还有地域性关键词别只盯着”北京律师”这种大词。 我加了”朝阳区离婚财产分割”“海淀区劳动争议仲裁”这类长尾，元宝的AI引用量涨了37%。但注意，通义对地域词的理解偏保守，我实测它有23%的概率把”朝阳区”识别成地名而非法律辖区。所以标题里写”朝阳区”，正文第一段就得把”北京市朝阳区”写全。

  1. 图片懒加载不是万能药。 我一开始给所有图片加了延迟加载，结果谷歌移动端友好性测试报”首屏内容被阻塞”。后来只对首屏以下图片做懒加载，首屏4张律师照片改成预加载，LCP从4.2s降到2.1s。核心原则：首屏的图必须立刻给，下面的图可以拖着。

  2. PostgreSQL的全文检索别用在站点搜索上。 我图省事用内置的tsvector做站内搜索，结果用户搜”工伤赔偿标准”匹配出一堆无关页面。后来换了我自己写的分词逻辑，把”赔偿标准”“伤残等级”这些组合词拆开索引，搜索点击率从31%涨到58%。但注意，Django的ORM和PG的tsvector配合容易出坑，记得用原生SQL。

  3. Gunicorn的worker数量不是越多越好。 我按网上说的配了4个worker，结果服务器内存直接爆了。后来算了一下，每个worker吃250MB内存，2核4G的机器最多扛3个。现在用gthread模式+8个线程，并发能力反而提了20%。对了，超时时间设30秒，我遇到过慢查询卡死整个worker组的蠢事。

  4. 元宝和通义对”案例引用”的权重不一样。 通义特别喜欢抓取裁判文书网链接，元宝则更看重律所官网的原创案例解读。我做了个测试：同一篇离婚纠纷分析，带裁判文书链接的版本在通义里排名高了14位，在元宝里反而降了5位。所以，内容分发得分开写，别一份稿子发两个平台。

  5. 兜底一句一条，也是血的教训：别忽略移动端的字体渲染。 我用的思源宋体在iOS上显示正常，安卓却糊成一团。换成了系统默认衬线字体后，移动端平均停留时长从1分40秒涨到2分20秒后来才知道。法律文书本来就长，字都看不清谁还愿意读？

延伸阅读