WordPress

WordPress Custom Post Types + custom taxonomies give solid modeling breadth, and Advanced Custom Fields (the near-universal build-time add-on) extends this to 30+ field types including repeater, flexible content, gallery, clone, and relationship fields. Schema is defined in PHP (register_post_type / register_field_group), which counts as schema-as-code but is imperative, not declarative or portable, and there are no native union/polymorphic types. Score holds at 65 — strong for a traditional CMS but below Drupal's Entity/Field API and purpose-built headless platforms.

ACF relationship and post-object fields enable cross-post-type references but are unidirectional by default — reverse lookups require a custom WP_Query or a WPGraphQL connection resolver. WPGraphQL auto-generates connections for registered CPTs which partially exposes traversal, but bidirectionality is never native or automatic and there is no graph model. Score holds at 55, matching the VIP sibling since this is a core+ecosystem trait.

Gutenberg's block system provides genuine component-based composition with nested blocks, reusable patterns, and block bindings, and ACF flexible content offers a parallel structured track. However, block content is serialized as HTML comment delimiters inside wp_posts.post_content rather than a portable JSON/AST, which caps portability below true structured-content platforms. Scored 62 (two below VIP's 64, which credits VIP-only Remote Data Blocks that self-hosted core does not ship).

Core WordPress offers sanitization functions rather than a validation model; ACF adds per-field validation (required, character min/max, numeric range, regex via the acf/validate_value filter) but each rule is developer-coded per field. There is no cross-field validation engine, no UI-configurable rule builder, and no schema-level uniqueness constraint. Score holds at 50 — functional but developer-dependent.

WordPress has mature native revision history stored as child posts with configurable depth, one-click rollback, and — new in WordPress 7.0 (May 2026) — Visual Revisions, which upgrades the diff experience beyond the old text-only comparison. Scheduled publishing is reliable and native. There is still no content branching/forking and no first-class programmatic snapshot API beyond WP_Post revisions. Score holds at 72.

The Gutenberg block editor provides genuine drag-and-drop visual composition with inline text editing and live block previews, and Full Site Editing extends layout control to templates and site-wide parts without developer involvement. Editing happens in the wp-admin canvas rather than on the live front-end URL, and FSE requires a block theme, so it is not true in-context page editing. Score 76 — same core capability as the VIP sibling.

Gutenberg rich text is extensible via custom block types, the RichText component, custom formats (registerFormatType), and 30+ oEmbed providers, with reasonable paste-cleanup from external sources. Output remains serialized HTML within block-comment delimiters rather than a portable AST like Portable Text, which is the rubric line for 75+. Score holds at 72.

Core WordPress now generates next-gen formats natively — WebP since 6.1 and AVIF upload/thumbnail support since 6.5/6.6 — and the media library handles upload, basic editing, and search. But self-hosted core has no on-the-fly URL-based transform service, no edge image CDN, no focal-point cropping, and no native folder organization (all plugin-dependent). Scored 56 — below VIP's 62, which credits the VIP File System edge image service that self-hosted operators do not get.

Real-time Google-Docs-style co-editing was planned for WordPress 7.0 but was removed before release over stability and performance concerns; it remains deferred to a future release. Core does ship async collaboration — the Notes feature (block-level threaded comments) landed in 7.0, and post-level edit locking warns when another user has a post open. So self-hosted core has async annotation and lock detection but no live co-editing. Scored 50 — well below VIP's 78 (VIP shipped GA real-time collaborative editing ahead of core).

Core WordPress ships only four post statuses (draft, pending review, scheduled, published) with no configurable stages. Editorial workflow depth comes from community plugins — PublishPress (custom statuses, editorial calendar, notifications) is the mainstream choice on self-hosted builds. There is no first-party VIP Workflow plugin here, no visual workflow builder, and no conditional routing or per-stage role enforcement at the platform level. Scored 52 — below VIP's 58.

The built-in WordPress REST API covers all content types with CRUD, filtering, and offset pagination (10 default / 100 hard cap per request), and WPGraphQL — the standard headless add-on — layers full GraphQL with Relay cursor pagination, robust filtering/sorting, and auto-generated schema for CPTs, taxonomies, and ACF fields. REST+GraphQL dual coverage lands in the rubric's strong band. Held at 72 (below VIP's 74): there is no delivery-vs-management API separation and GraphQL requires a plugin.

Self-hosted WordPress ships no CDN or edge layer — delivery performance is entirely the operator's responsibility. That said, the CDN-integration ecosystem is the most mature of any CMS: Cloudflare APO gives full-page HTML edge caching, and plugins like WP Rocket, W3 Total Cache, FlyingPress, and Super Page Cache add origin caching and Cloudflare cache-rule integration. Because nothing is platform-provided and there is no publish-triggered edge purge out of the box, it scores 46 — aligned with the Drupal self-hosted sibling and far below VIP's managed 82.

WordPress's internal action/filter system is unmatched in breadth (1000+ hook points), but that is in-process PHP extensibility, not an external event service. Outbound webhooks require plugins — WP Webhooks for generic events, WPGraphQL Smart Cache for purge events — and there is no managed event bus with event filtering, HMAC signing, retry, or delivery logs. Scored 55 — slightly below VIP's 62, which adds first-party VIP Workflow webhook notifications.

Decoupled WordPress via REST + WPGraphQL is a well-established pattern feeding Next.js/React/Vue front ends, but the content model is fundamentally web-first: blocks serialize to HTML and headless preview requires integration work. There are no official mobile SDKs and no format-agnostic AST output, and the Faust.js headless framework has seen reduced momentum. Scored 55 — same as the VIP sibling since the underlying architecture is shared.

Self-hosted WordPress has no native segmentation engine and none of VIP's edge Cache Personalization API. Rule-based segmentation comes only from plugins such as Logic Hop or If-So Dynamic Content (behavioral/geo/referrer rules), and any real CDP-grade segmentation is fully external. Scored 25 — below VIP's 30 since core ships nothing and the plugin options are lightweight, rule-only tools.

Serving different content per audience is possible via plugins (If-So, Logic Hop, WooCommerce dynamic content) but is entirely add-on-driven with no native variant authoring, no in-editor per-audience preview, and no decision engine. Self-hosted lacks VIP's Cache Personalization API and the VIP-for-Salesforce Data Cloud path. Scored 25, matching 2.1.1 and just below VIP's 28.

No bundled Parse.ly Headline Testing here — but the self-hosted ecosystem has genuine experimentation plugins: Nelio A/B Testing (page/post/headline/WooCommerce split tests with heatmaps and Bayesian significance) and FunnelKit for funnel/checkout tests. Real built-in-feeling experimentation with reporting, though it is a (largely paid) plugin add-on scoped narrower than a first-class platform feature. Scored 40, below VIP's 45.

Without VIP's bundled Parse.ly Content API recommendations, self-hosted relies on related-content plugins (YARPP, Contextual Related Posts, Jetpack Related Posts) and WooCommerce's related/up-sell/cross-sell products. These are similarity- and rule-based rather than a configurable ML recommendation engine with collaborative filtering. Scored 35, below VIP's 50.

Core WordPress search is a weak MySQL LIKE query with no relevance ranking, but no professional build ships bare — Relevanssi (free tier) adds relevance ranking, fuzzy/partial matching, and weighting, and SearchWP/ElasticPress (self-run Elasticsearch) add faceting and typo tolerance. Solid full-text with relevance once a plugin is added, but there is no managed Elasticsearch like VIP Enterprise Search. Scored 50, well below VIP's 70.

Integration paths to external search are mature and shared with the whole ecosystem: an official Algolia WordPress plugin, ElasticPress for self-managed Elasticsearch/OpenSearch, and SearchWP connectors, all wired through WordPress's hook/filter system for index sync. The operator must run the search infrastructure themselves (no managed cluster), which is the only gap versus VIP's 72. Scored 68.

WooCommerce is a free open-source plugin and self-hosted WordPress is its canonical home — full product catalog, cart, checkout, orders, tax, shipping, payments, and the largest commerce extension ecosystem of any CMS. Not a headless commerce engine, but a comprehensive genuine commerce solution. Scored 75, identical to VIP since this is a pure core+ecosystem capability.

Beyond WooCommerce, connectors to external commerce engines exist as plugins — BigCommerce for WordPress, Shopify buy-button/embed plugins, Ecwid — but these are product-display/embed connectors, not deep bidirectional sync against commercetools, Salesforce Commerce Cloud, or the Shopify Storefront API. Same plugin set as VIP without VIP's documented compatibility packaging. Scored 48, marginally below VIP's 50.

WooCommerce supports simple/variable/grouped/external product types with attributes, variations, categories, tags, galleries, SKUs, and rich descriptions, and ACF can extend product fields. It is not a purpose-built PIM — no advanced attribute governance, no asset-per-variant, limited structured product modeling, and product media inherits the Media Library's organization limits. Scored 60, identical to VIP.

Self-hosted has no bundled Parse.ly content analytics. Content-performance dashboards come from plugins — MonsterInsights and Google Site Kit surface GA4 data inside wp-admin, Jetpack Stats and Independent Analytics give pageviews and top content, and WooCommerce Analytics reports on sales. Functional engagement metrics but no enterprise content-intelligence layer or content-lifecycle/health dashboards. Scored 40, below VIP's 55.

WordPress integrates cleanly with every major analytics platform: Google Site Kit is the official GA4/Search Console plugin, Segment and Amplitude have plugins or drop-in snippets, and the open theme/hook system lets any tag or tag-manager container be placed without restriction. The platform never hinders analytics implementation. Scored 72, just below VIP's 75 (which pre-configures Parse.ly).

