«No necesito mantenimiento web» (y otras frases que se dicen justo antes de necesitarlo)

Hay una conversación que, con los años, se repite casi con la misma puntuación. La resumo aquí como escena tipo, no como el caso de nadie en concreto: es la suma de unas cuantas iguales.

Un cliente escribe tranquilo, casi aliviado, y viene a decir que va a dejar de pagar el mantenimiento de WordPress porque es un gasto que se puede ahorrar.

Y ahí tocan las dos versiones de uno mismo. La profesional, que responde con serenidad que es su decisión y que quedas a su disposición. Y la otra, la que se muerde la lengua para no comparar aquello con dejar de pasar la revisión del coche porque llevas tres años sin averías: técnicamente ahorras, y el ahorro es real hasta que deja de serlo.

No lo dices. O al menos no así.

Funcionaba perfectamente el día que dejaron de tocarla. Foto: Acabashi, CC BY-SA 4.0; imagen recortada y disponible bajo la misma licencia.

Por qué el mantenimiento parece un gasto tonto

Aquí está la trampa, y es una trampa buena: el mantenimiento bien hecho es invisible.

Nadie aplaude una web que sigue funcionando. Nadie manda un correo diciendo "gracias por la actualización de seguridad del martes que evitó un problema que no llegué a ver". No hay foto del incendio que no ocurrió.

Así que cae en esa categoría incómoda de cosas que solo se notan cuando faltan —el aire acondicionado, los frenos, el backup—, y lo que solo se nota cuando falta es facilísimo de confundir con un gasto prescindible.

Hasta que falta.

WordPress no se queda quieto (aunque tú sí)

La idea de fondo del "me ahorro el mantenimiento" es que la web se queda como estaba. Congelada, estable, a salvo.

Pero una web WordPress no es una foto. Es un ecosistema vivo con muchas piezas moviéndose a la vez y a distinto ritmo:

• El núcleo de WordPress.
• El tema (y a veces el tema hijo, y a veces el framework del tema).
• Entre 15 y 40 plugins, cada uno mantenido por gente distinta, con planes distintos y, seamos sinceros, ganas distintas.
• La versión de PHP del servidor.
• La base de datos, el servidor web, los certificados...

Cada pieza se actualiza por su cuenta: el plugin de formularios saca versión, el hosting sube PHP de 8.1 a 8.3 "por seguridad", el tema publica un parche. Y lo que hoy encaja perfecto, mañana deja de hablarse con el vecino.

Ese es el punto que casi nadie ve: no actualizar no es quedarse quieto. Es acumular distancia. El resto del ecosistema sigue moviéndose, y cuanto mayor es la separación, más caro y más incierto resulta el día en que, por lo que sea, hay que cruzarla de una vez.

El día que "no tocamos nada" y aun así se rompió

El patrón, cuando aparece, suele ser este. El cliente lleva meses sin mantenimiento y la web va bien —nada raro: los problemas de compatibilidad no avisan, se acumulan—. Un día pasa algo aparentemente inocente: el hosting actualiza PHP, un plugin fuerza una actualización de seguridad incompatible con la versión antigua de otro, o el navegador de turno deja de tragar algo que llevaba años funcionando de milagro.

Y la web, que "no había tocado nadie", deja de funcionar correctamente.

Ese mismo día vuelve el correo. Ya no habla de ahorro: habla de urgencia.

Y reparar una incidencia acumulada suele costar más que el mantenimiento que se quiso evitar. No porque nadie se aproveche, sino porque arreglar diez actualizaciones atrasadas de golpe, a ciegas y con prisa, es un trabajo distinto —y peor— que aplicarlas de una en una, con calma y con red. La conclusión la suelen decir ellos antes que yo: lo ahorrado no compensaba las horas perdidas.

Qué dicen los números, y qué no dicen

Conviene apoyarse en datos y leerlos con cuidado, porque la estadística de seguridad se presta al alarmismo.

El informe anual de Patchstack —State of WordPress Security in 2026, publicado en febrero de 2026 con los datos del año anterior— contabiliza 11.334 vulnerabilidades nuevas en el ecosistema WordPress durante 2025, un 42 % más que en 2024. De ellas, el 91 % estaban en plugins y el 9 % en temas; en el núcleo aparecieron seis, todas de prioridad baja. Y el 43 % eran explotables sin autenticación previa.

