Un mantenimiento web que merece ese nombre incluye cuatro cosas: actualizaciones de seguridad aplicadas a tiempo, copias de seguridad que alguien ha llegado a restaurar, vigilancia con una persona que recibe el aviso y un plazo de respuesta por escrito. Cambiar textos, hacer SEO o alquilar el servidor son otros servicios, aunque a menudo lleguen en la misma factura.
Lo difícil es comprobarlo. El mantenimiento bien hecho no se ve: cuando funciona, no pasa nada. Y «no pasa nada» es exactamente lo mismo que ves cuando nadie está haciendo nada. Es la parte menos vistosa del diseño web y la única que solo se nota cuando falta.
Mantener no es cambiar cosas
Mantener una web es conseguir que siga funcionando, segura y recuperable, igual que el día en que se entregó. Todo lo que la deja distinta —un texto nuevo, una sección, una página de campaña— es evolución. Las dos hacen falta, pero se contratan y se miden de forma diferente.
Confundirlas sale caro: si las «horas de cambios» se comen la cuota, lo primero que se aplaza es el trabajo invisible que protege la web. Nuestro criterio es sencillo: si una tarea deja la web distinta de como estaba, no es mantenimiento, y debe figurar aparte en el contrato.
Tampoco lo es el alojamiento, aunque prometa «seguridad incluida». Patchstack, empresa especializada en seguridad para WordPress, lo midió en su informe sobre el estado de la seguridad en WordPress de 2026: en una prueba a gran escala contra proveedores de alojamiento populares, solo se bloqueó el 26 % de los ataques.
Las cuatro cosas que tiene que incluir
Actualizaciones a tiempo, no en un día fijo del mes
Una web en WordPress es un sistema base más una serie de complementos de terceros —formularios, galerías, idiomas—, cada uno con su propio calendario de fallos. Según el mismo informe, en 2025 aparecieron 11.334 vulnerabilidades nuevas en el ecosistema WordPress, un 42 % más que el año anterior, y el 91 % estaba en complementos.
El dato que cambia un contrato es otro: aproximadamente la mitad de las vulnerabilidades de alto impacto se explotan en las primeras 24 horas. «Actualización mensual» describe un calendario, no una protección. Hay que dejar escrito cuánto se tarda en aplicar un parche crítico y si se prueba antes en una copia. Y a veces no hay parche: el 46 % de las vulnerabilidades del año no tenía arreglo del fabricante al hacerse pública. Entonces toca retirar la pieza, y alguien tiene que proponerlo.
Debajo hay otra fecha de caducidad. PHP, el lenguaje sobre el que funciona WordPress, publica hasta cuándo recibe parches cada versión: la 8.2, hasta el 31 de diciembre de 2026; la 8.1 dejó de recibirlos el 31 de diciembre de 2025. Aun así, según las estadísticas públicas de WordPress.org, más de un tercio de las webs WordPress seguía en septiembre de 2026 en la 8.1 o anteriores. Que nadie te haya propuesto subir de versión también es una respuesta.
Copias de seguridad que alguien ha restaurado
Todos los planes dicen «copias diarias»; casi ninguno dice cuándo se restauró una por última vez. Una copia que nunca se ha restaurado no es una garantía: es una suposición. INCIBE lo recoge en sus recomendaciones de copias de seguridad para empresas: «Comprueba periódicamente que las copias pueden restaurarse», y guarda al menos una «fuera de la empresa». En una web, fuera quiere decir lejos del mismo servidor: una copia que vive junto a la web cae con ella.
Si la web recoge datos personales —un formulario, una reserva, un área de clientes—, además hay norma detrás. El artículo 32 del Reglamento General de Protección de Datos, entre las medidas de seguridad que deben ajustarse al riesgo, cita «la capacidad de restaurar la disponibilidad y el acceso a los datos personales de forma rápida en caso de incidente físico o técnico».
Vigilancia con alguien al otro lado
Un sistema que comprueba cada pocos minutos si la web responde sirve de poco si el aviso llega a un buzón que nadie abre el sábado. La pregunta útil no es «¿vigiláis la web?», sino «si se cae un sábado a las diez, quién se entera y qué hace».
Con el candado del navegador —el certificado de seguridad— pasa algo parecido, y va a más. El CA/Browser Forum, que fija las reglas para quienes los emiten, aprobó acortar su vigencia: según sus requisitos básicos, los emitidos desde el 15 de marzo de 2026 duran como máximo 200 días; desde marzo de 2027, 100; desde marzo de 2029, 47. O la renovación es automática y alguien comprueba que funciona, o un día tus visitantes verán un aviso de sitio no seguro en lugar de tu portada.
Un plazo de respuesta que no sea «lo antes posible»
«Lo antes posible» no es un plazo. El contrato debe distinguir cuánto se tarda en actuar cuando la web está caída o comprometida y cuánto cuando algo puede esperar. Si tu web vende o cobra reservas, cada hora caída tiene un coste directo.
Hay un segundo reloj. Ante una brecha que afecte a datos personales, el artículo 33 del mismo reglamento obliga a tu empresa a notificarla a la autoridad de control «sin dilación indebida y, de ser posible, a más tardar 72 horas después de que haya tenido constancia de ella», salvo que sea improbable que suponga un riesgo. Si tu proveedor trata esos datos por cuenta tuya, debe avisarte «sin dilación indebida». Cuántas horas son eso, mejor dejarlo por escrito.
Lo que se vende como mantenimiento y no lo es
- Las horas de cambios. Son evolución. Útiles, siempre que no compartan bolsa con la seguridad.
- El «SEO incluido». Vigilar que una actualización no rompa lo que Google ya lee de tu web sí es mantenimiento. Un informe automático de posiciones no es posicionar.
- La accesibilidad «ya revisada». Si tu servicio está entre los que obliga la ley de accesibilidad web, el artículo 13.5 de la Ley 11/2023 exige procedimientos que garanticen que el servicio «siga siendo conforme con los requisitos de accesibilidad aplicables», teniendo en cuenta «los cambios en las características de la prestación del servicio». Cada página nueva puede deshacer lo que se revisó.
Y un límite: si el mantenimiento consiste, mes tras mes, en parchear algo que ya no admite más, la conversación es otra. La contamos en cuándo rehacer una web y cuándo basta con actualizarla.
Seis preguntas antes de firmar o renovar
Un proveedor serio responde a las seis sin tener que buscar nada. Si alguna respuesta es «depende», pide que ese «depende» quede por escrito.
- ¿Cuándo restaurasteis por última vez una copia de mi web, y dónde se guarda?
- ¿Cuánto tardáis en aplicar un parche de seguridad crítico, y lo probáis antes en una copia?
- ¿Qué versión de PHP usa mi web y hasta qué fecha recibe parches?
- Si la web se cae un sábado, ¿quién recibe el aviso y en cuánto tiempo actúa?
- ¿Qué me enviáis cada mes para saber qué se ha hecho, y no solo que «todo está bien»?
- ¿A nombre de quién están el dominio, el alojamiento y los accesos de administración, y qué me entregáis si dejamos de trabajar juntos?
La última es la que más se olvida y la que más duele. La web es un activo de tu empresa; el mantenimiento es un servicio sobre ese activo. Si cambiar de proveedor exige pedir permiso para entrar en tu propio dominio, el problema no es técnico sino contractual, y se resuelve antes de firmar.
Un mantenimiento se juzga el día malo
Un contrato de mantenimiento no se evalúa el mes en que no pasa nada, sino el día en que pasa. Ese día solo cuentan tres cosas: si había una copia que funciona, si alguien se enteró a tiempo y si estaba escrito quién hacía qué. Todo lo demás es una lista de tareas.
Si ya pagas un mantenimiento y no sabrías contestar a esas seis preguntas, podemos repasarlas contigo con tu contrato delante.
Actualizado: 18 de septiembre de 2026.
