WordPress

register_post_type(), register_meta() and register_taxonomy() let developers define fully custom types in code, and ACF (free core, Pro for repeater and flexible content) adds 30+ field types with JSON sync for schema-as-code. Not higher because core has no field UI at all, there is no union or polymorphic field type, and the richest field types sit in the paid ACF Pro tier.

ACF relationship and post object fields support many-to-many links, with an optional bidirectional setting since ACF 6.2, and WPGraphQL exposes them as connections. Core itself only offers parent/child hierarchy and taxonomy terms. Not higher because relationships are stored in post meta, reverse traversal relies on meta queries or extra configuration, and there is no graph model.

The block editor supports unlimited nesting through InnerBlocks, synced patterns with overrides and block bindings to custom fields, and WordPress 7.1 added more core blocks such as Tabs and Playlist. Not higher because blocks are persisted as HTML with comment delimiters in post_content rather than portable structured JSON, and self-hosted sites lack VIP's Block Data API and Remote Data Blocks.

ACF provides required, min/max, character limits and choice constraints plus the acf/validate_value filter for custom PHP rules, and register_meta() schemas validate REST API writes. Core has no declarative validation in the editor. Not higher because cross-field, unique and regex rules all require custom code.

Core revisions keep full snapshots with a compare screen, author attribution and one-click restore, post meta can be revisioned since 6.4, WordPress 7.0 added visual revisions, and Trash restores deleted posts for 30 days. Not higher because there is no branching, no release bundles and no field-level diff for meta that is not registered for revisions.

Core ships hierarchical categories, flat tags and custom taxonomies shareable across any post types, with manage_terms and assign_terms capabilities for governance, term meta for metadata, and full exposure through REST and WPGraphQL. Not higher because there are no synonyms, no controlled-vocabulary approval workflow and only basic bulk edit for reclassification.

Coupled sites preview drafts on the real theme frontend, and block themes make the Site Editor canvas closely match the published design. Shareable unauthenticated preview links need a plugin such as Public Post Preview, and headless preview requires WPGraphQL preview tokens plus custom frontend work. Not higher because there are no click-to-edit overlays on a live frontend and no official headless preview SDK in core.

Gutenberg RichText supports a custom formats API, inline embeds, oEmbed for 30+ providers, markdown shortcuts and solid paste handling from Word and Google Docs, and any block can be embedded in content. Not higher because output is an HTML string with block comment delimiters rather than a portable AST with custom renderers.

Core generates responsive srcset sizes on upload, supports WebP and AVIF (with 7.1 extending modern format and HDR handling), and stores alt text and captions. Not higher because there are no on-the-fly URL transforms, no focal point, no folders and no asset usage tracking without plugins or an external image service such as Jetpack, Cloudinary or Imgix.

Core has post locking to prevent conflicting edits, and Notes (block-level comments in 7.0, extended in 7.1 to inline text selections with mentions) add asynchronous review. Real-time co-editing was pulled from the 7.0 release and remains outside core. Not higher because there is no live simultaneous editing or presence in self-hosted core.

Core offers draft, pending review, scheduled and published states, and plugins such as PublishPress Statuses and Oasis Workflow add custom statuses, notifications and approval routing. Not higher because core has no configurable workflow engine, and conditional routing, parallel paths and audit trails depend on premium plugins.

Core schedules publishing per post with site timezone awareness and API control of the publish date, and the free PublishPress Future plugin adds scheduled unpublish and expiry with a calendar available from PublishPress Planner. Not higher because unpublish and calendar views are plugin-provided and there are no atomic release bundles.

Core has no content localization model, so sites use Polylang or WPML to link translations at document level, or one Multisite site per locale. Not higher because there is no field-level localization or fallback chain, and locale handling in the API depends on the chosen plugin.

