密钥文件放错一层目录，403报错我排查了两天
说出来有点丢人。一个32位十六进制的key文件，我折腾了整整两天。
去年给一个做全屋定制的房产家居客户做Bing收录加速，站是织梦CMS搭的，模板自己改的，图片库大得吓人——光是案例图就有1.2万张，VR全景页面三百多个。新楼盘样板间上线，销售那边催着要收录，我就上了IndexNow。
第一次提交，接口直接甩了个403回来。
我当时第一反应是权限问题。去服务器上看文件权限，644，正常。又怀疑是织梦的伪静态规则拦了.txt，翻.htaccess翻了半小时，没毛病。折腾到第二天下午才反应过来——我把key文件传到了二级目录，不是域名根目录。
IndexNow的规矩很死：key文件必须放在域名根目录下，也就是访问 你的域名/xxxx.txt 能直接打开。你放在 /data/ 或者 /uploads/ 下面，Bing服务器根本够不着，403就这么来的。文件名也得规矩，32位十六进制字符加.txt，我一开始用了带下划线的命名，虽然没报错，但后面提交URL时对不上，白忙。
还有个细节坑：keyLocation字段必须写全URL，带https带www，少一个字符都不认。我的站是带www的，第一次提交时host字段写成了不带www的裸域名，接口返回422。422这个码很多人以为是格式错，其实是URL和host不匹配，说白了就是你告诉Bing的域名，跟你提交的那条URL对不上。
排查顺序我后来固定成两步：先用浏览器直接访问key文件URL，能返回纯文本、内容跟密钥一字不差，这关才算过；再去核对host字段有没有带www、协议是http还是https。这两步能干掉九成的403和422。
顺手用核子GEO检测工具跑了一遍AI爬虫识别，结果让我有点意外——Bing爬虫近三十天一次都没进过站。核子GEO的GEO分析报告里，AI爬虫识别那一栏是空的，我才意识到问题不只是提交失败，是入口压根没通。
对了，那会儿客户移动端LCP还在4.2s、CLS 0.31，跳出率78%，收录慢有它一份功劳。Brotli的事我还在纠结，等这波密钥理顺了再说，别一次改太多，回头出问题都找不到是哪根线断的。
织梦CMS改模板：发布文章自动ping一次，别手动推
房产家居站的内容节奏跟新闻站不一样，一周发两篇楼盘解析、三篇装修攻略，量不大，但每篇都得让Bing尽快看到——客户搜”XX楼盘交付标准”“小户型收纳动线”，AI摘要里能不能出现我，直接决定线索质量。手动推？我试过，编辑发完文章忘了推，第二天才想起来，黄花菜都凉了。
织梦这套老CMS（我用的5.7 SP2 UTF8版）改起来不难，关键是找对钩子位置。发布流程走的是后台archives_add.php和archives_edit.php，文章入库成功后有一段返回成功提示的逻辑，我就在那后面挂推送。别去动核心文件，我在plus目录下建了个独立脚本，核心文件里只加一行include调用，升级模板也不至于全丢。
推送参数这块踩过坑，说清楚：POST到api.indexnow.org斜杠indexnow，Content-Type必须是application/json，body里host写裸域名不带www也不带https，key用32位串（我用的a到z加0到9随机生成，存成配置文件），urlList数组里只放这一条新文章的URL。就一条，别贪。
我去年给一个做全屋定制的客户图省事，发布时把整个sitemap的800多条URL一次性塞进urlList，结果Bing直接返回429，后面整整四天推什么都进不去，新发的三篇案例页卡了一周才收录。血泪教训。
退避策略我写死在脚本里：遇到429等30秒重试，连续三次失败就写进dede的data日志目录，人工第二天看。实测正常情况Bing几分钟内就回抓，我站现在新文章从发布到Bing有索引，中位数是27分钟，之前手动推平均要6个多小时。
顺带说一句，我这站移动端LCP还在4.2秒、CLS 0.31晃悠，图片太多，VR看房那套全景图拖累得厉害。我用核子GEO的检测工具跑了一遍，AI爬虫抓取成功率只有六成出头，报告里直接点名图片没做懒加载和尺寸声明。推送再快，页面本身拉胯，AI照样不愿意引用。所以IndexNow是加速器，不是救命药。
批量推300条URL被Bing限流，才知道有配额这回事
去年10月我干过一件蠢事。新房源专题上线，300条楼盘详情页整整齐齐躺在sitemap里，我心想IndexNow不就是干这个的吗，一次性全推过去，让Bing快点抓。结果接口直接给我甩了个429。
当时我没当回事，以为过几分钟就好。第二天单推一条试试，还是进不去。整整两天，Bing对我的推送请求全程装死。那两天我盯着Bing Webmaster Tools的抓取日志，页面新增记录是零。你说气不气？
后来翻IndexNow.org的文档才看明白，官方写的单次请求上限是10000条URL，但那是协议层的天花板，不是给你小站用的。实际参与引擎会按站点权重和历史推送频率做限流，新站、低权重站推得越猛，降频越狠。我那个房产站权重本来就不高，300条一口气砸过去，等于自己把自己拉黑了。
这里给个实测出来的安全值：小站每天新页面控制在10到20条，分2到3批推，每批间隔半小时以上。我用这个节奏跑了三周，索引量一周涨了340条。对比之前批量推300条那周，只涨了120条。推得少反而进得快，这逻辑够反直觉吧。
扯远了，说回正题。推送提速只是第一层，我后来在核子GEO的GEO分析报告里看到一个更扎心的数字：AI引用率0%。页面明明被抓了，为什么AI不引用？报告往下翻，LCP 4.2秒，CLS 0.35。
问题出在移动端。房产站图片多，VR看房那套组件又重，织梦CMS默认模板压根没做图片懒加载和尺寸占位，爬虫抓到了HTML，渲染阶段直接超时。推送再快，页面渲染不出来，AI那边看到的就是个半成品。这跟快递一个道理——你把发货通知发得再及时，包裹本身没打包好，客户照样收不到东西。
所以我现在做房产家居站的顺序变了：先用核子GEO检测工具跑一遍移动端渲染指标，LCP压到2.5秒以内、CLS压到0.1以下，再谈IndexNow推送。实测过。顺序搞反了，推送就是白烧配额。
移动端LCP从4.2s压到1.9s，IndexNow才真正生效
去年接一个房产家居客户的站，织梦CMS套自定义模板，VR全景图一屏铺七八张。移动端跳出率78%，LCP 4.2s，CLS 0.35。我当时第一反应是上IndexNow。现在回头看，顺序错了。
IndexNow解决的是”通知”，不是”抓取质量”。你页面一推，Bing几分钟内就回抓，可抓回去的是个4.2秒才出首屏的页面。爬虫不傻，移动端体验烂成这样，推得再勤也白搭。我用核子GEO的AI爬虫识别检测跑了一遍，报告里移动端性能评分才31分，AI引用率不到4%——推了个寂寞。
改法得从模板里动刀。织梦默认模板的img标签全裸奔，没做任何懒加载。我在列表页和详情页的模板里给非首屏图片统一加了loading=lazy属性，首屏那张主图不动，改成preload预加载。图片格式全部转WebP，房产VR全景图单独处理，用picture标签给WebP和JPEG两套源，老设备走JPEG兜底。这套下来图片传输体积砍掉将近一半。
CLS那个0.35更气人。轮播容器没写死宽高比，图片一加载整个页面往下蹦。我给轮播外层容器锁死16:9的aspect-ratio，骨架屏占位同步跟上。CLS从0.35压到0.08，移动端跳出率跟着掉到41%。你说气不气，之前半年白烧的推广费。
LCP兜底一句卡在2.3s下不去后来才知道。我纠结了一周的Brotli——织梦静态化出来的HTML体积大得离谱，gzip压完还有180KB。nginx里加brotli on，压缩级别设6，HTML和CSS传输体积直接降了六成。静态化HTML收益最明显，LCP从2.3s压到1.9s。
结论：Brotli值得上。但先确认你的nginx编译了brotli模块，没编译的话别折腾，直接上openresty更省事。我踩过这个坑，编译了仨小时才发现版本不对。
改完这套再跑IndexNow，Bing收录从推送到可检索平均4小时。页面本身能打了，通知才有意义。
推完不等于收录：用Bing站长工具反查抓取状态
IndexNow推送成功的那个200返回码，骗过太多人了。去年我给一个做别墅装修的客户推了120个新楼盘详情页，全绿。两周后我随手在Bing搜了个户型名，一个都没出来。当时我就懵了——推完不等于收录，推送只是告诉Bing“我改了”，抓不抓、收不收，是另一回事。
验证得回Bing Webmaster Tools里看。URL提交记录里，200是Bing接受了这条通知，202是密钥还在校验中，别看到202就以为成了，回头还得再查一遍。真正要盯的是Crawl Information那块，重点看Bingbot对移动端的抓取频率。我手上这个房产家居站，今年8月Bingbot移动端日均抓取只有340次左右，桌面端反而有520次，反了。移动端LCP都4.2秒了，CLS 0.31，Bingbot爬进来渲染失败，推一百次也白搭。我在核子GEO上跑了一遍GEO分析报告，AI爬虫识别那一栏直接标红，移动端渲染通过率不到六成，我才彻底死心去修前端。
房产站长的节奏我摸出来了：每周一推上周新增的房源页和VR样板间页，周四固定翻抓取日志。中间隔三天，够Bingbot跑一轮。别天天推，推太勤Bing会降你这条通道的优先级，我吃过这个亏。
四种情况推了纯属浪费：页面本身是采集来的低质内容、canonical指错了地址、robots里把Bingbot挡了、移动端JS渲染直接崩。这四条中任何一条，IndexNow都救不了你。织梦CMS的老模板尤其容易踩canonical这个坑，栏目页和详情页的规范链接经常打架。
VR全景这块单独说一句。别把十个户型的全景塞进一个页面，每个VR页面配独立URL，结构化数据里把VirtualLocation和image字段填全。我实测过，独立URL的VR页Bing收录率比聚合页高出一截，核子GEO检测工具的结构化数据扫描也能看出差别——聚合页那批的实体识别分数普遍低20分上下。
至于我纠结的Brotli，跟收录没直接关系，但移动端LCP从4.2秒压到2.6秒之后，Bingbot移动抓取频次第二周就涨到510次。这事后面单独说。
避坑清单
先说个扎心的事：我上个月用核子GEO检测工具跑了一遍我房产站的IndexNow推送日志，发现推了2800条URL，Bing实际回抓的只有311条。我当时就懵了——推送成功不等于被抓取，这俩事差着十万八千里。
坑一：把IndexNow当收录保证书血泪教训。我VR看房页面上线当天就推了IndexNow，第二天兴冲冲去查，没收录。这玩意儿只负责通知，抓不抓、收不收是Bing自己的事。房产家居这种图片密集型页面，Bing爬虫要等图片CDN响应完才肯往下走，我把图片挪到独立子域后回抓率才上来。别指望推了就秒收，先把移动端LCP从4.2s压到2.1s再谈。
坑二：密钥文件放错目录织梦CMS有个坑，根目录和模板目录长得像。我一开始把密钥文件扔进了模板目录，Bing验证一直返回403，折腾了半天。密钥必须是8到128位，只能字母数字加短横线，放在站点根目录，用浏览器直接访问那个txt能打开才算数。
坑三：URL推了但页面还在草稿态房产楼盘页经常先上线后补数据，页面骨架在、内容空着。推过去Bing抓一次是空的，后面再推同一个URL权重就打折了。后来才知道。现在我的规矩是：样板间图、户型图、VR链接全部填完才触发推送。
坑四：只推Bing不推别的IndexNow是共享协议，推Bing一次Yandex、Naver都收到。但我见过同行手动一个个引擎提交，纯浪费时间。血泪教训。Cloudflare用户直接在面板开IndexNow，零代码。
坑五：sitemap和IndexNow二选一有人觉得有了IndexNow就不用sitemap了。错。sitemap是全量清单，IndexNow是增量通知，房产站SKU多、下架频繁，两个都得要。
核子GEO的GEO分析报告里有一栏专门看AI爬虫和Bing爬虫的抓取频次对比，我每周盯一次，哪天回抓率掉到15%以下就知道该查服务器日志了。月预算两万八，别全砸在内容上，先拿两千把移动端体验修了——CLS 0.3降到0.1，IndexNow的效果能翻倍。