Las actualizaciones de WordPress las hago dentro del mantenimiento técnico con un calendario fijo: primero una copia de seguridad completa, después la actualización en una copia de pruebas del sitio (el entorno de staging), pruebas, comparación de capturas de pantalla de antes y después del cambio, y solo entonces publicación en producción en una ventana acordada. No instalo de forma automática cada versión nueva. Las correcciones de seguridad críticas se saltan la cola, pero también pasan por el entorno de pruebas.
Esta página explica cada cuánto actualizo cada cosa, cómo es una ronda de actualizaciones, qué hago cuando algo deja de funcionar después de actualizar y cómo son las actualizaciones en una tienda con integraciones, en un maquetador visual y en sistemas que no son WordPress. El servicio completo, con copias de seguridad y monitorización, está descrito en la página de servicio de mantenimiento WordPress.
Cada cuánto actualizo WordPress
Calendario del mantenimiento de un sitio. Para una tienda acuerdo las ventanas por separado.
Cada semana
- Correcciones menores y de seguridad del núcleo, los plugins y los temas
- Actualización con WP-CLI en un clon de pruebas
- Pruebas de los recorridos importantes y comparación de capturas
- Publicación en producción en la ventana acordada
Cada mes
- Revisión de las versiones mayores de plugins y de sus listas de cambios
- Decisión: actualizar ahora o retener la versión
- Revisión de las cuentas de administrador
- Medición de Core Web Vitals después de los cambios
Cada trimestre y cada semestre
- Trimestral: revisión de la lista de plugins y eliminación de los abandonados
- Semestral: revisión de seguridad, es decir integridad de archivos, cuentas de administrador, permisos y puntos de acceso expuestos
- Semestral: comparación del entorno de pruebas con producción
- Paso a una versión más reciente de PHP: según el plan, cuando los plugins y el tema estén listos
Actualizar WordPress fuera del calendario: parches de seguridad
Un parche de seguridad crítico no espera al ciclo semanal. Va primero, por separado, pero por el mismo camino: copia, entorno de pruebas, prueba, publicación. La ventana exacta para estos parches la escribo en el presupuesto, porque depende del tiempo de respuesta que incluya tu plan.
La información sobre vulnerabilidades sale de bases de datos de vulnerabilidades, entre ellas Patchstack y WPScan. Cuando aparece una vulnerabilidad en un plugin que tienes instalado, compruebo si ya existe una versión corregida y si el fallo afecta a tu configuración.
El equipo de seguridad de WordPress lo forman más de 50 expertos de confianza, entre ellos desarrolladores principales e investigadores de seguridad. Según esa misma página, oficialmente solo tiene soporte la última versión de WordPress, y las correcciones para ramas antiguas el equipo las aplica como cortesía. Un sitio que se ha quedado varias versiones atrás puede quedarse sin parche.
Cómo es una ronda de actualizaciones
El mismo orden para el núcleo, los plugins, los temas y PHP. Solo cambia el alcance de las pruebas.
Copia de seguridad completa
Antes de cualquier cambio hago una copia completa de la base de datos y los archivos. Esa copia es el punto de retorno si algo sale mal en producción.
Actualización en el entorno de pruebas
Las actualizaciones van primero a un clon del sitio, con WP-CLI. Las versiones mayores de plugins entran solo después de leer su lista de cambios.
Pruebas en el clon
Compruebo los recorridos importantes del sitio: formularios, inicio de sesión y, en una tienda, el carrito y el pago. Si una prueba falla, el cambio no avanza.
Comparación de capturas
Hago capturas de pantalla de una selección de páginas antes y después de actualizar y las comparo. Un bloque desplazado, un botón que falta o una tipografía distinta se ven aquí antes de que los vea un visitante.
Publicación en la ventana de mantenimiento
El cambio llega a producción en la ventana acordada, con una instantánea y el plan de vuelta atrás preparado.
Vigilancia después de publicar
Durante las 24 horas siguientes a la publicación vigilo de cerca los efectos secundarios. La monitorización de disponibilidad comprueba el sitio cada 1 a 5 minutos.
Anotación en el informe
Las actualizaciones, las regresiones detectadas y las vueltas atrás, si las hubo, entran en el informe mensual.
Un ejemplo de este año: WP Rocket 3.23.2.2 pasó por el clon antes de actualizar el sitio a WordPress 7.1. El error y la forma de esquivarlo están en el artículo WP Rocket, error fatal en WordPress 7.1 y Cloudflare.php.
Comparación de capturas después de actualizar
Una prueba funcional comprueba que el formulario se envía y que el carrito acepta un producto. No detecta que, después de actualizar el tema, la cabecera tapa el menú en el móvil o que el maquetador ha cambiado los márgenes de la sección de precios. Por eso, después de cada actualización comparo capturas de pantalla de una selección de páginas de antes y de después del cambio. La lista de páginas la acordamos al empezar el mantenimiento: la portada, las páginas de servicios más importantes, el formulario y, en una tienda, la ficha de producto, el carrito y el pedido.
Cuando la comparación muestra una diferencia, compruebo si viene de un cambio planeado. Si no es así, la actualización se queda en el entorno de pruebas y busco la causa. A producción solo llega la versión que se ve igual o que cambia de una forma que ya conoces.
Actualizar PHP dentro del mantenimiento
El paso a una versión más reciente de PHP forma parte del mantenimiento y no tiene presupuesto aparte. Lo planifico con antelación porque depende de tres cosas: que el hosting ofrezca la versión nueva, que todos los plugins y el tema la soporten y que el código propio del sitio no use funciones que han desaparecido en esa versión. Primero levanto un clon del sitio con la versión nueva de PHP, después paso las pruebas y la comparación de capturas, y solo entonces cambio la versión en producción, en la ventana acordada.
WordPress recomienda PHP 8.3 o superior, MariaDB 10.11 o MySQL 8.0 y soporte de HTTPS. Según el servicio de comprobación de versiones de WordPress.org, la versión mínima de PHP para el WordPress actual es la 7.4. El cambio de PHP lo uno a una revisión de la lista de plugins, porque un plugin que lleva mucho tiempo sin actualizarse es el primer candidato a fallar con la versión nueva.
Qué se rompe después de actualizar y qué hago entonces
Los síntomas más frecuentes después de actualizar el núcleo, un plugin, el tema o PHP.
- Síntoma: Error crítico o pantalla en blanco después de actualizar un plugin
- Qué hagoVuelvo al estado anterior desde la instantánea. Busco la causa en el clon y publico la versión corregida en la siguiente ventana.
- Síntoma: Una página se ve distinta que antes de la actualización
- Qué hagoLa comparación de capturas frena ese cambio en el entorno de pruebas. Si la diferencia llegó a producción, retiro la actualización y corrijo el estilo o retengo la versión.
- Síntoma: El carrito o el pago dejan de funcionar en la tienda
- Qué hagoNo publico un cambio que no ha pasado la prueba del carrito. Si el fallo solo apareció en producción, retiro la actualización y vuelvo al entorno de pruebas.
- Síntoma: Los pedidos dejan de llegar al ERP o al programa de facturación
- Qué hagoCompruebo en el entorno de pruebas el intercambio de datos entre la tienda y el otro sistema y retengo la versión del conector hasta que los datos pasen bien.
- Síntoma: La versión nueva de un plugin exige cambios en el código del tema
- Qué hagoRetengo la versión y describo qué hay que rehacer. Ese trabajo queda fuera del mantenimiento y recibe un presupuesto propio.
- Síntoma: El autor ha dejado de desarrollar el plugin
- Qué hagoEn la revisión trimestral de la lista de plugins propongo un sustituto o su eliminación.
- Síntoma: Un plugin exige una versión de PHP más reciente que la del servidor
- Qué hagoPlanifico el paso a la versión nueva de PHP y lo pruebo en el entorno de pruebas. Forma parte del mantenimiento.
- Síntoma: La web cambió durante la noche sin que nadie lo decidiera
- Qué hagoCompruebo qué actualizaciones automáticas están activas y las ajusto para que los elementos críticos pasen por el entorno de pruebas.
Actualizaciones en una tienda con Redsys, Bizum y VeriFactu
En una tienda WooCommerce la actualización no afecta solo a la tienda. El plugin de Redsys, el pago con Bizum, el plugin del transportista, el conector con el ERP y el plugin de facturas tienen cada uno su autor y su ritmo de versiones, y cada uno habla con un sistema que está fuera de tu servidor. Después de actualizar uno de estos conectores compruebo en el entorno de pruebas que los datos siguen pasando en los dos sentidos: el pedido llega al ERP, el stock vuelve a la tienda, la factura se genera.
Las facturas son un buen ejemplo. WooCommerce no las emite por sí mismo: lo hace un plugin, un servicio de facturación o un ERP, y ese programa es el sistema informático de facturación que regula el Real Decreto 1007/2023 (VeriFactu). Lo explico en el artículo sobre VeriFactu en WooCommerce. La actualización de un plugin así pasa por el entorno de pruebas como cualquier otra, pero la prueba incluye además emitir una factura de prueba en el entorno de pruebas del proveedor del programa de facturación. La arquitectura de las conexiones de una tienda con otros sistemas la explico en las guías de integración de WooCommerce con un ERP y de desarrollo API-first en WordPress.
Las pasarelas de pago las pruebo con el recorrido carrito, datos, envío y pago, sin hacer un pedido real. La tienda en la que esta prueba tiene que hacerse de forma constante, no solo después de actualizar, la llevo en el Store Reliability Plan. En ese plan el ritmo de actualizaciones depende del nivel: desde actualizaciones mensuales por el entorno de pruebas, pasando por actualizaciones cada dos semanas, hasta una ventana semanal de actualizaciones.
Escenario típico: WooCommerce y el plugin de Redsys en la misma semana
Una tienda típica de las que me llegan tiene el TPV virtual de Redsys, Bizum, un plugin de transportista, un plugin de facturas conectado al programa de contabilidad y una docena de plugins más. En una misma semana pueden recibir actualización a la vez WooCommerce y el plugin de la pasarela de pago. Esa semana los actualizo por separado: primero WooCommerce, prueba del carrito y de la factura, después la pasarela, y otra vez la prueba. Si algo sale mal, se sabe al momento qué cambio lo ha provocado.
Actualizaciones en un maquetador visual
Las webs hechas con Elementor, Divi o WPBakery tienen una capa más que actualizar: el propio maquetador, sus complementos y a menudo un tema aparte. El maquetador guarda la estructura de la página en su propio formato, así que su actualización puede cambiar el aspecto de muchas páginas a la vez. Las diferencias entre maquetadores están en el artículo Gutenberg, Elementor, Divi y WPBakery.
Una web de empresa típica con 30 plugins y un maquetador visual recibe varias actualizaciones casi todas las semanas. En una web así la comparación de capturas es la que más trabajo hace, porque la prueba funcional pasa aunque una sección de la portada se descuadre.
Actualizar por tu cuenta o encargarlo
La respuesta depende de qué se rompe en tu sitio cuando una actualización sale mal.
Tienes una web sencilla con pocos plugins, una copia de seguridad que funciona y tiempo para revisar la web después de actualizar.
Puedes actualizar tú. Haz una copia antes de cada actualización y deja activas las actualizaciones automáticas menores del núcleo.
La web está hecha con un maquetador visual y tiene decenas de plugins.
Llevas una tienda con Redsys, Bizum, un ERP o facturas VeriFactu.
El sitio va varias versiones de WordPress o de PHP por detrás de la actual.
Una actualización ya ha roto la web y no tienes contrato de mantenimiento.
Reparación WordPress, con precio según la descripción de la avería.
Actualizaciones automáticas de WordPress frente a actualizaciones gestionadas
WordPress sabe actualizarse solo. Según la documentación para administradores, las instalaciones existentes reciben por defecto las actualizaciones menores del núcleo, y las instalaciones nuevas desde la versión 5.6 reciben tanto las menores como las mayores. El comportamiento lo cambia la constante WP_AUTO_UPDATE_CORE en el archivo wp-config.php: el valor 'minor' deja solo las actualizaciones menores, el valor true activa todas.
Con los plugins y los temas funciona de otra manera. Desde WordPress 5.5 el administrador activa las actualizaciones automáticas plugin por plugin y tema por tema. Según esa misma página, WordPress las ejecuta dos veces al día y depende para ello de las tareas de WP-Cron.
Una actualización automática instala la versión nueva sin copia y sin prueba en el entorno de pruebas. Para las correcciones menores del núcleo es un riesgo aceptable. Para una tienda, un plugin de pago o un plugin del que depende el formulario de pedido es demasiado. Por eso en el mantenimiento dejo lo automático donde el cambio es pequeño y los elementos críticos los llevo a mano por el entorno de pruebas.
Una web con un año sin actualizar: cómo la pongo al día
Un escenario típico al empezar el mantenimiento: una web de empresa que nadie ha actualizado en un año, con decenas de plugins, una versión antigua de PHP y una sola copia de seguridad de hace varios meses. En una web así no actualizo todo de golpe, porque si algo falla no hay forma de saber qué cambio lo provocó.
Empiezo por la auditoría inicial, que va incluida en el primer mes: lista de plugins con sus versiones, comprobación de cuáles siguen desarrollando sus autores, versión de PHP y si la copia existente se puede restaurar. Después hago una copia completa nueva y un clon de pruebas. En el clon actualizo por tandas: primero el núcleo, después los plugins, de los más sencillos a los que sostienen el formulario o la tienda, y al final el tema. Después de cada tanda, pruebas y comparación de capturas. Los plugins abandonados reciben un sustituto o desaparecen. El paso a una versión más reciente de PHP lo planifico como un paso aparte, cuando todos los plugins ya están al día.
Solo cuando el clon pasa todas las pruebas llevo los cambios a producción en la ventana acordada. A partir de ahí el sitio entra en el ritmo semanal normal. Si por el camino aparece un elemento que necesita código nuevo, lo describo y lo presupuesto aparte.
Actualizaciones en una red Multisite
En una red WordPress Multisite los plugins y los temas se instalan una vez para toda la red, así que su actualización afecta a todos los sitios a la vez. Pero cada sitio puede usar el plugin de forma distinta: uno tiene en él el formulario de pedido, otro solo un banner. Por eso, en el entorno de pruebas de la red pruebo los recorridos importantes en cada sitio que usa ese plugin, y la comparación de capturas incluye páginas de varios sitios. Una red Multisite la presupuesto de forma individual, según el número de sitios y los requisitos.
Una versión mayor de WordPress: cómo la introduzco
Una versión mayor del núcleo, como WordPress 7.1, cambia más que una versión de corrección y destapa más a menudo incompatibilidades con plugins. Según el servicio de comprobación de versiones de WordPress.org, la versión actual es la 7.1.3 (a 28 de octubre de 2026). Una versión mayor no la instalo el día que sale. Primero compruebo en el entorno de pruebas que los plugins y el tema funcionan con ella, comparo capturas y leo las listas de cambios de los plugins que aún no han declarado compatibilidad. La versión mayor llega a producción en la ventana acordada, cuando el clon pasa las pruebas.
En un clon así apareció el error de WP Rocket 3.23.2.2 con WordPress 7.1 que menciono arriba. Cuando un plugin bloquea una versión mayor, dejo el sitio en la rama anterior hasta que el autor publica una corrección o encuentro una forma de esquivarlo, y lo anoto en el informe.
Qué de las actualizaciones llega al informe
Cada ronda de actualizaciones deja rastro en el informe mensual: qué se actualizó, qué regresiones salieron en el entorno de pruebas, qué versiones retuve y por qué, y si algún cambio se retiró de producción. Así, después de una avería se sabe qué cambió en el sitio y cuándo, y si cambias de proveedor de mantenimiento tienes un historial que puedes entregar.
Cambios en el código propio durante las actualizaciones
A veces una actualización exige un pequeño arreglo en el código propio del sitio: en el tema hijo, en un plugin hecho para la empresa o en una función que dejó de funcionar con un PHP más reciente. Cada uno de esos cambios lo guardo en un sistema de control de versiones, así se sabe qué se cambió, cuándo y por qué, y se puede deshacer. El código lo reviso contra los WordPress Coding Standards con PHP_CodeSniffer y las reglas WPCS, y el análisis estático con PHPStan detecta errores de tipos y llamadas a funciones que el PHP nuevo ya no tiene. Antes de publicar reviso mi propio cambio una vez más, por separado del momento de escribirlo. Una reconstrucción mayor sigue quedando fuera del mantenimiento y recibe un presupuesto propio.
Actualizaciones de Drupal, TYPO3, Laravel y Symfony
El mismo esquema (copia, entorno de pruebas, pruebas, ventana, plan de vuelta atrás) lo aplico en sistemas que no son WordPress. Cambian las herramientas y el ritmo de versiones.
Drupal lo actualizo con un proceso repetible basado en Composer y despliegues con Drush. Drupal 7 no tiene soporte de seguridad desde el 5 de enero de 2025, y Drupal 10 lo pierde el 9 de diciembre de 2026. Lo que eso significa para un sitio en Drupal 10 lo explico en el artículo Drupal 10, fin de soporte.
En TYPO3 lo que más cuenta son los saltos entre versiones LTS. El soporte gratuito de TYPO3 12.4 terminó el 30 de abril de 2026, así que un sitio en esa versión necesita un plan para pasar a la 13 o a la 14 LTS.
En una aplicación Laravel salen versiones de corrección incluso cada semana, y cada versión principal tiene dos años de correcciones de seguridad. Las correcciones llegan a producción en pocos días, junto con la actualización de las dependencias de Composer y una pasada de composer audit, siempre primero en un servidor de pruebas. En Symfony la versión 6.4 recibe correcciones de errores hasta noviembre de 2026 y de seguridad hasta noviembre de 2027, por eso muchos proyectos empiezan con un plan para pasar a la 7.4.
Qué no cubren las actualizaciones del mantenimiento
En el mantenimiento actualizo el núcleo, los plugins, los temas y la versión de PHP. Quedan fuera rehacer un elemento que necesita código nuevo después de una actualización, los cambios grandes en el tema o en la arquitectura del sitio, la construcción de integraciones nuevas y el paso a otro sistema, por ejemplo una migración a Next.js o Astro. Ese trabajo recibe un presupuesto propio y empieza cuando lo confirmas. Cuánto cuesta el mantenimiento en sí lo explico en la página de mantenimiento WordPress precio.
Si la web ya no funciona después de una actualización fallida y no tienes contrato de mantenimiento, empieza por la reparación WordPress. Si después de actualizar han aparecido archivos extraños, redirecciones o un aviso de Google, pasa a la página de eliminar malware de WordPress.
Siguiente paso: envíame la dirección del sitio y la lista de plugins que consideras críticos. Te respondo con el calendario de actualizaciones que les pondría y con lo que costaría el mantenimiento.
