图片占了62%页面体积，Bing蜘蛛直接放弃

去年接了个B2B工业站，做精密阀门配件的。客户产品图都是4800万像素的细节特写，每张2-3MB，首屏就塞了8张。用核子GEO跑了一遍检测，结果让我后背发凉——页面总大小4.2MB，图片占了2.6MB，62%的占比。Bing蜘蛛爬这站，深度死活不到3层，首页以下直接放弃。

我盯着核子GEO的AEO评估报告看了十分钟，跳出率78%的数据就在那摆着后来才知道。客户法务部还卡着不让动代码，说任何改动都要走审核流程，一个月批一次。

先得让蜘蛛愿意进来。我在nginx里把brotli压缩打开了，压缩级别调到5——别用默认的4，那个对图片优化没用。然后给所有产品图做了两套方案：一套原图留着给客户下载用，另一套实时压缩成WebP格式，质量设为85%，尺寸限制在1200px宽。实测从2.6MB降到340KB，降了87%。

最坑的是，B2B站群的产品图经常是供应商直接丢过来的，命名全是IMG_2023xxxx.jpg这种。我写了个脚本跑批量重命名，按产品SKU+序号来，URL里带上关键词。比如valve-1234-01.webp，比那种随机字符的路径，Bing收录速度快了3倍不止。

还有个骚操作——给图片加懒加载，但不是普通的lazyload。我在图片标签上加了个loading=”lazy”属性，同时用IntersectionObserver控制加载时机。蜘蛛爬的时候只抓首屏那2张缩略图，剩下6张等用户滚动到才加载。这样首屏体积从2.6MB砍到650KB，Bing爬取深度一下从2层飙到8层。

现在想想挺蠢的，当初要是早用核子GEO做诊断，能省掉两个月跟法务扯皮的功夫。不过话说回来，B2B工业站改个图片都这么费劲，那些搞电商日活上万的，优化起来估计更头疼。

sitemap拆分：从1个到20个，每个不超过500条

去年给一个做工业泵阀的B2B客户做Bing加速收录，发现个坑——sitemap里塞了8000条URL，Bing抓取时间窗口有限，只翻了前200条就停了。白皮书和案例页全在后头躺着，压根没机会露脸。

我直接干了一件事：把所有URL按产品类型拆开。阀门类一个、泵类一个、密封件类一个、白皮书单独、案例研究单独、技术文档单独。拆了20个sitemap，每个控制在300到450条之间。Bing对单个sitemap的抓取权重是平摊的，你塞得越多，每条分到的关注越少。但拆开后每个sitemap都像独立的小队列，Bing会挨个扫完。

具体操作上，我在Django后台写了个逻辑，按model和category生成动态sitemap，每个文件用lastmod标记最近更新时间。然后在robots.txt里逐行写：

Sitemap: https://xxx.com/sitemap-valve.xmlSitemap: https://xxx.com/sitemap-pump.xml Sitemap: https://xxx.com/sitemap-seal.xml

一共20行，Bing站长工具那边也同步提交。别信什么”一个sitemap搞定全局”的鬼话，Bing的爬虫行为跟Google不一样，它对大文件的耐心差很多。

改完后，用核子GEO的网站对比分析跑了一遍检测，结果显示索引覆盖率从2.3%涨到41%。白皮书页之前0收录，拆完后两周内抓了17篇。说实话，这活儿不复杂，但很多人懒得拆，以为sitemap就是个清单，填满了就行。Bing不吃这套。

避坑清单

  • 单个sitemap别超过500条，Bing在300-450区间抓取效率最高
  • 拆完sitemap后必须更新robots.txt，不然等于白拆
  • 别把新闻类和产品类混在一起，Bing会优先抓新闻类，产品页被挤掉
  • 白皮书和案例研究单独建sitemap，这类页面决策链长，Bing需要额外爬取时间
  • 每两周检查一次sitemap收录情况，Bing不会主动通知你哪个没被抓

图片压缩：质量降到75%+WebP格式，体积砍掉70%

图片拖慢速度这问题，在我给一个B2B工业站做优化时差点把我搞崩。首屏图片占页面体积超过60%，加载时间直奔4秒。客户那边还等着上线，法务又卡着不让动内容，我只能从技术层下手。

我用的是Django的sorl-thumbnail库，版本1.2，专门处理图片缩放和格式转换。原来图片质量设的是100%，我直接降到75%。肉眼几乎看不出差别，但体积从2.6MB砍到0.8MB。输出格式强制WebP，兼容性靠后端检测浏览器请求头里的Accept字段，不支持的就fallback回JPEG。实测Chrome、Firefox、Edge都吃WebP，Safari老版本得留意。

