Actualizar WordPress: qué se actualiza, qué se rompe y cómo hacerlo sin perder nada

Actualizar WordPress es poner al día las cuatro piezas de las que depende su web: el núcleo de WordPress, los plugins, el tema y la versión de PHP del servidor. Hoy significa estar en WordPress 7.1, la única serie que WordPress.org mantiene, y en PHP 8.3 o superior, porque PHP 8.2 deja de recibir parches de seguridad el 31 de diciembre de 2026. Lo que se rompe al actualizar casi nunca es WordPress: es un plugin o un tema que no encaja con la versión nueva. Con una copia de seguridad, las actualizaciones grandes probadas antes en una copia de la web y una revisión después, se actualiza sin perder nada.

Le contamos qué se actualiza y quién lo publica, por qué no conviene esperar, qué hacen solas las actualizaciones automáticas y qué no, qué se rompe, qué PHP le toca a su web y cómo lo hacemos nosotros. No es un tutorial para pulsar los botones: es lo que necesita saber para decidir cómo se actualiza su web y quién lo hace.

Qué se actualiza en WordPress: las cuatro piezas

Cuando WordPress avisa de que hay actualizaciones, habla de cosas distintas, que publican personas distintas y que fallan de forma distinta:

Las cuatro piezas que se actualizan en una web WordPress

Pieza	Quién la publica	Cada cuánto	Si se queda atrás
El núcleo de WordPress	WordPress.org	Dos o tres versiones grandes al año y de corrección cada pocas semanas	Deja de recibir correcciones: solo se mantiene la última de la serie 7.1
Los plugins	Cada desarrollador, a su ritmo	De varias veces al mes a nunca, si está abandonado	Es la puerta más habitual de los ataques
El tema	Su desarrollador o quien hizo la web	Unas pocas veces al año	Choca con las versiones nuevas de WordPress o de PHP
PHP	El proyecto PHP; lo instala su hosting	Una rama nueva al año, con cuatro años de vida	Se queda sin parches de seguridad y la web, atada a una versión vieja

Este año, WordPress publicó la 7.0 el 20 de mayo y la 7.1 el 19 de agosto, y tiene prevista la 7.2 para el 9 de diciembre; entre medias, versiones de corrección como la 7.1.3, del 6 de octubre. La página de versiones de WordPress.org lo resume en una frase: solo la más reciente de la serie 7.1 es segura y se mantiene.

Por qué hay que actualizar WordPress (y no dejarlo para más adelante)

Porque los fallos se descubren, se publican y se aprovechan en muy poco tiempo. Según el informe anual de Patchstack, en 2025 se publicaron 11.334 vulnerabilidades en WordPress y lo que se instala encima, el 91 % en plugins, y en las más explotadas los ataques masivos empezaron, de mediana, 5 horas después de hacerse públicas.

El núcleo tiene muchos menos fallos, pero no está libre de ellos. El 17 de julio de 2026, WordPress 7.0.2 corrigió un fallo crítico y otro de gravedad alta, uno de ellos con la posibilidad de ejecutar código en el servidor. Por la gravedad, WordPress.org forzó la actualización automática en las webs afectadas, las de la 6.8 en adelante. Una web con las actualizaciones automáticas desactivadas se quedó esperando a que alguien la actualizara a mano.

Y no todo depende de WordPress. El 21 de octubre se corrigió PHP2Shell, un fallo crítico en el propio PHP que no se arregla actualizando WordPress, sino el PHP del servidor. Según las estadísticas de WordPress.org, el 64 % de las webs WordPress ya está en la 7.1; el resto, más de una de cada tres, funciona con versiones anteriores.

Qué hacen solas las actualizaciones automáticas de WordPress

WordPress se actualiza solo en parte, y conviene saber en qué parte, porque eso decide cuánto tiempo queda su web abierta ante un fallo:

• Las versiones de corrección y de seguridad del núcleo se instalan solas desde la 3.7, si el servidor lo permite, según la guía oficial para actualizar WordPress.
• Las versiones grandes del núcleo, como el paso de la 7.0 a la 7.1, se instalan solas en las webs instaladas desde la 5.6, según sus instrucciones ampliadas; en las anteriores, solo si alguien lo activó.
• Los plugins y los temas, desde la 5.5, solo si se activa uno a uno. Entonces WordPress los actualiza dos veces al día y avisa por correo.
• Desde la 6.6, si la actualización automática de un plugin provoca un error fatal en la portada, WordPress vuelve a la versión anterior y avisa al administrador.

Lo que no hacen es lo que más importa en una web de la que vive un negocio: no comprueban que el formulario envía, que el carrito cobra o que el diseño se ve bien. La vuelta atrás de la 6.6 solo mira si la portada da un error fatal. Tampoco hacen una copia de seguridad (WordPress recomienda tenerla antes de activarlas), no cambian el PHP y dependen de las tareas programadas de WordPress: si fallan, las actualizaciones no llegan, y nadie se entera salvo que alguien mire la Salud del sitio.

Por eso no son ni buenas ni malas. Las de seguridad del núcleo conviene tenerlas siempre activas; las grandes y las de los plugins de los que depende la web (los pagos, los formularios, el constructor visual), mejor probadas antes.

Qué se rompe al actualizar WordPress

