Mantenimiento WordPress en Barcelona

El mantenimiento de WordPress en Barcelona no consiste en aplicar parches a ciegas el martes por la noche. Consiste en mantener un sitio que factura, capta leads o vende en línea funcionando de forma estable mientras WordPress, WooCommerce y la normativa española siguen cambiando bajo los pies. Damos soporte continuo a empresas de Barcelona y del resto de Cataluña que ya tienen un sitio en producción y no quieren que cada actualización sea una tirada de dados.

#Mantenimiento WordPress en Barcelona

La mayoría de los sitios que asumimos en Barcelona no nacieron mal: envejecieron sin cuidado. Plugins que la agencia original dejó de actualizar, una versión de PHP que el hosting ya marca como obsoleta, copias de seguridad que nadie ha restaurado nunca para comprobar que funcionan. El mantenimiento serio empieza por revertir esa deriva y después mantenerla a raya mes a mes, con un registro escrito de qué se tocó y por qué.

#Qué incluye el mantenimiento mensual

• Actualizaciones de WordPress core, plugins y temas probadas primero en un entorno de pruebas idéntico al de producción, con un plan de reversión documentado antes de cada despliegue
• Copias de seguridad diarias con retención de 30 días, almacenadas fuera del propio servidor, con restauraciones de prueba periódicas (una copia que nunca se ha restaurado no es una copia, es una suposición)
• Monitorización de seguridad: escaneo de malware, verificación de integridad de ficheros, vigilancia de intentos de acceso y reglas de Web Application Firewall ajustadas a los vectores típicos de WordPress
• Monitorización de uptime y de Core Web Vitals (LCP, INP, CLS) con avisos cuando una métrica se sale del presupuesto acordado
• Horas mensuales de desarrollo para cambios pequeños: ajustes de contenido, correcciones, retoques de plantilla, sin necesidad de abrir un presupuesto aparte
• Informe mensual con lo aplicado, lo detectado y lo que conviene planificar para el mes siguiente

#Por qué el contexto de Barcelona cambia el trabajo

Barcelona concentra una parte desproporcionada del tejido digital español. El distrito 22@ de Poblenou, levantado sobre el antiguo suelo industrial de Sant Martí, reúne hoy más de 1.500 empresas vinculadas a tecnología, medios y diseño, con sedes como la de Glovo (Yellow Park) y la presencia de la Universitat Politècnica de Catalunya y la Pompeu Fabra alimentando talento. Cada marzo, el Mobile World Congress y el 4YFN en la Fira de Gran Via traen más de 100.000 visitantes y centenares de startups a la ciudad.

Esto importa para el mantenimiento por una razón muy concreta: los picos de tráfico no son hipotéticos. Una agencia, un SaaS o un comercio de Barcelona que aparezca en prensa durante la semana del MWC, o que lance una campaña coincidiendo con el evento, recibe una carga que un hosting compartido sin caché de objetos no aguanta. Parte de nuestro trabajo de mantenimiento es preparar el sitio para esas ventanas: revisar la caché, el TTFB y los límites de PHP antes de que el tráfico llegue, no durante la caída.

#Mantenimiento de WooCommerce y cumplimiento de pagos en España

Buena parte de los sitios WordPress que mantenemos en Barcelona venden con WooCommerce, y ahí el mantenimiento se cruza de lleno con la realidad de pagos española. Redsys es la pasarela bancaria dominante en España (la usan Santander, BBVA y CaixaBank, entre otros), y Bizum, con decenas de millones de usuarios, se ha vuelto un método de cobro que los clientes esperan ver en el checkout. Mantener un WooCommerce aquí significa, en la práctica:

• Vigilar que la integración de Redsys siga firmando correctamente tras cada actualización del plugin de pasarela o de WooCommerce (un cambio de versión que rompe la firma HMAC deja el checkout muerto sin avisar)
• Comprobar que Bizum sigue activo como método independiente y que su flujo de redirección no se rompe con cambios de tema o de caché de página
• Probar el checkout completo en el entorno de pruebas después de cada ciclo de actualización, no solo cargar la home y dar por bueno el despliegue

#VeriFactu: el cambio normativo que conviene anticipar

El sistema VeriFactu de la Agencia Tributaria obliga a que el software de facturación genere registros encadenados, inalterables y con código QR en la factura. Tras la prórroga aprobada por el Real Decreto-ley 15/2025, los sujetos del Impuesto sobre Sociedades deberán tener adaptados sus sistemas antes del 1 de enero de 2027, y el resto de obligados antes del 1 de julio de 2027; los fabricantes de software ya debían ofrecer versiones adaptadas desde julio de 2025.

