Dos planes de mantenimiento web pueden prometer actualizaciones, copias, seguridad y soporte, y cubrir trabajos muy distintos. Para compararlos necesitas saber cómo se hace cada tarea, con qué frecuencia, quién responde y dónde termina el servicio.
Un buen plan reduce el riesgo y acorta el tiempo de reacción cuando algo falla. No garantiza que una web nunca se caiga, sufra un ataque o tenga una incompatibilidad. La diferencia está en detectar antes el problema, limitar su impacto y tener una forma probada de volver a un estado estable.
Un plan útil concreta tareas y responsabilidades
La lista básica es conocida. WordPress, tema y plugins actualizados; copias; seguridad; monitorización; rendimiento y soporte. Lo que permite valorar el servicio son las condiciones que acompañan a cada punto.
| Área | Lo que debería quedar definido |
|---|---|
| Puesta a punto | Estado inicial de la web, problemas previos y trabajo necesario antes de asumir el mantenimiento |
| Actualizaciones | Componentes cubiertos, frecuencia, tratamiento de parches urgentes, pruebas y vuelta atrás |
| Copias | Datos incluidos, frecuencia, retención, ubicación y pruebas de restauración |
| Monitorización | Qué se comprueba, cada cuánto y quién recibe y atiende las alertas |
| Seguridad | Medidas preventivas, revisión de accesos y actuación incluida ante una incidencia |
| Soporte | Canales, horario, niveles de urgencia y tiempo de primera respuesta |
| Cambios pequeños | Qué tipo de cambios entran, qué límite tienen y cómo se solicitan |
| Salida | Accesos, copias, licencias y documentación que recibes al terminar |
La puesta a punto merece una línea propia. Un proveedor puede mantener una web que recibe en buen estado, pero no debería asumir como mantenimiento ordinario años de actualizaciones pendientes, una infección anterior o un desarrollo que ya falla. El diagnóstico inicial separa esa deuda del trabajo recurrente y evita empezar una relación discutiendo de quién era el problema.
También conviene que el plan identifique las piezas críticas. En una web corporativa puede ser el formulario. En una tienda, el catálogo, el carrito, el pago y los correos de pedido. Comprobar que la portada carga no demuestra que el negocio siga funcionando.
Actualizar WordPress exige poder volver atrás
Una actualización controlada empieza por conocer qué hay instalado y qué depende de qué. El núcleo de WordPress, el tema, los plugins, la versión de PHP, el código propio y las integraciones no cambian siempre al mismo ritmo ni tienen el mismo riesgo.
La documentación oficial de WordPress recomienda hacer una copia antes de actualizar para poder restaurar si aparece un problema. En la práctica, el procedimiento debería incluir también una revisión posterior de las funciones importantes. Abrir la home es una comprobación; enviar un formulario o completar un pedido son otras bastante más útiles.
No todos los cambios necesitan el mismo despliegue. Un parche de seguridad urgente puede requerir actuar rápido. Una actualización mayor de WooCommerce, un constructor o una integración crítica merece copia previa, revisión de compatibilidad y, cuando el riesgo lo justifica, prueba en un entorno separado. El plan debe explicar qué criterio utiliza y quién decide.
Si algo falla, hace falta una ruta de vuelta. Puede ser restaurar una copia, recuperar una versión anterior o corregir el conflicto. Lo importante es que esa ruta exista antes del cambio y que el plan aclare hasta dónde llega la recuperación. El botón «Actualizar todo» es una función. Todavía no es un procedimiento.
Una copia sirve cuando se puede restaurar
«Copias automáticas» dice muy poco. Para saber qué protección tienes, pregunta si incluyen base de datos, archivos, configuración y contenidos subidos; dónde se guardan; cuánto tiempo se conservan y quién puede recuperarlas.
La frecuencia debería seguir el ritmo de cambio de la web. Si una página corporativa cambia una vez al mes, perder unas horas de datos puede no alterar nada. Si una tienda recibe pedidos durante todo el día, una copia diaria podría hacer desaparecer casi una jornada de actividad al restaurarla.
Hay dos preguntas sencillas detrás de esta decisión. ¿Cuántos datos puedes permitirte perder? ¿Cuánto tiempo puedes esperar hasta que el servicio vuelva? En infraestructura suelen llamarse objetivo de punto de recuperación y objetivo de tiempo de recuperación. No hace falta memorizar las siglas; sí acordar las respuestas.
La guía de seguridad de WordPress recomienda copias periódicas de la instalación completa en una ubicación de confianza y señala que deben comprobarse y poder restaurarse. Una prueba de recuperación verifica el archivo, las credenciales, el procedimiento y el tiempo real. Revisar solo que el fichero existe deja demasiadas preguntas para el día menos oportuno.
En nuestro servicio de mantenimiento web concretamos esta parte con una copia diaria en almacenamiento separado, retención mínima de cuatro semanas y una prueba mensual de restauración. No es la única configuración válida. Es un ejemplo de cómo una frase comprobable aporta más que «backups incluidos».
Monitorizar no es lo mismo que resolver
La monitorización descubre señales. Puede comprobar que una URL responde, que el certificado no está a punto de caducar, que no se llena el disco o que aumentan los errores. Para webs con operativa, también puede vigilar recorridos concretos. Cada comprobación tiene un alcance y una frecuencia que deberían conocerse.
Una alerta no arregla nada por sí sola. Al comparar planes, separa estos cuatro momentos:
- Detección. Cuánto puede tardar el sistema en ver el fallo.
- Primera respuesta. Cuándo confirma alguien que ha recibido la incidencia.
- Intervención. Cuándo empieza el diagnóstico o la recuperación.
- Resolución. Cuándo vuelve a funcionar el servicio o se ofrece una alternativa estable.
Prometer una primera respuesta en un plazo no equivale a prometer la resolución en ese mismo tiempo. Un error 502 puede nacer en la aplicación, el servidor o un intermediario. El equipo de mantenimiento debería localizar la capa responsable y actuar o escalar con información, pero no siempre controla al tercero que debe resolverla.
El horario también importa. «Monitorización 24/7» puede significar que una máquina comprueba la web a cualquier hora, no que haya atención humana inmediata durante toda la noche. La propuesta debe explicar qué incidencias se atienden fuera del horario habitual y qué ocurre con las demás.
Seguridad y rendimiento tienen límites
El mantenimiento de seguridad reduce exposición. Mantener componentes al día, retirar extensiones abandonadas, limitar privilegios, proteger accesos y revisar alertas son medidas razonables. WordPress reúne varias de estas comprobaciones en Salud del sitio, aunque pasar sus pruebas tampoco sustituye una revisión del entorno completo.
Ningún plan puede prometer protección total. Conviene saber si la detección y limpieza de malware están incluidas, en qué casos y con qué límites. Una infección previa al alta, una cuenta externa comprometida o un fallo de un proveedor pueden requerir un trabajo distinto. También debe quedar claro quién decide restaurar, qué datos podrían perderse y cómo se valida la web después.
Con el rendimiento ocurre algo parecido. El mantenimiento puede vigilar degradaciones, errores o consumos anómalos y corregir ajustes menores. Una optimización profunda de plantillas, consultas, imágenes o scripts es otro alcance. «Rendimiento incluido» debería traducirse en qué se mide, cuándo se revisa y qué tipo de intervención entra.
Hosting y mantenimiento tampoco tienen que contratarse siempre juntos ni siempre separados. El hosting sostiene la infraestructura; el mantenimiento atiende la aplicación y su funcionamiento. Si dos empresas reparten esas capas, el plan debe explicar quién diagnostica y coordina una incidencia. Si un mismo equipo cubre ambas, debe detallar igualmente sus límites. Lo mismo vale para dominio, certificados y gestión del DNS.
Los límites forman parte del servicio
No existe un contenido universal para todos los planes. Una web informativa, una tienda y una plataforma con usuarios no necesitan la misma frecuencia ni las mismas pruebas. Esta tabla sirve para localizar preguntas, no para fijar qué debe incluir cada proveedor.
| Trabajo | Puede formar parte del plan | Qué conviene aclarar |
|---|---|---|
| Hosting, dominio y certificados | Sí, o gestionarse aparte | Quién renueva, quién tiene acceso y quién responde |
| Textos, imágenes y pequeños ajustes | Según el plan | Tipo de cambio, límite y plazo habitual |
| Licencias de temas y plugins | A veces | Quién es titular y qué ocurre al terminar |
| Limpieza tras un ataque | Según origen y alcance | Condiciones, exclusiones y recuperación disponible |
| Atención fuera de horario | En planes que la contemplen | Qué se considera crítico y por qué canal se activa |
| Rendimiento avanzado | Puede ser una intervención separada | Diagnóstico, métricas y resultado esperado |
| SEO, contenidos o nuevas funciones | Normalmente son trabajos distintos | Cuándo deja de ser mantenimiento recurrente |
Las exclusiones no empeoran una propuesta. La hacen comparable. Si el plan incluye pequeños cambios, debería definir qué entiende por pequeño. Si cubre incidencias, debería distinguir las provocadas por una actualización propia de las que nacen en un servicio externo o en una modificación hecha por otra persona.
Un informe también necesita alcance. Puede registrar actualizaciones, copias, alertas, incidencias y trabajo pendiente. Una exportación automática de veinte páginas no aporta gran cosa si no permite saber qué cambió, qué riesgo sigue abierto y quién debe decidirlo.
Ocho preguntas para comparar dos planes
Haz las mismas preguntas a cada proveedor y pide que las respuestas formen parte de la propuesta o del contrato:
- ¿Qué problemas deben corregirse antes de empezar y cuáles asumís desde el primer día?
- ¿Cómo decidís qué actualizar, cuándo usar un entorno de prueba y qué comprobáis después?
- ¿Qué incluye cada copia, dónde se guarda, cuánto se conserva y cuándo se probó la última restauración?
- ¿Qué monitorizáis y quién recibe una alerta cuando aparece un fallo?
- ¿Cómo clasificáis una incidencia y qué plazos hay para responder e intervenir?
- ¿Qué ocurre ante malware, una caída del hosting o el fallo de una integración externa?
- ¿Qué cambios, licencias y horas de soporte entran y cuáles se consideran trabajo adicional?
- ¿Qué accesos, copias y documentación recibo si cambio de proveedor?
La mejor respuesta no tiene por qué ser la que promete más. Debe corresponderse con la importancia de la web y dejar clara la responsabilidad de cada parte. Una tienda con pedidos necesita más frecuencia y pruebas que una página casi estática; comparar ambas como si necesitaran lo mismo no sería útil.
Mantenerla tú o delegar
Puedes ocuparte de una web sencilla si entiendes sus piezas, haces copias externas, sabes comprobar una actualización y tienes disponibilidad para responder cuando algo falla. Las actualizaciones automáticas ayudan, pero no asignan a nadie la revisión ni la recuperación.
Delegar tiene más sentido cuando la web capta contactos, procesa pedidos, usa varias integraciones o no hay una persona responsable dentro del negocio. La decisión no depende solo del tamaño de la empresa. Depende del impacto de una incidencia y de la capacidad real para atenderla.
Antes de contratar, identifica los recorridos que no pueden fallar y utiliza las ocho preguntas para comparar propuestas. Si quieres que revisemos el estado de tu web y delimitemos ese alcance, puedes ver cómo planteamos el mantenimiento web. El resultado debería ser un acuerdo que se entienda también cuando todo funciona, no solo cuando llega una urgencia.