WordPress Multisite is a mature core feature: many sites from one install with shared users, themes, and plugins, and a Network Admin for centralized governance and per-site autonomy. Self-hosted lacks VIP's managed multisite orchestration and shared brand-asset tooling, and cross-site content syndication still needs plugins. Scored 68, below VIP's 78.

Core i18n is gettext UI-string translation only; content localization requires WPML or Polylang, both document-level (a translated copy per post) rather than field-level, with plugin-configured fallback chains, language switchers, and hreflang output. Functional and widely deployed but less elegant than native field-level localization. Scored 55, identical to VIP (shared ecosystem trait).

WPML ships TMS connectors (Smartling and other professional services) and machine-translation options; Polylang offers fewer TMS hooks. Workflow is largely export/import (XLIFF) rather than seamless in-platform translation management, and there is no native translation memory. Same plugin capabilities as VIP. Scored 55.

Multisite gives brand-level separation with shared infrastructure and network-enforced plugins/themes, but self-hosted has none of VIP's documented multi-brand governance tooling (customizable autonomy levels, shared brand assets/blocks). No native cross-brand approval workflows or brand-level analytics aggregation. Scored 55, below VIP's 65.

The WordPress Media Library is basic file storage — flat by default, folder organization only via plugins (FileBird, Real Media Library), simple metadata fields, and no asset versioning, rights/expiry management, or usage tracking across content. Enterprise DAM requires an external service (Cloudinary/Bynder plugins). Scored 33, roughly matching VIP's 35 (self-hosted lacks even VIP's certified Cloudinary packaging).

Self-hosted ships no VIP File System edge image service. Core now generates WebP and AVIF, and Jetpack Site Accelerator (free Photon CDN) plus plugins add basic image resizing/CDN delivery, but there is no built-in on-the-fly URL transform pipeline, no focal-point cropping, and serious optimization means external Cloudinary/Imgix/bunny.net. Scored 42, well below VIP's 68 (managed CDN image transforms).

No native video hosting, transcoding, or adaptive-bitrate streaming. Video is handled via YouTube/Vimeo oEmbed or external platforms (Mux, Cloudinary, Presto Player for playback UX); captions, thumbnail generation, and ABR all depend on the external service. Identical to VIP's 25 — a pure core gap.

Self-hosted combines the core Gutenberg block editor + Full Site Editing (block patterns, Global Styles, template/part editing) with an unrestricted page-builder ecosystem — Elementor (free tier, true drag-and-drop with live preview and a component library), Bricks, Beaver Builder, and Spectra. This is among the strongest no-code visual editing experiences in the dataset; it lacks VIP's Remote Data Blocks but gains full builder freedom. Scored 70, slightly above VIP's 65.

Core ships only four post statuses with no configurable stages, and self-hosted has no first-party VIP Workflow plugin. Workflow depth comes from PublishPress Planner (custom statuses, notifications, editorial comments) or Oasis Workflow. No visual workflow builder, conditional routing, SLA/due dates, or platform-level per-stage role enforcement. Scored 52, below VIP's 58.

Native scheduled publishing is reliable and timezone-aware; calendar views and auto-expiry come from plugins (PublishPress Planner editorial calendar, PublishPress Future for scheduled unpublish/embargo). No native release bundles for atomic multi-item publishing. Same ecosystem as VIP. Scored 55, roughly matching VIP's 58.

Real-time Google-Docs-style co-editing was planned for WordPress 7.0 (May 2026) but pulled before release over stability/performance concerns; it remains deferred. Core ships async collaboration instead: the Notes feature (block-level threaded comments) in 7.0 and post-level edit locking. So self-hosted has annotation and lock detection but no live co-editing — well below VIP's 70 (VIP shipped GA real-time collaboration in Jan 2026). Scored 50.

No native form builder, but the ecosystem is deep and shared with VIP: Gravity Forms, WPForms, and Fluent Forms deliver conditional logic, multi-step forms, file uploads, submission storage, spam protection, CRM/webhook integrations, and payment gateways; free tiers cover basic needs. Strong plugin-delivered form capability. Scored 65, identical to VIP.

Beyond the ESP connectors VIP has (MC4WP for Mailchimp, MailPoet), self-hosted can run FluentCRM — a self-hosted email marketing and CRM plugin with list management, campaigns, and sequences sent from your own server/SMTP. That native-feeling send capability plus broad ESP plugins (Klaviyo, Brevo, ConvertKit) is slightly stronger than a managed platform's connector-only story. Scored 60, marginally above VIP's 58.

Self-hosted actually beats VIP here: FluentCRM and FunnelKit Automations provide genuine WordPress-native automation — tag-based segmentation, drip/nurture sequences, behavioral triggers from WooCommerce and form events, and basic lead scoring — all running in-platform rather than requiring an external HubSpot/Marketo. Not enterprise-grade multichannel orchestration, but real automation. Scored 40, above VIP's 28.

No first-party CDP and none of VIP's VIP-for-Salesforce Data Cloud integration. Segment/mParticle/Tealium require a custom snippet or plugin, and FluentCRM is a lightweight CRM rather than an identity-resolving CDP. No unified profiles surfaced in the CMS or real-time identity resolution. Scored 28, below VIP's 35.

The WordPress.org plugin repository holds ~61,000 free plugins, with the broader commercial ecosystem exceeding 90,000 — by far the largest CMS integration ecosystem, spanning every category with strong first-party options (WooCommerce, Jetpack, Akismet). Self-hosted lacks VIP's curation/security-hardening layer, so quality is variable and vetting is the operator's job. Scored 85, just below VIP's 88.

WordPress core has no outbound webhook service — its action/filter system is rich in-process PHP extensibility (1000+ hooks) but does not auto-fire HTTP webhooks. Outbound delivery requires plugins (WP Webhooks, Uncanny Automator), and there is no native webhook management UI, signed payloads, retry, or delivery logs; self-hosted also lacks VIP's Data Pipeline event streaming. Scored 48, below VIP's 50.

Decoupled WordPress via REST + WPGraphQL is well established, and WPGraphQL preview tokens authenticate draft requests for a headless frontend. But self-hosted has no managed staging/promotion environments (the operator builds them), no shareable universal preview links out of the box, and the Faust.js headless framework has lost momentum. Scored 45, below VIP's 62 (VIP Dashboard environments).

Core ships 5 predefined roles (6 with Multisite Super Admin); custom roles and granular capabilities come from Members or PublishPress Capabilities, and SSO/SAML requires plugins (miniOrange, WP SAML Auth). There is no native SCIM, no field-level permissions, and none of VIP's provided MFA/audit-log layer. WP 7.0's Abilities API improves API-consumer access granularity. Scored 48, below VIP's 58.

WordPress core ships a consistent REST API (namespaced /wp/v2/ endpoints, standard CRUD verbs, discovery via the index endpoint) documented on developer.wordpress.org, and WPGraphQL adds a well-designed auto-generated GraphQL schema now favored for headless builds. This is the same core API surface as WordPress VIP. Not higher because the API was retrofitted onto WordPress rather than purpose-built, and custom endpoint consistency varies across the plugin ecosystem.

Self-hosted ships no edge cache or CDN by default — API delivery latency depends entirely on the operator's caching stack (page cache, object cache, Varnish, reverse-proxy CDN), unlike VIP's global edge layer. WPGraphQL supports cursor-based pagination and query batching, and there are no hard vendor rate limits, but there is no built-in rate limiting or documented large-dataset sync pattern. Middle-band because performance is achievable but is the operator's responsibility, not a platform guarantee.

WordPress is PHP-native (the platform itself is effectively the PHP SDK) and @wordpress/api-fetch is the official JS client for the REST API. There are no official Python, Ruby, Go, Java, or .NET SDKs — community clients exist but are inconsistently maintained — and no TypeScript types are auto-generated from the content schema. A clear gap versus headless CMS platforms shipping 6+ official SDKs.

WordPress has the largest extension ecosystem of any CMS — ~61,000 free plugins on wordpress.org and >90,000 including commercial marketplaces — so connector coverage for analytics, commerce, DAM, translation, AI, and CDN is unmatched. Self-hosted gets unrestricted access to the whole ecosystem with none of VIP's curation gate. Not higher because quality and maintenance vary widely and vetting is entirely the operator's job.

WordPress's action/filter hook system is among the most battle-tested extensibility models in any CMS — 1,000+ hook points across content lifecycle, request handling, admin UI, and the API — with custom post types, taxonomies, fields, Gutenberg blocks, REST endpoints, and admin pages giving an enormous extension surface without core changes. WordPress 7.0 (May 2026) added the Abilities API, a Connectors hub, and PHP-only block registration. Genuinely best-in-class, and self-hosted has none of VIP's code-review friction.

SSO/SAML (miniOrange, WP SAML Auth), OIDC, and OAuth are all available via plugins with no plan gating, MFA comes from Wordfence or the Two-Factor plugin, and core ships application passwords (5.6+) for API auth. Scores above enterprise-gated SaaS because everything is open, but below VIP's managed SAML because SSO/MFA are fully plugin-dependent rather than turnkey, and there is no first-class API token scoping or service-account model.

WordPress's role/capability system (Administrator through Subscriber) supports programmatic custom roles and content-type-level scoping, extended by Members or PublishPress Capabilities. However, there are no field-level permissions and no content-instance access control without custom development, and no permission-inheritance model — markedly less granular than Drupal's node access grants. Adequate for editorial governance, not for complex multi-team field-level workflows.

