Mantenimiento WordPress en Sevilla

El mantenimiento de un WordPress en producción no consiste en pulsar “actualizar” cuando hay tiempo. Consiste en mantener vivo, seguro y rápido un sitio del que depende la facturación, las reservas o el catálogo de una empresa sevillana, sin que cada martes de parches se convierta en una apuesta. Esta página describe cómo gestionamos ese trabajo de forma continua para negocios de Sevilla, con un enfoque que parte del contexto real del mercado andaluz.

#Mantenimiento WordPress en Sevilla, anclado en el contexto local

Sevilla concentra una parte notable del tejido digital del sur de España. El antiguo PCT Cartuja, hoy rebautizado como Sevilla TechPark sobre los terrenos heredados de la Expo ‘92, agrupa más de quinientas empresas y decenas de miles de trabajadores, con las telecomunicaciones y la informática como sector más representativo del recinto. A esa base se suman la Universidad de Sevilla, la Universidad Pablo de Olavide (en el entorno de Dos Hermanas) y un cluster aeronáutico maduro alrededor de las plantas de fabricación de la comarca. El resultado es un mercado con dos perfiles muy distintos que mantienen WordPress por motivos opuestos: empresas industriales y de servicios que lo usan como web corporativa y captación, y comercios, hoteles y operadores turísticos que lo usan como motor de reservas y venta.

Esa mezcla condiciona el mantenimiento. Un hotel del casco histórico o un operador de visitas guiadas no puede permitirse una caída en Semana Santa, Feria de Abril o el puente de mayo, sus picos de tráfico del año. Una tienda WooCommerce que cobra con Bizum y Redsys no puede arrastrar una pasarela de pago rota durante un fin de semana de rebajas. El calendario de Sevilla marca cuándo el riesgo de tocar producción es inaceptable, y planificamos los ciclos de actualización en consecuencia.

#Qué cubre el servicio mes a mes

• Actualizaciones de núcleo de WordPress, plugins y temas probadas primero en un entorno de pruebas idéntico a producción, con pruebas de regresión sobre los flujos críticos (carrito, checkout, formularios de reserva, login de cliente) antes de promover el cambio
• Copias de seguridad diarias con retención de 30 días en ubicación separada del hosting, con restauraciones probadas de verdad: una copia que nunca se ha restaurado no es una copia, es una suposición
• Monitorización de disponibilidad (uptime) y de Core Web Vitals con avisos automáticos, más verificación de malware y reglas WAF para frenar los bots de fuerza bruta contra wp-login.php y xmlrpc.php, que son el ruido de fondo constante de cualquier WordPress expuesto
• Gestión de certificados TLS, registros DNS y entregabilidad del correo transaccional (confirmaciones de pedido, recuperación de contraseña), un punto que se rompe en silencio y solo se nota cuando un cliente no recibe su factura
• Un informe mensual legible: qué se actualizó, qué se detectó, qué métricas se movieron y qué riesgos quedan abiertos para decidir el mes siguiente

#Cumplimiento que afecta a un WordPress español

El mantenimiento en España no es solo técnico, también es regulatorio, y 2026 es un año de transición que conviene tener resuelto en el calendario de mantenimiento, no descubierto a destiempo:

• VeriFactu y facturación verificable. El sistema de facturación verificable ante la AEAT pasa a ser obligatorio para autónomos y pequeñas empresas a partir del 1 de julio de 2026 (ya rige desde enero para grandes facturadores). Si una tienda WooCommerce o un sitio con facturación emite facturas, el plugin o la integración que las genera tiene que quedar alineado con VeriFactu. El mantenimiento incluye vigilar que esa pieza siga siendo conforme tras cada actualización.
• RGPD y consentimiento. Gestión de cookies y consentimiento real (no un banner decorativo), registro de actividades de tratamiento y minimización de datos en formularios. En un WordPress típico el riesgo está en los plugins que cargan scripts de terceros antes del consentimiento.
• PSD2 y autenticación reforzada. Bizum y las pasarelas de Redsys ya cumplen la autenticación reforzada (SCA) exigida por PSD2; el trabajo de mantenimiento es asegurar que las actualizaciones del plugin de pago no rompan ese flujo 3-D Secure, que es donde se pierden pedidos sin que nadie lo note hasta que cuadra caja.

#Cómo hacemos el onboarding de un sitio existente

Casi ningún sitio llega limpio. La mayoría de los WordPress sevillanos que recibimos arrastran años de plugins acumulados, un PHP que se quedó atrás y una copia de seguridad que nadie ha probado nunca. Por eso el primer paso no es mantenimiento, es diagnóstico:

1. Auditoría de entrada. Inventario de plugins y temas, versión de PHP, estado real de las copias, postura de seguridad y una referencia de rendimiento con Lighthouse. Aquí salen a la luz los plugins abandonados sin actualizaciones, las vulnerabilidades conocidas y la deuda técnica heredada.
2. Estabilización. Antes de hablar de cadencia mensual, cerramos los agujeros críticos: parcheo de lo vulnerable, reparación de copias rotas, limpieza si hay malware y subida de la versión de PHP cuando el sitio lo permite sin romperse.
3. Primer ciclo de actualización probado. Todo el catálogo de actualizaciones pendientes se aplica en el entorno de pruebas, se valida contra los flujos de negocio y se promueve a producción con un plan de reversión escrito.
4. Cadencia estable. A partir de ahí, ritmo mensual predecible: actualizaciones probadas, copias diarias, escaneos, control de rendimiento e informe.

El primer mes de un sitio descuidado se parece más a una remediación que a un mantenimiento, y lo decimos de entrada para que nadie espere magia en treinta días.

#Rendimiento, medido donde duele

Los Core Web Vitals no son una métrica de vanidad: en un comercio turístico sevillano cada décima de segundo de más en el LCP de la página de reserva se traduce en abandono antes de pagar. El mantenimiento de rendimiento que aplicamos trabaja sobre causas reales de un WordPress maduro:

• LCP. Caché de página y de objetos bien configurada, imágenes servidas en AVIF/WebP con dimensiones explícitas, y revisión de los plugins que inyectan CSS y JavaScript que bloquean el renderizado.
• INP. Reducción del JavaScript de terceros (chats, mapas, píxeles de marketing) que un departamento de marketing añade sin avisar y que degrada la interacción mes a mes.
• CLS. Reserva de espacio para imágenes y banners de consentimiento, que son la causa habitual de saltos de maquetación en sitios españoles por culpa del propio cumplimiento RGPD mal implementado.

Cada regresión queda registrada en el informe mensual con la causa, no solo el número, para que la decisión de gastar horas en optimizar sea informada.

#Seguridad continua

La base de seguridad es la misma para cualquier sector: HTTPS forzado con HSTS, cabeceras de seguridad (CSP, X-Content-Type-Options), doble factor en todas las cuentas de administración, principio de mínimo privilegio en los roles de usuario y escaneo de vulnerabilidades de los plugins instalados. Para sitios que tratan datos personales (reservas con nombre y documento, clientes de e-commerce) se añade la capa RGPD: gestión de consentimiento, contrato de encargo de tratamiento con el hosting y minimización en los formularios. Para clientes con mantenimiento continuo, revisamos la postura de seguridad cada trimestre, no solo cuando salta un incidente.

#Respuesta a incidentes

Cuando algo se rompe, el valor del mantenimiento es la velocidad y el rastro. Los tickets prioritarios reciben respuesta dentro de la jornada laboral; para una caída de producción o un incidente de seguridad confirmado, el protocolo SLA cubre la intervención fuera de horario. Cada incidente queda con cronología, causa raíz y pasos de remediación documentados, de modo que sea auditable y, sobre todo, no se repita por la misma puerta dos veces. En un WordPress hackeado el trabajo es metódico: aislar, analizar qué entró y por dónde, eliminar el código malicioso, rotar credenciales comprometidas, parchear la vulnerabilidad de origen y, si hubo desindexación o aviso de “este sitio puede dañar tu equipo”, gestionar la revisión con Google.

#Cómo trabajamos y con quién habla usted

El trato es directo con quien hace el trabajo. Sin capas de gestores intermedios que reenvían mensajes ni perfiles júnior aprendiendo sobre su producción. Cada cliente de mantenimiento tiene un contacto técnico que conoce la arquitectura de su sitio, su contexto de negocio y su calendario comercial, ese detalle de saber que la Feria de Abril no es semana para tocar el checkout.

La comunicación pasa por un canal de tickets escrito, con informe mensual, y se reservan las llamadas para cuando hay una decisión real que tomar o un incidente que repasar. Participamos en la comunidad WordPress (WordCamp y meetups), lo que nos mantiene cerca de los cambios del núcleo antes de que lleguen como sorpresa a las actualizaciones.

#Preguntas frecuentes de empresas en Sevilla

¿Qué incluye exactamente el paquete mensual? Actualizaciones probadas en el entorno de pruebas, copias diarias con 30 días de retención, monitorización de uptime y Core Web Vitals, verificación de malware y WAF, hasta cuatro horas mensuales de pequeños cambios de desarrollo y soporte prioritario. Lo que no entra en esas horas (un rediseño, una integración nueva) se cotiza aparte de forma transparente.