Five core roles map to a granular capabilities system, custom roles and per-post-type capabilities are defined in code or with plugins such as Members, and SAML/OIDC SSO comes from plugins. Not higher because there are no field-level or locale-level permissions, no SCIM provisioning and no vendor-provided SSO or MFA.

The core REST API offers full CRUD with filtering, pagination (100-item cap) and embedding, and WPGraphQL adds cursor pagination and auto-generated schema for custom types and ACF fields. Not higher because delivery and management are not separate API tiers, GraphQL is a plugin and locale queries depend on the localization plugin.

Self-hosted WordPress ships no CDN; operators add Cloudflare APO, a host's CDN or caching plugins such as WP Rocket or W3 Total Cache, several of which purge on publish. Not higher because all edge delivery and invalidation is operator-configured and nothing is provided by the platform itself.

The do_action/apply_filters hook system exposes nearly every content event internally, and plugins such as WP Webhooks send outbound HTTP calls on publish, update and delete. Not higher because there is no core outbound webhook service, and signing, retries and delivery logs depend on the plugin.

REST and WPGraphQL let content feed headless frontends and apps, and a large community of Next.js and other starters exists. Not higher because the model is web-first, rich content is serialized HTML, and there are no official multi-language SDKs.

Core has no segmentation or visitor profiles; plugins such as Logic Hop and If-So add rule-based targeting by geography, referrer or behavior, and CDP tags such as Segment are added by snippet. Not higher because there is no segment builder in the product and no deep CDP integration where audiences drive content rules.

Conditional-content plugins can show different blocks per rule, but there are no native content variants or per-audience preview in the editor. Full-page caching on self-hosted stacks also has to be configured to vary per segment. Not higher because personalization is entirely plugin or developer driven.

Nelio A/B Testing runs page, headline, template and WooCommerce experiments with traffic allocation and significance reporting from inside wp-admin. Not higher because experimentation is a third-party plugin with full features on paid plans, and core has no testing surface.

Related-content plugins such as YARPP, Contextual Related Posts and Jetpack Related Posts recommend by keyword and taxonomy similarity, and WooCommerce offers related products, up-sells and cross-sells. Not higher because none is an ML or behavior-driven engine with configurable weighting.

Core search is a basic database match with minimal relevance ordering, so real sites add Relevanssi, SearchWP or ElasticPress for weighting, fuzzy matching and facets, or the Algolia plugin for hosted search. Not higher because quality depends on plugin choice and the operator must run any Elasticsearch backend.

WooCommerce, a free GPL plugin from the same ecosystem, adds catalog, cart, checkout, pricing, tax, shipping and inventory with Cart and Checkout blocks and a Store API. It is installed separately rather than part of core. Not higher because subscriptions, B2B pricing and many payment and fulfilment features come from paid extensions.

BigCommerce for WordPress syncs catalog into WordPress, and Shopify and Ecwid offer buy-button and embed plugins. Not higher because these are mostly product pickers and embeds, with no maintained connectors for commercetools, SAP or Salesforce Commerce.

Core has no analytics; Site Kit, MonsterInsights and Jetpack Stats surface page views and top content in wp-admin, and WooCommerce Analytics covers store metrics. Not higher because content performance comes from external services and there is no content health, lifecycle or author productivity reporting.

Google maintains Site Kit for GA4, Search Console and Tag Manager, and Segment, Adobe and Amplitude tags are placed through theme hooks or tag manager plugins without restriction. Not higher because these are third-party connectors and event instrumentation is operator-configured.

Core Multisite runs many sites from one install with a Network Admin, shared users, themes and plugins, and per-site configuration. Not higher because content is siloed per site, so cross-site reuse needs a syndication plugin such as Distributor, and operating a large network is the operator's responsibility.

WPML Translation Management offers translation jobs, XLIFF export and import, machine translation credits and connectors to TMS vendors, and Smartling and Lingotek ship WordPress plugins. Not higher because all of this is third-party and paid, and Polylang's free tier has thin TMS coverage.