Self-hosted open-source WordPress carries NO vendor compliance attestations — SOC 2, ISO 27001, and FedRAMP posture belong entirely to the chosen host (WP Engine, Kinsta, Pantheon and similar hold SOC 2), not to WordPress itself. GDPR tooling exists (core privacy/export/erase tools plus consent plugins) but is operator-assembled. Scored in the low band because certifications are not intrinsic to the platform, unlike VIP's FedRAMP/SOC 2 stack; full compliance detail is in cat9.

The WordPress core security team patches quickly and 2026 added proactive measures — the 'Protect the Shire' 24-hour auto-update cooldown and AI-assisted plugin/theme review — plus Wordfence and HackerOne disclosure channels. But the dominant reality for self-hosted is the unvetted plugin/theme surface: Wordfence logs 200–250 new plugin/theme vulnerabilities weekly, and 2026 saw critical plugin CVEs and a supply-chain RCE (Shapedsmart, CVE-2026-10735). The operator owns all patching with no VIP-style scanning gate, which holds this below mid-band.

Maximum deployment flexibility: self-host on any PHP/MySQL environment — shared, VPS, dedicated, container (official Docker images), on-premise, or any of dozens of managed WordPress hosts. Multi-cloud, hybrid, and full data-sovereignty deployments are all viable with no SaaS lock-in. The trade-off is that infrastructure decisions and operations are entirely the operator's responsibility, but the choice is unconstrained — the clearest area where self-hosted beats VIP's SaaS-only model.

There is no inherent vendor SLA — uptime is entirely a function of the hosting choice. Managed hosts publish SLAs (WP Engine and Kinsta advertise 99.9%+), but self-managed installs own their own uptime, and there is no central WordPress status page because there is no central WordPress service. Scores in the self-hosted band: well-managed sites achieve excellent uptime, but the platform provides no guarantee, unlike VIP's contractual enterprise SLA.

WordPress powers a large share of the web and is proven at very high traffic, with well-documented scaling patterns — object caching (Redis/Memcached), full-page cache, Varnish, database read replicas, load balancers, and CDN all supported. But none of this is built in: scaling requires operator expertise and infrastructure assembly, unlike VIP's managed edge/load-balanced pods. Solid architecture, self-managed execution.

Data portability is strong — standard MySQL dumps plus WXR export keep lock-in low — and scheduled backups are available via plugins (UpdraftPlus, BackWPup) or host tooling. But there is no native backup service, no documented RTO/RPO, and no built-in multi-region failover; backup frequency, retention, and recovery are entirely the operator's or host's responsibility. Below VIP's hourly managed backups and Drupal's config-driven portability.

Excellent free local tooling: wp-env is the official Docker-based environment (now with an experimental WebAssembly Playground runtime that removes the Docker dependency), WordPress Studio is a free cross-platform desktop app/CLI from WordPress.com, and WP-CLI provides deep command-line management, alongside LocalWP and DDEV. Multiple mature, production-parity local options with no licensing cost.

Code (themes/plugins) deploys cleanly through Git and WP-CLI automates migrations, cache, and content operations in pipelines. But WordPress has no built-in configuration-management-as-code system like Drupal's CMI — site config and content live in the database, so environment promotion and schema/config migration require custom tooling or plugins (WP Migrate, WP-CLI scripts). Environments are operator-built with no native branch-per-PR content model.

developer.wordpress.org is one of the most extensive CMS documentation sets — REST API handbook, Block Editor handbook, code reference, and framework-agnostic guides — and the WordPress.org support docs are vast. Coverage is comprehensive though quality is uneven across older material, and there is no interactive API playground, which keeps it below the best headless-CMS doc experiences.

WordPress is a PHP platform and TypeScript remains an afterthought: no auto-generated types from the content model. The best path for typed frontends is WPGraphQL + graphql-codegen, which works but requires manual setup; @wordpress packages ship TypeScript definitions for block-editor development only (with a React 19 upgrade progressing). No type generation from the CMS itself.

WordPress core is back on a predictable three-major-releases-per-year cadence: 7.0 'Armstrong' shipped May 20, 2026 (native AI infrastructure — WP AI Client, Abilities API, redesigned admin), 7.0.1 maintenance on July 9 (31 bug fixes, PHP 8.5 compat), 7.1 Beta 1 on July 15 with 7.1 GA scheduled Aug 19, 2026, and 7.2 targeted December. This is core software available to every self-hosted install for free. Not higher because real-time collaboration slipped from 7.0 to a later cycle and the 7.0 GA itself slid from its original April 9 target.

Every major release ships a comprehensive Field Guide on make.wordpress.org with per-feature dev notes, plus per-version release posts and Codex/HelpHub upgrade documentation; the 7.0 Field Guide (May 2026) documented the PHP support baseline and migration guidance. Structured version history is available in the plugin/theme handbook and Trac. Not higher because the canonical changelog is spread across release blog posts, Field Guides, and Trac rather than a single structured per-release breaking-change feed like commercial SaaS vendors provide.

WordPress development is unusually transparent: the Gutenberg four-phase roadmap (now in Phase 3 — collaboration) is public, release schedules with dates are published on make.wordpress.org, and all planning happens in the open across Make WordPress team blogs, Slack, and Trac. Anyone can follow or contribute to direction. Not higher because the public roadmap is narrative/phase-based rather than a voted feature portal, and priorities are heavily steered by Automattic rather than a neutral governance body.

Backward compatibility is a foundational WordPress value and remains a genuine self-hosted strength: core preserves plugin/theme compatibility across major versions, minimum PHP moves only after years of notice, and the buggy real-time collaboration feature was pulled from 7.0 rather than shipped broken. The trade-off is that this BC discipline slows deprecation cleanup, but for operators it means upgrades rarely break existing sites at the core level (plugin conflicts, scored elsewhere, are the real risk).

WordPress has the largest community of any CMS by an order of magnitude — powering ~41.5% of all websites and ~59% of CMS-detected sites (July 2026, W3Techs), with the nearest rival near 5%. The wordpress.org plugin repository hosts 60,000+ free plugins (90,000+ including premium), and Stack Overflow question volume, @wordpress npm downloads, and hundreds of annual WordCamps are all unmatched. The recent market-share dip is a momentum signal (4.3.2), not a community-size change.

The 7.0 cycle showed strong, active participation — public Field Guide, dev notes, WordCamp Europe 2026 (Kraków) and WordCamp US 2026 (Phoenix, Aug) Contributor Days, and busy Make WordPress Slack channels and support forums. Third-party community documentation (Gutenberg Times 'Source of Truth') stays current. Held below the community-size score because ongoing governance tension around Automattic's control and its recalibrated 'Five for the Future' sponsored contributions has created contributor friction, even though it has not measurably disrupted the release cadence.

The delivery ecosystem is effectively unlimited: tens of thousands of agencies and freelancers worldwide build on WordPress, and major SIs (Accenture, Deloitte, Valtech) maintain WordPress practices, so buyers can always find help at any price point. Held below the very top because self-hosted open-source WordPress has no single formal certified-partner program or exam credential the way enterprise DXPs (or WordPress VIP) do — partner quality varies widely and vetting is left to the buyer.

WordPress third-party content is the deepest of any CMS and the 7.0 release generated a large fresh wave of upgrade guides, feature breakdowns, and video coverage from raidboxes, InMotion, Gutenberg Times, and dozens of hosts and educators within weeks. Countless Udemy/YouTube courses, books, and blogs cover every skill level. No plausible scenario where a self-hosted operator lacks learning material.

WordPress is the most abundant CMS talent pool in the market — the most-requested CMS skill in web-development job postings, with the largest freelancer availability across every hiring platform and price tier. Demand remains robust into 2026 for custom theme/plugin work, headless builds, and increasingly AI integration. Hiring risk is essentially nil.

WordPress market share has now declined roughly six consecutive months — 43.2% (Dec 2025) to ~41.5% (July 2026) per W3Techs — the first sustained erosion in a decade, with share ceding to no-CMS architectures (static generators, frontend frameworks, AI-built sites) and to Shopify/Wix at the small-business end. WordPress 7.0's native AI foundations give it a forward narrative, but for self-hosted specifically there is no enterprise-segment offset (unlike VIP's government/FedRAMP wins), so the macro decline dominates the score.

As open-source, WordPress cannot 'run out of funding' and is backed by the WordPress Foundation plus a broad contributor base, so its survival is not in question. But its development velocity is heavily dependent on Automattic, whose signals are negative: a 16% layoff (281 people) in April 2025, a BlackRock valuation markdown, the unresolved WP Engine litigation, and a publicly recalibrated reduction in sponsored 'Five for the Future' contribution hours. That dependency and the governance drama are real stability concerns even though the project keeps shipping on schedule.

WordPress remains the default open-source CMS with unmatched flexibility, ecosystem, and now credible native-AI positioning (7.0 AI Client / Abilities API) against both headless rivals and page builders. Offsetting this: the first decade-long market-share reversal is drawing 'cracks in the empire' press framing, the Automattic/WP Engine governance conflict is actively exploited by competitors in evaluations, and self-hosted WordPress carries no enterprise moat (no FedRAMP/attestations) to defend the upper market. Clear identity, but contested and slipping at the margins.

Self-hosted WordPress.org sentiment on G2 stays solidly positive (high-4 rating across thousands of reviews), praised for flexibility, customization, control over data, and ecosystem breadth. The consistent negative themes are operator burden — maintenance, the update treadmill, and plugin/security overhead can degrade performance if unmanaged — and ecosystem distrust stemming from the Automattic/WP Engine governance fight. Strong product love tempered by real operational and governance complaints.

