Mantenimiento de WordPress: la lista mensual (y qué hace un agente de IA por ti)

Casi toda avería grave que llega a una web "de la nada" es en realidad una fecha que nadie vio: un certificado vencido, una copia de seguridad que se detuvo, actualizaciones que se acumulan, una versión de PHP que salió de soporte. El mantenimiento de WordPress es simplemente el hábito de mirar esas fechas antes de que ellas nos miren a nosotros. En la guía sobre cómo gestionar un sitio WordPress con un agente de IA explicamos qué incluye el cuidado de la web y por qué se hace. Aquí vamos a lo práctico: qué se revisa, con qué frecuencia y quién hace cada cosa.

¿Qué es el mantenimiento de WordPress? La ronda del vigilante, no apagar incendios

Imagina a un vigilante nocturno en un edificio de oficinas. No lo revisa todo cada hora. Las puertas principales las comprueba en cada ronda, la sala eléctrica una vez por semana y el generador lo arranca una vez por trimestre, aunque no haya ningún apagón. El generador es el mejor ejemplo: nadie quiere descubrir en un apagón real que no arranca.

El mantenimiento (en hebreo hay dos palabras para designarlo, pero es lo mismo) funciona así. La diferencia entre una web que se rompe una vez al año y otra que no se rompe no es suerte. Es una ronda fija, con una frecuencia distinta para cada punto.

Mantenimiento semanal de WordPress: cinco revisiones de pocos minutos

Las revisiones semanales son las más baratas que existen: no cambian nada, solo miran. Por eso son las primeras que pasamos al agente. Él mira, comprueba y te envía un informe corto por Telegram. La tabla muestra qué hace solo y qué pasa a tus manos.

Dos revisiones de la tabla necesitan explicación, porque ahí nacen la mayoría de las sorpresas.

Formularios: un "gracias" no es una prueba. La página "Gracias, hemos recibido tu mensaje" solo demuestra que la página cargó. No demuestra que el correo salió, y mucho menos que llegó a tu bandeja y no a spam. La prueba real es un mensaje de verdad que se envía y se recibe al otro lado. Por eso el agente manda una consulta real con una marca acordada y comprueba que se registró.

Tienda: el correo forma parte de la venta. En WooCommerce, una confirmación de pedido que no llega al cliente es un cliente que llama alarmado. Según la documentación oficial, la mayoría de los problemas de correo son de entrega: el servidor envía, pero el mensaje no llega. Se recomienda enviar a través de un proveedor SMTP dedicado y asegurarse de que la dirección remitente pertenece a tu dominio y no a Gmail. También puedes mirar los registros de WooCommerce (en Estado) para ver si el sistema consiguió entregar el correo.

Actualizaciones del núcleo, plugins y tema: parte mensual, tras una prueba

El orden seguro de actualización (copia, prueba, aprobación y solo entonces la web en vivo) ya lo detallamos en la guía de gestión, y no lo repetiremos. Lo que allí falta es la lógica de la frecuencia.

La documentación oficial de WordPress insiste en hacer copia antes de cada actualización, incluida la base de datos y todos los archivos, y en comprobar después si el despliegue falló o aparecieron errores. También señala que las actualizaciones menores automáticas del núcleo están activadas por defecto desde la versión 3.7. Es decir, los arreglos pequeños WordPress los hace solo. Todo lo demás pertenece al mes.

Nuestra opinión: las actualizaciones que no son críticas para la seguridad conviene agruparlas en una ventana al mes, y no instalarlas cada vez que aparece un círculo rojo. Así tienes una sola revisión concentrada en lugar de diez pequeñas. Y una actualización de seguridad de un plugin del que depende tu web no espera a fin de mes: tiene su propia ventana. Además, no se actualiza el jueves por la tarde. Si algo se rompe, mejor que haya alguien disponible para arreglarlo.

Qué comprueba el agente en el entorno de pruebas (una copia de la web donde se puede fallar sin que ningún cliente lo vea):

1. La página de inicio, una página de servicio principal y una página de producto cargan sin errores.
2. Cada formulario envía y una consulta real llega.
3. En la tienda: un producto entra en el carrito, pasa a la caja y llega hasta el paso de pago.
4. No hay malas noticias nuevas en "Salud del sitio" que no estuvieran antes.
5. La web se ve bien en el móvil, porque ahí está la mayoría de los visitantes.