Multisite Network Admin can enforce themes and plugins network-wide, and theme.json style locking, block locking and restricted pattern libraries let a central team constrain brand sites. Not higher because there are no cross-brand approval workflows, policy dashboards or brand-level analytics.

The core Media Library is a flat store with basic metadata; folder plugins and marketplace connectors for Cloudinary, Bynder and others add DAM features. Not higher because rights, expiry, approvals, versioning and usage tracking all require an external DAM and partner-built connectors.

Core can upload video files and play them with the Video block, and oEmbed handles YouTube and Vimeo, while Presto Player and Mux or Cloudinary plugins add streaming. Not higher because there is no transcoding, adaptive bitrate or caption workflow in core, and video at scale must be offloaded.

The block editor and Site Editor let marketers compose pages from blocks and patterns with Group, Columns and Grid layouts, template locking and Global Styles guardrails, and 7.1 added responsive styling controls. Not higher because composition happens in an editing canvas rather than on the live frontend, does not extend to headless frontends, and true drag-and-drop builders such as Elementor are third-party.

WordPress renders the full site natively through themes, templates and permalink routing, and wordpress.org publishes hosting requirements and recommendations. Hosting, TLS, CDN, environments and uptime are the operator's responsibility, since managed hosting from WordPress.com or VIP is a separate product. Not higher because no hosting comes with the software.

Gravity Forms, WPForms and Fluent Forms provide conditional logic, multi-step forms, entry storage, spam protection, payments and CRM or webhook add-ons. Not higher because core has no form builder and progressive profiling and lead routing need premium tiers.

MailPoet and FluentCRM send newsletters and post notifications from within WordPress, and MC4WP, HubSpot and Brevo plugins sync subscribers to external ESPs. Not higher because deliverability is the operator's problem and in-CMS email preview and triggered sends depend on plugin choice.

FluentCRM and FunnelKit Automations add triggers, tag-based journeys and drip sequences driven by site and WooCommerce events, and HubSpot's plugin connects to its automation suite. Not higher because automation is email-centric, plugin-provided and lacks multi-channel lifecycle orchestration.

Core generates XML sitemaps, canonical tags, robots.txt and clean permalinks, and the free tiers of Yoast SEO or Rank Math, present on almost every professional build, add meta previews, schema.org output and recommendations. Not higher because meta descriptions, redirects and structured data authoring are plugin features rather than core.

Yoast SEO and other plugins can generate llms.txt, the robots_txt filter or a plugin manages per-bot crawler rules, and schema plugins add JSON-LD. Not higher because core has no AI-specific features, no Markdown endpoints and no AI citation reporting.

The WordPress.org plugin directory lists around 60,000 free plugins with one-click install from wp-admin, and premium marketplaces extend the ecosystem far beyond that. Not higher because the directory is not curated for quality or security, so operators must vet plugins themselves.

Core includes visitor registration, login and the Subscriber role, so gated content is possible, and plugins such as Paid Memberships Pro, MemberPress and OpenID Connect clients add portals, social login and CIAM federation. Not higher because there is no native portal layer, consent management or identity federation.

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 the surface keeps growing — WP 7.1 (Aug 2026) made the Icons API a public REST resource (WP_REST_Icons_Controller) and exposed the Abilities API over REST (/wp-json/wp-abilities/v1/). WPGraphQL 2.x 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. WP 7.1 (Aug 2026) extended the Abilities API with a filterable execution lifecycle, custom validation, and shared discovery, and added a Design System (semantic tokens, ThemeProvider) and public Icons API for custom admin UI. 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 (WP 7.0.2/7.0.3/7.0.4 were security releases in Jul–Aug 2026) 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, which worsened in 2026: ~250 new plugin/theme vulns disclosed weekly (43% unauthenticated), June 2026 saw six actively-exploited CVSS 9.8 flaws at once, a GiveWP CVSS 10.0 RCE, and multiple supply-chain attacks (ARVE backdoor, BdThemes poisoned promo API). The operator owns all patching with no VIP-style scanning gate, which drops this just 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 2.x + graphql-codegen, which produces types from the GraphQL schema 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.

