Todos los sistemas operativos200+ sitios que cuidamosRespuesta en menos de 2h+54 9 11 7820-8554
← Blog

Servicio de mantenimiento WordPress: quién arregla lo que rompe

Para responsables de marketing cuyo sitio WordPress se rompe tras actualizar: por qué pasa, qué debe cubrir un servicio de mantenimiento y cómo elegir quién lo gestiona.

werun.dev17 min de lectura
Obtén un resumen conChatGPTClaudeModo IA de Google
Torre abstracta de bloques encajados con un bloque desplazado, que muestra por qué importa un servicio de mantenimiento WordPress

Tu sitio WordPress funcionaba el viernes. El lunes, la actualización de un plugin dejó el checkout en blanco, o el formulario de contacto dejó de enviar leads, o la home mostró una pantalla blanca. Alguien lo arregló, y tres semanas después volvió a pasar.

Ese patrón no es mala suerte. Es lo que ocurre cuando las actualizaciones llegan sin probar a un sitio en producción y nadie se hace responsable del resultado. Un servicio de mantenimiento WordPress bien hecho sustituye esa apuesta por un proceso: staging, actualizaciones probadas, copias de seguridad restaurables, monitoreo y un equipo concreto que responde.

Esta guía es para responsables y equipos de marketing que tienen que decidir quién mantiene y protege el sitio. Vemos por qué las actualizaciones rompen cosas, qué debe incluir un servicio, cómo se comparan el equipo interno, el freelancer, el hosting y la agencia, y cómo funciona el plan Care de werun.dev.

Puntos clave

  • Los sitios WordPress se rompen tras actualizar porque cambios sin probar llegan a producción, no porque las actualizaciones sean peligrosas en sí.
  • Un servicio de mantenimiento real implica staging, actualizaciones probadas, copias restaurables y monitoreo, con un equipo concreto responsable del resultado.
  • La seguridad es un proceso de parches rápidos, accesos ajustados y respuesta a incidentes, y un plugin de seguridad cubre solo una parte pequeña.
  • La responsabilidad es el criterio decisivo: elige la opción en la que una sola parte responde del resultado cuando una actualización sale mal.

Por qué WordPress se rompe tras actualizar

WordPress en sí no es frágil. Un sitio de empresa típico es una instalación del core más un tema, a menudo un page builder y decenas de plugins, cada uno escrito por un equipo distinto con su propio calendario de versiones. Cada actualización cambia código del que depende algo más.

Tres causas explican la mayoría de las roturas que vemos. Ninguna se resuelve pulsando Actualizar con más cuidado.

Causa 1

Conflictos entre plugins y temas

Dos piezas de código tocan el mismo hook, plantilla o librería, y una actualización cambia el contrato entre ellas.

Causa 2

Saltos de versión

PHP, el core de WordPress y los plugins se van desfasando hasta que una actualización obliga a saltar varias versiones de golpe.

Sin staging

Las actualizaciones se aplican en el sitio en vivo, así que la primera prueba la hacen tus visitantes.

Conflictos entre plugins y temas

Dos plugins se enganchan a la misma action o al mismo filter. O incluyen versiones incompatibles de la misma librería. O una extensión de WooCommerce y un tema intentan sobrescribir la misma plantilla de checkout.

La actualización de cualquiera de ellos cambia un comportamiento en el que los demás confiaban. El resultado es una página en blanco, un formulario roto o un diseño que se desplaza sin avisar. Explicamos la razón estructural en el problema de los plugins: el mismo ecosistema abierto que da alcance a WordPress multiplica los caminos de código que pueden chocar.

Dos bloques superpuestos chocando en un mismo hueco, que ilustran un conflicto de plugins tras actualizar WordPress
Dos piezas de código reclaman el mismo hueco y una actualización rompe el contrato

Saltos de versión de PHP y del core

Los hosts retiran versiones de PHP según su propio calendario, y las versiones de PHP terminan llegando al fin de su vida útil y dejan de recibir correcciones de seguridad. Un plugin que necesita un PHP más nuevo que el de tu servidor fallará al actualizar. Un plugin antiguo que llama a una función eliminada en PHP más reciente fallará cuando el host actualice.

El core sigue la misma lógica. Las versiones menores de seguridad suelen instalarse solas, pero las mayores cambian APIs, y los plugins abandonados nunca las siguen. La brecha crece en silencio durante meses, y entonces una actualización forzada tiene que cruzar varias versiones de un solo paso. Esa es la actualización con más probabilidad de romper el sitio.

