El futuro de WordPress: Hoja de ruta 2026-2030 y más allá

En 2015, la conversación de WordPress giraba en torno a la REST API. En septiembre de 2026, con 7.1.1 como versión estable, gira en torno a quién puede editar una entrada a la vez, qué puede invocar un agente de IA y si puedes sacar tu contenido de un constructor cerrado sin copiarlo a mano.

Dos cifras enmarcan el resto de la página. W3Techs midió WordPress en el 40,2% de todos los sitios web y el 58,8% de los sitios con un CMS conocido el 20 de septiembre de 2026, frente al 43,2% de todos los sitios en diciembre de 2025. La hoja de ruta responde a esa pendiente, no la celebra. La base instalada sigue siendo unas siete veces y media la de su competidor más cercano, Shopify con un 7,8%, pero la línea baja.

Lo que sigue es la hoja de ruta contrastada con el núcleo, versión a versión. Donde una función es real, tienes el nombre de la función. Donde sigue siendo una discusión, se dice.

#Tiene WordPress colaboración en tiempo real en 2026

La hoja de ruta de wordpress.org nombra cuatro fases de Gutenberg: Edición más fácil, Personalización, Colaboración y Multilingüe. La fase 3 es la activa y se ha entregado a medias.

Notes sí llegó. El comentario a nivel de bloque aterrizó en WordPress 6.9 el 2 de diciembre de 2025, tras una etapa experimental en el plugin Gutenberg. Se renombró de “block comments” a Notes precisamente para no confundirlo con los comentarios de wp_comments que ven los lectores. La primera versión permite añadir, anidar, resolver y borrar notas sobre un bloque entero, no sobre una selección dentro del bloque. Ver o crear una nota exige la capacidad edit_post, porque las notas solo existen dentro del editor.

WordPress 7.1 lo amplió en lugar de sustituirlo: avisos por correo para las menciones dentro de Notes, enlaces compartibles a revisiones y una corrección para que las notas dejen de colarse en las consultas de feeds de comentarios. Ese último detalle conviene conocerlo antes de abrir un informe de error: un feed de comentarios propio construido sobre 6.9 podía ver registros de notas que nunca pidió.

La colaboración en tiempo real no llegó. Entró en el núcleo como función beta y después se retiró. La llamada a pruebas del 11 de marzo de 2026 pedía instalar WordPress 7.0 Beta 1 en un servidor accesible para otra persona, activar “Enable real-time collaboration” en Ajustes > Escritura y abrir la misma entrada desde dos cuentas. El 8 de mayo de 2026 se retiró de 7.0, y las razones son la parte útil: superficie de código, condiciones de carrera, carga de servidor, eficiencia de memoria y errores que seguían apareciendo en pruebas de fuzzing. Tampoco está activa en 7.1. La capa de sincronización usa Yjs y el bloque core/freeform (Clásico) figura como incompatible. Para la vista versión a versión, mira la hoja de ruta de WordPress 7.1.

Por qué esto importa para los desarrolladores. La llamada a pruebas enuncia la regla sin rodeos: los bloques se sincronizan a través de sus atributos, así que la mayoría admite colaboración por defecto y los que fallan son los que guardan estado del editor en otro sitio. Eso convierte el arreglo en algo concreto. Declara el campo en block.json con su tipo, léelo desde attributes y escríbelo con setAttributes al cambiar, en vez de dejarlo en un useState de React dentro de edit() hasta el blur. Eso ya mejora deshacer, revisiones y autoguardado, y es lo que decide si tu bloque sobrevive cuando la colaboración vuelva.

#Cuándo tendrá WordPress multilingüe en el núcleo

La hoja de ruta describe la fase 4 en una línea: implementación en el núcleo para sitios multilingües. No hay esquema, ni API, ni nota de desarrollo, ni fecha. El Advanced Administration Handbook sigue documentando el multilingüe en WordPress como algo que se resuelve con un plugin.

Lo interesante es el orden, y se dice abiertamente en las actualizaciones de la fase 3: la infraestructura de colaboración tiene que estar resuelta antes de poder diseñar el multilingüe, porque ambas necesitan la misma respuesta a cómo una pieza lógica de contenido se corresponde con varias versiones almacenadas. Hacerlo al revés significaría resolver eso dos veces. Así que la fase 4 no está frenada por falta de interés, sino por una fase 3 que va un ciclo por detrás de su propia beta.