Self-hosted WordPress core is free and open-source under GPLv2+ with zero licensing fee and no sales gate whatsoever — the entire cost stack (hosting + premium plugins) is publicly published by third parties. Every real cost input can be priced from public pages before a buyer talks to anyone. Not 100 only because the true budget assembles from many separate published sources (host, plugins, labor) rather than one canonical price sheet.

There is no vendor license, so cost scales with infrastructure and team rather than content volume, API calls, or user seats — no metering, no bandwidth overages, no per-editor fees. Highly predictable at the core level. Held below 90 because a professional build stacks several per-site annual plugin subscriptions (ACF Pro, Yoast Premium, WPML, WooCommerce extensions) that recur and multiply across sites, adding a predictable-but-creeping recurring line.

WordPress core and the free plugin ecosystem gate nothing — SSO, custom roles, multilingual, SEO, and REST/GraphQL APIs are all reachable via free plugins. The realistic penalty versus Drupal is that several production-grade capabilities (advanced SEO analysis, professional multilingual, WooCommerce subscriptions/bookings, advanced security) practically require the PAID tier of a third-party plugin. That gating is vendor-by-vendor and legitimate, not WordPress locking its own features, so it stays high.

No vendor contract exists for the software itself — an operator can start, stop, switch hosts, or bring everything in-house at will, and premium plugin licenses are low-commitment annual subscriptions cancellable without penalty (lapsing only stops updates, not usage). Nonprofit/education programs and free hosting tiers are widely available across the host ecosystem. Just short of Drupal because plugin renewals are the only recurring commitment, minor as it is.

The free tier is effectively the entire product: full-featured WordPress core under GPL with no usage caps, no entry limits, and permissive commercial use, runnable on a $5/mo shared host or free local install. This is a permanent, permissive, fully capable free entry point — the top of the rubric band. Not higher only because a genuinely professional deployment eventually layers in paid hosting and a few premium plugins.

WordPress is the benchmark for fast onboarding — the famous 5-minute install and one-click provisioning on essentially every host put a working, publishable site up in well under an hour, with Gutenberg and a vast free theme library producing content immediately. Faster on-ramp than Drupal and most DXPs. Held below the 75+ band because a production-grade themed build still needs plugin selection and configuration beyond the instant install.

Community signals put a simple marketing site at roughly 2-4 weeks and a mid-complexity business/WooCommerce build at weeks-to-a-few-months, accelerated by mature themes, page builders, and prebuilt plugins — generally quicker than Drupal for equivalent scope. The penalty is that plugin selection, conflict testing on staging, and custom theme work drag out larger builds, and quality varies widely with the assembled plugin stack.

WordPress has the largest and most liquid talent pool of any CMS, built on mainstream PHP/JavaScript skills — effectively zero specialist premium and easy sourcing, with freelance/agency rates ($75-$200/hr) tracking general web-dev rather than a niche certification market. Among the lowest premiums in the dataset. Not higher because senior enterprise-grade WordPress engineers (performance, security-hardened, headless) still command a modest premium over commodity generalists.

Self-hosted WordPress requires the operator to pay for PHP+MySQL infrastructure, but it runs on the cheapest, most commoditized hosting market in existence — from ~$5-15/mo shared hosting to ~$30-35/mo managed WordPress. Cheaper and more commoditized than Drupal for equivalent sites. Sits mid-band per the self-hosted rubric because real production traffic, CDN, and managed-host tiers scale into hundreds to thousands per month.

The operator owns the full burden: core and plugin patching, the well-documented plugin-conflict surface, backups, and security monitoring against WordPress's status as the web's most-attacked target. Core/plugin auto-updates and mature managed hosts soften the load versus Drupal, but the update treadmill and conflict testing remain a real, ongoing cost. Mid-low band — needs regular attention or a paid maintenance plan, not zero-ops.

Very low lock-in: content lives in a standard MySQL database with a documented schema, core ships a built-in WXR export, and migration tooling between hosts and platforms is abundant. Standard formats and no vendor gatekeeper make leaving cheap. Held below Drupal's 90 because heavy reliance on proprietary page-builder shortcodes (Elementor, Divi) and plugin-specific data structures can create real content-portability friction on complex builds.

The WordPress mental model (posts, pages, taxonomies, custom post types, hooks/filters, themes, plugins) is the single most widely understood CMS paradigm in web development, and self-hosted core has no managed-platform layer (no VIP dashboard, environments, or mu-plugins conventions) to re-learn. Gutenberg blocks and the WP 7.0 Block Bindings API add a newer but approachable paradigm. Not higher because the hook/filter lifecycle and template hierarchy are still WordPress-specific abstractions rather than pure standard-web concepts.

Self-hosted WordPress sits on the largest free learning ecosystem of any CMS — WordPress.org Learn, the Developer/Block Editor handbooks, WordPress Playground (zero-install in-browser), plus a vast third-party corpus of courses, tutorials, and WordCamp recordings — and the '5-minute install' remains the lowest barrier to a running instance. Not higher than VIP's 88 because there is no vendor-run structured enterprise onboarding path or in-console guided tour; the developer must self-assemble the learning journey from community resources.

Core development remains PHP on the WordPress template hierarchy — a proprietary-pattern paradigm not aligned with mainstream React/Next.js preferences — though PHP/WordPress skills are the most abundant in the labor market. WP 7.0's PHP-only block registration removes the JS/React build pipeline for simple server-side blocks, narrowing the gap slightly, and Gutenberg uses React internally. Not lower because standard REST and WPGraphQL APIs exist for decoupled use; not higher because the CMS layer itself is a WordPress-specific PHP paradigm.

The traditional path has strong scaffolding: the official @wordpress/create-block tool generates block plugins, the annual Twenty-series default themes and Underscores/block themes provide clean starting points, and Roots/Sage offers a modern build. The headless story is community-only — Next.js starters like gregrickaby/nextjs-wordpress and WP Engine's Faust.js (which saw reduced development in 2026) rather than a vendor-maintained starter with example content and deploy config. Not lower because official core scaffolding for the primary (monolithic) path is solid; not higher because no vendor Next.js/Nuxt starter matches headless-CMS vendors.

The base install is famously minimal (wp-config.php needs only DB credentials and salts, and the 5-minute install works with sensible defaults), and self-hosted has none of VIP's platform-specific config constraints (mu-plugins structure, npm-only, dependency-placement rules). However, a professional build's config surface is broad and fragmented across wp-config, theme settings, dozens of per-plugin admin UIs, and database-stored options that are hard to version-control. Not higher because most configuration lives in the database rather than in code, complicating multi-environment management.

Adding custom post types and ACF fields is straightforward and additive changes are safe, but the wp_postmeta key-value store is schema-flexible without enforcement, so data integrity depends entirely on code discipline, and there is no built-in migration tooling for schema changes on live content. Renaming or removing fields with existing content is risky and manual. Not higher because field evolution lacks tooling support; not lower because common additive modeling patterns (CPTs, taxonomies, ACF field groups) are well documented and low-risk.

For the typical monolithic self-hosted build, preview is fully built-in and one-click, and the Gutenberg block editor provides near-WYSIWYG in-editor visual editing with the Site Editor — effectively plug-and-play. For decoupled builds, draft preview requires Faust.js or a custom draft-routing implementation, and Faust.js's slowed development leaves headless preview a DIY burden. Not higher because the headless preview path requires custom middleware; not lower because the coupled path (the majority of self-hosted builds) needs zero setup.

No certification exists or is required, general PHP/web developers are productive immediately, and the WordPress skill set is the most abundant in the developer labor market. Self-hosted also removes VIP's specialization layer (platform coding standards, code-review gates, GitHub deploy workflow), so there is nothing platform-proprietary to learn beyond WordPress itself. Not higher because Gutenberg block development needs React knowledge and productive theme/plugin work still requires WordPress-specific hook/template expertise.

A solo full-stack PHP developer can build and ship a production self-hosted WordPress site, and small 1–3 person teams routinely do. Not higher than VIP's 78 because self-hosting reintroduces ops responsibilities — someone must own hosting, updates, security patching, and backups — so a maintenance/DevOps role is needed alongside the build even if it is part-time. Not lower because no solution-architect or large specialist team is required as with enterprise DXPs.

Post-launch, content teams self-serve extensively: the WordPress/Gutenberg authoring interface is familiar to the largest editor user base of any CMS, and marketers create pages, posts, and campaigns without developer involvement, with the WP 7.0 Block Bindings API and Site Editor further extending non-developer composition. Developer involvement is mainly needed for new block types or template changes. Not higher because heavily customized or decoupled builds reintroduce developer dependency for layout-level changes.

Core upgrades are the easiest in the CMS space: minor releases auto-apply by default and major upgrades are a one-click dashboard action, a mechanism proven since 2013. The recurring friction is plugin compatibility on major jumps — WordPress 6.9 (Dec 2, 2025) broke WooCommerce, Yoast SEO and Elementor on release day, and 7.0 (May 20, 2026, the biggest release in 8 years with real-time collaboration and new block/AI APIs) again required careful staging tests of page builders, ACF and checkout flows. Not higher because a major update still demands per-plugin testing that self-hosted operators own; not lower because the core update path itself is essentially frictionless.