The three-major-releases-per-year cadence is now proven, not just planned: 7.0 'Armstrong' shipped May 20, 2026, and 7.1 'Mary Lou' landed exactly on its Aug 19, 2026 target at WordCamp US, with 7.2 targeted Dec 9-10 (finalizing real-time collaboration). Between majors, security/maintenance releases were frequent and responsive — 7.0.1 (31 fixes), 7.0.2 (one critical + one high), 7.0.3 and 7.0.4 all shipped within weeks. All free to every self-hosted install. Not higher because real-time collaboration slipped again from 7.1 into the 7.2 cycle, showing the flagship collaboration feature still can't hit its dates.

Every major ships a comprehensive Field Guide on make.wordpress.org with per-feature dev notes, plus per-version release posts, developer.wordpress.org 'What's new for developers' monthly digests, and Codex/HelpHub upgrade docs; the 7.1 cycle continued this with documented interactive-states styling and new Tabs/Playlist blocks. Structured version history lives in the handbook and Trac. Not higher because the canonical changelog is spread across release posts, Field Guides, monthly dev digests, and Trac rather than one structured per-release breaking-change feed like commercial SaaS vendors provide.

WordPress development is unusually transparent: the Gutenberg four-phase roadmap (Phase 3 — collaboration) is public, dated release schedules are published (7.1 Aug, 7.2 Dec 2026), and planning happens in the open across Make WordPress team blogs, 'Roadmap to 7.1' posts, Slack, and Trac, so anyone can follow or contribute. Not higher because the public roadmap is narrative/phase-based rather than a voted feature portal, and priorities remain heavily steered by Automattic rather than a neutral governance body.

