La pregunta que llega a nuestra bandeja de entrada desde mayo no es «¿qué trae WordPress 7?». Es otra, más incómoda: «¿me conviene actualizar a WordPress 7 ya o espero?». Detrás suele haber un responsable de IT con veinte o doscientos sitios en producción, un contrato de mantenimiento firmado y la certeza de que si algo se cae un martes por la mañana, el teléfono va a sonar en su mesa. WordPress 7.0 «Armstrong» se publicó el 20 de mayo de 2026 y trae cambios estructurales en el editor que no se ven en una captura de pantalla, pero que sí se notan cuando un maquetador deja de renderizar o una metabox clásica desaparece del panel.
Este artículo no es un listado de novedades. Ese post ya lo escribimos: si buscas el detalle técnico de cada API, cada hook y cada cambio de comportamiento, tienes el repaso completo en nuestra guía de novedades de WordPress 7.0 Armstrong para desarrolladores. Aquí vamos a otra cosa. Aquí te contamos qué decisión tomar, en qué orden ejecutarla y qué respuesta darle a dirección cuando pregunte por qué hay que invertir horas en una actualización que, sobre el papel, «solo cambia el editor».
Lo resumimos por adelantado, porque tu tiempo vale: actualizar a WordPress 7 merece la pena, pero no el día del lanzamiento y no sin staging. Hay tres o cuatro puntos de fricción reales —iframes en el editor, WooCommerce, plugins con metaboxes clásicas y el salto de PHP— y todos son gestionables si los abordas en el orden correcto. Lo que no es gestionable es descubrirlos en producción un viernes. Vamos por partes.
Índice de la serie
1. Qué es WordPress 7 y por qué esta versión sí importa
WordPress 7.0 abre oficialmente la Fase 3 de Gutenberg, la dedicada a la colaboración y a los flujos de trabajo editoriales. Las fases anteriores fueron el editor de contenido (fase 1) y la edición completa del sitio (fase 2). La tercera es la que convierte a WordPress en algo parecido a una herramienta de trabajo en equipo, con historial, permisos y procesos, en lugar de un editor individual con un botón de publicar.
Que sea un salto de versión mayor no es cosmético. Los números de versión en WordPress han sido históricamente arbitrarios —el paso de 5.9 a 6.0 respondió más a la narrativa de la edición completa del sitio que a una ruptura técnica—, pero aquí hay un cambio de arquitectura debajo. El editor pasa a trabajar con iframes internos, se consolida una nueva capa de datos para las pantallas de administración y aparece infraestructura nueva para integrar servicios externos de IA. Varias voces de la comunidad hispana han calificado esta versión como la más importante desde 2018, cuando llegó Gutenberg. Es una comparación exagerada en cuanto a impacto visible para el editor de contenidos, pero razonable si miras la superficie de código que se toca.
El contexto también cuenta. 2025 fue un año atípico para el proyecto: disputas legales, tensión en la comunidad y una única versión publicada en doce meses. Muchos equipos se acostumbraron a que WordPress no se moviera. En 2026 el ritmo se recupera con tres versiones previstas —7.0, 7.1 y 7.2—, lo que significa que tu política de actualizaciones vuelve a necesitar un calendario real. Si has estado congelando versiones durante año y medio, el trabajo acumulado sale ahora todo junto, y ese es precisamente el escenario en el que las actualizaciones se rompen.
Para el responsable técnico, el resumen es este: WordPress 7 no te obliga a hacer nada hoy, pero fija el terreno sobre el que se van a construir las próximas dos versiones. Cuanto más tarde entres, más grande será el salto. Y cuanto más grande el salto, menos capaz serás de aislar la causa cuando algo falle.
2. Las cinco novedades que de verdad cambian tu día a día
De la lista larga de cambios, hay cinco que un equipo que mantiene sitios en producción va a notar en la primera semana. Las demás son mejoras internas que agradecerás sin darte cuenta. Estas cinco cambian procesos, y por eso conviene que las conozca también quien no toca código.
2.1. Visibilidad por dispositivo: el cambio más práctico de todos
Ahora puedes decidir, bloque a bloque, en qué tamaños de pantalla se muestra un elemento, sin plugins de terceros y sin CSS a medida. Fernando Tellado, una de las referencias en el ecosistema WordPress en español, sostiene que este es el cambio más relevante del día a día de toda la versión, y compartimos esa lectura sin reservas.
El motivo es puramente económico. Hasta ahora, ocultar un banner en móvil o mostrar un bloque distinto en escritorio implicaba o bien una clase CSS personalizada que alguien tenía que documentar, o bien un plugin adicional que había que mantener, actualizar y auditar. Multiplícalo por el número de sitios que gestionas. Cada plugin retirado del stack es una dependencia menos, una superficie de ataque menor y una casilla menos en tu inventario. Lo desarrollamos en detalle en el artículo sobre visibilidad por dispositivo y diseño responsive en WordPress 7, incluyendo qué plugins puedes desinstalar sin romper nada y cuáles conviene mantener.
2.2. Conectores de IA: infraestructura, no un botón mágico
Aquí es donde más ruido se ha generado y donde más expectativas mal calibradas hemos tenido que corregir en reuniones con clientes. WordPress 7 no incorpora un asistente que te escriba los posts. Lo que llega es infraestructura: un panel centralizado de credenciales en Ajustes > Conectores, la nueva Abilities API y un adaptador MCP para que agentes externos puedan interactuar con el sitio de forma estandarizada.
De serie se contemplan OpenAI, Google Gemini y Anthropic Claude, pero cada proveedor requiere instalar su plugin específico desde WordPress.org. Y el punto que hay que dejar claro en cualquier reunión de presupuesto: consumes tu propia clave API y la pagas por uso. No es gratis, no viene incluido y no sustituye a los plugins de IA de pago que ya tengas contratados. Existe además un plugin experimental «AI» del propio equipo de WordPress que genera extractos, textos alternativos, imágenes destacadas y títulos, pero está pensado para pruebas, no para producción.
El valor real está en la estandarización. Hasta ahora, cada plugin de IA guardaba las claves donde le parecía, con los riesgos de seguridad que eso implica. Centralizarlas es una mejora de gobierno. Si vas a montarlo, la configuración paso a paso está en cómo configurar los conectores de IA de WordPress 7, y el análisis de la capa cliente lo cubrimos en WP AI Client y la IA nativa de WordPress.
2.3. Nuevo escritorio y DataViews
Las pantallas de administración se reconstruyen sobre DataViews, la capa de listados que ya se probó en la edición del sitio. Vistas configurables, filtros persistentes, cambio entre tabla y cuadrícula. Para un editor puntual es un cambio estético; para alguien que gestiona cientos de entradas, productos o formularios al día, cambia el flujo de trabajo entero.
El coste está en la formación y en el soporte. Si tienes clientes con usuarios poco técnicos, cuenta con una tanda de tickets del tipo «no encuentro donde estaba». Merece la pena preparar una nota interna antes de actualizar en lugar de después. Repasamos las diferencias pantalla por pantalla en el nuevo escritorio de WordPress 7 y las DataViews.
2.4. Revisiones con Visual Diff
El historial de revisiones deja de mostrar solo diferencias de texto plano y pasa a enseñar el cambio renderizado. Suena menor hasta que te toca auditar quién tocó qué en una página de producto la semana pasada. Para equipos con varios editores, o para agencias que responden ante un cliente por cada modificación, esto reduce el tiempo de diagnóstico de forma tangible. Es también la primera pieza visible de esa Fase 3 de flujos de trabajo. Lo analizamos, con sus limitaciones actuales, en revisiones con Visual Diff en WordPress 7.
2.5. Bloques y medios
El quinto grupo es el menos vistoso y el que más afecta al rendimiento: mejoras en el manejo de medios, en el comportamiento de varios bloques del core y en cómo se cargan los recursos del editor. Si tu prioridad son las métricas de rendimiento —y si trabajas SEO, lo son—, aquí hay ganancias que se acumulan con lo que ya conseguiste optimizando Core Web Vitals. El detalle está en bloques, medios y rendimiento en WordPress 7.
3. Lo que se cayó por el camino: la colaboración en tiempo real
Si has leído artículos publicados en abril de 2026 anunciando la edición colaborativa en tiempo real al estilo Google Docs, están desactualizados. La colaboración en tiempo real no está en WordPress 7.0. Matt Mullenweg la retiró el 8 de mayo de 2026 y la RC3, publicada ese mismo día, ya salió sin ella. Se pospone a la 7.1.
Los motivos que se dieron son técnicos y, honestamente, sensatos. Cuatro frentes: superficie de ataque, condiciones de carrera, carga de servidor y eficiencia de memoria. Merece la pena desglosarlos porque explican por qué esta función es mucho más difícil de lo que parece.
La superficie de ataque crece porque la edición concurrente exige un canal persistente entre navegador y servidor, con autenticación y autorización en cada mensaje, no solo en la carga inicial de la página. Cualquier fallo ahí es un vector nuevo en millones de instalaciones. Las condiciones de carrera aparecen cuando dos usuarios modifican el mismo bloque en milisegundos consecutivos: resolver eso bien requiere estructuras de datos que garanticen convergencia, y eso es infraestructura seria, no un parche. La carga de servidor y la memoria son la consecuencia directa: mantener sesiones abiertas y estado sincronizado en el hosting compartido donde vive buena parte del ecosistema WordPress es un problema de escala real.
Nuestra lectura como agencia: fue la decisión correcta. Y coincidimos con Tellado en que la colaboración en tiempo real la habría usado poca gente. La mayoría de nuestros clientes tienen uno o dos editores que trabajan en momentos distintos del día. El conflicto de edición simultánea es un problema real en redacciones grandes y prácticamente inexistente en una pyme con un responsable de marketing. Si estabas justificando la actualización ante dirección apoyándote en esta función, cambia el argumento antes de la reunión.
4. Requisitos reales antes de actualizar
Vamos a la parte que determina si tu actualización va a ser aburrida —el objetivo— o interesante. Estos son los cuatro frentes donde hemos visto fricción real.
4.1. PHP: mínimo 7.4, recomendado 8.3
Conviene desmentirlo de entrada porque circula mucho: WordPress 7 no exige PHP 8. El mínimo sigue siendo PHP 7.4 y el recomendado es PHP 8.3. Puedes actualizar el core sin tocar tu versión de PHP y funcionará.
Dicho lo cual, quedarse en 7.4 es una mala idea por razones que no tienen nada que ver con WordPress 7. PHP 7.4 lleva años sin soporte de seguridad oficial: cualquier vulnerabilidad descubierta en el intérprete no se parchea, y tu única defensa son los backports que tu proveedor de hosting decida aplicar, si es que los aplica. Estás construyendo encima de una base que nadie mantiene. A eso se suma que el rendimiento de PHP 8.x es notablemente superior, que cada vez más plugins declaran 8.0 o 8.1 como mínimo, y que el salto solo se hace más difícil cuanto más se pospone.
Nuestra recomendación operativa: haz el salto a PHP 8.3 antes de actualizar a WordPress 7, y como proyecto separado. Si haces ambas cosas a la vez y algo se rompe, no sabrás qué lo rompió. Si tienes código legacy que no sabes si sobrevivirá, el ajuste fino del entorno lo cubrimos en la guía de optimización de PHP-FPM y configuración para PHP 8.
4.2. Maquetadores e iframes
El editor de WordPress 7 usa iframes internos para aislar el lienzo de edición. Es una decisión técnicamente correcta —evita que los estilos del administrador contaminen la vista previa— pero rompe suposiciones que muchos maquetadores llevaban años haciendo. Elementor, Divi y Bricks son los casos a vigilar. Los síntomas típicos son estilos que no se aplican en la vista de edición, controles que dejan de responder o scripts que buscan elementos del DOM que ahora viven dentro del iframe.
No estamos diciendo que tu maquetador vaya a fallar: los principales han ido publicando actualizaciones de compatibilidad. Estamos diciendo que debes verificarlo en staging antes de tocar producción, y que si tu maquetador lleva meses sin actualizarse, esa es tu señal de alarma. Si trabajas con Elementor, el contexto del cambio de arquitectura de su lado lo explicamos en el análisis del nuevo editor atómico de Elementor 4.
4.3. WooCommerce
Regla simple y sin matices: no actualices una tienda sin probarlo antes en staging. WooCommerce tenía actualizaciones de compatibilidad pendientes en el momento del lanzamiento de WordPress 7, y una tienda no es un sitio corporativo. Un fallo en la ficha de producto o en el checkout se traduce en pedidos perdidos que puedes cuantificar en euros esa misma tarde.
El riesgo real en ecommerce no suele estar en WooCommerce, que va bien mantenido, sino en la cola de plugins satélite: pasarelas de pago, gestión de envíos, sincronización con el ERP, plugins de facturación. Cualquiera de ellos puede llevar sin tocarse desde hace dos años. Revisa el inventario con criterio antes de mover nada; si necesitas una referencia de qué stack es defendible hoy, la tienes en nuestro repaso de plugins imprescindibles para un ecommerce profesional.
4.4. Plugins con metaboxes clásicas
Los plugins que registran metaboxes con la API clásica y esperan poder inyectar JavaScript directamente en el contexto del editor son los siguientes en la lista de riesgo, por el mismo motivo del iframe. Aquí entran plugins de SEO, de campos personalizados y de integraciones a medida escritas hace años por alguien que ya no está en la empresa.
El escenario que más nos preocupa no es el plugin comercial popular, que se actualizará. Es el desarrollo interno sin mantenimiento activo. Si en tu inventario hay plugins propios, esos son los que tienes que probar primero y los que más horas te van a costar.
¿Vas a actualizar a WordPress 7 y no quieres descubrir los problemas en producción?
En Keliam auditamos el sitio antes de tocar nada —plugins, versión de PHP, maquetador, integraciones— y ejecutamos la actualización con staging, backup y plan de rollback. Si son varios sitios, lo gestionamos como servicio recurrente.
5. Checklist para actualizar a WordPress 7 paso a paso
Este es el procedimiento que seguimos internamente. Está pensado para que cualquier persona del equipo pueda ejecutarlo y para que, si algo falla, el punto de retorno esté siempre a un paso de distancia.
5.1. Levanta un staging que se parezca a producción
Un staging con datos de hace seis meses y la mitad de los plugins desactivados no sirve para nada. Necesitas una copia reciente de la base de datos, la misma versión de PHP, la misma configuración de servidor y el mismo conjunto de plugins activos. La mayoría de sustos post-actualización que hemos visto venían de entornos de prueba que no reproducían producción.
5.2. Inventaría los plugins con criterio
Exporta la lista completa y clasifica cada plugin en cuatro columnas: fecha de la última actualización, compatibilidad declarada, criticidad para el negocio y responsable de mantenerlo. Los que lleven más de un año sin actualizarse y no sean críticos, desinstálalos ahora. Es el mejor momento del año para limpiar. Cada plugin que retiras es riesgo que no vas a tener que probar.
5.3. Backup completo y verificado
Archivos y base de datos, con la copia almacenada fuera del servidor. Y el matiz que la gente se salta: verifica que el backup restaura. Una copia que nunca has probado a restaurar no es un backup, es una carpeta con esperanza dentro. Restáurala en el staging y compruébalo.
5.4. Orden de actualización
El orden importa porque determina tu capacidad de aislar el fallo. Nosotros lo hacemos así:
- PHP a 8.3, si aún no estás ahí. Como proyecto independiente y con su propia validación.
- Plugins y temas a su última versión estable, con WordPress todavía en 6.x. Uno a uno si son críticos.
- WooCommerce y su ecosistema, si es una tienda, con pruebas de checkout reales.
- Core de WordPress a 7.0.x.
- Segunda ronda de plugins, porque algunos publican su versión compatible después del salto de core.
5.5. Verificación post-actualización
Define una lista de comprobaciones antes de actualizar, no después: se te ocurren mejores pruebas cuando no tienes prisa. Como mínimo, revisa el editor con las plantillas que uses de verdad, el formulario de contacto de punta a punta incluyendo la recepción del correo, el proceso de compra completo si hay tienda, las integraciones con sistemas externos, el rendimiento comparado con la medición previa y los errores del log de PHP. Ese último punto es el que más avisos tempranos da y el que casi nadie mira.
5.6. Plan de rollback
Antes de pulsar actualizar, ten escrito quién revierte, cómo y en cuánto tiempo. Si el proceso de vuelta atrás tarda más de quince minutos, el problema no es WordPress 7: es tu infraestructura. Y si gestionas la web de un cliente, comunícale la ventana de mantenimiento aunque estés convencido de que no va a pasar nada. La diferencia entre una incidencia y una crisis casi siempre es que alguien estaba avisado.
6. WordPress 7.0.1 y por qué conviene esperar a las minor
El 9 de julio de 2026 se publicó WordPress 7.0.1, una versión de mantenimiento con 31 bugs corregidos entre el core y el editor de bloques. Esa cifra es, por sí sola, el mejor argumento a favor de no actualizar el día del lanzamiento.
Entre las correcciones hay una que ilustra perfectamente el tipo de fallo que arruina una tarde: una regresión en wp_kses() que corrompía las declaraciones background-image: url(...) y las dejaba convertidas en style=")". Traducido: fondos de sección que desaparecen en contenido guardado con estilos en línea. En un sitio corporativo con cabeceras de imagen en varias landings, el efecto visual es inmediato y el diagnóstico nada evidente, porque el contenido no se ha borrado, solo se ha sanitizado mal.
La 7.0.1 arregla además una incompatibilidad con PHP 8.5 en una función del core relacionada con los adjuntos de imagen —relevante si tu hosting va por delante en versiones de PHP—, mejora la accesibilidad de la interfaz de revisiones visuales, corrige un fallo en el callback de copiar al portapapeles y resuelve un bug del bloque de navegación cuando se usa Page List dentro de submenús. Es decir: cosas cotidianas, no casos extremos.
Nuestra política con clientes es sencilla y no ha cambiado con esta versión. En sitios críticos esperamos a la primera o segunda minor antes de actualizar el core, salvo que haya un parche de seguridad de por medio, en cuyo caso la prioridad se invierte y actualizamos ya. Las actualizaciones de seguridad no se posponen nunca, y ese principio lo desarrollamos en nuestra guía de seguridad de WordPress para empresas. Para las funcionales, la paciencia sale gratis; la prisa no.
7. Calendario: qué esperar de 7.1 y 7.2
2026 recupera el ritmo de tres versiones anuales tras el paréntesis de 2025. Después de la 7.0 llegarán la 7.1 y la 7.2, y eso condiciona cómo planificas.
La 7.1 es la que se lleva la colaboración en tiempo real que se cayó de la 7.0. Conviene tomárselo con cautela: una función que se retira en RC3 por problemas de seguridad y arquitectura no vuelve resuelta en cuestión de semanas. Si tu caso de uso depende de la edición simultánea, no planifiques nada sobre esa fecha hasta ver la beta funcionando. Y aun cuando llegue, esperamos que sea la versión en la que no quieras estar el primer mes: una función que abre canales persistentes y toca el guardado de contenido merece un ciclo entero de minor antes de entrar en producción.
La 7.2 debería consolidar lo que la 7.1 abra, con el patrón habitual del proyecto: la versión mayor introduce, la siguiente pule. Para tu planificación anual, la conclusión práctica es que WordPress vuelve a moverse a velocidad normal y que necesitas ventanas de mantenimiento previstas en el calendario, no reactivas. Si tu organización lleva tiempo funcionando por excepción —actualizar solo cuando algo falla—, este es el año en que ese modelo empieza a costar caro.
Un apunte para quien esté valorando arquitecturas alternativas: si el ciclo de actualizaciones del front-end es tu principal fuente de fricción, quizá el problema no sea la versión de WordPress sino el acoplamiento entre back y front. En ese escenario, merece la pena valorar una arquitectura headless con WordPress y Next.js, donde los cambios del editor no afectan a lo que ve el usuario final. No es la respuesta para todos, pero sí para quien publica mucho y tiene equipo front propio.
Conclusión
WordPress 7 es una versión que merece la actualización, con matices. Aporta cosas que ahorran trabajo real —la visibilidad por dispositivo por encima de todas—, sienta la infraestructura de IA de forma ordenada y abre una fase del proyecto que va a definir los próximos años. Nada de eso justifica actualizar a ciegas.
Si tuviéramos que resumirlo en una recomendación única: audita primero, salta a PHP 8.3 como proyecto separado, prueba en un staging que se parezca de verdad a producción y actualiza el core cuando estés en la 7.0.1 o posterior. Las tiendas WooCommerce y los sitios con maquetadores necesitan una vuelta extra de pruebas, y los desarrollos internos sin mantener son siempre el eslabón que falla.
Y el mensaje para dirección, si te toca defenderlo: esto no es una actualización opcional que se puede posponer indefinidamente. Es mantenimiento preventivo. Cada versión que dejas pasar aumenta el coste y el riesgo de la siguiente, porque los saltos acumulados son exactamente donde se rompen las cosas. Actualizar de forma ordenada, con presupuesto y calendario, es más barato que actualizar de urgencia un viernes por la tarde. Siempre lo ha sido.
Preguntas frecuentes
¿Tengo que actualizar a WordPress 7 obligatoriamente?
No de forma inmediata. WordPress 6.x seguirá recibiendo parches de seguridad durante un tiempo, así que no hay una urgencia crítica esta semana. Pero es un aplazamiento, no una alternativa: cuanto más esperes, mayor será el salto acumulado y más difícil aislar la causa cuando algo falle. Nuestra recomendación es planificarlo dentro del año, no dejarlo para cuando el soporte se acabe.
¿WordPress 7 exige PHP 8?
No. El mínimo requerido es PHP 7.4 y el recomendado es PHP 8.3. Puedes actualizar el core sin tocar PHP. Ahora bien, PHP 7.4 lleva años sin soporte de seguridad oficial, así que estar ahí es un problema con independencia de WordPress 7. Nuestro consejo es hacer el salto a 8.3 antes, y hacerlo por separado para poder aislar cualquier incidencia.
¿Puedo usar ya la edición colaborativa en tiempo real?
No. Se retiró el 8 de mayo de 2026 por superficie de ataque, condiciones de carrera, carga de servidor y eficiencia de memoria, y la RC3 ya salió sin ella. Está pospuesta a la 7.1. Si has leído artículos que la anuncian como disponible, son anteriores al lanzamiento y están desactualizados.
¿La IA de WordPress 7 es gratis?
No. WordPress aporta la infraestructura —el panel de Ajustes > Conectores, la Abilities API y el adaptador MCP—, pero cada proveedor requiere su propio plugin y tú aportas tu clave API, que pagas por uso al proveedor correspondiente. Tampoco sustituye a los plugins de IA comerciales que ya tengas: es una capa de integración, no un producto terminado.
¿Puedo actualizar una tienda WooCommerce con seguridad?
Sí, pero nunca directamente en producción. WooCommerce tenía actualizaciones de compatibilidad pendientes con WordPress 7 y, además, el riesgo real suele estar en los plugins satélite: pasarelas de pago, envíos, facturación, sincronización con el ERP. Prueba el flujo de compra completo en staging, incluyendo un pedido real de principio a fin.
¿Cuánto tiempo lleva actualizar un sitio a WordPress 7?
Depende del inventario, no del tamaño de la web. Un sitio corporativo con tema estándar y pocos plugins bien mantenidos se resuelve en una mañana con staging incluido. Un ecommerce con integraciones a medida y desarrollos internos antiguos puede llevar varios días de pruebas. La variable que manda es cuántas piezas hay que nadie mantiene desde hace años, y por eso la auditoría previa suele ahorrar más horas de las que cuesta.
