WordPress 6.x: novedades, rendimiento y lo que cambia para desarrolladores

WordPress sigue evolucionando: más rápido, más flexible

Las últimas versiones de WordPress han traído cambios significativos tanto para usuarios como para desarrolladores. El editor de bloques (Gutenberg) ha madurado enormemente, el rendimiento del core ha mejorado sustancialmente, y la API de patrones de bloques abre nuevas posibilidades de diseño.

La rama 6.x no fue una versión, sino un ciclo largo: arrancó en mayo de 2022 con WordPress 6.0 «Arturo» y se cerró el 2 de diciembre de 2025 con WordPress 6.9, la última entrega antes del salto a la rama 7. En ese recorrido de tres años y medio el CMS pasó de tener el editor de sitios en fase experimental a ofrecer un sistema de diseño completo: tipografías gestionadas desde el escritorio, patrones sincronizados, controles de estilo por bloque y una API para crear interacciones sin cargar un framework JavaScript.

Si gestionas un sitio corporativo o una tienda online, entender qué aportó cada versión de la rama 6.x no es arqueología. Determina qué funcionalidades tienes ya disponibles sin instalar nada, qué deuda técnica arrastra tu instalación y cuánto trabajo real supone dar el salto a WordPress 7. En este artículo repasamos las novedades que de verdad importan, el impacto medible en rendimiento y qué cambia para quien desarrolla y mantiene proyectos WordPress a diario.

De 6.0 a 6.9: el recorrido completo de la rama

Conviene tener el mapa completo antes de entrar en detalle. Estas son las diez versiones de la serie 6.x y la aportación principal de cada una:

• 6.0 «Arturo» (mayo 2022) — el Full Site Editing llega al core y aparecen los primeros estilos globales.
• 6.1 «Misha» (noviembre 2022) — Twenty Twenty-Three y control de estilos por bloque desde theme.json.
• 6.2 «Dolphy» (marzo 2023) — el editor de sitios sale de la fase beta y se considera estable.
• 6.3 «Lionel» (agosto 2023) — vista previa de plantillas, revisiones de estilos y una tanda importante de optimizaciones.
• 6.4 «Shirley» (noviembre 2023) — Twenty Twenty-Four y los Block Hooks, que permiten insertar bloques mediante código.
• 6.5 «Regina» (marzo 2024) — Font Library para gestionar tipografías desde el admin y la Block Bindings API.
• 6.6 «Dorsey» (julio 2024) — pattern overrides y rollback automático cuando falla la actualización de un plugin.
• 6.7 «Rollins» (noviembre 2024) — Twenty Twenty-Five y la vista Zoom Out para trabajar la composición de página.
• 6.8 «Cecil» (abril 2025) — speculative loading y el cambio del hashing de contraseñas a bcrypt.
• 6.9 (diciembre 2025) — notas por bloque para trabajo en equipo, Abilities API y bloques nuevos como Acordeón.

Las versiones que marcaron un antes y un después

De todas ellas, tres cambian de verdad la forma de trabajar. La 6.2, porque a partir de ahí el editor de sitios deja de ser una apuesta y se puede proponer a un cliente sin advertencias. La 6.5, porque la Block Bindings API abre la puerta a conectar atributos de bloque con campos personalizados sin escribir un bloque a medida. Y la 6.8, porque el speculative loading mejora la percepción de velocidad sin tocar una línea de código y bcrypt cierra un frente de seguridad que llevaba abierto desde 2008.

Full Site Editing: edición completa del sitio

El FSE (Full Site Editing) permite editar headers, footers, templates y archive pages directamente desde el editor de bloques, sin necesidad de código PHP. Los themes basados en bloques como Twenty Twenty-Four demuestran que es posible crear diseños profesionales sin tocar una línea de código.

La pieza que sostiene todo el sistema es theme.json: un único fichero donde se declaran la paleta de colores, la escala tipográfica, los espaciados y qué controles se exponen al usuario en cada bloque. Bien planteado, evita el clásico problema de los sitios que se degradan visualmente a los seis meses porque cada persona que entra al editor aplica sus propios colores y tamaños. Mal planteado, produce lo contrario: un editor donde el cliente no puede tocar nada sin llamar a la agencia.