Actualizar producción sin staging

Pulsar Actualizar en un sitio en vivo es una prueba con los clientes mirando. Sin una copia de staging no puedes ver el fallo antes que tus visitantes. Sin una copia de seguridad que hayas restaurado de verdad, tampoco puedes deshacerlo.

En muchas empresas, quien pulsó el botón es un responsable de marketing sin ningún desarrollador a quien llamar. La solución no es más cautela. Es otro lugar donde ejecutar la actualización.

Qué cubre un servicio de mantenimiento WordPress

Un servicio de mantenimiento WordPress es un acuerdo recurrente en el que un equipo concreto mantiene tu sitio actualizado, respaldado, monitoreado y seguro, y arregla lo que se rompe. Las dos palabras que importan son recurrente y concreto. «Pulsamos Actualizar todo una vez al mes» no es mantenimiento. Es el hábito que causó tu problema.

Usa las cuatro áreas siguientes como el alcance que esperas ver por escrito.

Actualizaciones probadas en staging

Cada lote de actualizaciones va primero a una copia del sitio. Después alguien revisa los recorridos que generan ingresos: formularios, checkout, login y las plantillas que reciben tráfico. Solo entonces el lote llega a producción.

Esto incluye core, plugins y temas, también los plugins premium cuyas licencias y canales de actualización hay que vigilar. Las versiones de seguridad tienen prioridad. Las versiones mayores se programan y se prueban en lugar de aplicarse el día en que salen.

Copias de seguridad que has restaurado de verdad

Una copia de seguridad es una hipótesis hasta que alguien la restaura. Pregunta qué incluye (base de datos y uploads, no solo archivos), dónde se guarda, cuánto tiempo se conserva y cuándo se probó una restauración por última vez.

Las copias que viven solo en el mismo servidor que el sitio fallan justo en los escenarios en los que las necesitas. Copias guardadas fuera del servidor, con simulacros de restauración periódicos, convierten el rollback en una acción rutinaria en lugar de una crisis.

Monitoreo de uptime, rendimiento y errores

Monitorear significa que alguien se entera antes de que tus clientes te lo cuenten. Incluye comprobaciones de uptime desde fuera de tu host, logs de errores de PHP y vigilancia del rendimiento después de cada release.

El rendimiento importa porque las actualizaciones pueden degradarlo sin ruido. Google publica los umbrales de Core Web Vitals en web.dev: un LCP de 2,5 segundos o menos y un INP de 200 milisegundos o menos, medidos en el percentil 75. La actualización de un plugin que añade un script que bloquea el renderizado puede dejar una página fuera de esos umbrales sin que nada parezca roto.

Soporte y tiempos de respuesta

Necesitas saber a quién escribes, por qué canal y con qué rapidez te responden. Los objetivos de respuesta deben estar escritos, no sobreentendidos.

Define también la frontera entre mantenimiento y trabajo nuevo. Arreglar algo que rompió una actualización es mantenimiento. Construir una plantilla o una integración nueva es desarrollo, y es otra partida de presupuesto.

Servicio de seguridad WordPress: qué debe incluir

La seguridad en WordPress es un proceso, no un producto. No es un problema de plugins. Es un problema de parches, accesos y respuesta. Un buen servicio de seguridad WordPress cubre tres capas, y cada una necesita una persona responsable.

Los plugins vulnerables son la puerta habitual

Las bases de datos públicas de vulnerabilidades listan muchos más problemas en plugins y temas que en el core de WordPress. Los atacantes rastrean la web en busca de sitios con versiones vulnerables conocidas, así que el tiempo entre que se publica una corrección y tu sitio la instala es la ventana de exposición.

Por eso la velocidad de parcheo es el control principal. También significa que los plugins abandonados son un pasivo: si el autor ya no publica correcciones, hay que reemplazar el plugin, no solo vigilarlo. Para ver el panorama completo de categorías de riesgo, lee nuestro artículo sobre seguridad de aplicaciones web y prioridades OWASP.

Escáner, no parche

Un plugin de seguridad escanea archivos y bloquea parte del tráfico malicioso. No actualiza tus plugins vulnerables, no reemplaza uno abandonado ni revisa quién tiene acceso de administrador. Esos tres trabajos necesitan una persona.

