Tu sitio WordPress necesita un responsable técnico, no un botón de actualizar.
Mantengo sitios WordPress y WooCommerce existentes a nivel de código: actualizaciones, staging, copias de seguridad, QA, rendimiento, seguridad y el pequeño desarrollo continuo que mantiene producción sana. No es un plan de mantenimiento automático. Es un desarrollador senior que asume la responsabilidad de lo que ocurre cuando el sitio cambia.
Pulsar «Actualizar» es la parte fácil.
Un mensaje verde de «Actualización completada» no te dice si GTM dejó de funcionar, si se rompió el menú móvil o si una sobrescritura antigua de plantilla ya no es compatible. El mantenimiento profesional consiste en verificar todo eso: la parte que un plugin de 20 €/mes no puede hacer, porque no sabe si el checkout sigue aceptando pagos.
Casi nunca recibo un WordPress limpio.
No son clientes concretos: son situaciones técnicas que un sitio WordPress en producción tiende a acumular. La mayoría de los trabajos de mantenimiento empiezan averiguando cuáles de ellas están presentes.
Saber qué cambió. Probar lo que importa. Desplegar con criterio.
Qué incluye un mantenimiento WordPress profesional.
Actualizaciones del core de WordPress
Revisar la compatibilidad con el tema, los plugins y el código a medida y, después, desplegar de forma segura; no simplemente en cuanto aparece una notificación.
Actualizaciones de plugins
No hago «actualizar todo». Leo los changelogs, entiendo las dependencias y evalúo el riesgo antes de publicar actualizaciones relevantes, y pospongo las que todavía no deberían salir.
Tema y código a medida
Protejo las personalizaciones que hacen que el sitio sea tuyo y señalo el código que no debería vivir en un tema padre, donde la siguiente actualización podría borrarlo.
Staging → producción
Los cambios con riesgo se prueban primero en una copia del sitio, lejos de los clientes, antes de llegar a producción.
Backups & rollback
Una copia de seguridad solo sirve si existe una ruta clara y probada para volver atrás cuando producción falla. Lo importante es esa ruta, no el archivo de backup.
Higiene de seguridad
Usuarios, permisos, credenciales, componentes vulnerables y superficie de ataque evidente. Esto no sustituye unas operaciones de seguridad empresarial especializadas, y no voy a fingir que lo hace.
Controles de regresión de rendimiento
El mantenimiento no debería convertir poco a poco un sitio rápido en uno lento. Cuando el rendimiento necesita trabajo de verdad, eso corresponde a dedicated rendimiento de WordPress y Core Web Vitals.
Formularios y rutas de conversión
Los formularios, CTA, registros y flujos de captación que justifican tener el sitio se comprueban, porque pueden romperse sin hacer ruido.
WooCommerce
Para tiendas: carrito, checkout, pagos, emails transaccionales y las integraciones de las que dependen los pedidos, todo probado antes de que una actualización los toque.
Analytics & tracking
GTM, GA4 y el seguimiento de conversiones no deberían desaparecer silenciosamente después de un cambio frontend. Si los datos dejan de llegar, alguien debe detectarlo antes del siguiente informe.
Pequeño desarrollo continuo
Corrección de bugs, cambios de plantilla, ajustes CSS/JS, integraciones, mejoras del administrador y pequeña funcionalidad a medida. Ingeniería real, no simplemente hacer clic en «actualizar».
Qué ocurre cada vez que toco producción.
La profundidad de las pruebas se adapta al riesgo. Una actualización de pagos de WooCommerce no se trata igual que una utilidad inocua del admin, aunque la estructura del proceso sea la misma.
Snapshot / backup
Un punto conocido y estable al que poder volver.
Revisar cambios
Changelogs, dependencias y qué partes afecta.
Actualizar staging
Aplica primero el cambio lejos de los clientes.
Pruebas funcionales
Formularios, checkout, integraciones y las rutas que importan.
QA visual y móvil
Layout y plantillas en breakpoints reales.
Comprobación rápida de rendimiento
Asegurarse de que nada haya empeorado por el camino.
Desplegar
Desplegar a producción de forma deliberada.
Ver un caso real de automatización de despliegues WordPress
Verificación en producción
Confirmar que funciona donde importa: en producción.
Registrar qué cambió
Así, el siguiente cambio parte de un estado conocido.
A veces, la actualización correcta es no actualizar todavía.
Instalar una versión en cuanto aparece puede ser peor que retrasarla de forma deliberada. Una versión mayor puede introducir un cambio incompatible; un plugin puede eliminar una función de la que depende el sitio; una dependencia puede quedar abandonada sin avisar. El objetivo no es ejecutar software desactualizado para siempre, sino actualizar cuando sea seguro, no simplemente cuando esté disponible. El mantenimiento requiere criterio, no un cron.
El mantenimiento WordPress termina en desarrollo más veces de lo que parece.
Un sitio activo nunca está realmente terminado. Necesita corrección de bugs, pequeños cambios de UI, nuevo tracking, redirecciones, datos estructurados, soporte para landings, integraciones, mejoras para editores y revisiones ocasionales de rendimiento. La ventaja de una relación de mantenimiento es que el desarrollador que hace esos cambios ya conoce el código: así, un cambio pequeño sigue siendo pequeño en lugar de convertirse en una investigación.
WooCommerce cambia el modelo de riesgo.
En una web corporativa, un componente roto es molesto. En WooCommerce, un checkout roto detiene los ingresos. Por eso las actualizaciones de tiendas se prueban con más rigor, especialmente en las partes que los clientes realmente utilizan.
Hablas directamente con el desarrollador que mantiene tu web.
Sin cadena de account managers ni lotería de tickets. Hablas con la persona que hace el cambio, recibes explicaciones en lenguaje normal, ves resúmenes claros de lo modificado y tienes staging cuando el cambio lo requiere.
Para quién es este servicio.
Buen encaje
- Sitios WordPress consolidados que son importantes para el negocio
- Sitios de marketing fundamentales para la generación de leads
- Tiendas WooCommerce, publishers y sitios SaaS/corporativos
- Sitios con código a medida o integraciones externas
- Equipos que solicitan cambios en WordPress de forma regular, y agencias que necesitan soporte senior
Probablemente innecesario
- Un sitio estático de cinco páginas que cambia una vez al año
- Un sitio ya mantenido por un equipo interno competente de WordPress
- Un proyecto que espera desarrollo ilimitado por una cuota de mantenimiento mínima
¿Y cuando algo se rompe?
Pantalla blanca, actualización fallida, problema de checkout, layout roto, error fatal de PHP, conflicto de plugins o regresión inesperada. Los clientes de mantenimiento ya cuentan con alguien que conoce el sitio, lo que acelera mucho el diagnóstico frente a empezar desde cero. No prometo cobertura 24/7 ni tiempos de respuesta SLA fijos que no pueda garantizar; lo que obtienes es un desarrollador que ya conoce la instalación cuando realmente importa.
El mantenimiento depende de aquello de lo que voy a hacerme responsable.
No existe una tarifa fija de «care plan», porque asumir un sitio corporativo sencillo y asumir una tienda WooCommerce con mucho tráfico no son el mismo trabajo. El precio depende de:
Preguntas sobre mantenimiento, respondidas.
Actualizaciones de core y plugins revisadas según su riesgo, pruebas en staging, QA funcional y visual, copias y rollback, higiene de seguridad, comprobaciones de regresión de rendimiento, verificación de analítica y pequeño desarrollo continuo. El trabajo consiste en verificar y asumir responsabilidad técnica, no solo en pulsar «actualizar».
No a ciegas. Reviso changelogs, dependencias y riesgo, y actualizo con una cadencia adecuada al sitio. Una actualización relevante sale después de probarse; una actualización arriesgada puede posponerse deliberadamente hasta que sea segura. El objetivo es un sitio sano, no una insignia verde de «todo actualizado».
Sí, con una profundidad proporcional al riesgo. Una actualización de pagos o checkout en WooCommerce se prueba en staging antes de producción; una pequeña utilidad de administración no se trata como una release crítica. Las pruebas cubren las rutas que realmente importan: formularios, checkout, tracking y rendimiento.
Para cualquier cambio con riesgo, sí. Staging es donde los cambios se prueban lejos de los clientes antes de llegar a producción. Los cambios de bajo riesgo no siempre lo necesitan; el nivel de proceso debe corresponder al nivel de riesgo.
Sí. Ese es el punto de partida de la mayoría de estos trabajos. Primero mapeo lo que existe: plugins, código a medida, integraciones y cómo está configurada realmente producción, antes de cambiar nada.
Sí. Código a medida sin documentar, plugins desconocidos y cambios realizados directamente en producción son un punto de partida habitual. El primer trabajo consiste en entender el sitio lo suficiente como para modificarlo con seguridad.
Sí. En una tienda hay más en juego porque un checkout roto detiene los ingresos, así que las actualizaciones se prueban contra carrito, checkout, pagos, emails transaccionales e integraciones clave antes de publicarlas.
Sí. Correcciones de bugs, ajustes de plantillas y CSS/JS, redirecciones, correcciones de tracking y pequeña funcionalidad a medida forman parte normal del mantenimiento; no se convierten en un proyecto separado cada vez.
Sí, y normalmente ocurre así. Como ya conozco el código, el pequeño desarrollo —cambios de plantilla, integraciones, mejoras del admin, datos estructurados— es más rápido y de menor riesgo que poner al día a una persona nueva cada vez.
Me ocupo de la higiene de seguridad: usuarios y permisos, credenciales, componentes vulnerables y superficie de ataque evidente. Eso es distinto de unas operaciones especializadas de ciberseguridad empresarial, y dejo claro ese límite.
Sí. El mantenimiento incluye comprobaciones de regresión de rendimiento para que un sitio rápido no se vaya volviendo lento, y el trabajo más profundo de Core Web Vitals puede formar parte del servicio cuando sea necesario.
Existe un snapshot al que volver y, como ya conozco el sitio, el diagnóstico es mucho más rápido que empezar desde cero. Se aplica la corrección, se verifica en la zona que fallaba y se registra qué cambió.
Sí. Estoy en el área de Barcelona y puedo trabajar presencialmente en la zona, además de mantener sitios WordPress en remoto para empresas de toda España y Europa.
Sí. El mantenimiento se presta naturalmente al trabajo remoto: staging, Git y resúmenes claros de cambios funcionan igual esté donde esté tu equipo, dentro de una zona horaria europea compatible (CET).
Depende de la responsabilidad que asuma: WordPress frente a WooCommerce, cantidad y calidad del código a medida y plugins, frecuencia de cambios, nivel de pruebas que requiere cada modificación, desarrollo continuo y criticidad de producción. Defino el alcance después de revisar el sitio.
Enséñame cómo está tu WordPress ahora mismo.
Envíame el sitio y dime quién lo mantiene hoy. Revisaré la configuración, los riesgos evidentes y lo que implicaría realmente asumir su mantenimiento técnico continuado, antes de que cualquiera de los dos se comprometa a nada.