Si todo pasa, recibes por Telegram un mensaje con lo que se actualizó, lo que se comprobó y el riesgo. Tú apruebas y la actualización sube a la web en vivo. Si algo falla, la web en vivo ni se tocó.

Seguridad: usuarios, verificación en dos pasos y plugins olvidados

La mayoría de las brechas no se parecen a las de las películas. Se parecen a un plugin viejo que ya nadie usa, o a la cuenta de un diseñador que trabajó contigo hace tres años y una contraseña que no se ha cambiado desde entonces.

La guía oficial de seguridad de WordPress propone unos pasos sencillos: mantener las versiones al día, usar contraseñas fuertes y verificación en dos pasos, eliminar los plugins que no se usan y transferir archivos por SFTP y no por FTP normal. Son justo líneas de un mantenimiento mensual.

• El agente hace solo: genera una lista de usuarios con su rol y la fecha del último acceso (cuando hay datos), una lista de plugins y temas desactivados, y señala cambios raros: un usuario nuevo con permisos de administrador que nadie creó.
• Con tu aprobación: eliminar un usuario, borrar un plugin y activar la verificación en dos pasos en las cuentas de administrador. El motivo: quitar a un usuario puede cortar a un empleado en mitad de su trabajo, y borrar un plugin "viejo" a veces rompe una página de la que nadie recordaba que dependía.

La regla que cumplimos a rajatabla: el agente no recibe tu contraseña de administrador, sino un usuario propio, con el rol acotado que le basta, para poder cerrarle el acceso sin tocar tu cuenta. Más detalles sobre esta estructura en la guía de permisos y seguridad de un agente de IA.

Velocidad de la web: tres números que basta con conocer

"La web va lenta" no es un diagnóstico. Google definió tres mediciones, las Core Web Vitals, y según web.dev un sitio se considera sano cuando cumple las tres en el 75 % de las visitas, tanto en móvil como en ordenador.

Fuente: web.dev, Core Web Vitals. Los umbrales se miden en el percentil 75 de las cargas de página.

El agente mide una vez al mes la página de inicio y las tres páginas más importantes, compara con el mes anterior e informa de los cambios. Las herramientas de medición son PageSpeed Insights y el informe de Core Web Vitals de Search Console, que se basan en datos de campo de visitantes reales.

¿Qué no hace por su cuenta? No comprime imágenes en la web en vivo, no desactiva un plugin ni cambia el tema. Todo eso modifica lo que ven los clientes, así que propone y espera. Y si el problema es profundo, como un tema demasiado pesado, ya es trabajo para un profesional.

Enlaces rotos y páginas 404: no todo 404 es una avería

Aquí hay un error frecuente que sale caro: alguien ve en Search Console una lista de errores 404, se asusta y los redirige todos a la página de inicio. Es justo lo que Google pide no hacer.

Según la página de ayuda de Google, los errores 404 no perjudican el rendimiento de la web en las búsquedas, y se pueden ignorar cuando la dirección realmente no debería existir. Lo que sí conviene corregir:

• Una dirección que enviaste en el archivo de mapa del sitio (sitemap) y no existe. Se corrige el archivo.
• Contenido que pasó a una dirección nueva. Se añade una redirección a la nueva dirección.
• Errores de ortografía frecuentes en la dirección. Se pueden redirigir a la página correcta.
• Contenido eliminado para siempre. Se deja un 404 o un 410. No se redirige a la página de inicio, porque Google lo define como "soft 404" y puede dificultar el tratamiento de la web.

El reparto de trabajo aquí es sencillo. El agente rastrea los enlaces internos rotos, lee los informes de Search Console y prepara una lista ordenada: "requiere corrección" frente a "se puede ignorar". Las redirecciones en sí, que cambian el comportamiento de la web, pasan a ti para su aprobación.

Lo que tiene fecha de caducidad: certificado, dominio y versión de PHP

Estas cosas no se rompen. Caducan, y por eso se controlan con un calendario.

Certificado SSL. Desde el 15 de marzo de 2026, los certificados públicos son válidos como máximo 200 días (antes 398), y según el calendario del CA/Browser Forum la duración seguirá bajando hasta 47 días en 2029. Para un negocio pequeño esto significa que renovar a mano una vez al año ya no es un modelo que funcione. Quien gestiona la web necesita renovación automática y una comprobación de que de verdad ocurre. Con Let's Encrypt, por ejemplo, un certificado dura 90 días y se recomienda renovarlo cada 60. El agente comprueba cada semana cuántos días quedan y avisa con mucha antelación.