Para un comercio o una empresa de servicios de Barcelona que emite facturas desde WooCommerce o desde un plugin de facturación sobre WordPress, esto no es un detalle contable lejano: es una dependencia que hay que tener en el radar de mantenimiento. Cuando llegue el plugin o la actualización que añada el registro VeriFactu y el QR, habrá que probarla en el entorno de pruebas contra una factura real antes de tocar producción. Anticipar ese cambio dentro del plan de mantenimiento evita la prisa de última hora cuando la fecha apriete.

#RGPD y privacidad, gestionadas en el mantenimiento

El cumplimiento del RGPD (y de la LOPDGDD española) no se resuelve una vez y se olvida. Cada plugin nuevo, cada herramienta de analítica o de marketing que se añade, puede cambiar qué datos se recogen y qué cookies se cargan antes del consentimiento. En el mantenimiento revisamos que el banner de consentimiento siga bloqueando scripts no esenciales hasta la aceptación, que los formularios sigan registrando la base legal y que las integraciones con terceros no introduzcan transferencias de datos no declaradas tras una actualización.

#Cómo hacemos el onboarding de un sitio existente

No empezamos cobrando una cuota mensual sobre un sitio que no conocemos. El primer paso es siempre una auditoría:

1. Inventario y diagnóstico: listamos plugins y temas, versión de PHP, configuración de hosting, estado real de las copias de seguridad y postura de seguridad. Aquí salen casi siempre sorpresas (un plugin abandonado con CVE conocido, un cron de WordPress que nunca dispara, una base de datos hinchada de transients).
2. Referencia de rendimiento: medimos Core Web Vitals y TTFB en estado actual para tener una línea base contra la que comparar.
3. Lista de remediación: separamos lo crítico (vulnerabilidades, backups rotos, PHP sin soporte) de lo que puede esperar. El primer mes de un sitio descuidado suele ser más remediación que mantenimiento, y lo decimos por adelantado.
4. Cadencia estable: una vez saneado, pasamos al ritmo mensual de actualizaciones probadas, backups, escaneos e informe.

#Problemas que nos llegan con más frecuencia

• Una actualización rompió el sitio y nadie sabe cuál fue. Sin entorno de pruebas ni control de versiones, recuperar un sitio caído es arqueología. Nosotros probamos cada ciclo en el entorno de pruebas y mantenemos puntos de reversión, así que volver atrás es cuestión de minutos, no de noches en vela.
• El checkout de WooCommerce falla de forma intermitente. Suele ser una combinación de caché de página sirviendo el carrito cacheado, un conflicto entre la pasarela Redsys y otro plugin, o un timeout de PHP en la confirmación del pedido. Se diagnostica con logs, no adivinando.
• La base de datos se ha vuelto lenta tras años de uso. Limpiamos opciones autoload pesadas, purgamos transients caducados, archivamos revisiones antiguas de entradas y revisamos índices. En sitios maduros esto recorta de forma notable la carga de consultas.
• El equipo editorial rompe maquetaciones sin querer. Configuramos roles, flujos de revisión y publicación programada para que un cambio de contenido no tumbe una plantilla.

#Cómo trabajamos día a día

La comunicación va por un canal de tickets escrito, de modo que cada decisión queda trazada y cualquier persona del equipo cliente puede leer el histórico. Las llamadas se reservan para lo que de verdad necesita voz: un incidente en curso o una decisión de arquitectura. Cada mes llega un informe con lo aplicado, lo detectado y las recomendaciones.

El trato es directo con quien hace el trabajo técnico, sin capas intermedias que transmitan mensajes ni perfiles júnior aprendiendo sobre tu sitio en producción. Si surge un cambio de alcance, se habla antes con sus implicaciones claras; la facturación es individual y se acuerda por adelantado, sin sorpresas.

#Seguridad y respuesta a incidentes

La seguridad de un WordPress en mantenimiento se sostiene en capas: servidor endurecido, WAF con reglas ajustadas a los patrones de ataque habituales contra WordPress, escapado de salida y consultas parametrizadas en cualquier código a medida, verificación de nonces en formularios y limitación de intentos en el login. Cuando aparece una vulnerabilidad en un plugin en uso, el objetivo es aplicar el parche lo antes posible tras su publicación, probándolo primero en el entorno de pruebas salvo que la gravedad obligue a un despliegue de urgencia con vigilancia posterior.