Control de acceso, doble factor y mínimo privilegio

La mayoría de los sitios arrastran cuentas de administrador que nadie recuerda: un exempleado, una agencia anterior, un freelancer de una campaña pasada. Cada una es una puerta.

Un servicio de seguridad revisa los usuarios con periodicidad y aplica un conjunto corto de reglas:

  • Autenticación de dos factores para todos los administradores y editores.
  • Roles según la necesidad, para que autores y gestores de tienda no tengan permisos de administrador.
  • Credenciales únicas por persona, sin accesos compartidos.
  • Plugins y temas sin uso eliminados, no solo desactivados.
  • Cuentas de servidor y hosting a nombre de tu empresa, no de un proveedor.

Monitoreo y respuesta a incidentes

A veces la prevención falla. Lo que separa un mal día de un mal mes es que exista un plan. La detección de cambios en archivos, los escaneos de malware y las alertas de login te avisan de que algo ocurrió.

La respuesta en sí es una secuencia: aislar el sitio, restaurar una copia limpia, rotar todas las credenciales, encontrar el punto de entrada y parchearlo. Pregunta quién lo hace de noche y en fin de semana, y dónde está escrito. La documentación oficial de WordPress describe las herramientas de la plataforma, pero no puede asignar la responsabilidad.

Cómo elegir un servicio de mantenimiento WordPress

Hay cuatro formas realistas de resolverlo: tu propio equipo, un freelancer, un plan de hosting o una agencia especializada. Compáralas con cuatro criterios: quién responde, qué cubren, cómo evoluciona el coste en el tiempo y qué puede salir mal.

El coste merece una nota. El mantenimiento es una partida continua, y la comparación real no es precio mensual contra cero. Es un importe mensual predecible contra trabajo de emergencia impredecible, leads perdidos y el coste de recuperar la confianza tras una caída.

Dónde falla cada opción

Cada opción funciona en ciertas situaciones. Los puntos de fallo son distintos, así que conviene nombrarlos.

  • Equipo interno: funciona si tienes un desarrollador con tiempo libre. Falla cuando la persona es generalista, se va de vacaciones o deja la empresa, porque el proceso vive en una sola cabeza.
  • Freelancer: uno bueno conoce bien tu sitio. Los riesgos son la disponibilidad, el punto único de fallo y un alcance que sigue siendo informal hasta que algo se rompe.
  • Plan de hosting: los hosts gestionados se ocupan de los servidores, a menudo de las copias y a veces de las actualizaciones del core. No prueban tus plugins contra tu sitio ni lo arreglan cuando la actualización de un plugin rompe una plantilla.
  • Agencia especializada: te da un equipo, un proceso y un alcance por escrito. El riesgo es la calidad desigual, y por eso hay que evaluarla.

Opción A

Freelancer

  • Una persona que quizá conoce bien el sitio
  • Las pruebas dependen de sus hábitos
  • La cobertura termina cuando está ocupado o ausente

Opción B

Plan de hosting

  • Servidor, uptime y a menudo copias gestionados
  • Tus plugins y tu tema quedan fuera del alcance
  • Puede haber staging, pero probar es cosa tuya

Nuestra elección para este caso

Plan Care de werun.dev

  • Un equipo responsable del resultado
  • Cada actualización se prueba antes en staging
  • Copias, monitoreo y seguridad en un solo alcance

Tabla comparativa por criterios

La tabla pone las cuatro opciones lado a lado. Lee primero la última fila: el riesgo principal es el mejor indicador de qué opción encaja con tu situación.

CriterioEquipo internoFreelancerPlan de hostingAgencia especializada
ResponsabilidadTu equipo, compartida con otro trabajoUna personaSolo a nivel de servidorUn equipo contratado
Staging y actualizaciones probadasDepende de las habilidadesDepende de la personaSuele ofrecer staging, probar es cosa tuyaProceso estándar
Cobertura cuando alguien faltaDébilDébilFuerte en el servidorCobertura de equipo
Parches de seguridad y respuestaDepende de las habilidadesDepende de la personaA nivel de servidor y redDefinidos en el alcance
Forma del costeTiempo de salario, a menudo ocultoPor horas o mensualidad pequeña, con picos en emergenciasIncluido en la cuota de hostingMensual fijo, predecible
Riesgo principalSe va la persona claveDisponibilidadQue un plugin se rompa es problema tuyoLa calidad varía, así que evalúala

