El aviso llegó porque el sitio “no se veía bien”.

Entré y encontré un ecommerce sin header, sin footer y con partes enteras rotas. Lo primero que apareció fue bastante claro: Elementor Pro — el constructor con el que estaba armado el sitio — estaba desinstalado.

En su lugar había plugins para Elementor que no pertenecían a la instalación original. Plugins agregados después, probablemente intentando reemplazar funcionalidades de Elementor Pro con alternativas gratuitas. El resultado fue exactamente el esperable: el sitio quedó fragmentado.

Después revisé los backups.

El último disponible tenía aproximadamente un año.

Y ahí apareció el problema real.

Porque restaurar un backup viejo en un ecommerce no es solamente volver atrás en diseño o contenido. Significa perder pedidos, clientes registrados, historial de compras, cambios de stock y toda la operación de los últimos doce meses.

No era una opción.

Antes de tocar producción levanté el backup en un entorno local para entender qué seguía existiendo y qué tan alterado estaba el sitio actual.

La buena noticia fue que la estructura original seguía ahí. El problema no era pérdida de información. Era desconfiguración.

El plan de contingencia era simple: si reinstalar Elementor Pro no alcanzaba, iba a reconstruir la estructura visual exportando las plantillas desde el backup e importándolas al sitio actual, sin tocar la base de datos de WooCommerce.

La prioridad era recuperar el sitio sin afectar pedidos, clientes ni operación.

Reinstalé Elementor Pro.

El sitio volvió apenas se reinstaló el plugin. Headers, footers y templates seguían guardados en la base de datos. El constructor faltaba, pero la estructura seguía existiendo.

Con eso resuelto empezó la parte importante: la auditoría.

El ecommerce tenía siete usuarios con rol de Administrador.

En WordPress ese rol no tiene restricciones reales: puede instalar o eliminar plugins, modificar temas, borrar usuarios o cambiar configuraciones críticas. Siete administradores en un ecommerce son siete puntos posibles de falla.

Se revisaron los accesos y se dejó únicamente el usuario del propietario.

También aparecieron páginas publicadas que no deberían existir: pruebas, duplicados e intentos fallidos de rehacer partes del sitio. Algunas incluso podían ser indexadas por Google. Se eliminaron.

Después vino la revisión de plugins.

El sitio tenía más de veinte. Algunos activos, otros desactivados y varios que nadie tenía claro para qué estaban ahí. El criterio fue bastante directo:

si un plugin no cumple una función concreta hoy, sobra.

Se eliminaron plugins agregados después de la instalación original, herramientas sin configurar, funcionalidades duplicadas y componentes que ya no tenían uso real.

Uno de los casos más comunes en este tipo de sitios es encontrar más de un plugin de seguridad activo al mismo tiempo. Acá pasaba eso.

Dos plugins de seguridad no significan el doble de protección. Normalmente significa reglas duplicadas, conflictos y más complejidad innecesaria. Se dejó uno solo correctamente configurado.

Hubo un plugin que estuvo cerca de salir y terminó quedándose: Jetpack.

A simple vista parecía prescindible, pero durante la revisión apareció que estaba funcionando como CDN de imágenes y además había bloqueado miles de intentos de login. El sistema de caché principal no tenía CDN configurado — Jetpack estaba cubriendo esa parte sin que nadie lo tuviera presente.

Sin revisar el sitio completo, eso pasaba desapercibido.

Al final quedaron activos únicamente los componentes que tienen una función clara en la operación del ecommerce:

Nada más.

Lo único que sigue pendiente no tiene que ver con WordPress ni con Elementor.

El sitio no tiene backups automáticos configurados.

El respaldo de hace un año había sido manual y terminó siendo la única red disponible cuando el sitio cayó.

Y ese suele ser el problema real en muchos ecommerce: no el día que algo se rompe, sino el día que nadie tiene una forma segura de volver atrás.