La idea de que el núcleo estandarizará tablas de traducción no aparece en ninguna página de WordPress. Nadie ha publicado un modelo de datos. Lo que sí puedes hacer mientras tanto:

• Identidad de traducción fuera de la plantilla: guárdala en post meta o en una taxonomía, no en la lógica del tema, para poder reasignarla cuando aparezca un modelo del núcleo.
• Nada de locales dentro de los atributos de bloque: un bloque que fija de_DE se convierte en contenido inválido el día que la capa de traducción se mueva.
• WPML y Polylang como dependencias largas: no son un apaño temporal, van a sobrevivir a este punto de la hoja de ruta.

#Puede Data Liberation migrar un sitio a WordPress

La página del proyecto en wordpress.org/data-liberation se publicó el 6 de diciembre de 2023 y nombra cinco fases explícitas:

Esa tabla es la versión honesta de la historia. Las fases 4 y 5, que son las que la gente tiene en mente cuando dice “migración con un clic”, no han empezado.

Lo que sí existe es más estrecho y más útil que el eslogan. El plugin del agente de Data Liberation, liberado como código abierto por Studio de WordPress.com, trae extractores hechos a medida para plataformas concretas: GoDaddy Websites and Marketing, Hostinger Website Builder, HubSpot, Shopify, Squarespace, Webflow, Weebly y Wix. Eso es una lista de extractores para constructores cerrados concretos, no un formato universal. En paralelo, el equipo de Playground está escribiendo nuevos importadores PHP como analizadores en streaming, y el paso importWxr de los blueprints ya puede pasar por el importador de Data Liberation en lugar del antiguo.

La lectura práctica para una agencia: para esas ocho plataformas hay herramienta real que merece una prueba antes de presupuestar una migración manual de contenido. Para cualquier otra, el formato de exportación del núcleo sigue siendo WXR, y WXR sigue sin llevarse tus archivos de medios, tus ajustes de plugins ni tu biblioteca de patrones. Presupuesta en consecuencia.

Conoce más sobre nuestra migración a Next.js y Astro.

#Qué cambia en el admin de WordPress 7.1

Primero, una corrección que circula mucho. MP6 no aterrizó en 2012. Fue un feature plugin propuesto en octubre de 2013 y fusionado en WordPress 3.8, publicado el 12 de diciembre de 2013. Y el admin no lleva congelado desde entonces: 7.1 lo cambió.

Lo que salió en WordPress 7.1 el 19 de agosto de 2026 es la base de un sistema de diseño, descrita en la nota de desarrollo del 31 de julio de 2026. Ahora se registran dos recursos por defecto:

• Una hoja de estilos wp-theme con tokens semánticos como propiedades personalizadas CSS, con nombres del patrón --wpds-color-background-surface-neutral-strong, --wpds-border-radius-lg, --wpds-dimension-padding-2xl.
• Un handle de script wp-theme que exporta un componente React ThemeProvider del paquete @wordpress/theme.

ThemeProvider acepta cinco props: color.primary y color.background como colores semilla (hex, rgb, rgba o un color con nombre de CSS), cursor.control, cornerRadius con los preajustes none, subtle, moderate y pronounced, y isRoot para aplicar el tema en la raíz del documento.

Otros tres cambios de 7.1 en el admin que aparecerán en tu gestor de incidencias antes que en un blog:

1. La prop __next40pxDefaultSize ha terminado su recorrido: en 7.1 no hace nada, se sigue aceptando y se ignora en vez de eliminarse. Los controles de formulario se renderizan a 40px pase lo que pase, así que cualquier pantalla del admin cuyo espaciado estuviera ajustado al valor antiguo se desplaza.
2. wp_get_tooltip() y wp_get_toggletip() te dan tooltips accesibles como función del núcleo en vez de una reimplementación por plugin.
3. La cabecera de fila de la tabla de entradas pasó de la columna de la casilla a la columna del título, una corrección de accesibilidad que cambia lo que anuncia un lector de pantalla en cada fila.

Lo que 7.1 no es: un sustituto de wp-admin, un panel para clientes ni una entrega con marca blanca. Tokens y un componente proveedor son la apertura, no el rediseño terminado. Planifica un admin de cara al cliente asumiendo que esa capa sigue siendo tuya.

Descubre más sobre rediseño WordPress.