Impacto para desarrolladores

Para agencias de desarrollo, FSE cambia el modelo: los themes clásicos con template hierarchy PHP siguen funcionando, pero los block themes permiten entregar sitios donde el cliente puede modificar prácticamente todo el diseño desde el admin. Esto reduce el soporte post-lanzamiento pero requiere una buena arquitectura de bloques y patrones.

En la práctica, el trabajo se desplaza. Se dedica menos tiempo a maquetar plantillas PHP y más a diseñar el sistema: definir theme.json, crear una biblioteca de patrones reutilizables, decidir qué controles se bloquean y documentar cómo se monta una página nueva. Es un trabajo más de producto que de encargo puntual, y conviene presupuestarlo como tal.

Block themes o themes clásicos: cómo decidir

No hay una respuesta única. Un block theme encaja cuando el cliente va a publicar con frecuencia, quiere autonomía sobre landings y campañas, y el diseño admite componerse a partir de patrones. Un theme clásico sigue siendo razonable cuando hay lógica PHP compleja, integraciones a medida con un ERP o un CRM, o una tienda con plantillas de WooCommerce muy personalizadas donde migrar a bloques no aporta nada al negocio.

También existe el punto intermedio: mantener el theme clásico y añadir theme.json para unificar estilos y aprovechar el Style Book, que desde WordPress 6.8 está disponible también para themes clásicos con estilos de editor. Es la vía menos disruptiva para proyectos que ya funcionan.

Mejoras de rendimiento en el core

WordPress ha incorporado mejoras importantes de rendimiento: lazy loading nativo de imágenes, atributo fetchpriority para la imagen LCP, carga diferida de scripts con defer y async, y optimizaciones en las consultas SQL del core. Estas mejoras se aplican automáticamente al actualizar.

La incorporación más visible llegó con WordPress 6.8 y el speculative loading. Apoyándose en la Speculation Rules API del navegador, el core precarga en segundo plano las URLs que el usuario tiene más probabilidad de visitar a continuación, de forma que al hacer clic la página ya está lista. El efecto sobre el Largest Contentful Paint percibido es notable y no exige ninguna configuración: viene activo por defecto, con un modo conservador que se puede ajustar por filtro.

WordPress 6.9 continuó por esa línea con mejoras de en torno al 3-6 % respecto a 6.8 en las métricas del equipo de rendimiento. Son cifras modestas leídas de forma aislada, pero acumuladas a lo largo de la rama explican por qué una instalación actualizada rinde bastante mejor que la misma web en 6.0 con idéntico hosting.

Qué no arregla el core por ti

Conviene ser honesto con las expectativas: el core optimiza el core. Si tu web carga cuarenta plugins, tres librerías de iconos y un constructor visual que inyecta 800 KB de CSS, actualizar no va a cambiar el resultado del test de PageSpeed. Los cuellos de botella habituales siguen siendo los mismos de siempre: imágenes sin comprimir ni servir en formatos modernos, plugins que cargan sus assets en todas las páginas, opciones autoloaded desbocadas en la tabla de opciones, y hosting compartido con TTFB alto.

Por eso el orden correcto es actualizar primero y auditar después, con datos reales de campo y no solo de laboratorio. Si quieres ver cómo abordamos ese análisis en profundidad, lo detallamos en nuestra auditoría técnica.

Interactivity API

La Interactivity API es una de las novedades más relevantes para desarrolladores. Permite crear bloques interactivos (acordeones, pestañas, búsqueda en vivo, filtros) sin necesidad de React o frameworks JavaScript pesados. Usa un enfoque declarativo directamente en el markup del bloque.

El planteamiento recuerda a Alpine.js: se añaden directivas data-wp-* al HTML del bloque y un pequeño store en JavaScript se encarga del estado. El resultado se renderiza en servidor y se hidrata en cliente, lo que evita el problema clásico de los bloques hechos con React puro, que se ven vacíos hasta que carga el bundle. Para SEO y para Core Web Vitals la diferencia es sustancial.