Core security patching is excellent and largely hands-off — minor security releases (e.g. the 6.9.2–6.9.4 batch fixing 10 vulns including critical PclZip path traversal CVE-2026-3907 and getID3 XXE CVE-2026-3908, shipped in under 30 hours Mar 10–11, 2026) auto-apply within hours. But for self-hosted WordPress the dominant attack surface is plugins, and that burden is entirely the operator's: 2025 saw 11,334 new ecosystem vulnerabilities (+42% YoY), 91% originating in plugins, with a ~5-hour median from disclosure to mass exploitation and 46% unpatched at disclosure. Not lower because core auto-patching genuinely removes the core CVE burden; not higher because the plugin patch treadmill is the largest of any CMS and requires constant operator vigilance (and often a WAF for virtual patching).

As open-source self-hosted software, no vendor can force an upgrade on its own timeline, and WordPress's legendary backward-compatibility culture means deprecated APIs persist for years and old sites keep running — 7.0 raised minimums only modestly and preserved classic workflows behind the block editor. Release cadence is predictable (6.9 Dec 2025, 7.0 May 2026, 7.1 Beta Jul 15, 2026). Not higher because running behind is a real security liability given the plugin-exploitation reality, so 'staying put' is not cost-free; not lower because forced, breaking migrations on a vendor clock simply do not occur here.

The core runtime stack is the simplest and most ubiquitous in the category — a conventional LAMP/LEMP setup (PHP 8.x, MySQL/MariaDB, web server) that is trivially understood and hosted everywhere. The weakness is the plugin dependency graph: plugins are installed ad hoc through the admin with no lockfile by default, each carries its own update cycle and transitive risk, and the 91%-of-vulns-from-plugins reality makes that graph a live liability operators must track manually. Not lower because the base runtime is dead-simple versus Drupal's Symfony/Composer trees; not higher because there is no first-class, lockfile-based dependency governance in core.

Core ships the Site Health screen (status checks and recommendations for PHP version, updates, and configuration), which is slightly more than Drupal or Joomla offer in-core, but there is no built-in APM, uptime monitoring, alerting, or observability. Real production monitoring is DIY — external uptime services, New Relic/Datadog, or monitoring plugins configured entirely by the operator. Sits in the self-hosted 30-45 band, nudged to the top of it by Site Health.

Core has no automated orphan detection, broken-reference alerts, or content-expiry workflows — governance relies on editorial discipline. But the free plugin ecosystem covers most content hygiene better than any peer: Broken Link Checker, OrphanPages/WPLIA, Redirection, WP-Optimize and Yoast handle broken links, orphaned content, redirects and database cleanup, and Gutenberg gives a strong editorial UX. Not higher because these remain bolt-on plugins the operator must select and maintain with nothing automated in core; not lower because free-tier tooling genuinely closes most of the hygiene gap.

Performance is actively operator-managed: core has no built-in page cache, so consistent speed requires a caching plugin (WP Rocket, W3 Total Cache, LiteSpeed Cache), object caching (Redis/Memcached), CDN configuration, and database/query optimization. The mitigating factor is a mature, well-documented, largely one-click caching-plugin ecosystem plus commodity managed hosts that pre-tune the stack. Sits in the self-hosted 40-60 band — real ongoing effort, but tooling makes it tractable.

There is no first-party vendor support for open-source WordPress core — no SLA, no ticket queue from the project. Formal support is purchased from the enormous third-party market: commodity/managed hosts, thousands of agencies, and paid plugin/theme vendor support channels, all with quality tied to the specific contract. Matches the 40-60 band where good support requires a paid arrangement, landing at the low end because none of it comes from the platform itself and quality varies widely by provider.

WordPress has the largest and most active community support network of any CMS: the WordPress.org support forums, 200,000+ WordPress-tagged Stack Overflow questions, the Make WordPress Slack with direct core-team participation, and a dense global WordCamp circuit (WCEU Kraków June 2026, WCUS Phoenix Aug 2026). Sheer scale means most self-hosted questions already have answers and community responsiveness is high. Not higher only because forum answer quality is uneven and much circulating content lags the current major version.

Core velocity is strong: 7.0 (May 20, 2026), a 7.0.1 maintenance release fixing 31 bugs (Jul 9, 2026), and 7.1 Beta 1 (Jul 15, 2026), with security/minor fixes shipped and auto-applied within hours. The drag is the long tail — non-critical core issues can linger in Trac for years, and plugin bug-fix velocity depends entirely on individual (sometimes abandoned) maintainers with no SLA. Not higher because that community/plugin long tail lacks guaranteed timelines; not lower because critical core bugs and CVEs are turned around fast and transparently.

Self-hosted WordPress has unrestricted access to the entire drag-and-drop page-builder ecosystem — Elementor, Bricks, Beaver Builder, Divi — alongside the core Gutenberg block editor with Full Site Editing. Marketers can build and launch new landing-page layouts with no developer involvement, which is the platform's defining strength for marketing sites. This is arguably stronger than a governed managed environment because there are no approved-plugin constraints on which builder a team may install. Not above 75 because production-grade builds still typically involve a developer for theme structure and performance hygiene, and unconstrained builders can produce heavy, off-brand pages.

No native campaign management in core. Editorial calendaring and campaign coordination are assembled from plugins (PublishPress, CoSchedule, Nelio Content), and multi-channel campaign orchestration relies on external marketing tools connected via plugin. Campaign analytics require GA4/GTM integration rather than native tooling. Scores at the top of the 20–40 band because scheduled publishing plus plugin-based editorial calendaring are readily available and widely used.

WordPress + Yoast SEO or Rank Math is the best-in-class SEO stack in the CMS market: meta title/description management with validation, XML sitemaps, JSON-LD/Schema.org structured data, redirect management, canonical URLs, breadcrumbs, and real-time content optimization scoring. Clean permalinks and semantic HTML output are inherent. This is self-hosted WordPress's single strongest use-case differentiator and is identical in capability to any managed WordPress deployment since it lives entirely in the open-source plugin layer.

Form and lead-capture tooling is strong via Gravity Forms, WPForms, and Formidable — with CRM integration, conditional logic, and payment capture. CTA management is possible through blocks and popup plugins (OptinMonster, Popup Maker). Conversion tracking integrates via GTM/GA4 or plugins. However, the CTA/form/analytics pipeline is plugin-assembled rather than a single integrated performance-marketing engine, and landing-page optimization is not native. Sits mid-band: better than headless CMS (no native forms) but below purpose-built marketing platforms.

Self-hosted WordPress has no native personalization engine and no managed edge-cache personalization layer. Rule-based targeting is available via plugins (If-So Dynamic Content, Nelio Personalization, Logic Hop) and geo-targeting via GeoTargeting plugins, covering audience/geo/behavioral rules. These are developer-configured plugin add-ons without a marketer-facing segmentation UI or real-time behavioral engine, and caching complicates dynamic personalization on commodity hosting. Sits low-mid in the 40–60 band: basic rule-based targeting via third-party plugins only.

Native A/B testing depends on plugins: Nelio A/B Testing provides page, headline, CTA, and widget experiments with statistical tracking and automatic winner application directly in WP admin, and split-test plugins integrate with page builders. This is genuine tight integration, not just external tag injection. However, it is not a first-class platform capability — teams must install and operate a testing plugin, and there is no bundled headline-testing/experimentation service. Scores in the 40–60 tight-integration band, toward the lower end given the plugin dependency.

Gutenberg enables fast production: block patterns for template cloning, synced patterns (reusable blocks), inline editing with live preview, and bulk operations. WordPress 7.0 'Armstrong' (May 2026) added real-time collaborative editing (Google Docs-style) and a DataViews-based admin that further reduce editorial cycle time for teams. Brief-to-publish under an hour is realistic for structured content. Not above 70 because new layout types still require developer or page-builder setup and unconstrained builds can slow QA.

WordPress exposes content via the core REST API and WPGraphQL, enabling headless delivery to mobile apps, signage, and other channels — web-first with API-based distribution. Jetpack and social plugins add push-to-social, and newsletter plugins add email. However, structured content models with channel-specific renditions are not native; multi-channel delivery requires deliberate content architecture and custom frontends. Sits at the boundary of the 40–60 band: API delivery to multiple channels exists but is not a first-class authoring workflow.

Google Site Kit and MonsterInsights surface GA4 traffic and engagement dashboards directly inside wp-admin, giving in-CMS content performance visibility. However, self-hosted WordPress has no bundled first-party content-analytics product (no Parse.ly), so content decay, author performance, and referral intelligence require GA4 configuration or paid add-ons rather than a native dashboard. Adobe Analytics/Mixpanel integrate via tag injection. Sits mid-band: standard analytics available in-admin via plugin, but not a purpose-built native content-analytics layer.

theme.json provides style tokens (typography, color palettes, spacing) enforced across the block editor, and block patterns/templates can be locked to constrain layout changes. However, enforcement is soft — a determined editor can override block styles, page builders bypass theme.json entirely, and there is no component-library governance UI. Component-based consistency without hard enforcement, sitting mid-band.

Yoast SEO manages Open Graph and Twitter/X Card meta with preview and validation, and Jetpack Social (free on self-hosted with a connected account) enables push-to-social publishing to Facebook, X, LinkedIn, and Instagram directly from the editor. Core oEmbed supports social/UGC embeds. Just below 60: OG management plus real push-to-social exists, but social scheduling depth and social proof widgets are plugin-dependent.

The core media library provides upload, basic crop/resize, and (with plugins like FileBird or Media Library Folders) folder organization. WordPress 7.0 added client-side media processing, improving upload handling. DAM-grade capability — transforms, tagging, rights management, usage tracking — requires integration with Cloudinary, Bynder, or similar via plugin. The DAM story is integration-dependent; without it, teams get only a basic library. Scores mid-band: basic library plus a clear DAM integration path.

