Mantenimiento WordPress: qué hacer, con qué frecuencia y qué puedes automatizar

Por qué un sitio WordPress necesita mantenimiento

La mayor parte del riesgo está en los plugins. Patchstack contabilizó 11.334 vulnerabilidades nuevas en el ecosistema WordPress en 2025, un 42 % más que en 2024: el 91 % estaban en plugins, el 9 % en temas, y solo 6 en WordPress mismo. El 46 % no tenía parche todavía cuando se publicaron, y para las vulnerabilidades más atacadas, Patchstack sitúa la mediana del tiempo hasta el primer exploit en 5 horas.

WordPress mismo avanza rápido también. La versión 7.1.4 salió el 28 de octubre de 2026, WordPress planea tres versiones mayores en 2026, y el proyecto solo da soporte oficial a la última versión. Las ramas más antiguas reciben parches de seguridad solo por cortesía.

Nada de esto necesita atención diaria de una persona. Sí necesita una rutina, unas cuantas cosas activadas, y una forma de notar cuándo una actualización rompe algo.

Actualizaciones: WordPress, plugins y temas

WordPress ya actualiza parte de sí mismo. Desde la versión 3.7 instala en segundo plano las versiones menores y de seguridad y los archivos de traducción, y desde la 5.6 las instalaciones nuevas también actualizan solas las versiones mayores; las instalaciones más antiguas se quedan en las actualizaciones menores salvo que un administrador active las mayores. Los plugins y los temas son distintos: solo se actualizan solos si lo activas, uno por uno, algo que WordPress ofrece desde la 5.5. Las actualizaciones automáticas se ejecutan dos veces al día y envían un correo al administrador con lo que ha pasado.

Desde la 6.6, WordPress también deshace una actualización automática de un plugin que rompe gravemente el sitio: carga la página de inicio tras la actualización, y si aparece un error fatal de PHP, restaura la versión anterior y te avisa por correo. Eso solo cubre los errores fatales. Una actualización que vacía el carrito, rompe un formulario o descoloca el diseño se carga sin error y se queda instalada.

Así que actualiza con prontitud, primero las versiones de seguridad, y haz una copia de seguridad antes. Actualiza los plugins de uno en uno para saber cuál causó un problema, y revisa después las páginas que te dan dinero: el checkout, el formulario de contacto, el inicio de sesión. Nuestra guía sobre si conviene desactivar las actualizaciones automáticas de WordPress trata ese compromiso en detalle.

Plugins y temas: menos, mantenidos, eliminados si no se usan

Cada plugin es código que hay que mantener al día, así que el mantenimiento más barato es tener menos. Elimina los plugins y temas que no usas en vez de solo desactivarlos; la Salud del sitio también recomienda eliminar los temas inactivos. Conserva un tema por defecto como respaldo.

Vigila los plugins que ya no se mantienen. Cuando WordPress.org confirma un problema de seguridad en un plugin, normalmente lo cierra de inmediato, y un plugin cerrado no publica actualizaciones hasta que su desarrollador lo corrige. El aviso aparece en la página del plugin en wordpress.org, y el motivo se añade a los 60 días. Otra señal es una página de plugin que dice que no se ha probado con las últimas tres versiones mayores de WordPress: puede que ya no se mantenga.

Sustituye los plugins abandonados antes de que se conviertan en un problema, y compra los plugins premium a su desarrollador, nunca en un sitio que los redistribuye.

PHP y el servidor

WordPress recomienda PHP 8.3 o superior, MariaDB 10.11 o MySQL 8.0 o superior, y HTTPS. Todavía funciona con PHP 7.4, su mínimo desde WordPress 7.0; los sitios con PHP 7.2 o 7.3 se quedan en la rama 6.9. Usar una versión antigua de PHP es uno de los problemas que señala la Salud del sitio.

Las versiones de PHP tienen fechas fijas, así que esto es fácil de planear. PHP 8.1 llegó a su fin de vida el 31 de diciembre de 2025. PHP 8.2 solo recibe parches de seguridad hasta el 31 de diciembre de 2026, así que un sitio con 8.2 debería cambiar ya. PHP 8.3 está en soporte solo de seguridad hasta finales de 2027, y PHP 8.4 tiene soporte completo hasta finales de 2026 y recibe parches de seguridad hasta finales de 2028.

