WordPress still runs roughly 42–43% of the web in 2026, but the platform a team meets today is not the platform from five years ago. The block editor matured into full-site editing (FSE), the headless ecosystem stabilized around WPGraphQL and Faust.js, AI plugins are everywhere, and — most importantly for an AI-native landscape report — WordPress 6.9 shipped a core Abilities API and an official MCP Adapter that turn any site into an agent-callable surface. At the same time, plugin-driven security debt, performance overhead, design lock-in, and a genuine governance crisis are pushing a measurable slice of teams toward Webflow, headless setups, and modern alternatives. This chapter gives an honest, evidence-based assessment of modern WordPress, lays out a realistic upgrade path for a 1,000-page site, and catalogs the legitimate reasons teams leave.
According to W3Techs (May 2026), WordPress powers 42.2% of all websites and holds 59.6% of the known-CMS market — more than every other CMS combined. It sits at roughly 49% of the top 1 million and 52% of the top 100,000 sites. The official directory still lists 63,000+ free plugins.
The headline that matters, though, is direction: Patchstack and several trackers note WordPress slipped from a peak above 43% to ~42.2–42.6% — the first sustained decline since W3Techs began tracking in 2011. The drop is about a full percentage point. That is small in absolute terms but symbolically large after a decade of monotonic growth, and it is driven by a mix of technical fatigue and the trust/governance issues discussed below.
The single biggest change to "what WordPress is" happened in the editor. Gutenberg (the block editor, merged into core back in WP 5.0) has evolved into Full Site Editing (FSE): in 2026, block themes and the Site Editor are the standard, not an experiment. Themes are no longer PHP template hierarchies stitched together with header.php/footer.php — a block theme is essentially a folder of HTML block templates plus a configuration file.
theme.jsonKey FSE building blocks as of WordPress 6.8–6.9:
| Capability | What it does | Status (2026) |
|---|---|---|
| theme.json (v3) | Single config for colors, typography, spacing, block style variations; normalizes longhand/shorthand CSS, adds shadow presets and fluid-typography min/max | Shipping; v3 in current releases |
| Block style variations | First-class objects in theme.json — reusable design tokens | Formalized in theme.json v3 |
| Patterns + Pattern Overrides | Reusable layouts where instances can override specific fields (e.g., a "team card" pattern) | Shipped (WP 6.6+, expanded in 6.8) |
| Block Bindings API | Bind block attributes to dynamic data (custom fields, meta) without custom blocks | Stable |
| Interactivity API | Standard for front-end interactivity (filtering, search-as-you-type) without ad-hoc JS | Stable, expanded in 6.9 |
| Connectors API (alpha) | Preview of data-driven templates pulling external data — slated to mature in 7.0 | Alpha in 6.8 |
| New core blocks | Accordion, Math, expanded Query Loop | Accordion + Math added in 6.9 |
The default theme Twenty Twenty-Five is a fully block-based showcase. For a 2026 build, the developer baseline is: block theme + theme.json design system + patterns for repeated layouts + the Interactivity API for front-end behavior. WPPoland and Atto WP both frame theme.json as the place to define a design system (tokens, scales, variations) rather than scattering CSS across plugins.
The honest caveat: FSE is powerful but has a real learning curve and historically rough edges (template part management, global-styles conflicts, plugin compatibility). Many agencies still ship "classic + Advanced Custom Fields (ACF)" or page-builder stacks because FSE's editorial UX for non-technical authors can be confusing compared to a curated builder.
WordPress exposes three programmatic surfaces that matter for an AI-native, decoupled world:
/wp-json/wp/v2/.... Universal, but chatty (multiple round-trips, over-fetching) and not typed.wp-graphql-smart-cache it becomes cacheable at the CDN edge.Headless WordPress in 2026 means: keep WordPress as the editorial back end, render the front end with Next.js, Astro, or similar, and pull content via WPGraphQL or REST.
wp-graphql-smart-cache, wp-graphql-ide, and wp-graphql-content-blocks. The community has partly drifted toward "raw" WPGraphQL + Next.js/Astro without the Faust abstraction.Headless is a valid but not free choice: you gain performance, security (the WP admin can be firewalled off the public internet), and front-end freedom, but you take on a build pipeline, lose the WYSIWYG "what I edit is what I see" promise of FSE, and break many plugins that assume they render the front end (forms, popups, some SEO output).
There are two layers to "AI in WordPress 2026": the plugin layer (assistive features inside the editor) and the core agent layer (the Abilities API + MCP Adapter). The plugin layer is incremental; the core layer is the genuinely interesting development for an AI-native landscape.
| Plugin | What it does | Pricing (2026) |
|---|---|---|
| Jetpack AI Assistant | In-editor drafting, tone adjustment, summaries, tables/lists, featured-image generation, translation (12+ languages) | ~20 free requests, then ~$10/mo |
| Elementor AI | Copy generation, high-res images, custom CSS per widget, AI Copilot wireframing, brand-voice "AI Context" | Credit system from ~$48/yr for ~24,000 credits (text 1 credit, image 33, container 40) |
| Yoast SEO Premium (AI) | Auto titles/meta descriptions tied to the traffic-light grading, readability, schema automation | ~$69.30/yr |
| AI Engine (Meow Apps) | Chatbots, content generation, and — notably — turns a site into an MCP server with 30+ tools | Free + Pro tiers |
| Rank Math / AIOSEO | AI content/SEO assist plus llms.txt generation | Freemium |
These are useful but commoditized — every CMS now has comparable in-editor AI. They are not a reason to choose or keep WordPress on their own.
WordPress 6.9 ("Gene," released December 2, 2025) shipped the Abilities API into core. An "ability" is a registered capability with a description, typed inputs/outputs, a permission callback, and execution logic — discoverable and callable consistently across PHP, JavaScript, and the REST API. Core ships defaults like core/get-site-info, core/get-user-info, and core/get-environment-info. WordPress 7.0 is slated to add a client-side Abilities API.
On top of that, the official WordPress MCP Adapter (from the "AI Building Blocks for WordPress" initiative, GitHub WordPress/mcp-adapter) bridges Abilities to the Model Context Protocol, so MCP clients — Claude Desktop, Claude Code, Cursor, VS Code — can discover and execute site functionality as MCP tools and read data as MCP resources. Technical specifics from the WordPress Developer Blog (Feb 2026):
mcp-adapter-discover-abilities, mcp-adapter-get-ability-info, mcp-adapter-execute-ability.meta.mcp.public flag to be exposed on the default public server.@automattic/mcp-wordpress-remote proxy).WordPress.org itself now runs a Plugin Directory MCP Server (announced March 2026), and tools like MainWP expose multi-site management via MCP. This is strategically significant: rather than every plugin inventing its own AI integration, WordPress is standardizing the functional surface so agents can operate a site — publish, update, configure — not just read it. For the AEO/discoverability side, the Website LLMs.txt plugin (and AI-Ready WP) auto-generate llms.txt with Yoast/Rank Math/SEOPress/AIOSEO integration.
Honest read: this is the most credible argument that "WordPress isn't going anywhere." It gives the dominant CMS a native, standardized agent interface that proprietary platforms will struggle to match in openness. But it is early — most abilities are read-oriented, public exposure is opt-in, and real agentic write workflows need careful permission design to avoid the obvious abuse surface.
The reasons are concrete and, in 2026, increasingly defensible.
1. Plugin-driven security debt. Patchstack's State of WordPress Security 2026 whitepaper is blunt: 11,334 new vulnerabilities in 2025 (+42% YoY), of which 91% were in plugins, 9% in themes, and only 6 affected core (all low priority). 46% of disclosed vulnerabilities had no patch at disclosure. Premium components had 3× more Known Exploited Vulnerabilities than free ones, and the weighted median time to first exploit is 5 hours. A separate 217-plugin audit (Appycodes) flags page builders, WooCommerce extensions, membership/LMS, and marketing/popup plugins as the four highest-risk categories. WordPress core is not the problem — the plugin economy is.
2. Plugin sprawl and performance debt. A typical mature WordPress site accumulates 20–40 plugins, each adding queries, scripts, and update obligations. The result is performance debt (slow TTFB, Core Web Vitals struggles) that requires caching plugins, object caches, and CDNs to paper over. Page builders (Elementor, Divi) in particular produce heavy, div-soup markup. Teams that migrate to Webflow or headless often cite "we replaced 25 plugins with platform features" as the real win.
3. Design and authoring lock-in. Page-builder content is hard to extract — Elementor/Divi store layout as proprietary shortcodes/JSON, so leaving the builder often means rebuilding pages. FSE reduces this (it's standard block markup), but the broader perception of WordPress as "fiddly" persists versus the polished, opinionated UX of Webflow or Framer.
4. Governance and trust. New in this cycle and impossible to ignore: the Automattic vs WP Engine conflict. WP Engine sued Mullenweg/Automattic alleging extortion and abuse of power; Automattic alleges trademark infringement and demanded 8% of WP Engine's gross revenue as a royalty. A Feb 2026 filing claims Automattic planned to target 10 hosting companies with royalty fees. Discovery closed May 2026, motion-to-dismiss arguments are set for June 4, 2026, with a jury trial in September 2027. The episode exposed a real architectural truth: the plugin/theme update mechanism is a single point of failure controlled by one person. That governance risk — not features or price — is now the reason many enterprises hesitate. Forks like ClassicPress (Gutenberg-free) exist but are niche.
The instinct to "rip and replace" is usually wrong for a content-heavy WordPress site. A staged modernization is lower-risk and often sufficient.
| Phase | Action | Why |
|---|---|---|
| 0. Audit | Inventory plugins (PVR/risk scoring), themes, custom code, traffic by URL, Core Web Vitals. Identify the ~10% of plugins doing 90% of the work. | You cannot modernize what you haven't measured; plugin sprawl is the root cause of most pain. |
| 1. Reduce surface | Remove abandoned plugins (anything not updated in 12+ months), consolidate overlapping plugins, replace risky page-builder pages with block-theme patterns where feasible. | Directly cuts the 91%-of-vulns attack surface and performance debt. |
| 2. Harden | Application passwords/OAuth scoped tightly, a reputable WAF/security plugin, automated backups, staging, managed hosting with auto-updates. Assume 5-hour exploit windows. | The threat model is fast and plugin-centric. |
| 3. Modernize the editor | Migrate to a block theme + theme.json design system incrementally; move classic templates to block templates; convert repeated layouts to patterns with overrides. Keep ACF/Block Bindings for structured data. | Removes builder lock-in, reduces plugins, future-proofs against 7.0. |
| 4. Decouple (optional) | Stand up WPGraphQL v2 + smart cache; render the front end with Next.js/Faust.js or Astro; firewall wp-admin. Pilot on a high-traffic section first. | Performance + security; only worth it if you have the engineering capacity to own a build pipeline. |
| 5. AI-enable | Generate llms.txt, enable the MCP Adapter with carefully scoped public abilities, add assistive AI in the editor as desired. | Makes the site agent-readable and (cautiously) agent-operable. |
When NOT to leave: if your pain is plugin sprawl + performance, Phases 1–4 usually solve it for a fraction of a migration's cost, and you keep your content, SEO equity, and editorial team's muscle memory. A 1,000-page migration risks redirects, SEO regressions, and content-fidelity loss.
When leaving is rational: if you are dependent on a fragile page builder, your team is small and non-technical and wants an opinionated visual tool (→ Webflow/Framer), you need true structured content and a typed API as the primary contract (→ a headless-native CMS like Sanity/Contentful/Payload), or governance/trust is a board-level concern. For e-commerce specifically, WooCommerce's plugin-extension model is among the highest-risk categories — Shopify is often the cleaner exit.
theme.json v3 (design tokens, block style variations, shadow/fluid-typography presets) + patterns-with-overrides + the Interactivity API.