WPML and Polylang provide translation management, locale-specific content, and translator workflows, and per-locale scheduling and market variants are achievable. TranslatePress adds visual front-end translation. However, there are no native transcreation workflows or market-level campaign scheduling, and regional compliance (cookie consent, disclaimers) requires additional plugins (Complianz, CookieYes). Generic localization applied to marketing content via a multi-plugin stack.

The plugin ecosystem offers pre-built connectors across multiple MarTech categories — HubSpot, Salesforce, Marketo, Mailchimp, ActiveCampaign — plus webhook/automation bridges (WP Webhooks, Uncanny Automator, Zapier). Breadth of available connectors is a genuine strength. It scores below the top band because self-hosted WordPress has no curated/managed integrations marketplace and no native event-orchestration layer; each connector is independently installed and maintained by the operator.

WooCommerce is the canonical WordPress commerce engine (33.4% of the global ecommerce market by store count, 4.25M active stores in 2026), and self-hosted WordPress is its native home. It supports variable/grouped products, custom attributes, per-variation content, galleries, and rich descriptions; ACF and custom taxonomies extend product modeling substantially. Well-adapted product content, though not a purpose-built PIM — advanced attribute inheritance and complex relationship modeling need extensions or a separate PIM.

WooCommerce provides category management, cross-sells, upsells, coupons, sale pricing, and product spotlights via blocks — real but basic merchandising. Extensions add product recommendations and search merchandising (e.g., FiboSearch, Product Recommendations). Falls just below 60 because visual and search-result merchandising are not native to core WooCommerce and require paid extensions, and there is no rules-driven merchandising engine.

On self-hosted WordPress, WooCommerce is the commerce engine itself, so 'synergy' is native for the WooCommerce stack — deep content+commerce co-authoring in one system. Integration with external headless commerce (commercetools, Shopify Storefront, SFCC, BigCommerce) is available via plugins/connectors but is not deep API federation out of the box. Scores mid-band: excellent for the WooCommerce path, moderate for external commerce engines requiring custom or plugin integration.

Editorial commerce is a native WordPress strength: buying guides, lookbooks, and shop-the-look articles are a mature pattern, and WooCommerce blocks (product grids, single product, add-to-cart) can be embedded inline anywhere in the block editor, creating first-class shoppable content with purchase CTAs. The content+commerce blend in a single authoring surface is a genuine differentiator, warranting a solid 60+.

WooCommerce Blocks provide a block-based cart and checkout editor where operators can customize layout, add trust badges, and configure upsell/cross-sell notices without re-engineering commerce templates — genuine CMS control over transactional flows. This applies only to the WooCommerce stack; for external commerce engines there is no CMS injection into checkout. Above the baseline because WooCommerce block checkout is truly CMS-managed, below 60 because it is WooCommerce-specific.

WooCommerce order-confirmation pages and transactional emails are editable from wp-admin, and AutomateWoo adds event-driven post-purchase sequences (review requests, follow-ups, win-backs) and loyalty/referral flows tied to order events — going beyond static templates. Still not a fully CMS-managed post-purchase content layer; much depends on the AutomateWoo extension. Sits in the upper 30–50 band given the plugin-based but genuinely event-driven capability.

B2B plugins (B2BKing, Wholesale Suite, WooCommerce B2B) add customer-specific pricing display, quote-request flows, account-based catalog segmentation, and gated wholesale catalogs, layered on WordPress role/access control. Self-hosted can deploy any of these freely. Capability is real but plugin-assembled rather than native B2B content tooling. Sits in the 30–50 band, mid-range, reflecting mature plugin coverage without native features.

Commerce search is served by plugins: FiboSearch provides fast AJAX product search with suggestions, SearchWP and Relevanssi add relevance tuning and synonyms, and self-managed ElasticPress enables faceted, Elasticsearch-backed search blending content and products. Search landing pages are standard WordPress pages. Capability is solid but operator-assembled and, for Elasticsearch, self-hosted and self-maintained. Above baseline, below 55: real faceted content-product search via plugins without a managed search service.

WooCommerce natively supports time-scheduled sale pricing with start/end dates, coupon/promo-code management, and sale badges — genuine promotional tooling in the commerce layer. Countdown timer and sale-banner plugins add urgency, and block editor scheduling handles promotional banners. Just below 60 because channel-specific promotional targeting and orchestration are not native.

WordPress Multisite with WooCommerce enables multiple storefronts from one installation, with per-site editorial/legal content and region-specific tax/shipping/currency via extensions. Shared product content across storefronts requires syndication plugins or disciplined duplication rather than architectural enforcement. Self-hosted lacks the managed multisite orchestration of enterprise WordPress hosts, so operation is more hands-on. Scores mid-band: real multi-storefront from a single admin, with content sharing requiring discipline.

WooCommerce supports product image galleries, zoom, per-variation images, and video embeds; 360-degree viewer plugins add spin views, and Cloudinary integration adds transforms and CDN delivery. No native AR/3D model support or interactive hotspots. Functional standard product media without commerce-grade visual features natively — sits mid-band.

Self-hosted WordPress can freely deploy mature multi-vendor marketplace plugins — Dokan, WCFM Marketplace, WC Vendors — which add seller profiles, seller-contributed product content, commission handling, and basic review aggregation. Content moderation at scale remains largely custom. This unrestricted access to marketplace plugins is a modest self-hosted advantage over governed environments. Sits in the upper 25–45 band: real marketplace capability via plugins, not native tooling.

WPML WooCommerce Multilingual provides product description translation, locale-specific product content, and currency-aware content synced to locale via currency-switcher extensions. Regional regulatory content (EU labels, Prop 65) is manageable via custom product fields or blocks. Functional but plugin-assembled rather than native — generic localization applied to product content, sitting mid-band.

GA4 enhanced ecommerce (via Site Kit, GTM, or MonsterInsights eCommerce) provides content-to-conversion attribution for WooCommerce transactions, and WooCommerce Analytics gives built-in product/sales reporting. Bridging content engagement to revenue requires deliberate GA4 setup — there is no native content-to-revenue attribution linking page performance to sales. Sits in the 30–50 band: analytics integration with conversion data assembled across tools.

Core roles (admin, editor, author, contributor, subscriber) plus capability plugins (Members, PublishPress Capabilities) and membership plugins (MemberPress, Restrict Content Pro) enable department-level and content-instance access control. Private/password-protected posts and SSO plugins (SAML/OAuth) extend this. Dynamic audience-based content visibility (different content to different employee groups) still requires configuration or custom work. Fits the 40–60 band: RBAC plus membership-based restriction, below true audience-based visibility.

Taxonomies organize knowledge, revision history provides version control, and dedicated knowledge-base plugins (Heroic KB, BetterDocs, Echo KB) add article structure, categorization, and internal search — freely deployable on self-hosted. However, there are no native lifecycle features (scheduled review, expiry, archival workflows) and search quality depends on the search plugin chosen. Adequate content modeling with KB plugins, but no native knowledge lifecycle tooling — mid-band.

WordPress was not designed as an employee portal, but self-hosted deployments can freely install BuddyBoss/BuddyPress to add activity feeds, member profiles, notifications, and personalized dashboards — a fuller employee-experience layer than a bare CMS. Even so, building a production intranet still requires substantial theming and custom frontend work, and notifications/mobile consumption are limited. Scores at the top of the 20–35 headless band, slightly above, reflecting the unrestricted BuddyBoss option.

Company news and department announcements publish as posts with category/taxonomy targeting, and multisite subsites can cascade news from a central hub. However, there are no native read receipts, acknowledgment tracking, mandatory-read workflows, or audience segmentation for internal comms — these require custom development. Publishing-focused only, no engagement loop. Sits low in the 30–50 band.

No native employee directory or org chart. Directory plugins (WP User Directory, staff-list plugins) and BuddyBoss member profiles can build a basic staff listing, but org-chart visualization and HR-system integration (Workday, BambooHR) require custom development. Skills/expertise search is not native. Sits in the low-mid 25–45 band: buildable via plugins/content modeling with no HR integration.

Revision history provides basic version control and files attach to posts/pages; document-library plugins (Document Library Pro) add structured document listings. However, acknowledgment tracking, automated expiry reminders, policy approval workflows, and mandatory-read enforcement are not native and require significant plugin assembly or custom work. Sits at the floor of the 30–50 band: document publishing with revision history only.

Role-specific onboarding content can be created with access restrictions, and scheduled publishing plus LMS plugins can approximate progressive 30/60/90-day disclosure. However, there are no native structured onboarding journeys, HR-triggered new-hire portals, task checklists, or completion tracking without assembling an LMS/membership stack. Sits near the bottom of the 25–45 band.

Internal search is improved via plugins — SearchWP and Relevanssi add relevance tuning and faceting, and self-managed ElasticPress adds Elasticsearch-backed search over WordPress content. Search quality for WordPress content volumes is good, but there is no federation across SharePoint/Confluence/Drive, no AI relevance layer, and Elasticsearch must be self-hosted and maintained. Sits mid-band: adequate internal search via plugins, not federated or AI-powered.

The WordPress mobile app supports authoring and basic reading, and themes are responsive by default; PWA plugins add installable/offline-lite experiences. However, there is no purpose-built frontline app, no robust offline content mode, limited push notification support for content consumption, and no kiosk/shared-device mode natively. Responsive web access without a native frontline-worker app — mid 30–50 band.