Ante un incidente confirmado (malware, defacement, caída de producción) seguimos un protocolo: contener, documentar la cronología y la causa raíz, remediar y dejar constancia auditable en el informe. Un incidente mal documentado es un incidente que vuelve a ocurrir.

#Rendimiento, medido antes y después

La velocidad influye directamente en la conversión, y en un comercio que cobra con Redsys y Bizum cada segundo de checkout cuenta. El trabajo de rendimiento dentro del mantenimiento es continuo, no un sprint puntual:

• Caché en capas: caché de página, caché de objetos (Redis) para consultas repetidas, y una CDN delante para servir estáticos cerca del visitante
• Imágenes: conversión a WebP/AVIF y srcset responsivo, que en sitios cargados de fotografía de producto suele ser la mayor palanca de mejora de LCP
• Base de datos: limpieza periódica de autoload y transients, que es donde más se degrada un WordPress veterano
• Red: HTTP/2 o HTTP/3, compresión Brotli y resource hints donde aportan

Medimos Core Web Vitals antes y después de cada intervención y dejamos las cifras en el informe, para que la mejora sea verificable y no una afirmación de marketing.

#Preguntas frecuentes de empresas en Barcelona

¿Podéis asumir un sitio que ya tiene problemas? Sí. De hecho es lo más habitual. La auditoría inicial saca a la luz lo crítico y producimos una lista de remediación antes de pasar al mantenimiento estable.

¿Mantenéis WooCommerce con Redsys y Bizum? Sí. Tratamos el checkout como el punto más sensible del sitio: cada ciclo de actualización se prueba contra un pedido real en el entorno de pruebas antes de tocar producción.

¿El servicio se presta en remoto? Sí. Trabajamos por tickets con informes mensuales; la mayoría de clientes de Barcelona y de fuera no necesitan reuniones presenciales para un mantenimiento que funciona.

¿Qué pasa con VeriFactu cuando llegue su fecha? Lo seguimos dentro del plan: cuando el plugin de facturación publique la versión adaptada, la probamos en el entorno de pruebas contra una factura real antes de desplegarla, sin esperar al último día del plazo.

¿Cuánto cuesta? La cuota depende del tamaño del sitio, del stack y de cuánta remediación arrastre. La valoración es individual y se cierra tras la auditoría inicial, no antes.

#Endurecimiento del servidor y protocolo ante una intrusión

El apartado de seguridad de más arriba enumera las capas de defensa. Este baja al detalle: la configuración concreta que las sostiene y el procedimiento que se activa cuando algo ya ha entrado. Son dos trabajos distintos. Uno se hace en frío, con calma y en el entorno de pruebas; el otro se hace bajo presión y con un reloj legal corriendo, así que conviene tenerlo escrito antes de necesitarlo.

Permisos y propiedad de ficheros. El reparto sano de permisos en un WordPress es 755 para directorios y 644 para ficheros, con wp-config.php restringido a 600 o 440 porque contiene las credenciales de base de datos y las claves de sal. El 777 no es una solución a un problema de permisos, es la renuncia a tenerlos. Igual de importante es la propiedad: los ficheros deben pertenecer al usuario bajo el que corre PHP-FPM, no a root ni al usuario del servidor web, y el grupo debe permitir la lectura sin conceder escritura. La auditoría se hace rápido con find usando -type f y -perm, listando primero lo que se sale de la norma antes de corregir nada en masa. El directorio wp-content/uploads necesita escritura, y precisamente por eso hay que bloquear la ejecución de PHP dentro de él a nivel de servidor: un fichero subido a través de un formulario mal validado deja de ser un problema si el servidor se niega a interpretarlo.

Editor de código del panel. La constante DISALLOW_FILE_EDIT en wp-config.php elimina el editor de plugins y temas del escritorio. Es de las medidas con mejor relación entre coste y efecto: una cuenta de administrador robada deja de poder escribir PHP arbitrario en dos clics. La versión más estricta, DISALLOW_FILE_MODS, bloquea además la instalación y la actualización de plugins y temas desde el panel; tiene sentido cuando las actualizaciones llegan por WP-CLI o por un flujo de despliegue automatizado, y no tiene sentido si el equipo cliente todavía instala plugins por su cuenta. Es una decisión de proceso, no solo de seguridad, y se acuerda en el onboarding.