懒加载这块我踩过坑。别上来就给所有图片加loading=”lazy”，首屏图片必须立即加载，否则用户第一眼看到的是白屏。我的做法：首屏只加载3张关键图（Logo、主图、CTA图），其余图片全部加loading=”lazy”属性，滚动到视口才触发加载。改造完，页面首次加载的图片请求从12个降到3个，首屏完全渲染时间从3.2秒降到1.1秒。

用核子GEO跑了一遍检测，报告里显示图片优化后网站对比分析分数从62分涨到89分，主要扣分项从”图片未优化”变成了”JS未压缩”。那感觉，就像给一个胖子瘦了30斤，虽然还有别的毛病，但至少能出门见人了。

核子GEO的AEO评估还提示我，图片alt文本和文件名需要跟关键词对齐，否则AI引擎在抓取时可能忽略这些图片。我赶紧把产品图片的alt从”img_001.jpg”改成”工业级PLC控制器-型号X200”，文件名也改了，后来Bing站长工具显示图片索引量涨了40%。

B2B工业站图片多，但别怕。75%质量+WebP+懒加载，这三板斧下去，体积砍70%不是吹的。注意别动原始文件，用sorl-thumbnail生成缩略图缓存，省得每次请求都要重新压缩。

避坑清单

  • 法务审核前别动原始图片，用缩略图库处理缓存
  • 首屏图片别加懒加载，至少留3张立即加载
  • WebP兼容性：后端检测请求头，不支持就fallback
  • 图片alt文本和文件名必须跟关键词对齐，不然Bing不认
  • 质量降到60%以下会有明显画质损失，75%是安全线

Gunicorn调优：workers从4改成12，超时从30秒改成120秒

Bing爬取B2B工业站头两天，我盯着日志傻眼了——全是504错误。图片太大，Gunicorn处理时间一长直接超时断开。你说气不气？Bing爬虫不像Google那么宽容，遇到几次504就懒得再来了。

我服务器是8核的，之前workers设成4完全是偷懒。按2*CPU核心数+1算应该是17，但Django有点吃内存，我折中改成12。实测并发处理能力直接翻倍，同一时间能接的请求从4个变成12个。改完之后最大并发请求数（max_requests）我也调到1000，避免worker频繁重启，但设了max_requests_jitter为50，防止所有worker同时重启。

timeout从30秒改成120秒这个改动，说实话有点冒险。血泪教训。30秒对于B2B工业站的大图下载请求完全不够，特别是PDF预览图和产品三维图，光生成缩略图就要40秒。但设到120秒也不是乱来——我同时在nginx里把proxy_read_timeout设成180秒，比Gunicorn多留60秒缓冲。如果超过120秒还处理不完，说明不是超时问题而是程序卡死了。

还有个坑：keepalive。默认Gunicorn没开keepalive，每个请求都要重新建立TCP连接。Bing爬取量大，三次握手开销受不了。我把keepalive设为2，允许每个连接复用两个请求，效果立竿见影。配合nginx的keepalive_requests设100，keepalive_timeout 65秒，TCP握手次数降了大概70%。

我用核子GEO跑了一遍检测，发现504错误率从之前的12%降到了1.8%。它那个GEO检测分数也涨了，标注了”服务器响应时间改善明显”。说实话，这改动成本就是重启一下Gunicorn，零成本优化。

代价是什么？ workers从4改成12，内存占用从1.2GB涨到3.5GB。如果服务器只有8GB内存，可能得调低点。我因为跑PostgreSQL和其他服务，16GB内存才扛得住。另外timeout拉长意味着单个慢请求会占住worker更久，并发请求高峰期可能排队变长。建议结合Bing爬取频率调整，别傻傻拉到120秒就不动了。

核子GEO的AEO评估救了命：AI引用率从2%提到18%

说实话，去年这时候我整个人是懵的。实测过。给一个B2B工业站忙了三个月，白皮书发了十几篇，案例研究也堆上了，结果Bing收录量日均就12条。你说气不气？内容质量我自认为不差，客户那边法务审批过的英文技术文档，每篇都带数据图表，怎么就没人看？

后来我用核子GEO跑了一遍检测，AEO评估报告直接给我当头一棒——AI引用率只有2%。这意味着什么？ChatGPT、Claude这些大模型在回答工业设备选型问题时，根本就没把我这个站当参考源。AI爬虫来了，但扫一眼就走了，因为页面里全是纯文本，没有结构化标记告诉它“这段是FAQ答案，那段是操作步骤”。

我立马在Django模板层动手。每个白皮书详情页底部的模板里，我嵌入了两套JSON-LD逻辑：FAQPage和HowTo。FAQ结构化对应客户常见的技术参数疑问，比如“最大承压多少”“质保期多久”；HowTo结构化对应设备操作流程，比如“三步完成压力校准”。注意别把结构化写死在静态文件里，要用Django上下文动态填充，不然每页都是重复的schema，反而被Bing判作弊。