#Qué debe aprender un desarrollador WordPress en 2026

Si quieres ser un desarrollador WordPress en 2030, hay tres cosas concretas y una afirmación que conviene tirar.

1. La Abilities API, publicada en 6.9. Es el registro que permite a plugins, al núcleo y a agentes externos descubrir qué puede hacer un sitio. Enganchas wp_abilities_api_init, llamas a wp_register_ability() con un nombre con espacio de nombres del tipo mi-plugin/mi-habilidad, y aportas un callback de ejecución y otro de permisos con esquemas tipados de entrada y salida. Las habilidades son privadas por defecto: show_in_rest es false salvo que lo cambies, y solo entonces aparecen bajo el espacio REST wp-abilities/v1. Si de toda esta hoja de ruta vas a aprender una sola API, es esta.
2. React, en concreto la capa de datos del editor. JSX es la mitad fácil. La mitad que decide si tu bloque sobrevive a la colaboración y al nuevo admin es @wordpress/data, los esquemas de atributos en block.json y ahora @wordpress/ui y @wordpress/theme para superficies de administración que siguen los tokens del núcleo en lugar de pelearse con ellos.
3. PHP, que no se va. Los dos puntos de extensión más nuevos del núcleo se registran desde PHP. Saber JavaScript no te exime de saber dónde vive el hook.

Y la afirmación que conviene tirar: no existe una “API canónica” que haga fácil el WordPress headless. Está la REST API, está WPGraphQL como plugin y ahora está la Abilities API para llamadas orientadas a agentes. Son tres contratos distintos con tres historias de mantenimiento distintas, y elegir entre ellos sigue siendo una decisión de arquitectura tuya.

#Cómo afecta la hoja de ruta de WordPress a los plugins

La hoja de ruta no solo afecta al núcleo; cambia cómo los plugins se apoyan en la plataforma. Pero conviene separar lo que ya obliga a actuar de lo que sigue siendo condicional.

#Hay que adaptar los plugins a la colaboración en tiempo real

Mientras la edición simultánea no vuelva al núcleo, nada te obliga a rehacer un plugin. Lo que sí puedes hacer hoy, porque vale igual sin colaboración, es que los editores de tablas, constructores de formularios y herramientas de SEO guarden su estado en los atributos del bloque y no en estado local de React. Es el mismo requisito que pedía la llamada a pruebas de 7.0 Beta 1, y también es lo que hace que deshacer y las revisiones funcionen bien.

#Hay que adaptar los plugins al multilingüe del núcleo

Aquí no hay nada que preparar contra una API, porque no hay API. Lo único accionable es no encadenarte: mantén la identidad de traducción en meta o taxonomía y no metas cadenas de idioma dentro de los atributos de los bloques. Cualquier lista de “APIs de traducción estandarizadas” del núcleo es, a día de hoy, invención.

#Qué IA trae el núcleo de WordPress 7.0

El AI Client se fusionó en WordPress 7.0. La propuesta de fusión del 3 de febrero de 2026 describía infraestructura agnóstica del proveedor: un constructor de prompts en PHP, una abstracción de proveedor y modelo, almacenamiento de credenciales compartido entre plugins, endpoints REST y una API JavaScript, y filtros para permitir o denegar configuraciones de prompt. Se aceptó a condición de que el flujo de Connectors saliera con ella, y 7.0 trae ambas cosas.

El SDK vive en wp-includes/php-ai-client/, con sus dependencias empaquetadas bajo el espacio de nombres WordPress\AiClientDependencies\*; el pegamento de WordPress encima (el constructor de prompts, el resolutor de funciones de habilidades) vive en wp-includes/ai-client/. La pantalla de Connectors tiene su propio archivo de admin, wp-admin/options-connectors.php, marcado @since 7.0.0 en trunk.

La consecuencia práctica es pequeña de enunciar y grande en mantenimiento: dejas de empaquetar una clave de API y un cliente HTTP en cada plugin que quiere hablar con un modelo. Lo que no hay en el núcleo es generación de páginas a partir de una descripción, optimización de contenido ni actualizaciones predictivas. Eso sigue siendo territorio de plugins.

Explora nuestros servicios de SEO, GEO y AEO para WordPress y comercio con IA en WordPress.

#Qué pasó con la colaboración en tiempo real después de WordPress 7.0

