The future of WordPress: 2026-2030 roadmap and beyond

In 2015, the WordPress conversation was about the REST API. In September 2026, with 7.1.1 as the stable release, it is about who gets to edit a post at the same time, what an AI agent is allowed to call, and whether you can get your content out of a closed builder without hand copying it.

Two numbers frame the rest of this page. W3Techs measured WordPress at 40.2% of all websites and 58.8% of sites with a known CMS on 20 September 2026, down from 43.2% of all websites in December 2025. The roadmap is a response to that slope, not a victory lap. The launch of Cloudflare’s EmDash CMS is one visible piece of the same pressure.

What follows is the roadmap checked against core, release by release. Where a feature is real, you get the function name. Where it is still a discussion, it says so.

#Phase 3: collaboration, what shipped and what did not

The wordpress.org roadmap names four Gutenberg phases: Easier Editing, Customization, Collaboration, Multilingual. Phase 3 is the active one, and it has been partially delivered.

Notes shipped. Block-level commenting landed in WordPress 6.9 on 2 December 2025, after an experimental run in the Gutenberg plugin. It was renamed from “block comments” to Notes specifically to keep it distinct from the wp_comments feature readers use. The first release covers adding, threading, resolving and deleting notes on a whole block, not on a selection inside a block. Viewing or creating one requires the edit_post capability, because notes only exist inside the post editor.

WordPress 7.1 extended it rather than replacing it: email notifications for at-mentions inside Notes, shareable revision links, and a fix so Notes no longer leak into comment feed queries. That last one is the sort of detail worth knowing before you file a bug: a custom comment feed built on 6.9 could see note records it never asked for.

Real-time collaboration did not ship. It reached core as a beta feature and was then pulled. The 11 March 2026 call for testing asked people to install WordPress 7.0 Beta 1 on a server somebody else could reach, switch on “Enable real-time collaboration” under Settings > Writing, and open the same post from two accounts. On 8 May 2026 it was removed from 7.0, and the reasons given are the useful part: surface area, race conditions, server load, memory efficiency, and bugs that kept surfacing through fuzz testing. It is not enabled in 7.1 either. The sync layer is built on Yjs, and the core/freeform (Classic) block is listed as incompatible. For the release-by-release view, see the WordPress 7.1 roadmap.

The part that touches your code. The test call states the rule plainly: blocks sync through their attributes, so most blocks support collaboration by default, and the ones that break are the ones holding editor state somewhere else. That makes the fix concrete rather than speculative. Declare the field in block.json with a type, read it from attributes, and write it with setAttributes on change, instead of parking it in a React useState inside edit() until blur. That already pays off in undo, revisions and autosave, and it is what decides whether your block survives if collaboration returns.

#Phase 4: multilingual, still a name on a list

The roadmap describes phase 4 in one line: core implementation for multilingual sites. There is no schema, no API, no dev note and no date. The Advanced Administration Handbook still documents multilingual WordPress as something you solve with a plugin.

The sequencing is the interesting part, and it is stated openly in the phase 3 updates: the collaboration infrastructure has to be settled before multilingual can be designed, because both need the same answer to how one logical piece of content maps to several stored versions. Doing them in the other order would mean solving that twice. So phase 4 is not blocked by lack of interest, it is blocked by phase 3 not being finished, and phase 3 is a release cycle behind its own beta.

The claim that core will standardise translation tables is not on any WordPress page. Nobody has published a data model. What you can sensibly do while waiting:

• Keep translation identity in post meta or a taxonomy, not baked into template logic, so it can be remapped when a core model appears.
• Do not store a locale string inside block attributes. A block that hardcodes de_DE becomes invalid content the day the translation layer moves.
• Treat WPML and Polylang as long-term dependencies, not stopgaps. They will outlive this roadmap item.

#Data liberation, five phases and the tools that exist now

The project page at wordpress.org/data-liberation was published on 6 December 2023 and names five phases explicitly:

That table is the honest version of the story. Phases 4 and 5, which are the ones people mean when they say “one click migration”, have not started.

What does exist is narrower and more useful than the slogan. The data liberation agent plugin, open sourced by Studio by WordPress.com, ships purpose-built extractors for named platforms: GoDaddy Websites and Marketing, Hostinger Website Builder, HubSpot, Shopify, Squarespace, Webflow, Weebly and Wix. That is a list of scrapers for specific closed builders, not a universal format. In parallel, the Playground team is building new PHP importers as streaming parsers, and the Playground blueprint importWxr step can now route through the Data Liberation importer instead of the legacy one.

The practical read for an agency: for the eight platforms on that list, there is real tooling worth testing before you quote a manual content migration. For anything else, the core export format is still WXR, and WXR still does not carry your media files, your plugin settings or your block pattern library. Budget accordingly.