Las entradas, las páginas, los pedidos y los clientes están en la base de datos y se conservan. Lo que falla es casi siempre lo que se ha añadido encima de WordPress:

• Un plugin que no encaja con la versión nueva de WordPress, de PHP o de otro plugin: los constructores visuales, las extensiones de WooCommerce y los pagos son los más delicados.
• El tema modificado sin tema hijo: al actualizarlo se sobrescribe, y con él los cambios hechos a mano. La guía de WordPress lo advierte también del núcleo: lo que se haya cambiado en sus archivos se pierde.
• El cambio de PHP: WordPress funciona desde PHP 7.4, pero, como reconoce en su página sobre actualizar PHP, no sabe si su tema y sus plugins funcionarán con una versión nueva: hay que probarlo.
• Una actualización a medias: si se corta, la web puede quedarse en modo mantenimiento o con archivos de dos versiones distintas.
• Los plugins abandonados, que llevan años sin una versión nueva: no se rompen al actualizarlos, sino cuando se actualiza todo lo demás.

Cuando algo así falla de forma grave, lo que ven sus clientes es el aviso «Ha habido un error crítico en esta web».

Qué versión de PHP le toca a su WordPress

WordPress recomienda PHP 8.3 o superior. Sigue funcionando desde PHP 7.4, pero avisa de que esas versiones han llegado al final de su vida y pueden dejar la web expuesta. Y el calendario de PHP no espera a nadie: cada rama tiene dos años de soporte completo y dos más solo de seguridad.

Según el calendario oficial de PHP, la 8.2 recibe parches de seguridad hasta el 31 de diciembre de 2026; la 8.3, hasta el final de 2027; la 8.4, hasta el de 2028, y la 8.5, hasta el de 2029. Lo anterior a la 8.2 ya no los recibe.

Según las estadísticas de WordPress.org, el 34 % de las webs WordPress funciona con PHP 8.1 o anterior, y otro 23 %, con la 8.2. Es decir: desde el 1 de enero, más de la mitad de las webs WordPress funcionará con un PHP sin parches. Si la suya está entre ellas, lo sensato es saltar directamente a la 8.3 o la 8.4, no a la 8.2.

La versión de su web se ve en Herramientas › Salud del sitio › Información › Servidor. El cambio lo hace el hosting, desde su panel o a petición suya, pero antes hay que comprobar que el tema y los plugins lo admiten. WordPress sugiere un plugin que lo revisa, aunque advierte de que puede pasar cosas por alto: lo seguro es probarlo antes en una copia de la web.

Cómo actualizamos un WordPress sin romperlo

Es lo que hacemos en nuestro mantenimiento web WordPress, con más de 300 proyectos WordPress y 13 años manteniendo webs:

1. Inventario: la versión de WordPress y la de PHP, los plugins (los de pago, con su licencia a nombre del cliente), el tema y lo que se haya cambiado a mano.
2. Copia completa de archivos y base de datos justo antes, además de las diarias, guardada fuera del servidor y comprobada: WordPress insiste en verificar que las copias existen y se pueden usar.
3. Los parches de seguridad, en cuanto salen.
4. Lo grande, primero en una copia de la web: una versión nueva de WordPress, un plugin con cambios importantes o un PHP nuevo.
5. Una cosa cada vez, revisando avisos y errores, como recomienda WordPress: si algo falla, se sabe qué ha sido.
6. Pruebas de lo que hace la web: los formularios, el carrito y el pago, el buscador y el diseño en el móvil.
7. Después: la caché vaciada, una copia nueva y unos días vigilando errores.

Lo que no conviene hacer al actualizar WordPress

• Actualizarlo todo de golpe en la web en marcha, a media mañana y sin copia: si algo falla, no se sabe qué ha sido ni se puede volver atrás.
• Desactivar las actualizaciones automáticas de seguridad «para que no se rompa nada»: con la 7.0.2, esas webs se quedaron abiertas.
• Cambiar de PHP a ciegas, o quedarse en la 8.2 porque funciona: funciona, pero sin parches desde el 1 de enero.
• Editar el tema sin tema hijo o tocar los archivos del núcleo: la siguiente actualización se lleva los cambios por delante.
• Conservar plugins abandonados o que nadie usa: cada uno es una puerta más. Si un plugin lleva años sin actualizarse, toca buscarle sustituto.
• Fiarse de un plugin que lo «actualiza todo sin riesgos»: mueve archivos, pero no sabe si su formulario seguirá enviando.

Y si sospecha que ya han entrado en su web, lo primero no es actualizar: es lo que contamos en cómo saber si su WordPress ha sido hackeado.

Cuánto cuesta actualizar WordPress

Depende de cuánto tiempo lleve la web sin actualizar, de cuántos plugins tenga, de si el tema está modificado, de si es una tienda WooCommerce y de si además hay que cambiar de PHP. No es lo mismo una web al día que una con tres años de retraso y PHP 7.4. Por eso no trabajamos con tarifas cerradas: en nuestra página de precios de mantenimiento web le explicamos cómo lo calculamos, y qué entra en un mantenimiento lo contamos en qué incluye el mantenimiento web. Para revisar su web, escríbanos.

Preguntas frecuentes sobre actualizar WordPress