Mantenimiento WordPress en 2026: contratos y cambio de proveedor sin caídas
Introducción: el mantenimiento es un contrato de confianza, no una suscripción
Sobre el papel, todos los planes de mantenimiento WordPress parecen iguales: actualizaciones, copias de seguridad, monitorización, soporte. La diferencia entre un contrato de mantenimiento serio y una suscripción cara se esconde en tres cosas que solo notas cuando algo se rompe. ¿Esa copia de seguridad se ha restaurado alguna vez de verdad? ¿Quién coge el teléfono cuando una actualización tumba producción un sábado por la noche? ¿Y qué entrega el proveedor cuando terminas la relación?
Ahí empieza esta guía. Está escrita para quienes deciden y van a firmar un contrato de mantenimiento en 2026, revisar uno existente o cambiar de proveedor: sin caídas, sin pérdida de datos y sin que la web pase tres semanas como rehén de una disputa por el traspaso. Nos quedamos a propósito en lo cualitativo. Nada de precios inventados, sino la lógica de costes detrás de cualquier presupuesto serio y las piezas del contrato que de verdad marcan la diferencia.
Describimos estos estándares tal y como los aplicamos en nuestro mantenimiento de WordPress: actualizaciones probadas primero en staging, copias de seguridad diarias, monitorización permanente y respuesta a incidentes en menos de cuatro horas. Si después de leer comparas tu contrato actual con esta lista y descubres que falta la mitad, el artículo ya se ha amortizado.
Qué debe incluir un contrato de mantenimiento WordPress
Un contrato de mantenimiento es una promesa de servicio a lo largo del tiempo. Para que esa promesa se pueda exigir, cada servicio esencial tiene que ser concreto, medible y verificable. Estos seis elementos separan los contratos profesionales de los folletos de marketing.
1. Gestión de actualizaciones con pruebas de compatibilidad. El contrato debe especificar qué componentes se actualizan (núcleo de WordPress, plugins, temas, versión de PHP), con qué cadencia y, lo más importante, en qué orden. Bien hecho significa: las actualizaciones se ejecutan en un entorno de staging que refleja la producción de forma realista, se prueban contra los flujos críticos para el negocio (login, checkout, formularios, integraciones) y solo después pasan a producción con una vía de reversión definida. Los parches de seguridad tienen prioridad y se aplican mucho más rápido que las actualizaciones de funcionalidad. Si el contrato solo dice “actualizaciones periódicas”, sin mencionar staging ni reversión, no estás comprando mantenimiento. Estás comprando un boleto de lotería.
2. Copias de seguridad con pruebas de restauración. Un plan de copias de seguridad se reduce a cuatro preguntas: qué se copia (archivos y base de datos, por separado), con qué frecuencia, dónde se guarda (fuera del servidor, fuera de la cuenta de alojamiento, en una jurisdicción distinta a la del servidor web) y la pregunta que casi nadie hace: ¿cuándo se restauró por última vez? Un proveedor que merezca la pena prueba restauraciones con regularidad en un entorno aislado y documenta el resultado. En los sitios sujetos al RGPD, el propio almacenamiento de las copias también debe estar cubierto por su propio contrato de encargo del tratamiento.
3. Monitorización de disponibilidad y seguridad. Monitorizar no es “un ping a la página de inicio”. Las comprobaciones útiles vigilan la disponibilidad a intervalos de un minuto, verifican la integridad de los archivos, buscan malware, detectan ataques de fuerza bruta contra el login y, en las tiendas, vigilan de forma sintética los flujos que cuestan dinero: el checkout, los webhooks de pago, el banner de consentimiento de cookies. Una alerta que acaba en un buzón que nadie lee no es monitorización. Pregunta en concreto: ¿a qué canal llegan las alertas, y quién las lee, y cuándo?
4. Respuesta a incidentes con tiempos definidos. “Según disponibilidad” no es un tiempo de respuesta. El contrato debe indicar qué se aplica en cada nivel de prioridad: cuándo empieza el análisis del fallo tras una caída crítica, en qué ventana (¡y en qué zona horaria!) responde el proveedor y cómo funciona el escalado. A nuestros clientes de mantenimiento les garantizamos respuesta a incidentes en menos de cuatro horas en horario laboral CET. Cifras así deben estar en cualquier contrato, no solo en una llamada comercial.
5. Informe mensual. Sin informe no hay rendición de cuentas. Un informe mensual útil muestra: las actualizaciones aplicadas (incluido lo que se ha fijado a propósito en una versión), el estado de las copias de seguridad y las restauraciones, el porcentaje de disponibilidad, los incidentes de seguridad con las medidas adoptadas y las tendencias de rendimiento en las Core Web Vitals. El informe es también tu base de pruebas si más adelante rescindes el contrato y el nuevo proveedor necesita un punto de partida limpio.
6. Un presupuesto para pequeñas mejoras. El mantenimiento que solo reacciona deja la web técnicamente congelada durante años. Los buenos contratos incluyen una bolsa definida de tiempo de trabajo para las pequeñas tareas que de otro modo nunca se hacen: un plugin sustituido por una función del núcleo, la etiqueta de un formulario, una redirección, un ajuste de caché. Esta bolsa evita que la web se convierta en un proyecto cada vez que hace falta un cambio real.
Si falta uno de estos seis elementos, no es automáticamente motivo de ruptura, pero es una conversación que hay que tener antes de firmar, no después.
Cómo detectar un mal contrato de mantenimiento WordPress
La mayoría de los malos contratos de mantenimiento no son un fraude. Simplemente se quedan cortos: prometen la palabra “mantenimiento” y entregan una fracción. Estos son los patrones que vemos con más frecuencia cuando asumimos sitios de proveedores anteriores.
El contrato que solo cubre copias de seguridad. El proveedor hace copias diarias y nada más. Sin staging, sin gestión de actualizaciones, sin monitorización. Suena a red de seguridad, pero es solo un seguro para el momento en que ya es demasiado tarde. Si las actualizaciones no se gestionan, el riesgo ha pasado sin hacer ruido del proveedor a ti, y la caída para la que existía la copia se vuelve más probable precisamente por esos componentes sin parchear.
Copias de seguridad sin pruebas de restauración. Un archivo que lleva tres años en verde pero nunca se ha restaurado tiene un estado desconocido. Hemos asumido sitios cuya cadena completa de copias estaba corrupta mientras el panel seguía informando de éxito. La pregunta para cualquier proveedor: ¿cuándo restaurasteis de verdad una copia en un entorno aislado, entrasteis, la recorristeis y verificasteis la base de datos, en lugar de comprobar solo la integridad de los archivos?
Actualizaciones de plugins sin gestionar. Las actualizaciones automáticas sin staging son el desencadenante más habitual de la clásica llamada del lunes: “La web está en blanco desde esta mañana”. Un plugin de consentimiento que deja de cargarse en silencio tras una actualización automática a las 2 de la madrugada es un incidente técnico. Pero según el RGPD es un problema con posibles obligaciones de notificación si la web funciona 48 horas sin un mecanismo de consentimiento válido. Precisamente por eso probamos cada actualización de consentimiento y de pagos de forma manual y controlada, en lugar de fiarnos de la automatización.
Sin entrega de documentación. El contrato regula la rescisión, pero no lo que ocurre en la rescisión. Sin inventario de accesos, sin documentación de la infraestructura de staging, sin lista de plugins a medida y sus particularidades, sin exportación de la configuración de la monitorización. El cambio se convierte entonces en un proyecto de arqueología, que te facturan en horas del nuevo proveedor.
Tiempos de respuesta “según disponibilidad”, informes “bajo petición”. Dos expresiones sin valor en una disputa. Si el contrato no define niveles de prioridad ni zona horaria, “según disponibilidad” en una emergencia tiene más o menos la fuerza vinculante de una sugerencia.
“Mantenimiento gratuito incluido con el alojamiento”. La traducción honesta de esa frase es: actualizaciones automáticas sin staging, una copia de seguridad guardada en el mismo servidor que la web y una cola de soporte donde las dudas sobre WordPress quedan detrás de todo lo demás. Para una web corporativa sencilla puede bastar. Para una web que genera ingresos, no es un plan de mantenimiento, es un actualizador automático sin gestión.
Cuánto cuesta el mantenimiento WordPress
Lo que cuesta el mantenimiento no depende “del mercado”, sino de cuatro factores que puedes valorar tú mismo. Entender esta lógica te permite distinguir presupuestos serios de los que no lo son, sin necesidad de tarifas.
Primero: la complejidad del sitio. Una web corporativa con doce plugins se mantiene de forma distinta a una tienda WooCommerce con pasarela de pago, sincronización con ERP, gestión de consentimientos y estructura multilingüe. Cada integración es un flujo que hay que volver a probar después de cada actualización. El número de plugins importa menos que su naturaleza: un plugin de muro de pago exige mucha más atención que un fragmento de estadísticas.
Segundo: el tiempo de respuesta que compras. Una respuesta a incidentes vinculante en cuatro horas le cuesta al proveedor disponibilidad, es decir, personas que de verdad cogen el teléfono. “Al siguiente día laborable” es otra clase operativa y tiene el precio correspondiente. Ambas son legítimas; lo que no es legítimo es difuminar la diferencia.
Tercero: la proporción entre prevención y reparación. El mantenimiento es la mitad barata del ciclo de vida. La mitad cara es la emergencia no planificada: una restauración sin copia probada, una limpieza de malware con prisas, un relanzamiento que solo hizo falta porque nadie tocó la plataforma en cinco años. Cada unidad de esfuerzo invertida en un mantenimiento estructurado traslada gasto de la categoría imprevisible a la planificable.
Cuarto: la transparencia del modelo de facturación. El mercado ofrece básicamente cuatro modelos: una bolsa de horas en la que las horas no usadas pasan al mes siguiente, una cuota mensual fija con alcance definido y tope de horas, disponibilidad solo para incidentes y la variante “gratuita” que conviene evitar. Ninguno es objetivamente incorrecto; lo incorrecto es un contrato que no diga expresamente qué está incluido y qué genera costes adicionales. Nuestra página de precios de WordPress muestra cómo es una estructura transparente: sin recargos ocultos y con una línea clara entre mantenimiento continuo y trabajo de proyecto.
Una nota práctica para cerrar: los proveedores serios solo dan precio después de un breve briefing o de una auditoría del sitio. Un presupuesto sacado de la manga sin haber visto nunca tu lista de plugins no está valorando tu carga de trabajo, está valorando tu firma.
Cómo cambiar de proveedor de mantenimiento WordPress
En 2026, cambiar de proveedor es una operación que se puede hacer de forma rutinaria. La caída no la provoca el cambio en sí, sino cuatro errores clásicos: falta de inventario de accesos, un traspaso sin auditoría, un cambio sin staging y plazos de preaviso que nadie leyó hasta la última semana. Este es el proceso que seguimos nosotros cuando asumimos un sitio.
Paso 1: inventario de accesos
Antes de rescindir nada, crea un registro completo de todas las credenciales de acceso y de quién es su propietario legal. La lista básica:
- Registrador del dominio: ¿dónde está registrado el dominio, quién es titular de la cuenta, quién controla el código de autorización? El dominio debe seguir siendo tuyo, nunca dentro de la cuenta del proveedor.
- Gestión de DNS: ¿dónde está la zona DNS (registrador, Cloudflare, panel de alojamiento), quién tiene acceso y hay TTL que convenga reducir antes del cambio?
- Alojamiento: acceso a la cuenta, quién paga la factura, panel del servidor. También aquí: la cuenta es tuya o de tu empresa, no del proveedor de servicios.
- Administración de WordPress: una lista de todas las cuentas de administrador, idealmente con limpieza de cuentas antiguas antes del cambio.
- SFTP/SSH y base de datos: credenciales, vía de conexión, phpMyAdmin o Adminer, acceso a las copias de seguridad en el almacenamiento externo.
- Todo lo demás: cuenta de CDN, relay de correo, claves de licencia de plugins premium (¿de quién son las licencias?), servicios de monitorización, hooks de staging, accesos de CI/CD.
El principio para cada línea: tienes que poder restablecer cada acceso por tu cuenta. Si una credencial pertenece al proveedor anterior (una cuenta de alojamiento facturada a su nombre, una licencia a su nombre), ese es precisamente el primer punto del traspaso, y tu primera posición negociadora.
Paso 2: auditoría antes del traspaso
El nuevo proveedor debería hacer una auditoría técnica antes del traspaso: versiones de WordPress y PHP, inventario de plugins con comprobación de abandono, una línea base de seguridad (una auditoría de seguridad muestra enseguida si el sitio llegó a protegerse), la configuración de copias de seguridad incluida una primera prueba de restauración, el estado del rendimiento y, si existe, la documentación del proveedor anterior. Esta auditoría no es una cortesía: fija el estado de partida y evita que, después del cambio, los daños previos se carguen a la nueva relación.
Paso 3: staging y preparación en paralelo
El nuevo proveedor monta un entorno de staging que refleja la producción y despliega allí sus herramientas: monitorización con comprobaciones útiles, un flujo de copias de seguridad con verificación externa y un proceso de actualización con la disciplina de “primero staging”. Todo esto ocurre en staging; la producción no se toca hasta el cambio. Esta fase también saca a la luz las cuestiones que más tarde saldrían caras: plugins fijados en una versión por un motivo que nadie recuerda, tareas cron que chocan con la capa de caché, código a medida sin control de versiones.
Paso 4: documentación que debe entregar el nuevo proveedor
Exige esta documentación como muy tarde en el momento del cambio, y conviértela en una obligación contractual del nuevo proveedor para que el siguiente cambio sea más fácil:
- Documentación de accesos y del sistema (este inventario, actualizado)
- Lista de plugins con decisiones: actualizado, fijado en una versión (con motivo y fecha de revisión), sustituido
- Arquitectura de copias de seguridad: qué, con qué frecuencia, dónde, fecha de la última prueba de restauración
- Resumen de la monitorización: qué comprobaciones existen y qué flujos cubren
- Proceso de incidentes: niveles de prioridad, tiempos de respuesta, vías de escalado
- Registro de código propio: plugins y temas propios, dónde están y cómo se despliegan
Paso 5: plazos de preaviso y fin del contrato según la normativa UE
Lee el contrato actual ahora, no en la semana de la rescisión. En la práctica, tres puntos son los que más pesan. Primero, el propio plazo de preaviso: un mes es lo habitual en el mantenimiento B2B en la región DACH, pero existen contratos anuales con tres meses de preaviso antes del vencimiento. Segundo, la forma: ¿la rescisión tiene que ser por escrito y basta con un correo electrónico? Tercero, el ángulo del derecho de consumo de la UE: si el contrato se celebró como contrato de consumo a distancia, se aplica un derecho de desistimiento de 14 días salvo que intervenga otra excepción; en los servicios continuos, ese derecho decae total o parcialmente cuando el servicio se ha prestado por completo con el consentimiento previo y expreso del consumidor. Los contratos B2B no tienen ese derecho: ahí manda únicamente el texto del contrato. Una frase más que a menudo se pasa por alto en los contratos serios: la obligación de traspaso. El proveedor se compromete a transferir de forma colaborativa todos los accesos, datos y documentación al rescindir. Si falta esa frase, es una señal de alarma, no solo para el cambio, sino para la forma en que el proveedor gestiona la dependencia en general.
Paso 6: lista de comprobación para cambiar de proveedor sin caídas
El día del cambio transcurre sin sobresaltos cuando todo está preparado. Esta lista ha demostrado su valor en nuestros traspasos:
- Elige la ventana del cambio en un periodo de poco tráfico (en la región DACH, normalmente a primera hora de la mañana, CET), con todas las partes implicadas informadas.
- Haz una copia de seguridad completa de producción justo antes del cambio y verifícala en el momento.
- Congela los despliegues: el proveedor anterior no sube nada más, el equipo editorial no publica nada. Una ventana de una a dos horas suele bastar.
- Reduce con antelación los TTL de DNS (horas en lugar de días) para que un posible cambio de servidores de nombres se propague rápido.
- Activa las nuevas herramientas en paralelo: la monitorización y el flujo de copias de seguridad del nuevo proveedor ya funcionan antes de que asuma la responsabilidad.
- Haz pruebas de humo en producción: login, páginas de destino clave, envío de formularios y, en las tiendas, una compra de prueba completa incluido el webhook de pago, además de comprobar que el banner de consentimiento está en el DOM.
- Mantén abierta la vía de reversión: un cambio de DNS es reversible y la copia previa al cambio permite restaurar. Si algo falla después del cambio, volver atrás siempre es una opción; la perfección a cualquier precio no es el objetivo.
- Escribe el registro posterior al cambio: qué se cambió, qué comprobaciones se hicieron, qué pareció anómalo en las primeras 48 horas.
Trata el cambio como un lanzamiento de software, no como una mudanza de oficina. Un lanzamiento tiene congelación, reversión y pruebas; una mudanza tiene cajas de cartón. Lo segundo explica la mayoría de las caídas que luego se atribuyen “al cambio”.
RGPD, contrato de encargo y BFSG en el mantenimiento WordPress
Un contrato de encargo del tratamiento según el artículo 28 del RGPD. En cuanto tu proveedor de mantenimiento puede acceder a datos personales de la web (formularios de contacto, pedidos, cuentas de usuario, registros, copias de seguridad de esos datos), actúa como encargado del tratamiento. El contrato de encargo es entonces una obligación legal. Atención a tres detalles que en la práctica se escapan: el contrato debe cubrir también a los subencargados (sobre todo al proveedor de almacenamiento de las copias); el almacenamiento externo de las copias debería estar en la UE y tener su propio contrato; y el contrato debe incluir obligaciones documentadas de supresión y devolución al terminar la relación, porque eso también forma parte de un traspaso limpio.
La BFSG: la accesibilidad no termina en el lanzamiento. La ley alemana de refuerzo de la accesibilidad (Barrierefreiheitsstärkungsgesetz) ha hecho obligatoria la accesibilidad para muchas ofertas online B2C, y esas obligaciones siguen vigentes durante el mantenimiento continuo. Una actualización de tema, un plugin nuevo o un widget de formulario sustituido pueden empeorar en silencio el contraste, el orden del foco o el manejo con teclado. Un contrato de mantenimiento que nunca menciona la accesibilidad la trata como un criterio puntual de lanzamiento. Mejor: pruebas de regresión de las características de accesibilidad críticas en las actualizaciones relevantes y una revisión anual para comprobar si el sitio sigue cumpliendo los requisitos aplicables de la BFSG.
Facturación en EUR y tiempos de respuesta por escrito. Para clientes de la región DACH, el marco serio incluye también lo prosaico: facturas en EUR, correctamente tratadas a efectos de IVA (proveedores de la UE con la inversión del sujeto pasivo bien aplicada), y cada tiempo de respuesta prometido por escrito en el contrato, con referencia a la zona horaria. “Siempre estamos localizables” es marketing; “el análisis del fallo empieza en un plazo de cuatro horas desde el aviso, en horario laboral CET” es una cláusula contractual. Llevamos años trabajando con clientes alemanes y austriacos exactamente con este esquema, y la línea del tiempo de respuesta en el contrato nunca ha estorbado en una emergencia.
Preguntas frecuentes
¿Cómo cambio de proveedor de mantenimiento WordPress sin caídas?
En cuatro pasos: haz el inventario de accesos (alojamiento, DNS, administración de WordPress, SFTP, base de datos, registrador, y aclara quién es el propietario legal de cada credencial), pide al nuevo proveedor una auditoría técnica antes del traspaso, deja que prepare en paralelo el staging y las herramientas, y después ejecuta el cambio controlado con despliegues congelados, una copia de seguridad reciente, TTL de DNS reducidos y una vía de reversión probada. Mientras el dominio y el alojamiento sigan siendo tuyos y solo se entreguen los accesos, la caída es técnicamente innecesaria. La causa más habitual de caídas durante un cambio no es el cambio de tecnología, sino la falta de inventario: una credencial que solo tiene el proveedor anterior se descubre la primera vez que hace falta.
¿Qué debe incluir un contrato de mantenimiento WordPress?
Seis elementos: gestión de actualizaciones del núcleo, plugins, temas y PHP con pruebas en staging y vía de reversión; copias de seguridad diarias fuera del servidor con pruebas de restauración documentadas; monitorización de disponibilidad y seguridad 24/7 con un canal de alertas que una persona lee de verdad; tiempos de respuesta definidos por nivel de prioridad (indicando la zona horaria); un informe mensual sobre actualizaciones, disponibilidad, incidentes y Core Web Vitals; y una bolsa definida para pequeñas mejoras. A eso súmale el marco legal: condiciones de rescisión, obligaciones de traspaso al terminar el contrato, un contrato de encargo del tratamiento según el artículo 28 del RGPD y la cláusula de que el dominio, el alojamiento y todas las claves de licencia siguen siendo tuyos.
¿Qué señales de alarma aparecen en un mal contrato de mantenimiento?
Un alcance limitado a copias de seguridad sin gestión de actualizaciones, copias de seguridad sin ninguna prueba de restauración documentada, actualizaciones automáticas de plugins directamente en producción sin staging, tiempos de respuesta "según disponibilidad" sin zona horaria, informes solo "bajo petición", ninguna entrega de documentación acordada para la rescisión y, como categoría general, el "mantenimiento gratuito" incluido con el alojamiento, que en la práctica es un actualizador automático sin gestión. Todos estos patrones trasladan el riesgo a tu lado sin que se note; solo salen a la luz cuando la web ya está caída.
¿Necesito un contrato de encargo del tratamiento con el proveedor de mantenimiento?
Sí, en la mayoría de los casos. En cuanto el proveedor, en el marco del mantenimiento, tiene acceso a datos personales de tu web (envíos de formularios, datos de pedidos, cuentas de usuario, registros, copias de seguridad), los trata por tu cuenta según el artículo 28 del RGPD, y el contrato de encargo es obligatorio. Comprueba si los subencargados (sobre todo el almacenamiento externo de las copias) están cubiertos y si se regulan las obligaciones de supresión y devolución al terminar el contrato. Un contrato que solo nombra al proveedor directo, pero no la cadena de copias de seguridad, no cubre la ruta de riesgo real.
¿Cuánto tiempo de preparación necesita de forma realista un cambio de proveedor?
El plazo de preaviso del contrato anterior más cuatro a seis semanas de preparación es un marco realista: una semana para el inventario y la rescisión, una o dos semanas para la auditoría y la creación del staging por parte del nuevo proveedor, una semana de funcionamiento en paralelo de los nuevos flujos de copias de seguridad y monitorización y, después, el cambio en una ventana definida. En tiendas con integraciones de pago y ERP la transición se alarga, porque los flujos críticos deben reconstruirse y probarse en staging antes del cambio. Si además hay que transferir licencias o contratos de alojamiento que estaban bajo la responsabilidad del proveedor anterior, prevé una semana extra de margen.
Conclusión
Un buen contrato de mantenimiento en 2026 se reconoce por detalles casi banales: una prueba de restauración con fecha, un tiempo de respuesta con zona horaria y un informe que llega de verdad cada mes. Un buen cambio de proveedor se reconoce porque funciona como un lanzamiento de software: inventario, auditoría, preparación en paralelo, congelación, cambio, opción de reversión. Nada de esto requiere tecnología exótica, solo disciplina, y la disciplina se puede poner por escrito en un contrato.
Si ahora mismo estás comparando tu contrato con esta lista o planificando un cambio: la página de mantenimiento de WordPress describe nuestro enfoque en detalle, la página de precios de WordPress muestra nuestra estructura transparente y, a través del formulario de contacto, recibirás un presupuesto por escrito tras un breve briefing. Para la elección estratégica merece la pena leer el artículo sobre refuerzo avanzado de la seguridad de WordPress: es la mejor prueba de si tu proveedor actual domina de verdad los temas que dice cubrir en el contrato.
La parte de ejecución de este tema la agrupamos en desarrollador WordPress.
