Mantenimiento WordPress en Alicante

El mantenimiento de WordPress en Alicante no consiste en aplicar actualizaciones sin pensar. Consiste en mantener un sitio que factura, vende y cumple la normativa española funcionando sin sorpresas, mes tras mes. Trabajamos con empresas de la ciudad y de la provincia, desde tiendas que cobran con Bizum y Redsys hasta webs corporativas del ecosistema de Distrito Digital, con un objetivo claro: que la web deje de ser una fuente de incidentes imprevistos.

#Mantenimiento WordPress para el tejido empresarial de Alicante

Alicante no es un mercado genérico. La provincia exporta calzado y producto agroalimentario por más de 5.200 millones de euros a más de 200 destinos, vive del turismo durante buena parte del año y, en paralelo, ha levantado un polo digital alrededor de Distrito Digital Comunidad Valenciana, con sedes en la Ciudad de la Luz y el Puerto de Alicante. Cada uno de esos perfiles tiene un patrón de riesgo distinto en su WordPress.

Una tienda de calzado de Elche que vende a Francia y Alemania no puede permitirse una caída en plena campaña. Un hotel o un apartamento turístico del litoral sufre picos de tráfico estacionales que revientan la caché mal configurada. Una startup alojada en la órbita de la Ciudad de la Luz necesita un sitio que aguante demos, prensa y rondas sin tocar nada a deshora. El mantenimiento que ofrecemos parte de entender en cuál de esos escenarios está su negocio antes de tocar una sola línea de configuración.

#Qué incluye el mantenimiento mensual

• Actualizaciones de núcleo, plugins y temas validadas primero en un entorno de pruebas idéntico a producción, con plan de reversión documentado antes de promover ningún cambio
• Copias de seguridad diarias con retención de 30 días en ubicaciones separadas geográficamente, con restauraciones probadas (no solo programadas) y tiempos de recuperación documentados
• Monitorización de seguridad: escaneo de malware, verificación de integridad de archivos, control de intentos de acceso y reglas de Web Application Firewall ajustadas a los vectores de ataque típicos de WordPress
• Seguimiento de Core Web Vitals y de tiempo de respuesta del servidor, con informe mensual que indica qué se midió, qué cambió y qué riesgo queda pendiente
• Horas de desarrollo incluidas para pequeños ajustes (cambios de contenido, correcciones, retoques funcionales) sin abrir un presupuesto aparte cada vez
• Revisión de compatibilidad de versión de PHP y salud de plugins, para que las actualizaciones no se conviertan en una deuda que estalla de golpe

#Pagos y normativa española: lo que de verdad rompe una tienda

La parte más delicada del mantenimiento de un WooCommerce en Alicante casi nunca es el diseño. Es la pasarela de pago y la facturación.

En España, la mayoría de bancos (Sabadell, CaixaBank, Santander, BBVA, Bankinter) operan el TPV virtual a través de Redsys, y sobre esa misma pasarela se activa Bizum como método independiente. Cada actualización de WooCommerce o del plugin de Redsys puede romper la firma de la transacción, dejar pedidos en estado “pendiente” que sí se cobraron, o tumbar Bizum sin que nadie lo note hasta que un cliente reclama. Por eso, en sitios con cobro online, validamos cada ciclo de actualización contra un pedido de prueba real en el entorno de pruebas antes de tocar producción: una actualización aplicada a ciegas en una tienda que cobra es la forma más rápida de perder ventas sin darse cuenta.

A esto se suma VeriFactu. La obligación se aplazó respecto a las fechas originales: las empresas sujetas al Impuesto de Sociedades quedan obligadas desde el 1 de enero de 2027 y el resto de empresas y autónomos desde el 1 de julio de 2027, mientras que los fabricantes de software de facturación debían tener sus productos adaptados desde el 29 de julio de 2025. Para una tienda WooCommerce de Alicante esto significa que el sistema que genera facturas tendrá que ser conforme a VeriFactu, y que esa integración (normalmente un plugin de facturación o un conector con el software contable) entra dentro de lo que hay que mantener y vigilar como cualquier otra pieza crítica. La pasarela de pago y el sistema de facturación son independientes, así que tratamos cada uno por separado en el plan de mantenimiento.