Es también la base sobre la que el propio core construye interacciones que antes requerían un plugin: navegación instantánea entre páginas, formularios de búsqueda que se actualizan sin recarga o el bloque Acordeón que llegó en 6.9. Si mantienes bloques a medida antiguos escritos con React, migrarlos a la Interactivity API es una de las inversiones técnicas más rentables que puedes plantear.

Block Bindings API: conectar bloques con datos reales

Llegada en WordPress 6.5 y consolidada en las versiones siguientes, la Block Bindings API resuelve un problema muy concreto: mostrar el valor de un campo personalizado dentro de un bloque estándar sin crear un bloque nuevo. Un párrafo puede vincular su contenido a un meta del post; un botón puede tomar su URL de un campo; una imagen puede apuntar a un adjunto guardado en un custom field.

Para proyectos con contenido estructurado —fichas de producto, directorios, catálogos, portales inmobiliarios— esto elimina buena parte del código a medida que antes hacía falta. Combinada con los pattern overrides de la 6.6, permite montar plantillas reutilizables donde el editor solo rellena los huecos previstos y no puede romper la maquetación.

El aviso, otra vez, es de arquitectura: cuanto más se apoye un sitio en bindings y patrones sincronizados, más importante es documentar el modelo de datos. Un cambio de nombre en un meta puede vaciar medio sitio sin dar ningún error visible.

Seguridad y mantenimiento

Las actualizaciones automáticas de seguridad son más robustas, y el sistema de rollback automático para actualizaciones fallidas reduce el riesgo de sitios rotos. Aun así, recomendamos siempre mantener un proceso de staging/testing antes de actualizar en producción, especialmente en ecommerce.

El cambio de fondo más relevante de toda la rama llegó en la 6.8 con el paso del hashing de contraseñas de phpass a bcrypt, el primer cambio en ese terreno desde 2008. Los hashes se regeneran solos en el siguiente inicio de sesión de cada usuario, sin ninguna acción por tu parte, y elevan de forma considerable el coste de un ataque por fuerza bruta sobre una base de datos filtrada.

Dicho esto, la superficie de ataque real de casi cualquier WordPress no está en el core, sino en los plugins y en las credenciales. La mayoría de incidentes que atendemos empiezan en un plugin sin actualizar o en un usuario administrador con contraseña reutilizada. Si quieres profundizar, lo desarrollamos en nuestra guía de seguridad WordPress para empresas, y el caso de la vulnerabilidad wp2shell ilustra bien cómo un fallo concreto se convierte en un compromiso completo del servidor.

Cómo planificar la actualización sin romper nada

Actualizar WordPress no debería ser un evento. Cuando lo es, casi siempre significa que se ha dejado pasar demasiado tiempo. Un sitio que arrastra dos años sin tocar acumula incompatibilidades de PHP, plugins abandonados y personalizaciones sobre versiones antiguas de hooks que ya no existen.

El orden que funciona

Primero, copia de seguridad completa de ficheros y base de datos, con la restauración probada de verdad —un backup que nunca se ha restaurado no es un backup, es una intención—. Después, clonar a staging replicando la misma versión de PHP que producción, porque buena parte de los errores tras actualizar no vienen del core sino de un salto de versión de PHP no previsto.

A continuación, actualizar por bloques y no todo a la vez: core, luego plugins críticos, luego el resto, revisando el log de errores entre pasos. Si algo falla, sabes exactamente qué lo provocó. Antes de desplegar, probar los flujos que generan ingresos: checkout completo con una pasarela en modo test, formularios de contacto con envío real de correo, login de clientes y áreas privadas.

Errores frecuentes al actualizar

