内容管理系统统计里 WordPress 占近六成，剩下的份额在谁手上

内容管理系统市场份额统计里 WordPress 占近六成，剩下的份额在谁手上？先看这份 2026 年 10 月的统计原文：WordPress is used by 40.1% of all the websites, that is a content management system market share of 58.6%。剩下那部分并不集中在某一个后继者手上，同页头部替代项依次是 Shopify 5.4%、Wix 4.2%、Squarespace 2.4%，其余分散在长尾里；更要紧的是同一页写着 31.6% of the websites use none of the content management systems that we monitor——三成以上的站点用的系统根本不在这份统计的监测范围内。

同一份统计里的两个百分比为什么不一样

40.1% 与 58.6% 说的不是同一件事：前者在所有网站里计算，后者只在被识别出使用内容管理系统的那部分网站里计算。分母一缩，比例就上升，两个数字之间不存在矛盾，也不能相互替换。

选型时被引用最多的往往是较大的那个数，而它成立的前提是「在被识别出使用内容管理系统的站点里」。引用时把分母一并写出来，结论才可复核。

分母不同带来的读法陷阱

第一处陷阱是把 31.6% 的未监测部分当作「没有用内容管理系统」。统计页的表述是这些站点使用的系统不在监测范围内，未监测不等于未使用——自建程序、行业专用系统、小型开源系统都可能落在这一档里。

第二处陷阱是把头部替代项的百分点相加去推算「剩下的份额」。5.4%、4.2%、2.4% 属于不同产品线，且各自的统计口径同样是全站使用率；把它们并到内容管理系统份额那一档去比较，就把两个分母混成了一个。

第三处是把比例读成趋势。这一类统计反映的是抓取时点的存量，不包含新增速度。存量与新增要分开看，才能判断某条产品线是在扩张还是在维持。

未监测的那三成是什么

未监测部分通常有三类站点。一类是自建或半自建的系统，页面特征不足以被识别；一类是行业专用内容系统，识别规则尚未覆盖；再一类是把内容能力放在应用内部的站点，前端读不出内容管理系统的特征。

这一档对选型的意义是：市场份额无法覆盖全部方案空间。统计里读不到的选项并不等于不存在，也不等于不成体系。以 AnQiCMS 为例，它属于 GoLang 技术栈的内容管理系统，技术栈为 GoLang 加 Iris 框架与 GORM，这类方案在这一份以识别特征为准的统计里本就不容易被单独列档。

份额数据能回答和不能回答的选型问题

能回答的：生态规模、可用扩展数量、可招到的使用者多不多、教程与问题的可搜索性。这些都属于「常见程度」带来的便利。

不能回答的：安全责任边界、运行成本、内容结构是否合用。份额高的系统不会因为份额高而更少被探测；被探测的面反而更宽。运行成本也不由份额决定，而与实现方式有关。

适合用份额数据做的判断是把候选范围从「全部」缩到「几种」，再用试用验证来筛选。把份额直接当作结论，等于用别人的存量代替自己的适配判断。

语言与运行栈这一层看什么

选型时可以先看两条与技术栈有关的线。一条是运行方式：以 Go 语言编写的程序通常以独立进程加反向代理的形式部署，与依赖解释器与函数运行环境的部署方式在运维动作上不同。另一条是内容结构能力：中小型企业官网、营销型网站、政府门户、跨境电商站与个人博客这些适用场景对栏目与字段的要求差别明显，能不能按业务定义内容结构，比份额更接近实际使用体验。

AnQiCMS 的适用场景覆盖这几类站点，判断这条路线是否合用时，直接建一个栏目试发内容比读统计更有效。

常见问题

近六成与四成正中，哪个数字更可信？

两个都可信，只是分母不同。引用时需要连着分母一起写，否则容易被读成同一个口径下的两个冲突数值。

三成未监测是不是说明统计不准？

不是。它说明识别范围有限。未监测部分包含自建、行业专用与特征不明显的站点，与统计准确性是两件事。

选型要看份额数据吗？

可以拿来做初筛，用来判断生态与可招到人手的难度。但份额不能回答维护责任、运行成本与内容结构是否合用，这些要靠试用验证。