Y por encima de todo, RGPD y LSSI-CE: cookies, formularios de contacto, registros de consentimiento y los datos personales que WooCommerce almacena en la base de datos. Una web descuidada acumula plugins que escriben datos personales sin control; parte del mantenimiento es revisar que esa superficie no crezca sin que nadie la mire.

#El mercado real de Alicante, no un cliente abstracto

Nuestra cartera en Alicante mezcla pymes exportadoras del eje Alicante-Elche, comercios y hostelería del litoral, y empresas tecnológicas vinculadas al ecosistema de Distrito Digital. La cercanía de la Universidad de Alicante y de la Universidad Miguel Hernández de Elche (que llega a impartir formación específica en ecommerce y marketing online) alimenta un tejido de proyectos digitales que necesitan operación seria, no parches puntuales.

En todos esos casos la web ya es una pieza operativa del negocio, no un folleto. Una tienda que cobra con Bizum, un portal de reservas turísticas o el sitio de producto de una empresa exportadora dejan de funcionar como escaparate y pasan a depender de que las actualizaciones, los backups y el rendimiento estén bajo control. El mantenimiento existe precisamente para que esa dependencia no se convierta en un punto único de fallo.

#Cómo trabajamos un ciclo de mantenimiento

1. Auditoría de onboarding. Inventariamos plugins, hosting, estado real de los backups (probando una restauración, no fiándonos del panel), postura de seguridad y una referencia de rendimiento con Lighthouse. En tiendas, comprobamos el estado de Redsys, Bizum y del flujo de facturación.
2. Monitorización y entorno de pruebas. Activamos seguimiento de uptime, rendimiento y seguridad, fijamos backups diarios con 30 días de retención y preparamos un entorno de pruebas donde validar cada actualización.
3. Primer ciclo controlado. El primer ciclo de actualizaciones se ejecuta en el entorno de pruebas, se valida contra pruebas de regresión (incluido un pedido de prueba si hay tienda) y se promueve a producción con plan de reversión escrito.
4. Cadencia mensual. Actualizaciones probadas, backups, escaneos, control de Core Web Vitals e informe mensual con métricas, decisiones y riesgos abiertos.
5. Respuesta a incidentes. Ante un compromiso de seguridad o una caída, activamos el protocolo de SLA: respondemos, contenemos, documentamos cronología y causa raíz, y entregamos la remediación con trazabilidad.

#Incidencias que más vemos en sitios de la provincia

• Tiendas con decenas de plugins acumulados durante años, base de datos hinchada de transients caducados y revisiones antiguas, y un TTFB que se dispara los días de más tráfico. Limpiamos autoload, transients e índices y aligeramos la consulta antes de añadir más caché encima del problema.
• WooCommerce hackeados que llegan ya con spam inyectado o redirecciones maliciosas: análisis forense, retirada del código, parcheo de la vulnerabilidad de origen, rotación de credenciales y endurecimiento para que no vuelva por la misma puerta.
• Webs estacionales (hostelería, turismo) que aguantaban bien en temporada baja y colapsan en temporada alta porque la caché y el hosting no se dimensionaron para el pico real.
• Pasarelas de pago que dejaron de firmar correctamente tras una actualización a ciegas, con pedidos cobrados pero marcados como pendientes.
• Equipos editoriales que rompen plantillas o publican páginas a medias: configuramos roles, control de revisiones y flujos de aprobación que evitan el cambio destructivo.

#Seguridad pensada para WooCommerce