Cómo mantiene y protege WordPress werun.dev

Nuestro lema es el modelo de trabajo: no lanzamos proyectos, los operamos. Para WordPress eso significa dos servicios mensuales, descritos en la página de servicios. El plan Care es mantenimiento mensual. El Retainer es desarrollo mensual. En ambos casos tratas con un solo equipo que conoce tu sitio.

Línea constante de luz a lo largo de una pista junto a la silueta de un escudo, que representa el cuidado y la seguridad continuos de WordPress
Cuidado continuo: un proceso estable en lugar de arreglos de emergencia

El flujo de actualización segura

Nada de lo que actualizamos toca producción primero. Cada release sigue la misma secuencia, sea un parche de un plugin o una versión mayor del core.

  1. Snapshot y copia

    Capturamos la base de datos y los archivos y confirmamos que la copia se guarda fuera del servidor.

  2. Clonar a staging

    Una copia del sitio en vivo se convierte en el lugar donde la actualización puede fallar.

  3. Actualizar y probar

    Aplicamos las actualizaciones de core, plugins y tema, y revisamos formularios, checkout, login y plantillas clave.

  4. Desplegar con rollback listo

    El lote probado pasa a producción con el snapshot en espera.

  5. Monitorear tras el release

    Vigilamos errores, uptime y rendimiento hasta que empieza el siguiente ciclo.

El bucle importa tanto como los pasos. El monitoreo posterior al release alimenta el ciclo siguiente, así que una regresión detectada el martes cambia cómo se prueba el lote que viene.

Ciclo seguro

  1. 01Snapshot producciónBase de datos y archivos, fuera del servidor
  2. 02Clonar a stagingAquí la actualización puede fallar
  3. 03Update y pruebasCore, plugins, tema, formularios y checkout
  4. 04Deploy a producciónRollback al snapshot listo
  5. 05VigilarErrores, uptime y rendimiento
Volver al snapshot

Ciclo seguro de actualización de WordPress: snapshot, clon en staging, actualización probada, despliegue y monitoreo, con rollback al snapshot

El ciclo de actualización segura con rollback listo en cada release

Plan Care frente a Retainer

Los dos servicios responden a preguntas distintas. El plan Care mantiene sano lo que tienes. El Retainer cambia lo que tienes.

  • Plan Care: actualizaciones probadas en staging, copias de seguridad, monitoreo, parches de seguridad y soporte cuando algo se rompe.
  • Retainer: capacidad mensual de desarrollo para plantillas nuevas, bloques de Gutenberg, integraciones y trabajo de rendimiento.

Muchos equipos contratan ambos. Un sitio que solo se mantiene es estable pero deja de mejorar, y un sitio que solo se desarrolla acumula riesgo sin parchear.

Qué pasa cuando una actualización rompe el sitio

Como las actualizaciones pasan antes por staging, la mayoría de los problemas se detectan antes de que los vea un visitante. Si algo se cuela, el orden es fijo: volver al snapshot y restablecer el servicio, y después reproducir el fallo en staging, encontrar la causa y publicar una corrección adecuada.

La causa puede ser un parche, un cambio de configuración o el reemplazo de un plugin que ya no encaja. Recibes un informe en lenguaje claro de qué falló y qué cambió. La corrección vive en tu código y en tus cuentas, así que no dependes de nosotros para que siga funcionando.

Si tu sitio ya es inestable, empezamos con una auditoría de versiones, plugins, PHP, usuarios y copias antes de proponer un alcance. Puedes ver cómo abordamos la plataforma en nuestra página de WordPress.

Cómo evaluar a cualquier proveedor de mantenimiento

Elijas a quien elijas, somete al proveedor a los mismos criterios. Nuestras preguntas para hacer a una agencia de desarrollo web cubren la conversación de contratación en general. Las comprobaciones de abajo se centran en el mantenimiento.

Preguntas antes de firmar

Los buenos proveedores responden esto sin dudar y con detalles. Una respuesta vaga también es una respuesta.

  • ¿Pruebas cada actualización en una copia de staging antes de producción?
  • ¿Cuándo restauraste por última vez una copia de seguridad de un cliente y cuánto tardó?
  • ¿Cuáles son vuestros tiempos de respuesta y por qué canal os contacto?
  • ¿El alcance está por escrito, con lo que cuenta como mantenimiento y lo que cuenta como desarrollo?
  • ¿Soy dueño de mi hosting, dominio, repositorio y cuentas de administrador?
  • ¿Cómo gestionáis un plugin abandonado por su autor?
  • ¿Qué informáis cada mes y puedo ver un ejemplo?
  • ¿Quién responde si el sitio se ve comprometido un fin de semana?