Cambia de PHP primero en una copia de staging si puedes, o en un momento tranquilo con una copia de seguridad reciente, porque lo que suele romperse es un plugin antiguo. El panel de control de tu hosting normalmente te deja volver atrás.

Copias de seguridad que puedes restaurar

El propio manual de WordPress es claro sobre qué es una copia de seguridad: la base de datos y los archivos, porque necesitas ambos para restaurar un sitio. Los archivos son WordPress mismo, los temas, los plugins, las subidas, wp-config.php y .htaccess. Haz primero la copia de la base de datos, luego la de los archivos; para restaurar, pon primero los archivos y después importa la base de datos.

Sobre la frecuencia, sugiere semanal para sitios pequeños y diaria para los muy visitados, y siempre antes de una actualización mayor. Guarda copias en sitios distintos, como tu hosting, un almacenamiento en la nube y tu propio ordenador, y conserva varias: al menos tres a cinco copias recientes de la base de datos y tres de los archivos.

Una copia de seguridad solo cuenta si se puede restaurar. El manual pide verificar que las copias existen y son usables; la prueba más simple es restaurar una en un sitio de staging de vez en cuando, y hacer una copia manual ocasional para confirmar que las automáticas siguen funcionando.

La Salud del sitio y los avisos que WordPress ya te da

Herramientas > Salud del sitio es el propio informe de mantenimiento de WordPress. Entre sus problemas críticos están las actualizaciones en segundo plano que no funcionan, un sitio que no puede contactar con WordPress.org, una versión de PHP anticuada, plugins esperando actualización, errores mostrados a los visitantes o registrados en un archivo que puede ser público, y una solicitud loopback que falla, algo que WordPress necesita para ejecutar tareas programadas.

Su pestaña Info enumera las versiones de WordPress y PHP, el tamaño del directorio y de la base de datos, los plugins y temas activos e inactivos, y si cada plugin se actualiza solo. Léela una vez al mes; un nuevo problema crítico suele significar que algo cambió en el servidor o en un plugin.

Tareas de seguridad habituales

Revisa quién puede iniciar sesión. Elimina las cuentas de administrador que nadie usa, da a cada persona el rol más bajo que cubra su trabajo, y busca cuentas que no reconozcas; nuestra guía sobre los roles de usuario de WordPress explica qué puede hacer cada rol.

Mantén apagada la salida de depuración en el sitio en producción: la Salud del sitio avisa cuando los errores se muestran a los visitantes o se escriben en un archivo de registro que puede leerse desde la web. Y renueva lo que caduca: el registro del dominio y, si tu hosting no lo hace solo, el certificado SSL.

Si algo sale mal de todos modos, nuestra checklist de WordPress hackeado explica qué hacer primero.

Cómo ayuda Relvato

Relvato vigila un sitio WordPress entre sesiones de mantenimiento y justo después de las actualizaciones. El monitor de vulnerabilidades comprueba WordPress, los plugins y los temas contra vulnerabilidades conocidas y señala los plugins cerrados o abandonados en wordpress.org. El monitor de salud de WordPress ejecuta las propias pruebas de la Salud del sitio según un calendario y vigila el fin de vida de PHP, el tamaño de la base de datos y el espacio libre en disco. El monitor de copias de seguridad lee tu plugin de copias de seguridad e informa cuando la última copia falló o se quedó colgada, cuando no hay ninguna programada, o cuando las copias solo se guardan en el servidor.

Tras una actualización, los monitores que pasaban se vuelven a ejecutar, así que una actualización que rompe el checkout, un formulario, el diseño de una página o causa un error de PHP se informa el mismo día, no cuando se queja un cliente. El monitor Admin roster de Relvato señala un administrador nuevo u oculto. En los planes Business y Agency, las actualizaciones automáticas seguras de WordPress actualizan los plugins de uno en uno en una franja semanal, vuelven a ejecutar los monitores tras cada una, y revierten y bloquean una actualización que rompe algo, no solo la que causa un error fatal.

Relvato no crea ni restaura tus copias de seguridad, y la monitorización no las sustituye: mantén un plugin de copias de seguridad y copias fuera del servidor. Para agencias, los informes de clientes y páginas de estado de Relvato convierten esa misma monitorización en un informe de mantenimiento mensual.