La seguridad no es un añadido posterior. En los sitios de Alicante que mantenemos aplicamos endurecimiento del servidor, reglas de WAF ajustadas a WordPress, consultas parametrizadas frente a inyección SQL, escapado de salida frente a cross-site scripting, verificación de nonces en formularios y limitación de peticiones en los endpoints de autenticación. En una tienda esto importa el doble: el panel de WooCommerce custodia datos personales de clientes y, según el flujo, información de pedidos sujeta a RGPD. Cuando se confirma un incidente, la actuación queda registrada con cronología, causa raíz y pasos de remediación para que sea auditable.

#Rendimiento: por qué pesa tanto en este mercado

Para una tienda de Elche que vende fuera de España o un portal de reservas del litoral, la velocidad es conversión directa. Nuestro trabajo de rendimiento en mantenimiento incluye:

• Recursos. Imágenes servidas en WebP y AVIF con srcset responsivo, CSS dividido por ruta y crítico en línea para el contenido visible, y JavaScript con code-splitting y carga diferida.
• Caché por capas. Navegador, CDN (Cloudflare), caché de aplicación (Redis) y caché de consultas con invalidación cuidadosa, ordenadas para no enmascarar una base de datos lenta.
• Red. HTTP/3 con QUIC, compresión Brotli y hints de preconnect y dns-prefetch hacia los orígenes que de verdad se usan (incluida la pasarela de pago).
• Renderizado. Carga asíncrona de estilos, lazy loading de imágenes e iframes y animaciones disparadas por Intersection Observer.

Cada cambio se mide antes y después, y la referencia queda en el informe mensual. No prometemos un porcentaje fijo de mejora porque depende del punto de partida; sí documentamos el delta real medido en su sitio.

#Preguntas frecuentes de las empresas de Alicante

¿Trabajáis solo en remoto? Sí. La operación se gestiona por un canal de tickets escrito, con informes mensuales. Las llamadas se reservan para decisiones o para repasar un incidente concreto. Estar en Alicante o en cualquier punto de la provincia no cambia el servicio.

¿Podéis asumir un WooCommerce ya con problemas? Sí. La auditoría inicial detecta lo crítico (PHP desfasado, plugins vulnerables, backups que no restauran, Redsys mal configurado) y produce una lista de remediación previa al mantenimiento estable. El primer mes de un proyecto heredado suele ser más remediación que rutina.

¿Qué pasa con VeriFactu y mi facturación? Lo tratamos como una pieza crítica más: identificamos qué sistema emite tus facturas, verificamos que sea (o vaya a ser) conforme a VeriFactu dentro de los plazos aplicables y lo incluimos en el ciclo de validación de actualizaciones. La pasarela de pago y el sistema de facturación se mantienen por separado porque son independientes.

¿En qué se diferencia esto de una agencia local genérica? El alcance se centra en mantenimiento de WordPress y WooCommerce, no en un paquete difuso de rediseño. Trato directo con perfil sénior, decisiones documentadas y criterios de aceptación medibles.

¿Cómo es la facturación del servicio? El mantenimiento continuo se factura de forma mensual. Las condiciones son individuales según el alcance y se fijan por escrito antes de empezar.

#Alcance: esta página es sobre mantenimiento, no sobre rediseño

El trabajo se define alrededor del servicio del título: revisión del estado actual, mapa de riesgos, prioridades, criterios de aceptación y verificación posterior. Si durante la auditoría aparece otra plataforma o una migración, lo tratamos como contexto del proyecto, no como excusa para convertir esto en otra cosa. El resultado sigue siendo un plan claro de mantenimiento para una empresa de Alicante: qué se actualiza, qué se vigila, qué se mide y qué conviene posponer.

#Copias de seguridad y recuperación ante desastres

Una copia de seguridad no existe hasta que alguien la restaura. El panel del plugin marca el trabajo como completado, el aviso diario llega puntual y el archivo pesa lo que debería, y aun así la restauración falla el día que hace falta. Los motivos son casi siempre los mismos: el volcado de la base de datos se cortó a mitad porque el proceso agotó el tiempo máximo de ejecución de PHP, el fichero .sql se guardó con una codificación distinta de la de las tablas originales y los acentos llegan rotos, o el paquete comprimido no incluye wp-content/uploads porque alguien excluyó esa carpeta para ahorrar espacio en el hosting. Por eso separamos dos cosas que muchos proveedores mezclan: la copia programada y la copia con restauración probada. Solo la segunda cuenta como protección real.

