Bing索引架构重建：Compare2Best如何修复92%索引覆盖缺口

1. 症状：Bing将一个站拆成四个目录

调查始于Bing网站管理员工具将Compare2Best展示为四个独立"目录"——每个子域名一个——且每个目录的已索引URL均接近零：

总计：952个已索引页面。而平台实际拥有12,000+内容页面，涵盖产品详情、对比中心、采购指南、规格参考、术语表、品牌档案和市场洞察。灯饰子域名上1,800个被排除的URL是第一个危险信号——一个子域名不应占全部被排除页面的89%，除非存在结构性问题。

从各目录导出URL列表后确认了这一模式：Bing的CSV导出每个目录仅显示1个URL，不是因为目录为空，而是因为Bing的内部URL分组将重定向链处理为独立站点。

2. 诊断：Sitemap毒药

2.1 robots.txt——四个Sitemap，三个损坏

第一个诊断检查针对robots.txt，其中列出了四个sitemap：

sitemap索引本身格式正确，但额外列出的三个sitemap——core、content、guides——存在致命缺陷：其中的每个URL都使用了lighting.compare2best.com子域名。

2.2 域名分布分析

对sitemap进行快速域名统计后，结构性问题一目了然：

与此同时，sitemap-main.xml（302个URL）和sitemap-insights.xml（97个URL）正确使用了www.compare2best.com——但它们被埋在sitemap索引中，而Bing因三个问题sitemap消耗大量注意力而未充分处理该索引。

2.3 重定向链

下一步是追踪Bing爬取这658个URL时实际发生的情况：

每个sitemap URL都经历双重301重定向链。Bing的处理逻辑：

1. 爬取lighting.compare2best.com URL → 收到301
2. 跟随重定向 → 再次收到301
3. 最终到达规范URL → 但sitemap"属于"错误的子域名目录
4. 结论：lighting.compare2best.com是一个只有重定向、没有内容的站点 → 排除1,800个URL

2.4 生成器根因

Sitemap生成器脚本（scripts/generate-sitemap.mjs）在8个位置硬编码了灯饰子域名URL：

这是一个迁移后遗留问题。当灯饰内容从独立子域名迁移至主www域名（通过301重定向）时，sitemap生成器从未更新以反映新的规范URL结构。内容可以访问——但sitemap却将搜索引擎指向了错误的地址。

3. 修复：三阶段部署

第一阶段：robots.txt清理（即时生效）

第一步修复是外科手术式的即时操作——从robots.txt中移除三个损坏的sitemap，仅保留格式正确的索引：

效果：Bing立即停止在658个重定向链URL上浪费爬取预算。仅此一项更改，在后续修复部署期间就防止了进一步排除累积。

第二阶段：Sitemap生成器重写

所有8处硬编码的lighting.compare2best.com引用被替换为www.compare2best.com/lighting——主域名下的规范URL路径：

第三阶段：Sitemap索引恢复

Sitemap索引（sitemap.xml）从4个子sitemap扩展至6个，新增了现已正确格式化的灯饰和产品sitemap——这些在旧架构下被排除在索引之外：

4. 提交与验证

4.1 即时操作

4.2 IndexNow密钥：9262f4c0c0e4401d9e247c54b08a04e1

Compare2Best维护一个已在Bing和Yandex注册的活跃IndexNow密钥。密钥文件托管在/9262f4c0c0e4401d9e247c54b08a04e1.txt并每周验证。Sitemap重建后，5个sitemap文件和20个优先URL通过IndexNow提交以触发即时重新爬取。

5. 架构经验

5.1 子域名 vs 路径：选定唯一规范形式

Compare2Best的灯饰内容当前遵循此模式：子域名URL 301重定向至www URL。正确的规范形式是www.compare2best.com/lighting/...，所有sitemap现均使用此格式。如果未来决定直接从灯饰子域名提供内容，必须先移除301重定向。

5.2 Sitemap索引是唯一真相来源

robots.txt应引用恰好一个sitemap——即索引。所有子sitemap应仅在索引中列出。这可防止robots.txt中有4个sitemap条目、其中3个损坏、调试需要检查多个来源的情况。单入口点既简化爬虫处理，也简化运维排障。

5.3 迁移后Sitemap审计是强制性部署关卡

任何域名或URL结构迁移都必须在部署流程中包含sitemap审计。可立即发现此类问题的三项检查：

1. 域名审计：grep -oh 'https://[^/]*' sitemap-*.xml | sort | uniq -c——按域名统计URL数量。任何子域名计数>0即为危险信号。
2. 重定向追踪：curl -sI -L {样本URL} | grep '^HTTP'——追踪HTTP响应链。sitemap中出现的每个URL必须在首次请求时返回200，而非经过重定向链。
3. 索引数基线：迁移前记录Bing和Google的已索引URL数。迁移后任何>20%的下降需立即调查。

5.4 爬取预算经济学

658个损坏的sitemap URL不仅未能被索引——它们消耗了本可用于真实内容的爬取预算。以双重重定向链计算，每个URL消耗3次HTTP请求（初始+两次重定向）却无任何可索引输出。规模放大后，一个充满重定向的2,000 URL sitemap约消耗6,000次爬取请求——足以将一个300页的站点完整重新爬取20次。

6. 预期恢复时间线