¿Pueden asumir un sitio que ya tiene problemas? Sí. Es lo habitual. La auditoría de entrada identifica lo crítico y produce una lista de remediación antes de pasar a la cadencia estable.

¿Trabajan en remoto? Sí, todo el mantenimiento se gestiona en remoto, con informes escritos. No es un obstáculo para una empresa sevillana, sí lo es no tener registro de lo que se toca.

¿Cómo es el presupuesto? La cuota de mantenimiento se ajusta al tamaño y la criticidad del sitio (un WooCommerce con cientos de pedidos al mes no es una web corporativa de cinco páginas), por eso la valoración es individual tras la auditoría inicial, sin tarifas de catálogo que no encajan con la realidad del proyecto.

#Actualizaciones de PHP y del núcleo sin romper el sitio

La versión de PHP decide a la vez el rendimiento y la superficie de riesgo del sitio. El proyecto PHP mantiene cada rama con dos años de soporte activo y un tercer año dedicado solo a correcciones de seguridad. Pasado ese plazo, la rama queda sin parches: da igual lo actualizado que esté el núcleo de WordPress si el intérprete que ejecuta el código ya no recibe arreglos. En el lado del rendimiento, los saltos de rama del intérprete y una OPcache bien dimensionada (con opcache.memory_consumption y opcache.max_accelerated_files ajustados al número real de ficheros PHP del sitio, que en un WooCommerce con decenas de plugins es alto) actúan justo donde la caché de página no llega: carrito, checkout y área de cliente, que son peticiones que se sirven siempre en caliente. El JIT que llegó con PHP 8.0 aporta poco a un WordPress típico, porque la carga es de base de datos y entrada/salida, no de cálculo puro: quien prometa milagros por activar el JIT no ha medido el caso.

El mínimo que exige WordPress no es la versión recomendada, y no siempre es la que se ejecuta. La pantalla Salud del sitio, dentro del menú Herramientas, muestra la versión en uso y avisa cuando queda por debajo de la recomendada. Una trampa habitual en hostings compartidos españoles: el PHP del panel (el que sirve las peticiones vía PHP-FPM) y el PHP de la línea de comandos son binarios distintos, así que wp cli info puede informar de una rama y el sitio ejecutar otra. Conviene comprobar las dos antes de dar por buena una migración, porque las tareas programadas que se lanzan mediante WP-CLI se ejecutan entonces sobre un entorno que nadie ha probado.

Comprobar la compatibilidad de plugins y tema antes de subir de rama. El orden que seguimos es siempre el mismo:

1. Inventario real. wp plugin list --fields=name,version,status,update y wp theme list dan la foto exacta. De cada pieza se leen las cabeceras Requires PHP y Requires at least, y la fecha de la última actualización en el repositorio. Un plugin sin commits en años es el candidato número uno a romperse, y muchas veces la decisión correcta es sustituirlo, no arrastrarlo.
2. Análisis estático. PHP_CodeSniffer con el conjunto de reglas PHPCompatibilityWP, apuntado a wp-content y con la rama de destino como objetivo, señala llamadas eliminadas y sintaxis incompatible en el tema a medida y en los plugins propios, que es donde suele estar la deuda que nadie documentó.
3. Copia idéntica en pruebas. El sitio se clona a un entorno con la rama de PHP de destino, se activa WP_DEBUG_LOG y se recorren los flujos que facturan: checkout completo con redirección a la pasarela y vuelta, alta de reserva, generación del PDF de factura, formularios con adjuntos, importaciones programadas y las tareas de wp cron event list.
4. Lectura del registro, no de la portada. Los avisos que importan casi nunca se ven en pantalla. Query Monitor y el fichero debug.log sacan a la luz las obsolescencias típicas de cada salto: propiedades dinámicas declaradas al vuelo (obsoletas desde PHP 8.2), pasar null a parámetros no anulables de funciones internas (obsoleto desde 8.1) y el cambio en la comparación entre cadenas y números que llegó con 8.0 y que puede alterar en silencio una condición de descuento o de stock.