Self-hosted WordPress has an unusually strong LMS plugin ecosystem — LearnDash, TutorLMS, LifterLMS, Sensei — offering course authoring, quizzes, drip content, completion tracking, and certificates, all freely deployable. This is a self-hosted advantage. However, there is no native LMS in core, no core SCORM/xAPI, and no pre-built integration with enterprise LMS (Cornerstone, Workday Learning). Sits mid 25–45 band: capable learning hosting via plugins, external LMS for enterprise tracking.

Core comments provide basic engagement, and self-hosted can freely deploy BuddyPress/BuddyBoss (activity feeds, groups, profiles) and bbPress (forums) for a social layer, plus poll/survey plugins. This is more attainable than in governed environments. Still, these are plugin-assembled and not enterprise-grade engagement/peer-recognition systems out of the box. Sits low-mid in the 30–50 band.

Slack/Teams notification plugins and automation tools (Uncanny Automator, Zapier) can push content events to workplace chat, and embed blocks can surface some external content. However, there is no native embedded content cards in Teams/Slack, no bot-driven content workflows, and no single-pane experience — integration is webhook/notification-level only. Sits at the floor of the 30–50 band, low end given self-hosted has no bundled notification service.

Revision history and post statuses (draft/published/private/trash) provide basic lifecycle control, and PublishPress Future adds scheduled status transitions/expiry. However, there are no native automated review dates, stale-content flagging, archival workflows, or ownership-based freshness accountability without plugin assembly. Sits near the bottom: basic revision/status control, no governance-grade lifecycle.

Content analytics come from GA4 (Site Kit/MonsterInsights) with no bundled first-party content-analytics product, and reporting is oriented to external web traffic rather than intranet adoption. Department-level breakdowns, failed-search analysis, engagement heatmaps, and adoption dashboards require custom segmentation and additional tools. Sits in the low-mid 25–45 band: basic page-view analytics, no intranet-specific adoption metrics.

WordPress Multisite provides site-level isolation with per-site table prefixes, per-site settings, and per-site roles; Network Admin governs cross-tenant administration. This is genuine silo-based isolation used widely for multi-brand networks. Limitations keep it below true multi-tenancy: themes/plugins are network-level (no per-site plugin versioning), user accounts are shared across the network, and a shared codebase means one compromise can affect all sites. Fits the 55–70 silo-isolation band.

Multisite enables shared themes with per-site customization, and block patterns plus synced patterns can be shared network-wide as a de facto component library. The standard enterprise pattern is a common parent theme consumed by all brand sites. However, there is no formal component-library or design-token management system — sharing works but relies on architectural discipline and code deployment. Sits near the top of the 40–60 federation band.

Super Admin enforces network-level plugin/theme availability, must-use plugins enforce global policies, and role plugins scope brand/section editor access — enabling a real editorial governance model (lead editors per brand, scoped shared teams). Self-hosted lacks the managed control-plane, code-review gates, and turnkey governance tooling of enterprise WordPress hosts; cross-brand approval hierarchies require custom workflow setup. Sits at the lower-mid of the band: organization-level management with limited native cross-brand enforcement.

Multisite shares one codebase, database infrastructure, and caching layer across all brands, so maintenance (one plugin update, not N) and development are amortized, and the GPL license is free — there is no per-site license fee, so adding brands mainly adds hosting/support cost rather than licensing. This is a genuine self-hosted economic advantage over per-site-licensed platforms, tempered by hosting scaling costs and operator labor. Sits mid-upper band: shared infrastructure with sub-linear licensing cost.

theme.json provides per-site style tokens (color, typography, spacing) and block themes support site-level style variations, while parent/child themes let each brand layer visual identity onto shared components. The documented enterprise pattern is a master design system in a parent theme with controlled per-site variations. Real per-brand theming atop shared components, though token propagation is code-deploy-driven rather than platform-managed. Sits just below the top band.

WPML/Polylang operate per-site within Multisite, so each brand can run its own translation workflow and translator assignments. Per-brand translation approvals are achievable via WPML. However, the brand × locale intersection — shared vs isolated translation policy, which locales each brand publishes — has no native governance and requires custom tooling. Sits at the bottom of the 30–50 band.

Analytics are per-site via GA4, with no bundled network-level content-analytics product (no Parse.ly), so portfolio-level aggregation across brands requires GA4 roll-up configuration or manual assembly. Per-brand metrics are available, but cross-brand executive comparison, velocity benchmarking, and freshness tracking are not native. Sits in the low-mid 25–45 band: per-brand analytics with manual aggregation.

Per-site roles let each brand run its own editorial team, and PublishPress can be configured per site for brand-specific approval chains and review stages. However, there is no native centrally-auditable per-brand workflow engine — configuration is done site-by-site via plugin rather than through a central governance UI. Sits mid 30–50 band: brand-specific workflow variants achievable, not centrally managed.

Network-wide block/synced patterns syndicate components, and syndication plugins cascade content (news, press releases) from a corporate/central site to child brand sites — a documented multisite pattern. However, controlled override points (corporate content with brand-level customization) are limited; syndicated content is largely copied or locked rather than governed with granular overrides. Sits mid 35–55 band.

Must-use plugins can enforce cookie-consent and GDPR tooling network-wide, and each brand can run its own consent plugin (Complianz, CookieYes). However, self-hosted WordPress carries no vendor compliance attestations and provides no native publishing guardrails that block non-compliant content; compliance is enforced at the plugin/theme level, and accessibility/data-residency depend entirely on the operator. Sits in the 25–45 band, mid-low: per-brand compliance settings without automated guardrails.

theme.json and block patterns act as a de facto shared design system, and the parent/child theme model enables a master system with per-site variations where parent-theme changes propagate network-wide. However, there is no formal design-system UI, no component versioning with rollback, and no token-propagation system beyond code deployment — updates are dev operations, not platform-managed. Sits mid 30–50 band.

Multisite Super Admin centrally manages users, plugins, themes, and policies across all brand sites, while per-site roles allow autonomous brand teams, and SSO plugins (SAML/OAuth) enable single sign-on across the network. Cross-brand contributor assignment is supported via network user management. Below the top band because delegation is coarser than purpose-built multi-brand platforms and SSO is plugin-dependent rather than native. Sits mid-upper band.

Custom post types and taxonomies can be registered at the network level (via must-use plugin) so shared types are available to all brands, and ACF extends fields per site. However, there is no inheritance model where a brand extends a base content type without forking — per-site customizations are independent configurations that diverge from the base. Sits mid 30–50 band: shared types with limited non-forking extension.

With no bundled network content-analytics product, portfolio reporting relies on GA4 roll-ups and manual assembly across sites. Per-brand breakdowns are available, but executive dashboards with content freshness by brand, publishing-SLA adherence, cost allocation per tenant, and capacity planning are not native and require custom dashboard construction. Sits in the low-mid 25–45 band: basic per-brand reporting with manual aggregation.

WordPress ships privacy tooling in core (since 4.9.6, present in the 6.x/7.x line): Tools → Export/Erase Personal Data with an email-verified request workflow, a Settings → Privacy policy generator with an Editing Helper that aggregates disclosures from core and participating plugins, and wp_privacy_personal_data_exporters/erasers hooks so plugins register their own data handlers. Consent/cookie banners come from mature free plugins (Complianz, CookieYes). It scores slightly above the self-hosted baseline because these tools are in core rather than contributed, but no DPA is available — WordPress.org is not the data processor — so all GDPR obligations fall to the operator, capping it in the mid band per the 'no DPA' rule.

WordPress.org signs no BAA and offers no HIPAA-specific features in core; the software itself is not HIPAA compliant. It is routinely deployed in HIPAA-compliant environments via hosts that will sign a BAA — Liquid Web/Nexcess offers HIPAA-compliant WordPress hosting with a BAA — while mainstream managed hosts (WP Engine, Kinsta) explicitly do not sign BAAs. PHI handling depends entirely on hosting and custom implementation, so the software-level score sits at the top of the no-coverage band, matching the Drupal analog.