XML-RPC y la REST API para usuarios no autenticados. xmlrpc.php sigue siendo un vector cómodo para el atacante: el método system.multicall permite probar muchas combinaciones de credenciales en una sola petición, lo que multiplica la eficacia de un ataque de fuerza bruta frente al formulario de login, y pingback.ping se ha usado históricamente para reflejar tráfico contra terceros. Si nada en el sitio lo necesita (ni la app móvil, ni Jetpack, ni un cliente de publicación externo), se bloquea en el servidor o en el WAF. Si algo lo necesita, se permite solo lo que hace falta y se limita el ritmo de peticiones. Con la REST API el bisturí tiene que ser más fino: el editor de bloques y buena parte de WooCommerce dependen de ella para usuarios autenticados, así que apagarla entera rompe el panel. Lo que sí se cierra es el acceso anónimo a lo que no aporta nada público, empezando por la enumeración de usuarios en /wp-json/wp/v2/users, que expone el listado de autores con su nombre público, y en muchas instalaciones ese nombre coincide con el de acceso. Los filtros rest_endpoints y rest_authentication_errors permiten exigir sesión iniciada en las rutas que no deban ser públicas, y conviene cerrar también la enumeración clásica por el parámetro author en la URL.

Doble factor y gobierno de cuentas. El segundo factor debe ser obligatorio para los roles con capacidad de escribir código o de ver datos personales: administrador, editor y, en tiendas, gestor de pedidos. TOTP funciona en cualquier sitio; WebAuthn o las claves de acceso son mejores porque resisten el phishing, que es una de las vías por las que más credenciales se pierden. Las contraseñas de aplicación de WordPress son cómodas para integraciones, pero son credenciales de larga vida: hay que inventariarlas, asignarlas a un uso concreto y revocarlas cuando ese uso termina, o desactivarlas si nadie las usa. Nada de cuentas de administrador compartidas entre varias personas: sin cuenta individual no hay trazabilidad, y sin trazabilidad la investigación de un incidente se queda en conjeturas. Tras cualquier sospecha, wp user session destroy cierra las sesiones abiertas de forma explícita; conviene ejecutarlo en lugar de dar por hecho que el cambio de contraseña ya se las ha llevado por delante, porque eso depende de por dónde se haya cambiado.

WAF y limitación de ritmo. El WAF cumple dos funciones que no se deben confundir. La primera es el parcheo virtual: cuando se publica una vulnerabilidad en un plugin en uso, una regla puede bloquear el patrón de explotación mientras la actualización se prueba en el entorno de pruebas, de modo que la urgencia no obligue a desplegar a ciegas en producción. La segunda es la limitación de ritmo sobre los puntos que un atacante golpea una y otra vez: wp-login.php, xmlrpc.php, las rutas de recuperación de contraseña y, en WooCommerce, el checkout y la validación de cupones, donde el abuso automatizado también sale caro en CPU. Lo que el WAF no es: un sustituto de la actualización. Compra tiempo para probar, no permiso para no parchear.

#Cómo reconocer que una instalación está comprometida

Rara vez hay un cartel que lo anuncie. Las señales que sí aparecen, ordenadas por lo pronto que suelen verse:

• wp core verify-checksums y wp plugin verify-checksums devuelven ficheros modificados respecto a los originales del repositorio oficial. Es la comprobación más barata y la primera que hacemos.
• Aparecen usuarios administradores que nadie ha creado, o una cuenta legítima cambia de rol sin registro en el histórico de tickets.
• wp cron event list muestra tareas programadas con nombres que no corresponden a ningún plugin instalado, a menudo el mecanismo de persistencia que reinfecta después de una limpieza.
• Ficheros PHP nuevos dentro de wp-content/uploads, o ficheros del core con fecha de modificación reciente sin que haya habido despliegue. Un find con -type f, -name para PHP y -mtime acotado a los últimos días lo saca en segundos.
• Contenido inyectado que solo se sirve a Googlebot o a visitantes que llegan desde un buscador, mientras el navegador del propietario ve la página normal. Search Console lo delata antes que el ojo humano: páginas indexadas en otro idioma, picos de consultas ajenas al negocio o un aviso en el informe de problemas de seguridad.
• Redirecciones que solo se activan en móvil, .htaccess reescrito o los valores siteurl y home alterados en la tabla de opciones.
• El servidor empieza a enviar correo saliente en volumen y la IP acaba en listas de bloqueo, con el efecto colateral de que dejan de llegar los correos de pedido.

#Procedimiento paso a paso ante un incidente