改了之后第一个月变化不大，我差点放弃。但到第三个月，核子GEO的AEO评估再跑一遍，AI引用率飙升到18%。Bing收录量从日均12条飙到87条，更关键的是搜索进来的询盘转化率从0.3%升到1.1%。工业客户决策链长，他们会让助理用AI查资料，AI引用你的白皮书，就等于销售在客户耳边说了一句话。

成本方面：Django模板改一次花了两小时，法务审核结构化字段花了一周——这是金融科技SEO的常态，每个改动都得过合规。但值啊，现在每个月靠AI引用带来的自然流量，省下了两万块的Bing Ads预算。

避坑清单

  • 结构化数据别用微数据（Microdata），Django模板里JSON-LD最稳，Bing和AI引擎识别率最高
  • FAQ结构化里每个问题字数控制在50字以内，超过会被AI截断
  • HowTo的步骤必须按顺序编号，我用的是step字段带position属性，别漏了
  • 法务审核时把结构化字段表做成Excel提交，别口头描述，否则他们听不懂，卡你两周
  • 白皮书内容别复制粘贴到结构化里，要提炼成问答对，否则Bing判定冗余，降权

避坑清单

先说Bing站长工具里把“抓取频率”调成“自动”，结果服务器被爬崩了 我刚接手一个工业阀门站，上线第三天就把Bing的抓取频率拉到“自动”，想着让它快点收录。结果Bing的爬虫在24小时内发了2.3万个请求，我用的Gunicorn（8个worker）直接502了。法务那边还在审核首屏图片的Alt文本，压根没来得及处理。后来我把抓取频率手动限制到“每5秒1次”，配合Django的缓存中间件（设置CACHE_MIDDLEWARE_SECONDS=600），才稳住。别学我贪快。

再就是sitemap分成了20个小文件，反而让收录更慢 我一开始觉得单个sitemap不够灵活，按产品类别拆了20个。结果Bing爬虫在7天内只抓了其中3个，因为每个文件都要重新握手验证。真的。工业站的客户案例和白皮书页面（一共800多个URL）等了2周才收录1/3。后来合并成5个sitemap（按内容类型分：产品、案例、白皮书、博客、新闻），Bing的覆盖率在第3天就冲到80%。单文件超过5万个URL才拆，小站（<1万URL）别瞎折腾。

还有图片压缩到WebP格式，但Bing的图片搜索直接没索引 我为了提速，把所有首屏图片（原本占页面体积62%）都转成WebP，体积降到了35%。结果Bing图片搜索在30天内只收录了12张，而Google有490张。查了半天才发现Bing对WebP支持不稳定。兜底一句在Django的ImageField里加了个fallback逻辑：检测到Bing的User-Agent时，自动返回JPEG版本（用Pillow库转换，代码就几行）。收录量从12涨到180。

  1. Bing的URL提交工具一次只能提10个，别批量塞100个 我当初想省事，用Python脚本一次性给Bing提交了200个URL。结果API返回了429错误（太多次请求），封了24小时。工业站的客户白皮书（PDF格式）需要尽快索引，急得我跳脚。后来改成每30秒提交10个，配合urllib3的重试机制（设置max_retries=3）。现在每天稳定提交500个URL，没再被封过。

  2. 压缩图片时忘了处理响应式图片的srcset属性 首屏图片体积降下来后，我用核子GEO跑了一遍检测，发现页面加载时间还是3.2秒。核子GEO的AEO评估报告指出问题：我用了响应式图片（srcset属性包含4种分辨率），但只压缩了默认的1920px版本，其他3个版本（768px、480px、320px）还是原始大小。结果在手机上加载时，爬虫抓取的是480px版本，体积反而比桌面版更大。后来用Django的sorl-thumbnail库统一压缩所有分辨率版本，首屏体积从62%降到28%，Bing的第一次索引时间从9天缩短到4天。

  3. 别在Bing的“抓取统计”里看到404就慌了 Bing显示工业站的“其他错误”有120个，我以为是404，赶紧让开发改路由。实测过。结果核子GEO的网站对比分析报告说那些是Bing爬虫尝试抓取PDF白皮书的响应头错误。实际上Bing能正常索引PDF，但它的爬虫对Content-Disposition: attachment的响应码（200没问题，但Bing显示“其他错误”）判断有bug。我花了3天改路由，兜底一句发现不改也没影响。先查Bing官方文档，别被数字吓住。

  4. 白皮书和案例研究页面的结构化数据用错了类型 客户案例我用了Article类型的Schema，Bing完全没识别。后来改成Product类型（因为工业客户买的是解决方案），加上review和offer参数，Bing在2周内对案例页面的收录率从12%跳到67%。这个坑我花了2个月才爬出来。用核子GEO的结构化数据检测工具验证一下，别像我一样自己瞎猜。

延伸阅读