#La regla 3-2-1 aplicada a un WordPress en producción

Tres copias de los datos, en dos tipos de soporte distintos, con una fuera de las instalaciones. Aplicada a WordPress, eso significa el sitio vivo en producción, una copia en el propio hosting (útil por la rapidez de acceso, inútil si el incidente afecta al servidor) y una tercera en almacenamiento de objetos externo, compatible con S3, Backblaze B2 o Google Cloud Storage, en una cuenta que no comparte credenciales con el panel del hosting.

Ese último punto es el que más se descuida. Si las claves del destino remoto están guardadas en la configuración de un plugin dentro del propio WordPress, un atacante con acceso de administrador puede borrar las copias antes de cifrar o alterar el sitio. La mitigación es concreta: credenciales de escritura sin permiso de borrado, versionado activado en el bucket y bloqueo de objetos (object lock) durante la ventana de retención, de modo que ni siquiera una clave comprometida pueda eliminar el histórico. En una tienda del eje Alicante-Elche que factura a diario, ese detalle decide si el incidente cuesta unas horas de trabajo o el histórico completo de pedidos.

#Qué debe incluir un volcado completo

• Base de datos entera, no solo las tablas del núcleo. wp db export con las opciones --add-drop-table y --single-transaction genera un volcado consistente en InnoDB sin bloquear la tienda mientras se ejecuta. Las tablas propias de WooCommerce, del plugin de facturación y de los formularios no forman parte del esquema del núcleo, así que se pierden en cuanto el volcado se limita a una lista de tablas escrita a mano.
• wp-content/uploads completo, con las miniaturas generadas. Es la parte pesada y la primera que se excluye por comodidad.
• wp-content/themes, incluido el tema hijo con las plantillas personalizadas, y wp-content/plugins junto con wp-content/mu-plugins, que suele contener el código que nadie recuerda haber puesto ahí.
• wp-config.php, el .htaccess o la configuración equivalente de nginx, y wp-content/languages.
• La configuración que no vive en el sitio: reglas del WAF, registros DNS, certificados, tareas de cron del sistema si se sustituyó wp-cron.php, y las versiones exactas de PHP y de MySQL o MariaDB. Restaurar una base de datos hecha en una versión y levantarla en otra distinta introduce errores que no aparecen hasta semanas después.
• Cifrado en reposo del propio archivo, porque el volcado contiene datos personales de clientes sujetos al RGPD y, en muchas instalaciones, claves de integración con la pasarela y el software contable.

#Probar la restauración de verdad, no revisar el registro de backups

Probar significa levantar el sitio completo en un entorno aislado y usarlo. El procedimiento que aplicamos es siempre el mismo: crear un entorno con dominio distinto y acceso restringido, importar el volcado con wp db import, ejecutar wp search-replace primero con --dry-run para ver cuántas filas cambiarían y solo después en firme, validar los ficheros del núcleo con wp core verify-checksums, comparar el número de adjuntos frente al de producción y, si hay tienda, completar un pedido de prueba de principio a fin con la pasarela en modo de pruebas. Una restauración que arranca la portada pero no cierra un pedido no es una restauración válida para un WooCommerce.

La cadencia de esas pruebas se fija en el contrato de mantenimiento, junto con quién las ejecuta y quién firma el resultado. Lo que no depende del calendario es el disparador: además de la prueba periódica, la restauración se repite después de cualquier cambio estructural, es decir, migración de hosting, salto de versión mayor de PHP, cambio del plugin de pagos o del sistema de facturación. Cada una de esas operaciones invalida la suposición de que la última prueba sigue siendo representativa.

#RPO y RTO explicados sin jerga