Backward compatibility is a foundational WordPress value and a genuine self-hosted strength: core preserves plugin/theme compatibility across major versions, the minimum PHP baseline moves only after years of notice, and the still-immature real-time collaboration feature was again held back (7.1 -> 7.2) rather than shipped broken. The trade-off is that this BC discipline slows deprecation cleanup, but for operators it means core upgrades rarely break existing sites (plugin conflicts, scored elsewhere, remain 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 (2026, W3Techs), with the nearest rival near 5%. The wordpress.org plugin repository hosts 60,000+ free plugins (90,000+ including premium), and its Stack Overflow volume, @wordpress npm downloads, and WordCamp network are all unmatched; even the WordPress Foundation G2 listing alone carries 9,500+ reviews. The recent share dip is a momentum signal (4.3.2), not a community-size change.

The 2026 cycle showed strong, active participation — WordCamp US 2026 (Phoenix, Aug 16-19) drew 1,100+ registered attendees plus thousands watching remotely, with a Contributor Day, and WordCamp Europe (Kraków) and busy Make WordPress Slack channels and forums stayed active alongside a 7.1 release party. Third-party community docs (Gutenberg Times 'Source of Truth') stay current. Held below the community-size score because governance tension around Automattic's control and its slashed-then-partially-restored 'Five for the Future' hours has created real contributor friction, even though it hasn't 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/7.1 releases generated a fresh wave of upgrade guides, feature breakdowns, and video coverage from raidboxes, DreamHost, SmartWP, 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 six-plus consecutive months — from 43.2% (Dec 2025) to ~41.5% (mid-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/Webflow at the SMB end. WordPress 7.x's native-AI foundations give it a forward narrative and WCUS drew 1,100+, 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 multi-company contributor base, so its survival is not in question. But its development velocity is heavily dependent on Automattic, whose signals are mixed-to-negative: a 16% layoff (~280 people) in April 2025, a BlackRock valuation markdown, ongoing WP Engine litigation, and Five for the Future hours cut from ~3,900 to ~45/week before a partial May 2025 restoration. That dependency and governance drama are real stability concerns even as 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 used against WordPress 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 — 4.4/5 across ~9,552 verified reviews (WordPress Foundation listing, 2026) — praised for flexibility, customization breadth, ecosystem depth, and data control. The consistent negatives are operator burden (maintenance, the update treadmill, plugin/security overhead, non-obvious admin UX) and ecosystem distrust from the Automattic/WP Engine governance fight. The very high rating-plus-volume argues for a higher band, but the recurring operational and governance complaints hold it here per the sentiment-penalty guidance.

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 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, WooCommerce) 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 ~$25-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. WP 7.1 'Mary Lou' (Aug 19, 2026) adds an expanded Abilities API and a new Icons API — additive, approachable developer surfaces — while enforcing an iframed editor requiring Block API v3. Not higher because the hook/filter lifecycle, template hierarchy, and evolving Block API versions 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, and Gutenberg uses React internally, but WP 7.1's enforced iframed editor now requires Block API v3 for custom blocks, adding a WordPress-specific constraint. 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-plus-vendor: Next.js starters like gregrickaby/nextjs-wordpress and WP Engine's Faust.js (still positioned in 2026 as the official WP Engine headless framework handling preview/auth/routing) rather than a first-party core-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 core-vendor Next.js/Nuxt starter matches dedicated 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 — WP 7.1 further improves the in-editor experience with a redesigned image editor (client-side media processing) and Notes review annotations. For decoupled builds, draft preview still requires Faust.js or a custom draft-routing implementation, leaving headless preview a framework-dependent 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 WP 7.1 (Aug 19, 2026) now ships GA responsive block styling and hover/focus (pseudo-state) styling in the Site Editor — so non-developers can adjust per-viewport layouts without a developer writing CSS — plus upgraded Notes (@mentions, reactions, text-range annotations) for editorial review. Developer involvement is mainly needed for new block types or template-level changes. Not higher because heavily customized or decoupled builds reintroduce developer dependency for layout-level changes.

Core upgrades remain 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. WordPress 7.1 'Mary Lou' shipped GA at WordCamp US on Aug 19, 2026 and is described as backward compatible with properly maintained plugins/themes, with the highest-risk surfaces being older blocks still on Block API v2 and media plugins that assume server-side image processing (7.1 moved image resizing to the browser). The recurring friction is still per-plugin compatibility testing on major jumps that self-hosted operators own; not higher because that testing burden persists, not lower because the core update path itself is essentially frictionless.

Core security patching is excellent and largely hands-off — Patchstack's State of WordPress Security 2026 found only 6 core vulnerabilities in 2025 (all low priority), and minor security releases (e.g. 7.0.2 fixing one critical + one high issue Jul 17, plus 7.0.3/7.0.4 Aug 2026) auto-apply within hours. But for self-hosted WordPress the dominant attack surface is plugins and that burden is entirely the operator's: 11,334 new ecosystem vulnerabilities in 2025 (+42% YoY), 91% in plugins, highly-exploitable vulns up 113%, 46% unpatched at disclosure, with roughly half of high-impact bugs exploited within 24 hours (worst cases in ~5). Not lower because core auto-patching removes the core CVE burden almost entirely; not higher because the plugin patch treadmill is the largest of any CMS and traditional hosting defenses blocked only 12–26% of attacks, so a WAF/virtual patching and constant operator vigilance are effectively mandatory.

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.1 preserved compatibility for maintained plugins/themes and continued the block-editor transition without deprecating classic workflows. Release cadence is predictable (7.0 May 2026, 7.1 Aug 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. Mitigating factors are a mature, well-documented, largely one-click caching-plugin ecosystem plus commodity managed hosts that pre-tune the stack, and 7.1's move of image resizing to the browser reduces one class of server-side load. 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 — WCUS 2026 wrapped in Phoenix Aug 16-20 with 1,100+ in-person attendees and thousands more streaming, and WCEU Kraków ran in June 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), rapid security minors 7.0.2/7.0.3/7.0.4 (Jul-Aug 2026), and 7.1 GA (Aug 19, 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, and 7.1 'Mary Lou' (Aug 2026) turned editorial Notes into a real review tool — rich-text comments, @mentions, multiple threads per block, and shareable revisions — further compressing the review-to-publish loop for teams alongside the DataViews-based admin. Brief-to-publish under an hour is realistic for structured content. Nudged to 70 (from 68) for the review tooling; still capped there because new layout types 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; WordPress 7.1 added per-screen and per-state responsive styling within these tokens. 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.1 'Mary Lou' extended media handling with a new Media Editor Modal, client-side HEIC/UltraHDR/AVIF processing, and more resilient uploads, improving the built-in asset workflow. DAM-grade capability — transforms, tagging, rights management, usage tracking — still requires integration with Cloudinary, Bynder, or similar via plugin. Scores mid-band (nudged from 45): an improved 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 core merchandising. The official WooCommerce AI Product Recommendations extension (2026) now adds behavioral, individually-profiled personalized recommendations plus advanced automated upsell/cross-sell, moving beyond static hand-picked relations toward a rules/ML-driven merchandising engine, and search-merchandising extensions (FiboSearch) add discovery tuning. Held just below 60 because the AI recommendations and search merchandising are paid extensions (cost reflected in cat5) rather than native core capability, and visual/search-result merchandising is not built into core WooCommerce.

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, personalized dashboards, SSO, and a knowledge base — a fuller employee-experience layer than a bare CMS, with vendors reporting production intranets shipped on BuddyBoss. 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, and open-source orchestration tooling (e.g. OneDesign) now syncs block patterns and templates from a governing site to every brand site. 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, the parent/child theme model enables a master system with per-site variations, and open-source orchestration tooling (OneDesign/OneUpdate under the OnePress framework) now propagates block patterns/templates and centralizes plugin updates from a governing site across brand sites via CI/CD. However, there is still no formal design-system UI, no first-class component versioning with rollback, and token propagation remains code/deploy-driven rather than platform-managed. Sits mid 30–50 band, nudged up (from 36) for the maturing open-source propagation tooling.

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), and the Accessible team has run a year-long documentation push (make.wordpress.org/accessibility, Aug 2026), but there is still 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) lets external agents — Claude Desktop/Code, Cursor, VS Code, ChatGPT — draft, publish, update, and bulk-edit content by invoking registered Abilities, and WordPress 7.1 'Mary Lou' (Aug 2026) hardened that surface with a filterable execution lifecycle, custom validation, and shared discovery. Third-party plugins (Bit Flows, Uncanny Automator, AI Engine) add no-code agent builders on top. Not higher because there is no first-party named agent product executing multi-step editorial pipelines end-to-end, no agent marketplace, and no governance layer purpose-built for agentic runs.

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, Queryra (launched Jan 2026) uses SentenceTransformers + ChromaDB, 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 (Claude Desktop/Code, Cursor, VS Code) can discover and invoke read/write/publish operations, superseding the archived Automattic/wordpress-mcp. WordPress 7.1 'Mary Lou' (Aug 2026) made the discovery and validation surface production-ready with improved querying, filtering, input validation, and a unified public-exposure flag. Not higher because the adapter is still a pre-1.0 plugin on its own release cadence rather than bundled-in-core, and AI Engine's alternative MCP server remains third-party.

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 core provides a genuine AI developer foundation that matured in 7.1 'Mary Lou' (Aug 2026): the Abilities API (introduced 6.9) is a machine-readable registry of site capabilities that gained a filterable execution lifecycle, custom validation hooks, and a unified public-exposure flag for surfacing capabilities to the WP AI Client and external connectors; the PHP AI Client SDK (wp-ai-client) offers a uniform interface across providers, and the MCP Adapter exposes Abilities to LLM tooling. 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.