2026 年网页订阅源调查报告

# 2026 年 Web 订阅源现状调查 来源：https://mnot.net/blog/2026/feed-survey 2026 年 5 月 10 日 星期日 Web Feeds (https://mnot.net/blog/web-feeds/) 几周前，我提出了一份关于新型 Web 订阅源自动发现机制的初步提案 (https://www.ietf.org/archive/id/draft-nottingham-feed-menu-00.html)。我收到了一些鼓励，也遇到了一些反对意见（这类事情向来如此）。其中提出的一个问题涉及国际化——有些人认为我应该在该格式中支持多语言，而不是依赖 HTTP 内容协商。 结合具体的使用场景，我认为我的方法已经足够。但这让我有些在意：我没有数据来支撑我的观点——据我所知，目前几乎没有关于当今 Web 上订阅源使用情况的显著数据。 我意识到这并非无法解决。两件事帮了大忙：一位在 Common Crawl 的朋友向我保证他们确实会抓取订阅源，以及 AI。我根本没有足够的时间去深入研究 Common Crawl 数据集的导出、MapReduce 以及各种数据科学细节，但我可以在处理其他事务的同时，监督几个 AI 代理1 (https://mnot.net/blog/2026/feed-survey#fn:1)替我完成这些工作。于是我真的这么做了 (https://github.com/mnot/feed-survey)。 你可以查阅完整的（首届？）调查报告 (https://projects.mnot.net/feed-survey/2026-05-10/report.html)。以下是我从个人角度总结的主要发现。 ### Web 订阅源依然存在…… 在 Common Crawl (https://commoncrawl.org/) 抓取的 Tranco (https://tranco-list.eu/) 排名前 50 万的网站中，本次分析运行检查了 196,598 个可注册站点，并**发现了 303,790 个可解析的订阅源**。35.9% 的站点暴露了订阅源自动发现功能，19.7% 的被分析 HTML 响应中包含订阅源链接。 这个数字非常庞大——超过三分之一的站点提供某种形式的订阅源，这对开放网络 (https://mnot.net/blog/2026/open_web) 的本质来说是一个有力的证明。 ### ……但其中大量已被废弃。 高质量的订阅源只占少数。采用一项综合考虑订阅源更新频率、内容和元数据的质量指标进行评估，**57,995 个订阅源**得分超过 0.5——仅占**已解析订阅源的 19.1%**。仅有**100,643 个订阅源**（占已解析订阅源的 33.1%）在 365 天的截止期内有任何更新信号，而同时满足“已更新”且“包含条目”的仅有**67,997 个**。 因此，Web 上存在*大量*被废弃的订阅源。 我怀疑一个主要原因是内容管理系统（CMS）倾向于自动暴露订阅源，即使发布者的自定义设置意味着这些订阅源已不再反映网站中有价值的部分。例如，在我们能识别出由 WordPress 创建的订阅源中，仅有 19.3% 达到了我们的质量门槛（衡量更新频率、内容和元数据的指标）。Drupal 略高一些，但也仅为 24.9%，而 Blogger 更是低至惨淡的 3.5%。 换句话说，当你访问一个由主流 CMS 托管的网站时，其生成的订阅源很可能已经过时、空白或基本无用，这种概率高得令人不适。这里的结论简单而紧迫：**CMS 软件不应在发布者不知情或未维护的情况下静默创建并广播订阅源；订阅源应当是可见的、可测试的，并且需要由用户明确启用。** 在几个主流平台的下一个版本中修复这一问题，可以在短时间内大幅提升 Web 上订阅源的整体质量。 ### 自动发现并非质量信号。 17.5% 的订阅源有 HTML 订阅源自动发现 (https://www.rssboard.org/rss-autodiscovery) 链接指向它们，但这些链接并不一定能带来更高质量的订阅源。尽管自动发现的订阅源在测量质量上略有提升，但平均质量依然很低——**0.251 对比无自动发现订阅源的 0.179**。 这损害了自动发现作为面向用户功能提示的价值；如果人们在使用自动发现信息时频繁遇到过时或零条目的订阅源（这正是我的亲身经历！），他们就不会再依赖它。 正是这种失败促使我提出了新型订阅源自动发现机制的提案 (https://www.ietf.org/archive/id/draft-nottingham-feed-menu-00.html)，并作为主流浏览器的扩展提供了原型实现。理由很直接：**如果自动发现机制更加审慎，且位于网站的中心位置，它就更有可能指向正常运作且有价值的订阅源。** 题外话：自动发现几乎完全等同于 `rel=alternate`。通过 `rel=alternate` 进行订阅源自动发现的页面多达**8194 万个**；相比之下，`rel=feed` 微不足道，仅有**12,793 个页面**。WHATWG 应该废弃 feed (https://blog.whatwg.org/feed-autodiscovery) 链接关系；事实标准早已确立（顺应现有习惯即可）。 ### 大多数订阅源均可成功解析。 本次运行检查了**311,382 个订阅源 URL**，成功解析了**303,790 个** RSS/Atom 订阅源，**解析成功率高达 97.6%**。因此，虽然损坏的 XML 确实存在，但直接的解析失败并不是主要的质量问题。 这在 RSS 和 Atom 早期曾是一个主要担忧；当时 XML 尚属新生事物，结构复杂2 (https://mnot.net/blog/2026/feed-survey#fn:2)，且无论是 XML 解析器还是订阅源软件的实现都尚未成熟。从我们目前看到的情况来看，这似乎已不再是个问题。 遇到的最大问题——占所有错误的 52% 以上——是“XML 声明仅允许出现在文档开头”。其次是约占 13% 的“EntityRef: expecting ';'”，以及约占 8% 的“CData 部分未闭合”。 所以，是的，网站仍应使用订阅源验证器 (https://validator.w3.org/feed/)。但就整个生态系统而言，我们不必对订阅源质量的这一方面过度担忧。 ### RSS 与 Atom 共存。 在**303,790 个已解析的订阅源**中，约**20 万属于 RSS 系列**，**10.4 万为 Atom**。仅 RSS 2.0 就占了**181,975 个订阅源**。两者之间的质量差异微乎其微。因此，二十多年后订阅源格式之争仍在继续——或者换个说法，根本没人真正在意。 给网站的建议很简单：**不要过度纠结于格式选择**。选一个就行——两者皆可——不要重复提供多套订阅源。消费端软件都会支持两者。 我特别想检查的一件事是，是否有页面同时广播同一订阅源的 Atom 和 RSS 版本。从我们的数据来看，这种情况并不多见；抽样中仅有七个页面似乎在做这件事。 ### 订阅源是单语的。 最后，回到引发我此次调查的问题——19.2% 的订阅源带有 HTTP `Content-Language` 头，而几乎正好 50% 的订阅源包含订阅源级别的语言信息（例如 `dc:language`、`xml:lang` 或 RSS 的 `language` 标签）。然而，仅有 1.2%（3,571 个订阅源）包含条目级别的语言信息，只有 2,527 个订阅源——占已解析订阅源的 0.8%——显示了多种条目语言。 因此，基于当前的 Web 现状，**在单个订阅源中混合使用多种语言并非普遍做法**。 ### 关于方法论的几点说明 和所有统计数据一样，对这些结果应持保留态度（甚至要多打几分折扣）。代码由 AI 编写（尽管由我指导，因此责任由我承担）。我没有逐行审查所有代码；这只是一个副业项目。Common Crawl 并未覆盖整个 Web（尽管订阅源的开放网络特性使其成为一个很好的匹配样本！）。我过滤了 Tranco 前 50 万名的网站，以减少极低质量域名的影响。本次运行完成了 44,281 个 WARC 文件，跳过/失败了 71 个，因此 WARC 缺失率约为 0.16%。我确信还有更多需要注意的细节，但你明白我的意思。欢迎查看代码 (https://github.com/mnot/feed-survey)，如果发现问题请提交 Issue。