El RPO responde a cuántos datos puede permitirse perder el negocio; el RTO, a cuánto tiempo puede estar parado. Si la única copia se genera de madrugada y el fallo ocurre por la tarde, el RPO efectivo es el trabajo de toda la jornada: pedidos, altas de clientes, contenido publicado y cambios de stock. Para una web corporativa eso puede ser tolerable. Para un portal de reservas del litoral en plena temporada alta, no lo es, y la respuesta técnica pasa por copias incrementales de la base de datos o por replicación con registro binario, no por hacer el volcado completo más veces.

El RTO incluye mucho más que el tiempo de importar un fichero. Suma la detección del problema, la decisión de restaurar, la descarga del archivo desde el almacenamiento externo, la importación, la limpieza de la caché en todas sus capas y la propagación en la CDN. Ambos valores son decisiones de negocio con coste asociado, no ajustes por defecto de un plugin: se acuerdan por escrito en el acuerdo de nivel de servicio antes de dimensionar la infraestructura, porque bajar el RPO obliga a cambiar la estrategia de copia y bajar el RTO obliga a tener un entorno de recuperación ya preparado.

#La primera hora tras una pérdida de datos

1. No restaurar encima de nada. Lo primero es congelar el estado actual y guardar una imagen de él, aunque esté corrupto o comprometido. Contiene evidencia forense y, con frecuencia, datos posteriores a la última copia que se podrán recuperar tabla a tabla más tarde.
2. Clasificar el incidente antes de actuar. Borrado accidental, actualización fallida, fallo de hardware y compromiso de seguridad exigen respuestas distintas. Restaurar una copia limpia sobre un sitio comprometido reinstala la vulnerabilidad de origen y el atacante vuelve por la misma puerta.
3. Aislar. Modo mantenimiento, cierre del proceso de pago y corte del acceso público mientras se decide. Seguir aceptando pedidos que no se van a poder servir agrava el problema legal y contable.
4. Localizar la última copia verificada y comprobar su integridad antes de importarla, no después: tamaño esperado, suma de verificación y apertura del volcado para confirmar que termina donde debe.
5. Restaurar en un entorno paralelo, validar allí y solo entonces conmutar. Restaurar directamente sobre producción elimina la posibilidad de comparar los dos estados.
6. Rotar credenciales: base de datos, SSH y FTP, cuentas de administrador, claves de seguridad y salts de wp-config.php, tokens de la pasarela y del ERP. Si hubo compromiso, todo lo que estuvo al alcance del atacante se considera expuesto.
7. Documentar la cronología mientras ocurre, no al día siguiente de memoria. Hora de cada acción, quién la ejecutó y qué se observó.
8. Evaluar la obligación de notificar. Si hay indicios de acceso a datos personales, se activa el artículo 33 del RGPD, que exige notificar a la autoridad de control (en España, la AEPD) sin dilación indebida y, de ser posible, a más tardar 72 horas después de tener constancia de la violación, además de valorar la comunicación a los afectados. Esa evaluación es parte del incidente, no un trámite posterior.

Los tiempos de respuesta y de escalado de nuestro equipo se definen en el contrato de mantenimiento y se registran ticket a ticket, de forma que cada intervención quede auditable con cronología, causa raíz y remediación.

Si la tienda que mantenemos también debe escalar hacia Madrid, Barcelona o Valencia, el encaje técnico se describe en el desarrollador WooCommerce en Madrid, el desarrollador WooCommerce en Barcelona y el desarrollador WooCommerce en Valencia.

#Empecemos

Cuéntenos en qué estado está su WordPress o su tienda WooCommerce en Alicante. La colaboración arranca con una auditoría que pone sobre la mesa los riesgos reales (pasarela, facturación, seguridad, rendimiento) y una propuesta con alcance, cadencia y condiciones definidas. Construimos y mantenemos soluciones WordPress desde 2007, hemos sobrevivido a cada actualización mayor del núcleo y seguimos cuidando sitios en producción por toda Europa.