Mayor y menor no son el mismo riesgo, ni el mismo procedimiento. En WordPress, una versión con formato x.y es una entrega mayor (APIs nuevas, cambios en el editor, a veces retirada de funciones obsoletas) y una x.y.z es menor: seguridad y mantenimiento, sin cambios de API. En PHP la distinción es equivalente un nivel más arriba: pasar de 8.3.6 a 8.3.7 es un parche, pasar de 8.2 a 8.3 es cambio de rama con posibles roturas. En los plugins el versionado semántico se respeta menos, así que la referencia no es el número sino el changelog: una entrega puede anunciar una migración de esquema en base de datos (el caso más conocido en WooCommerce es el almacenamiento de pedidos de alto rendimiento, HPOS) y eso no es una actualización, es una conversión de datos. Las menores se aplican en ciclo corto tras pasar por pruebas; las mayores reciben ventana propia y no se programan cerca de un pico comercial, que en Sevilla significa evitar Semana Santa, la Feria de Abril y la campaña navideña.

Actualizaciones automáticas de seguridad, activadas con criterio. WordPress aplica por defecto las versiones menores del núcleo desde la rama 3.7. El comportamiento se gobierna con la constante WP_AUTO_UPDATE_CORE (admite true, minor y false), con AUTOMATIC_UPDATER_DISABLED para desactivarlo todo, y con los filtros auto_update_plugin y auto_update_theme para decidir plugin a plugin. La política que aplicamos: núcleo en automático para las menores, automático también en los plugins de bajo acoplamiento (seguridad, SEO, utilidades de administración) y control manual en todo lo que toque checkout, pasarela, plantillas o cálculo de impuestos. Conviene además dejar intactas dos redes de seguridad del propio núcleo: desde WordPress 6.3, si una actualización automática de un plugin provoca un error fatal, el sistema revierte ese plugin a la versión anterior; y desde 5.2 el modo de recuperación aísla el componente que rompe el sitio y envía al correo de administración un enlace para entrar y desactivarlo. Definir WP_DISABLE_FATAL_ERROR_HANDLER desarma ambas, así que no se toca salvo motivo muy concreto.

El plan de reversión se escribe antes de tocar producción, no durante la caída. Antes de cada ciclo: volcado de base de datos con wp db export, copia de wp-content, ambos fuera del servidor siguiendo la regla 3-2-1, y un criterio de éxito escrito (qué flujos deben funcionar para dar el cambio por bueno). Si algo falla, la vuelta atrás depende de qué se movió. Una versión de plugin se revierte con wp plugin update indicando en --version la versión anterior; el núcleo admite wp core update con --version y --force; la rama de PHP se devuelve a su valor previo desde el panel del hosting, y es la marcha atrás más limpia porque cambiar de intérprete no altera los datos. Lo que no se revierte con un comando es una migración de esquema ya ejecutada: ahí la única salida limpia es restaurar el volcado, y por eso el orden de la copia importa. Tras revertir o tras confirmar el cambio se verifica la integridad con wp core verify-checksums y wp plugin verify-checksums --all, se revisa el registro de errores, se repiten los flujos críticos, se comprueba que el correo transaccional sigue saliendo y se contrastan los Core Web Vitals con la referencia previa. Los plazos de intervención y de aviso al cliente no se improvisan: los fija el contrato de mantenimiento y quedan en el informe del mes.

Para la capa de tienda, consulte el desarrollador WooCommerce en Sevilla. Operadores con filiales en Madrid o Barcelona comparan el mismo SLA con mantenimiento WordPress en Madrid y mantenimiento WordPress en Barcelona.

#El siguiente paso

Si gestiona un WordPress en Sevilla y quiere dejar de tratar las actualizaciones como una lotería, el primer paso es una revisión de su instalación actual: estado de las copias, plugins en riesgo, versión de PHP y referencia de rendimiento. A partir de ahí proponemos un plan de mantenimiento concreto, con criterios medibles y un calendario que respeta los picos comerciales de la ciudad. Sin discurso de venta, una conversación técnica sobre el estado real de su sitio y qué hace falta para mantenerlo sano.

Para mantenimiento estable fuera de las grandes plazas, mira el mantenimiento WordPress en Bilbao.

Para mantenimiento estable fuera de las grandes plazas, mira el mantenimiento WordPress en Zaragoza.

Para mantenimiento estable fuera de las grandes plazas, mira el mantenimiento WordPress en Córdoba.

Para mantenimiento estable fuera de las grandes plazas, mira el mantenimiento WordPress en Alicante.

Para mantenimiento estable fuera de las grandes plazas, mira el mantenimiento WordPress en Málaga.

Para mantenimiento estable fuera de las grandes plazas, mira el mantenimiento WordPress en Valladolid.

Para mantenimiento estable fuera de las grandes plazas, mira el mantenimiento WordPress en Fráncfort.

Para mantenimiento estable fuera de las grandes plazas, mira el mantenimiento WordPress en Lisboa.

Para mantenimiento estable fuera de las grandes plazas, mira el mantenimiento WordPress en Zúrich.