Señales de alerta en las ofertas

Algunas ofertas suenan completas y no lo son. Fíjate en estos patrones:

  • «Todo ilimitado» sin un alcance por escrito.
  • Ninguna mención de staging ni de cómo se prueban las actualizaciones.
  • Copias guardadas solo en el mismo servidor que el sitio.
  • Ninguna persona concreta, solo una cola de tickets sin responsable.
  • Peticiones de contraseñas de administrador compartidas por correo o chat.
  • Un montón de plugins extra ofrecidos como solución a cada problema.
  • El proveedor retiene tus cuentas de hosting o dominio.
  • Ningún informe mensual de lo que se actualizó, encontró y corrigió.

Por dónde empezar

No necesitas elegir proveedor esta semana. Sí necesitas conocer el estado del sitio, porque todo proveedor te lo preguntará. Tres acciones te llevan ahí:

  1. Audita el estado actual. Lista las versiones de WordPress, PHP y plugins, los usuarios administradores y la fecha de la última restauración de una copia. Si no puedes elaborar esa lista, ese es tu primer hallazgo.
  2. Haz una copia y restáurala en un lugar seguro. Hazlo antes de que nadie vuelva a tocar el sitio, nosotros incluidos.
  3. Define el alcance por escrito. Decide qué partes del sitio generan ingresos, quién debe responder ante un incidente y qué esperas cada mes.

Si quieres que un equipo tome el relevo, lee cómo llevamos los proyectos WordPress y el plan Care y el Retainer, y luego escríbenos con la auditoría en la mano. Te diremos con honestidad qué opción encaja, también cuando no seamos nosotros.

Preguntas frecuentes

¿Por qué mi sitio WordPress se rompe con cada actualización?

Porque las actualizaciones cambian código del que dependen otros plugins o tu tema, y suelen aplicarse directamente en el sitio en vivo sin pruebas. Los saltos de versión en PHP y core lo empeoran. Probar antes en una copia de staging detecta la mayoría de las roturas antes de que las vean los visitantes.

¿Cuánto cuesta el mantenimiento de WordPress al mes?

Depende del número de plugins, de si usas WooCommerce, de la rapidez de respuesta que necesites y de cuánto trabajo de seguridad se incluya. El mantenimiento suele ser una cuota mensual fija, mientras que las urgencias se facturan por incidente. Pide el alcance por escrito antes de comparar precios.

¿Qué incluye un plan de mantenimiento de WordPress?

Un plan sólido incluye actualizaciones probadas en staging, copias de seguridad con pruebas de restauración, monitoreo de uptime y errores, parches de seguridad, revisión de accesos de usuarios y soporte cuando una actualización rompe algo. Las funcionalidades nuevas suelen ser desarrollo aparte.

¿Puedo activar las actualizaciones automáticas en WordPress?

Puedes, y las versiones menores de seguridad del core ya se actualizan solas por defecto. Pero las actualizaciones automáticas se ejecutan en el sitio en vivo sin pruebas ni rollback, así que el conflicto con un plugin puede tumbar el sitio. Son una capa útil, no un sustituto de un proceso probado.

¿Quién puede arreglar mi WordPress tras una actualización fallida?

Un desarrollador WordPress o una agencia especializada con acceso a tu hosting y a tus copias puede restaurar el sitio y encontrar la causa. Primero vuelve a la última copia buena y después arregla el conflicto en una copia de staging. A largo plazo, un plan de mantenimiento te da un equipo concreto al que llamar.

¿Basta un plugin de seguridad para proteger mi WordPress?

No. Un plugin de seguridad escanea archivos y filtra parte del tráfico, pero no parchea plugins vulnerables, no elimina los abandonados ni revisa quién tiene acceso de administrador. La protección real combina parches rápidos, control de acceso con doble factor, monitoreo y un plan de incidentes.

¿Te pasa esto en tu propio stack?

Cuéntanos la plataforma y el problema. Te diremos qué hace falta y quién lo hace.

Sin compromiso. Solo una conversación.