1. Preservar la evidencia antes de limpiar. Copia completa de ficheros y base de datos en el estado comprometido, más los registros de acceso, de error y del WAF. Limpiar primero destruye la única traza que permite saber por dónde entraron, y sin esa respuesta la puerta sigue abierta para la siguiente vez. En una tienda, además, esa evidencia es lo que después sostiene la valoración legal.
2. Contener. Cortar el acceso público desde el WAF o poner el sitio en mantenimiento, cerrar todas las sesiones activas y rotar credenciales sin excepción: contraseñas de administrador, contraseñas de aplicación, usuario de base de datos, claves SSH y SFTP, claves de sal (wp config shuffle-salts invalida de golpe las cookies de sesión) y las credenciales de las integraciones, incluidas las de la pasarela de pago.
3. Delimitar el alcance. Cruzar la fecha de los ficheros modificados con los registros de acceso para identificar la vía de entrada, normalmente un plugin con vulnerabilidad conocida o una cuenta sin doble factor. Aquí se decide lo importante: si hubo acceso a la base de datos y, en ese caso, a qué datos personales (pedidos, direcciones, correos de formularios, usuarios registrados).
4. Erradicar reinstalando, no desinfectando. El core y los plugins se reponen desde la fuente oficial con wp core download --force y reinstalación forzada de cada plugin, en lugar de borrar a mano el código sospechoso. El tema y el código a medida vuelven desde el control de versiones. En base de datos se eliminan usuarios y tareas programadas ilegítimas y el contenido inyectado, y se revisan las opciones con autoload por si guardan carga útil.
5. Verificar y devolver a producción. Comprobación de sumas limpia, lista de usuarios y roles revisada, cron sin tareas extrañas, escaneo externo y vigilancia reforzada de registros durante los días siguientes, que es cuando se manifiesta una puerta trasera que sobrevivió.
6. Cerrar con un informe escrito. Cronología, vía de entrada, datos afectados, medidas aplicadas y cambios de configuración para que no se repita. Los plazos de respuesta y de entrega del informe no se prometen en abstracto: los fija el contrato de mantenimiento y ahí es donde deben leerse.

La obligación de notificar una brecha bajo el RGPD. No todo incidente técnico es una brecha de datos personales, pero un WordPress con clientes registrados, pedidos o formularios casi siempre trata datos personales, y en una tienda de Barcelona que cobra con Redsys y Bizum el volumen de datos de cliente es considerable. Cuando se confirma una violación de seguridad que afecta a datos personales, el responsable del tratamiento (el cliente, no la agencia) debe notificarla a la autoridad de control sin dilación indebida y, a más tardar, en el plazo de 72 horas desde que tuvo constancia de ella, salvo que sea improbable que suponga un riesgo para los derechos y libertades de los afectados. El artículo 33 del RGPD admite notificación por fases si no se dispone de toda la información, así que la falta de detalle no justifica agotar el plazo. La autoridad competente con carácter general en España es la AEPD, que dispone de un canal específico de notificación de brechas y de una herramienta de valoración del riesgo; en Cataluña, la APDCAT asume la competencia sobre el sector público catalán.

Si la brecha entraña un alto riesgo para los afectados, el artículo 34 obliga además a comunicárselo a ellos sin dilación indebida, con lenguaje claro y con medidas concretas que puedan tomar. Y con notificación o sin ella, el artículo 33.5 exige documentar toda violación en un registro interno, incluidos los hechos, sus efectos y las medidas correctivas. Aquí es donde el trabajo técnico y el legal se tocan: la agencia que mantiene el sitio actúa normalmente como encargado del tratamiento, y en esa posición debe informar al responsable sin dilación indebida para que el reloj de las 72 horas no se le agote mientras espera un diagnóstico. Por eso el procedimiento anterior prioriza la evidencia y la delimitación del alcance sobre la prisa por devolver la web a producción: lo que el cliente necesita para decidir si notifica no es que el sitio vuelva a cargar, sino saber qué datos, de quién y cuándo. Ese es el entregable real de una respuesta a incidentes bien hecha, y conviene tener acordado por escrito, antes de que pase nada, quién redacta qué parte de él.

Para la capa de tienda, consulte el desarrollador WooCommerce en Barcelona. Operadores con filiales en la capital reutilizan el mismo SLA en mantenimiento WordPress en Madrid.

#Empezar

Si tienes un WordPress o un WooCommerce en producción en Barcelona y quieres dejar de improvisar cada actualización, el primer paso es una auditoría de tu instalación actual: estado de plugins, hosting, copias de seguridad, seguridad y rendimiento. Con ese diagnóstico sobre la mesa decidimos juntos qué remediar primero y qué cadencia de mantenimiento tiene sentido para tu sitio.

Si además operas un WordPress en Mallorca, el mismo criterio de actualizaciones y vigilancia aplica en mantenimiento WordPress en Palma de Mallorca.

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.