#The admin redesign, what 7.1 actually gave you

First, a correction that circulates a lot. MP6 did not land in 2012. It was a feature plugin proposed in October 2013 and merged into WordPress 3.8, released 12 December 2013. And the admin has not been frozen since: 7.1 changed it.

What shipped in WordPress 7.1 on 19 August 2026 is a design system foundation, described in the core dev note of 31 July 2026. Two resources are now registered by default:

• A wp-theme stylesheet carrying semantic design tokens as CSS custom properties, named on the pattern --wpds-color-background-surface-neutral-strong, --wpds-border-radius-lg, --wpds-dimension-padding-2xl.
• A wp-theme script handle exporting a ThemeProvider React component from the @wordpress/theme package.

ThemeProvider takes five props: color.primary and color.background as seed colours (hex, rgb, rgba or a CSS named colour), cursor.control, cornerRadius with the presets none, subtle, moderate and pronounced, and isRoot to apply theming at the document root. The dev note’s own example:

import { ThemeProvider } from '@wordpress/theme';
import { Card } from '@wordpress/ui';

function Application() {
	return (
		<ThemeProvider
			color={ { primary: '#3858e9', background: '#11004d' } }
			cornerRadius="pronounced"
		>
			<Card.Root>
				<Card.Content>
					WordPress is designed for everyone.
				</Card.Content>
			</Card.Root>
		</ThemeProvider>
	);
}

Three more 7.1 admin changes that will show up in your issue tracker before they show up in a blog post:

1. The __next40pxDefaultSize prop has finished its journey: as of 7.1 it is a no-op, still accepted and ignored rather than removed. Form controls render at 40px regardless, so any admin screen whose spacing was tuned against the old default shifts.
2. wp_get_tooltip() and wp_get_toggletip() give you accessible tooltips as a core function instead of a per-plugin reimplementation.
3. The post list table row header moved from the checkbox column to the title column, an accessibility fix that changes what a screen reader announces per row.

What 7.1 is not: a replacement for wp-admin, a client dashboard, or a white-label handover. Tokens and a provider component are the opening, not the finished redesign. Plan a client-facing admin on the assumption that you still own that layer.

#What should you learn

Three things are concrete enough to justify study time, and one common claim is not.

The Abilities API, shipped in 6.9. This is the registry that lets plugins, core and external agents discover what a site can do. You hook wp_abilities_api_init, call wp_register_ability() with a namespaced name such as my-plugin/my-ability, and supply an execute callback plus a permission callback with typed input and output schemas. Abilities are private by default: show_in_rest is false unless you set it, and only then do they appear under the wp-abilities/v1 REST namespace at /abilities, /abilities/{name} and /abilities/{name}/run. WordPress 7.0 added the client-side counterpart. Core registers three read-only abilities of its own in wp-includes/abilities.php, all marked @since 6.9.0: core/get-site-info, core/get-user-info and core/get-environment-info. Check the current names in trunk before you code against them, because earlier drafts of this set carried different ones. If you want a single API to learn from this roadmap, it is this one.

The AI Client, merged into 7.0. The merge proposal of 3 February 2026 described provider-agnostic infrastructure: a PHP prompt builder, a provider and model abstraction, credential storage shared across plugins, REST endpoints and a JavaScript API, and filters to allow or disallow prompt configurations. It was accepted on condition that the Connectors flow shipped alongside it, and 7.0 ships both. The SDK itself sits in wp-includes/php-ai-client/, with its vendored dependencies scoped to WordPress\AiClientDependencies\*; the WordPress glue on top of it (the prompt builder, the ability function resolver) sits in wp-includes/ai-client/. The Connectors screen has its own admin file, wp-admin/options-connectors.php, marked @since 7.0.0 in trunk. The practical consequence: you no longer bundle an API key and an HTTP client in every plugin that wants a model.

React, specifically the editor data layer. JSX is the easy half. The half that decides whether your block survives collaboration and the new admin is @wordpress/data, attribute schemas in block.json, and now @wordpress/ui and @wordpress/theme for admin surfaces that follow core tokens rather than fighting them.

And the claim to drop: there is no “canonical API” that makes headless WordPress easy. There is the REST API, there is WPGraphQL as a plugin, and there is now the Abilities API for agent-facing calls. They are three different contracts with three different maintenance stories, and choosing between them is still an architecture decision you have to make yourself.

WordPress is not slowing down, but it is not sprinting either: one collaboration feature delivered, one deferred, an admin redesign at the token stage, and a multilingual phase that has not begun. If you want that read applied to a specific stack, we do exactly this kind of audit as WordPress developers.