La retirada no cerró el trabajo, lo sacó de la rama de la versión. El 3 de junio de 2026 el equipo del núcleo anunció un programa de pruebas de edición colaborativa para 7.1: quienes se apuntan usan la última versión del plugin Gutenberg, activan la colaboración en Ajustes > Escritura e informan en el canal de Slack #collaborative-editing-outreach durante el ciclo de 7.1, al menos hasta el 18 de agosto de 2026. La entrada del equipo de Hosting del mismo día pidió a los proveedores de alojamiento que invitaran a sus propios clientes, para probar la función en muchas configuraciones de servidor y no en una sola. Encaja con los motivos de la retirada: la carga de servidor y la eficiencia de memoria dependen del alojamiento.

Dos repositorios muestran hacia dónde fue la ingeniería después. Gutenberg Sync Engines, creado el 10 de agosto de 2026, se describe como una comparación de posibles motores de sincronización y transportes para la colaboración en tiempo real de Gutenberg. El plugin experimental Presence API, publicado en wordpress.org desde el 21 de julio de 2026 y que requiere WordPress 7.0, registra qué usuarios han iniciado sesión, en qué pantalla del admin están y qué entradas están editando. Mueve esos datos a través de la Heartbeat API hasta una tabla propia, wp_presence, con un TTL de 150 segundos, y guarda allí los bloqueos de entrada en lugar de en post meta, de modo que mantener un bloqueo ya no deja obsoletas las consultas de entradas en caché. La versión 0.18.1 salió el 13 de octubre de 2026.

El resumen de la reunión de Presence API del 12 de octubre de 2026 fija el listón para una propuesta al núcleo: tres proyectos externos que usen la API y ocho semanas sin un cambio incompatible, contadas desde la versión 0.17.0, lo que deja el 3 de diciembre como fecha más temprana. Los bloqueos de entrada son el primer consumidor y Gutenberg Sync Engines el primer proyecto externo. No se nombra ninguna versión de WordPress como objetivo. Si tu plugin lee o escribe el post meta _edit_lock, este es el trabajo que conviene seguir, porque los bloqueos de entrada son justo lo que el plugin traslada.

#Cuándo sale WordPress 7.2

La convocatoria de voluntarios del 12 de agosto de 2026, publicada por Jeffrey Paul, propone el 9 de diciembre de 2026 como fecha de lanzamiento final y la califica de flexible. El desarrollo alfa empezó el 10 de agosto de 2026. Los hitos propuestos avanzan semana a semana:

La página de la hoja de ruta, modificada por última vez el 20 de agosto de 2026, sitúa 7.2 el 10 de diciembre de 2026 y advierte de que las fechas proyectadas solo sirven para una planificación aproximada. También indica que las funciones nuevas se congelan un mes antes de cada versión. La convocatoria enumera roles (líder de la versión, coordinación, líderes técnicos, líder de triaje, líder de pruebas), pero ninguna función. A mediados de octubre no hay alcance publicado para 7.2, así que cualquier cosa presentada como novedad de 7.2 antes de la Beta 1 es una suposición. Para planificar en una agencia, las fechas útiles son las release candidates: prueba los sitios de clientes y los bloques propios contra la RC1 la semana del 17 de noviembre, no el día del lanzamiento.

#Cómo preparar plugins y bloques para WordPress 7.1

Sin adivinar el futuro, esto es lo que ya se puede hacer con lo que hay publicado:

1. Declara los atributos de bloque en block.json con su tipo y escríbelos con setAttributes. Es la condición que la propia llamada a pruebas puso para que un bloque sincronice.
2. Registra tus capacidades con la Abilities API en lugar de inventar un endpoint REST propio para que un agente te llame, y deja show_in_rest en false hasta que sepas quién consume esa habilidad.
3. Consume los tokens --wpds- en las pantallas de administración propias, en vez de fijar colores y radios a mano que se desalinearán en la siguiente versión.
4. Revisa el espaciado de tus pantallas de admin contra los controles de 40px, porque __next40pxDefaultSize ya no cambia nada.

WordPress no se está frenando, pero tampoco esprinta: una función de colaboración entregada, otra aplazada, un rediseño del admin en fase de tokens y una fase multilingüe que no ha empezado. Si quieres esa lectura aplicada a tu stack concreto, ese es exactamente el tipo de auditoría que hacemos como desarrolladores WordPress. Contacta con WPPoland.