• Actualizar plugins y core el mismo día que se lanza la versión. Esperar dos o tres semanas a la primera versión de mantenimiento evita la mayoría de sorpresas.
• Olvidar el theme hijo. Las personalizaciones aplicadas directamente sobre el theme padre desaparecen en la primera actualización.
• No revisar las funciones obsoletas. Activar WP_DEBUG en staging revela avisos de deprecated que se convertirán en errores fatales dos versiones más adelante.
• Ignorar la caché. Tras actualizar hay que purgar caché de página, de objeto y de CDN; muchos «fallos» posteriores a una actualización son simplemente HTML antiguo servido desde caché.
• No monitorizar después. Las primeras 48 horas concentran casi todos los problemas: errores PHP, caída de conversiones o Core Web Vitals empeorados.

De la rama 6.x a WordPress 7: qué cambia ahora

WordPress 6.9 cerró la serie en diciembre de 2025 y el proyecto dio el salto de numeración con WordPress 7.0 «Armstrong», publicado el 20 de mayo de 2026 tras retrasarse desde la fecha inicialmente prevista en abril. Es el cambio de mayor calado desde la llegada de Gutenberg.

Los ejes principales son tres. Un rediseño del escritorio, con paleta de comandos, gestión de tipografías en una página propia y revisiones visuales. Una capa de IA en el core, articulada sobre el AI Client, la Abilities API que ya asomaba en 6.9 y un hub de conectores para proveedores. Y la edición colaborativa en tiempo real, con varios usuarios sobre el mismo contenido, sincronización por polling HTTP por defecto y un hook para que hostings y plugins añadan WebSocket.

Si estás en cualquier versión de la rama 6.x, el salto es perfectamente asumible siempre que se haga con método. Lo hemos detallado paso a paso en la guía para actualizar a WordPress 7 sin romper tu web, y las novedades más recientes de la rama las repasamos en el análisis de WordPress 7.1 y su capa de IA. Para equipos que trabajan varias personas sobre el mismo contenido, merece la pena revisar también cómo funcionan ahora las revisiones y el visual diff.

¿Qué significa para tu negocio?

WordPress sigue siendo la base de algo más del 40 % de la web. Las mejoras en rendimiento y edición hacen que sea una plataforma cada vez más competitiva para proyectos profesionales. Si tienes un sitio WordPress, mantenerlo actualizado no es solo cuestión de seguridad, sino de rendimiento y funcionalidades.

En términos prácticos, quedarse en una versión antigua tiene tres costes que rara vez se contabilizan. El primero es de riesgo: cada mes sin actualizar amplía la ventana de exposición a vulnerabilidades ya publicadas y con exploit disponible. El segundo es de velocidad de entrega: funcionalidades que hoy vienen en el core siguen resolviéndose con plugins que hay que pagar, mantener y auditar. El tercero es de deuda acumulada: cuanto más se retrasa el salto, más caro y más arriesgado se vuelve, hasta que deja de ser una actualización y se convierte en un rehacer.

La alternativa razonable es tratar las actualizaciones como una rutina de mantenimiento con calendario, ventana de despliegue y responsable asignado, igual que las copias de seguridad. No es glamuroso, pero es lo que separa a los sitios que envejecen bien de los que un día dejan de funcionar sin avisar.

Conclusión

La rama 6.x fue el ciclo en el que WordPress dejó de ser un gestor de contenidos con un editor encima y pasó a ser un sistema de diseño completo. El Full Site Editing maduró, el rendimiento mejoró de forma sostenida versión a versión, y las nuevas APIs —Interactivity, Block Bindings, Abilities— redujeron drásticamente la cantidad de código a medida necesaria para resolver requisitos habituales.

Para quien desarrolla, el trabajo se ha desplazado del maquetado a la arquitectura: definir sistemas de diseño, bibliotecas de patrones y modelos de datos que el cliente pueda usar sin romper nada. Para quien gestiona un negocio, la conclusión es más simple: una instalación actualizada rinde mejor, es más segura y cuesta menos de evolucionar que una congelada tres años atrás.

Si no tienes claro en qué punto está tu sitio ni qué implicaría ponerlo al día, un diagnóstico técnico previo suele resolver la duda en pocos días y evita decisiones tomadas a ciegas.