Dominio. Una renovación anual que llega a un correo antiguo. Recomendamos renovación automática y una dirección de correo que alguien lea de verdad. El agente informa de la fecha de vencimiento, y el pago lo haces tú.

Versión de PHP. Según la página de requisitos de WordPress, se recomienda PHP 8.3 o superior. Y según php.net, el estado del soporte a día de hoy es:

Si tu web sigue en 8.2, tienes hasta finales de año. La actualización de PHP se hace en el panel del alojamiento y puede romper un plugin antiguo que no se haya actualizado. Por eso se prueba antes en el entorno de pruebas y pasa por tu aprobación. El agente detecta la versión en "Salud del sitio", avisa y prepara la prueba.

Revisiones trimestrales: cuatro comprobaciones que casi nadie hace

Las revisiones más importantes son las que se aplazan para siempre, porque nada se rompe mientras no se hacen. Hasta que se rompe.

Sobre la primera revisión hay que extenderse. La guía oficial de WordPress recomienda una copia semanal para una web pequeña y diaria para una activa, y varias copias guardadas en sitios distintos, incluido fuera del servidor. Pero una copia guardada es solo media historia. Una restauración fallida suele descubrirse en el peor momento. Por eso recomendamos una restauración completa en un entorno de pruebas una vez por trimestre. Es nuestra opinión, no un requisito oficial, y quien no la haga no sabrá con seguridad si su copia funciona.

La lista: la ronda mensual y trimestral

Marca lo que ya está hecho y verás cuánto de la ronda tienes cubierto. Las marcas no se guardan en ningún sitio, así que puedes volver aquí cada mes. Cada línea indica su frecuencia.

Dónde un agente de IA no sustituye a un profesional

Conviene decirlo con claridad, porque es donde más tienta exagerar. Un agente de IA es bueno en revisiones que se repiten, en informes y en preparar un expediente. Es menos adecuado para:

• Recuperarse tras un ataque. Hay que identificar qué entró, limpiar y cerrar la puerta. Es trabajo de un experto en seguridad.
• Un fallo por choque entre dos plugins. El agente puede identificar cuándo empezó y preparar un expediente, pero no siempre resolverlo.
• Cambio de servidor y de DNS. Un cambio externo así exige aprobación explícita y planificación previa.
• Cualquier resultado que parezca "demasiado bueno". Un informe que dice "todo en orden" sin ninguna prueba es motivo de sospecha. Un buen informe adjunta la fecha de la copia, una captura de la prueba del formulario y los números de velocidad.

Cómo empezar este mes

1. Comprueba tres fechas: cuándo fue la última copia de seguridad, cuándo caduca el certificado y qué versión de PHP tienes.
2. Envía una consulta de prueba desde cada formulario y comprueba que llegó.
3. Decide quién hace qué: qué revisiones pasan al agente y qué acciones esperan tu aprobación. Por escrito, no de palabra.
4. Empieza con un mes de solo informes. Sin cambios. Mira qué te cuenta la web.

Si todavía no tienes claro qué es un agente así, empieza por la guía sobre agentes de IA para empresas. ¿Quieres entender cómo se construye uno? Hay una guía paso a paso para crear un agente de IA. Y si el mantenimiento es solo una parte de las tareas que se repiten en tu negocio, en diez tareas que conviene pasar a un agente encontrarás más ideas.

Preguntas frecuentes

Fuentes

• https://developer.wordpress.org/advanced-administration/security/backup/
• https://developer.wordpress.org/advanced-administration/upgrade/upgrading/
• https://developer.wordpress.org/advanced-administration/security/hardening/
• https://wordpress.org/about/requirements/
• https://www.php.net/supported-versions.php
• https://web.dev/articles/vitals
• https://support.google.com/webmasters/answer/2445990
• https://developers.google.com/search/docs/crawling-indexing/http-network-errors
• https://woocommerce.com/document/email-faq/
• https://letsencrypt.org/docs/faq/
• https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/
• https://www.digicert.com/campaigns/tls-ssl-certificate-validity