No FedRAMP authorization exists for standard self-hosted WordPress (WordPress VIP's FedRAMP Moderate belongs to the separate managed platform and is not inherited), and core ships no native CCPA/LGPD/PIPEDA tooling beyond the general GDPR privacy tools. Regional coverage relies on third-party plugins (e.g. Complianz handles CCPA/LGPD), and PCI-DSS is a host/integration concern. Score reflects near-absence of regional regulatory capability in core.

SOC 2 Type II is a service-organization attestation and does not apply to open-source software — WordPress.org holds no SOC 2 report and cannot. Operators obtain SOC 2 coverage from their managed host: WP Engine, Kinsta, and Pantheon (Gold) all hold SOC 2 Type II. The strong managed-hosting ecosystem is why this lands at the same level as Drupal rather than lower like Joomla.

ISO 27001 is an organizational ISMS certification that does not apply to the WordPress software or the WordPress.org project, which is not certified. WordPress has a structured core security team, coordinated vulnerability disclosure, and automatic background updates for security releases, but process maturity is not a formal ISMS certification. Managed hosts such as WP Engine hold ISO 27001:2022 for their platforms.

No PCI DSS, CSA STAR, Cyber Essentials, FedRAMP, or IRAP certifications exist at the WordPress software level — all such certifications belong to the hosting/integration layer. WordPress core does run a well-regarded security process (dedicated security team, coordinated disclosure, and the 2026 'Protect The Shire' 24-hour cooldown on plugin/theme auto-updates to harden the .org repository), but governance process is not certification.

Self-hosted open-source WordPress gives operators complete control over data residency — any region, jurisdiction, or infrastructure, with no platform-imposed data flows and no vendor sub-processor dependencies. This is a genuine strength of the self-hosted model, matching the Drupal/Joomla analogs. It falls short of a perfect score only because there are no built-in contractual guarantees or guardrails and compliant residency requires operator expertise.

Core provides a self-service right-to-erasure and export workflow (email-verified user requests, admin approval, downloadable .zip) plus an extensible exporter/eraser API, and full-site content export via the core WXR exporter and REST API. This is somewhat stronger than the Joomla/Drupal baseline because the request workflow and APIs are in core. However, there is no native automated retention policy, no data classification, and post-termination retention is undefined in the self-hosted model — anything beyond the core tools requires custom development.

WordPress core has no built-in audit log — only post/page revision history with user attribution — so compliance-grade logging depends on plugins. The mature, widely deployed WP Activity Log (Melapress) records logins, content edits, settings changes, and user management, with CSV/HTML export and, in the Enterprise tier, SIEM integration (Syslog, Splunk, AWS CloudWatch, Papertrail, Loggly). It lands roughly level with Drupal: core is weaker (no dblog/syslog equivalent) but the plugin ecosystem is excellent, though SIEM export sits behind a paid tier.

WordPress commits, via its published Accessibility Coding Standards, that all new and updated core code conforms to WCAG 2.2 Level AA, with ATAG 2.0 encouraged for authoring interfaces and an active Make WordPress Accessible team gating releases. The admin is largely keyboard-navigable and the block editor exposes ARIA labels, though Gutenberg has a history of accessibility criticism and known issues remain tracked in the 'accessibility' Trac focus. Strong documented commitment but no formal third-party conformance audit holds it just below the documented-conformance threshold.

WordPress publishes an accessibility statement and a detailed accessibility handbook/coding standards (make.wordpress.org/accessibility), but there is no official, current VPAT or ACR for WordPress core suitable for procurement, and no Section 508 conformance statement for the software. That places it in the accessibility-page-without-formal-VPAT band — marginally below Drupal, which maintains a draft OpenACR-based ACR.

Text generation on self-hosted WordPress comes from a deep plugin ecosystem rather than core: Jetpack AI Assistant (free) generates, rewrites, expands, summarizes and adjusts tone inside the Gutenberg block editor, while AI Engine by Meow Apps (70k+ active installs) adds a copilot, custom prompt templates, and bulk generation with BYOK GPT-5/Claude/Gemini. WordPress 7.0 core ships only the plumbing (AI Client SDK + Abilities API) plus a reference 'AI Experiments' plugin whose sole shipping demo is Title Generation. Not higher because native brand-voice enforcement and content-type-aware guardrails live in premium plugin tiers, not in core.

Both halves of this item are well covered by widely-adopted plugins: Jetpack AI and AI Engine generate images from prompts inside the editor, and a mature auto-alt-text ecosystem (AltText.ai, Seenalt, AI Alt Text Generator) writes descriptive alt text automatically on upload with bulk Media Library processing, WP-CLI, multisite, and multilingual support. Seenalt also handles WebP/AVIF optimization. Not higher because image generation and alt-text automation are separate third-party plugins rather than a single native AI-DAM workflow, and quality depends on the operator's chosen provider keys.

AI/MT translation is a strong plugin category: Weglot combines neural MT (DeepL, Google, Microsoft) with a custom AI language model (OpenAI/Gemini) to match brand voice, TranslatePress AI bundles GPT/Gemini/DeepL/Google through a managed pipeline, and Jetpack AI translates across 12+ languages in the editor. Weglot's brand-voice model and TranslatePress SEO-Pack (translated slugs/meta/alt) push beyond raw MT. Not higher because glossary/translation-memory quality scoring is uneven across plugins and the strongest brand-voice controls sit behind paid tiers.

This is a WordPress ecosystem strength: Yoast SEO Premium auto-generates SEO titles and meta descriptions and its AI Optimize gives in-editor on-page scoring, while Rank Math Content AI generates instant image alt text, on-page recommendations with competitor analysis, llms.txt output, and an AI search-traffic tracker. On-page SEO scoring is built into both. Not higher because comprehensive schema-markup suggestion automation and true bulk AI SEO processing remain gaps, and the strongest features require premium plugin licenses.

Multiple no-code AI workflow plugins wire routine content ops: Uncanny Automator connects OpenAI to any plugin for AI-driven publishing/enrichment recipes, Bit Flows builds AI agent workflows, and bulk alt-text/tagging tools enrich media libraries at scale. Not higher because these are assembled from separate third-party plugins rather than a cohesive native pipeline, WordPress core provides no built-in auto-tagging or duplicate detection, and most automation is manually triggered rather than lifecycle-driven.

The official WordPress MCP Adapter (core AI team, v0.5.0) lets external agents — Claude Desktop/Code, Cursor, ChatGPT — draft, publish, update, and bulk-edit content by invoking registered Abilities, and third-party plugins (Bit Flows, Uncanny Automator, AI Engine) add no-code agent builders. Not higher because there is no first-party named agent product executing multi-step editorial pipelines end-to-end, no agent marketplace, no governance layer purpose-built for agentic runs, and the MCP Adapter is still pre-1.0.

Content intelligence is thin on self-hosted WordPress: Rank Math adds an AI search-traffic tracker and content recommendations with competitor analysis, but VIP-only Parse.ly content intelligence is explicitly out of scope here. There is no native AI content-gap analysis, topic clustering, ROI attribution, or stale-content detection dashboard in core or the mainstream free ecosystem. Not lower because SEO plugins deliver real performance-scoring and recommendation signals; not higher because a genuine content-health intelligence dashboard requires stitching external analytics.

Auditing capability is partial and plugin-assembled: SEO plugins score on-page content quality, bulk alt-text tools audit accessibility gaps across the Media Library, and accessibility-checker plugins scan for WCAG issues, but there is no unified AI audit spanning quality + brand voice + accessibility across thousands of pages. Not higher because brand-voice compliance checking and thin/duplicate-content detection at scale are not covered natively; not lower because accessibility and SEO auditing are genuinely available via mainstream plugins.

Vector/semantic search ships in production via several actively-maintained plugins: AI Vector Search (Semantic) combines Postgres FTS with OpenAI embeddings, VectorSeek and wp-search.ai deliver RAG answers over indexed posts/pages/PDFs, SemantiQ uses Qdrant with local embeddings, and AI Search for WooCommerce vectorizes the catalog with hybrid keyword+semantic ranking. Not higher because semantic search is not native to core, requires a plugin plus embedding-provider setup, and index freshness/scale is the operator's responsibility.

There is no native ML personalization engine in WordPress core, and the ecosystem is dominated by rule-based tools (If-So, OptinMonster). ML-driven personalization exists mainly in commerce recommendation plugins (WooAI product recommendations) and FlowAI, which blends rules with ML for content/CTA personalization. Not higher because predictive audience scoring, cold-start handling, and next-best-content engines comparable to Bloomreach Loomi or Sitecore CDP are absent; not lower because commerce ML recommendation plugins do provide a genuine (if narrow) predictive layer.

WordPress ships an official MCP path: the WordPress/mcp-adapter plugin, maintained by the core AI team, bridges the core Abilities API to the Model Context Protocol so MCP clients can discover and invoke read/write/publish operations, superseding the now-archived Automattic/wordpress-mcp. AI Engine also exposes an MCP server. Not higher because the official adapter is still v0.5.0 (pre-stable) on its own release cadence rather than a bundled-in-core 1.0, though it is officially governed rather than merely community-maintained.

BYOK is now a core capability: WordPress 7.0's Settings → Connectors is a central credential vault shipping featured connectors for OpenAI, Anthropic, and Google plus custom services, with keys hashed/masked in the database and reusable by any AI-aware plugin. AI Engine extends this to 10+ providers including fully self-hosted, data-resident options (Ollama, LM Studio, vLLM, LocalAI, any OpenAI-compatible endpoint). Not higher only because the core Connectors hub itself features three providers out of the box; broad provider choice and self-hosting still lean on the plugin layer.

WordPress 7.0 core provides a genuine AI developer foundation: the Abilities API (introduced 6.9) is a machine-readable registry of site capabilities discoverable by AI agents, the PHP AI Client SDK (wp-ai-client) offers a uniform interface across providers, and the MCP Adapter exposes Abilities to LLM tooling, all documented on the official developer blog. The mature WP REST API and WPGraphQL provide RAG-ready content delivery for headless consumption. Not higher because there is no first-party LangChain/LlamaIndex/CrewAI integration guide and much agent tooling still routes through third-party plugins.

WordPress 7.0 core adds foundational governance: a new prompt_ai capability restricts AI access to administrators by default, Abilities carry user-controlled permissions, and Connector API keys are hashed and masked in the database and REST responses like WooCommerce payment keys. Not higher because core provides no audit trail of AI invocations, no brand-safety enforcement, no hallucination/confidence scoring, and no IP indemnification; governance depth beyond access control and credential security depends entirely on the operator's chosen plugins.

Observability is plugin-dependent: AI Engine provides usage statistics, per-user query tracking, token/cost visibility, and request limits/quota management within its dashboard, which is the primary source of AI usage insight on a self-hosted install. WordPress core Connectors surfaces which providers are connected but ships no AI usage or cost dashboard. Not higher because there is no native, cross-plugin observability layer, no model-performance or prompt-effectiveness analytics in core, and quality-trend monitoring is absent outside individual plugins.