Ahora el matiz, que es la mitad del dato. Una vulnerabilidad publicada no es un incidente. Entre las dos cosas hay cuatro escalones que casi nunca se distinguen: que se descubra y se publique; que sea explotable de verdad en una instalación concreta, lo cual depende de la versión, la configuración y de si esa función siquiera se usa; que alguien la esté explotando de forma activa; y que te haya ocurrido a ti, que es el único que sale en la factura.

La mayoría de esas 11.334 no llegará nunca al cuarto escalón en tu web, y un plugin sin actualizar no es vulnerable por definición. Pero unas cuantas alcanzan el tercero muy deprisa: el mismo informe sitúa en cinco horas la mediana ponderada hasta el primer intento de explotación en las vulnerabilidades más atacadas, no en todas. Por eso «ya lo actualizo el mes que viene» es mala idea ante un aviso grave y perfectamente razonable para el resto. El problema de una web sin mantener no es que esté condenada: es que nadie está mirando, y por tanto nadie sabe en qué escalón está.

El coste real no es la factura de la reparación

Cuando se rompe una web, la factura del arreglo es lo primero que se ve. Pero casi nunca es lo más caro.

Lo caro va alrededor: cada hora de caída es una tienda con la persiana bajada, y facilita que parte de los visitantes busque otra cosa. Una web que devuelve errores o sirve contenido inyectado deja de rastrearse con normalidad y, en los casos feos, acaba marcada como insegura en el navegador; cuánto cuesta recuperar lo perdido depende del daño y del tiempo que estuvo así. Si reparte spam o redirige a sitios raros, además, no da imagen de empresa seria. Y si hay formularios, clientes o pedidos de por medio, una brecha deja de ser un problema técnico y pasa a ser legal.

Sumado a que todo lo urgente cuesta más, el mantenimiento no compite contra "cero euros": compite contra esa suma, ponderada por la probabilidad de que ocurra. Y esa probabilidad no crece sola por el calendario, sino con la exposición: componentes de terceros, tráfico, datos que manejas, distancia respecto a las versiones que reciben parches y tiempo que pasaría hasta que alguien notara que algo va mal.

Qué es (de verdad) un buen mantenimiento

Conviene aclararlo, porque "mantenimiento" suena a factura fija y a poco más. No es dar a «actualizar todo» y rezar: es un trabajo aburrido y metódico, que es justo lo que uno quiere de la seguridad.

• Actualizaciones controladas, probadas antes en un entorno de pruebas. Nada de experimentos en producción.
• Copias de seguridad automáticas y, sobre todo, restauradas alguna vez. Un backup que nunca has probado es un rumor.
• Monitorización: enterarte de que la web se ha caído antes que el cliente.
• Vigilancia de seguridad: parchear rápido lo grave.
• Revisión de rendimiento y enlaces rotos, que se pudren solos con el tiempo.

Y no promete inmunidad. Hace cuatro cosas: reduce la probabilidad de que aparezca el problema, permite verlo antes, limita el destrozo mientras ocurre y acorta la vuelta a la normalidad. Ninguna es "no te va a pasar nada"; las cuatro juntas son la diferencia entre una tarde mala y una semana muy mala.

Tampoco conviene confundirlo con dos cosas contiguas. El soporte atiende lo que pides tú: un cambio de texto, una duda, una función nueva. La respuesta a incidentes llega cuando algo ya ha pasado: contener, limpiar, restaurar y averiguar por dónde entró. El mantenimiento es la tercera pata, y la única que trabaja cuando no ocurre nada.

Entonces, ¿el mantenimiento es obligatorio?

No. Es una decisión del cliente y se respeta, y hay webs para las que no compensa: un sitio estático de cinco páginas sin formularios, sin pagos y sin datos de nadie no necesita el mismo cuidado que una tienda con pedidos.

Lo que conviene es tomar esa decisión sabiendo lo que se decide, y no por el argumento de que hoy funciona. Muchas webs sin mantenimiento aguantan años sin un disgusto; otras no, y la diferencia rara vez se sabe de antemano.

Conclusión

Quitar el mantenimiento casi nunca parece un error el día que se decide: la web va bien y la factura desaparece. Si algún día deja de encajar una actualización, un plugin o una versión de PHP, para entonces ya nadie recuerda cuánto se estaba ahorrando.

Y si tienes una web WordPress y no sabes muy bien en qué estado está, la mejor forma de averiguarlo no es esperar al día que falle. Es mirarlo antes, que además es más barato.