Casi nueve años con Elementor. Y por qué ya no.

Llegué a España en 2016 con lo justo. Sin red, sin clientes, sin certezas. Solo las ganas de construir algo desde cero en un país que no era el mío, en un sector que todavía estaba definiendo sus reglas.

En 2017 descubrí Elementor. Fui de los primeros en adoptarlo y terminó convirtiéndose en una pieza central de mi trabajo durante casi nueve años.

Este no es un artículo contra Elementor. Es una explicación de algo más útil: cuándo una herramienta sigue resolviendo el problema y cuándo empieza a definir tus límites.

Más de 250 proyectos después

Con Elementor construimos tiendas online, webs corporativas, landings, portfolios y plataformas de contenido. También aprendimos la versión que no aparece en los tutoriales básicos: ACF conectado a widgets dinámicos, condiciones de visualización, variables globales, plantillas específicas de WooCommerce y sistemas pensados para que el cliente pudiera editar sin romper el diseño.

La web de Reveled también estuvo construida con Elementor durante años. No como una solución provisional, sino porque era la herramienta que mejor conocía.

Sigo manteniendo una licencia legacy de mil sitios. Para algunos clientes sigo trabajando con Elementor. La herramienta no se volvió mala de un día para otro.

Lo que cambió fue el tipo de problema que necesitábamos resolver.

Los límites aparecieron en cuatro lugares

1. Rendimiento

Un constructor visual debe servir componentes, estilos y compatibilidad para muchos escenarios. Esa flexibilidad tiene un coste. Se puede optimizar con caché, imágenes correctas, una buena configuración y menos plugins, pero llega un punto donde el trabajo consiste en compensar la arquitectura en lugar de construir desde una base ligera. En esta guía sobre el coste de una web lenta explicamos cómo medir ese impacto sin convertir una puntuación en una promesa de ventas.

No voy a publicar un «antes y después» inventado. No conservamos una medición histórica del antiguo sitio de Reveled realizada con el mismo contenido, dispositivo, red y versión de herramientas que permita una comparación seria con el actual. Una captura vieja de Lighthouse y una prueba nueva no serían evidencia comparable.

Lo que sí puede comprobarse en cada migración es:

• peso transferido;
• número de solicitudes;
• JavaScript ejecutado;
• LCP, INP y CLS de usuarios reales;
• estabilidad del diseño;
• tiempo necesario para cambiar y desplegar contenido.

Esas son las métricas que guardamos cuando el proyecto permite medir un antes y un después.

2. El contenido vive dentro del diseño

Elementor guarda buena parte de la estructura como datos en la base de datos. Para una persona que edita desde el panel puede ser cómodo. Para trabajar con Git, revisar cambios, buscar contenido en todo el proyecto o modificar muchas páginas de forma controlada, no lo es.

Cambiar un título en una página es sencillo. Revisar cien textos, detectar una frase repetida, automatizar una migración o comparar exactamente qué cambió entre dos versiones deja de serlo.

El problema no es que sea imposible. Es que el contenido y la presentación están demasiado unidos para el flujo que usamos ahora.

3. Automatización

Nuestros procesos actuales conectan contenido, código, APIs, validaciones y despliegues. Necesitan archivos que puedan leerse, compararse y probarse antes de publicar.

En un proyecto basado en archivos, una herramienta puede detectar una ruta sin canonical, comprobar enlaces, cambiar contenido en varias páginas y enseñar el diff antes del deploy. En Elementor, muchas de esas operaciones terminan convertidas en clics dentro del panel o en transformaciones delicadas sobre datos serializados.

La automatización no fue un añadido. Cambió el criterio con el que elegimos la arquitectura.

4. Mantenimiento acumulado

WordPress, Elementor y sus extensiones evolucionan a ritmos distintos. La mayoría de las actualizaciones salen bien. El problema aparece cuando una web depende de un tema, varios complementos, widgets de terceros y código añadido durante años.

Cada capa amplía lo que debe comprobarse: compatibilidad, seguridad, licencias, caché y comportamiento visual. Para un proyecto que necesita esa flexibilidad puede compensar. Para una web corporativa de contenido, muchas veces no.

Cuándo conservar Elementor y cuándo dejarlo

No tomamos la decisión por moda. La tomamos con una matriz sencilla:

Situación	Elementor	WordPress a medida	Astro
El equipo necesita editar visualmente cada página	Buena opción	Posible, con editor preparado	Requiere un CMS o flujo editorial
Presupuesto inicial muy ajustado	Puede encajar	Normalmente más inversión	Puede encajar si el alcance es claro
Ecommerce con ecosistema WooCommerce	Encaja	Encaja	Necesita backend o plataforma externa
Web corporativa con contenido estable	Funciona, pero puede añadir capas innecesarias	Encaja	Suele ser nuestra primera opción
Rendimiento y poco JavaScript como prioridad	Exige optimización continua	Depende de la implementación	Ventaja estructural
Cambios masivos, Git y automatización	Limitado	Posible	Encaja de forma natural
Cliente quiere mantenerla sin desarrollador	Muy accesible	Depende del editor	Necesita CMS o soporte

La respuesta correcta no es «Astro siempre». Es elegir la herramienta que deja menos deuda para el uso real que tendrá la web.

Qué hacemos antes de recomendar una migración

Migrar por entusiasmo tecnológico es una mala decisión. Antes revisamos:

1. Qué problemas existen de verdad.
2. Qué parte puede resolverse sin reconstruir.
3. Quién edita la web y con qué frecuencia.
4. Qué integraciones dependen de WordPress.
5. Qué URLs y posicionamiento deben preservarse.
6. Cuánto cuesta mantener la arquitectura actual durante los próximos años.
7. Qué mejora concreta justificaría el cambio.

Si optimizar imágenes, retirar plugins, corregir caché y ordenar el contenido resuelve el problema, no hace falta migrar.

Si el negocio depende de editar visualmente páginas con libertad, Elementor puede seguir siendo más honesto que entregar una arquitectura que obligue a llamar a un desarrollador para cada cambio.

La migración tiene sentido cuando el coste estructural ya aparece en rendimiento, mantenimiento, seguridad, edición o capacidad de evolución.

El nuevo centro de trabajo

Para webs corporativas y proyectos de contenido, nuestro centro es ahora Astro. Para plataformas con lógica compleja, Next.js. Para proyectos donde el cliente necesita un panel editorial, WordPress o un CMS desacoplado pueden seguir siendo la respuesta correcta.

La explicación de cómo funciona Astro, su arquitectura de islas y sus límites está en Por qué usamos Astro y cuándo no. Esta página tiene otra función: explicar la decisión de abandonar Elementor como opción predeterminada.

Lo que cambia en la práctica es el flujo:

• contenido en archivos o en un CMS con estructura explícita;
• cambios visibles en Git;
• preview antes de publicar;
• validaciones automáticas;
• despliegue repetible;
• menos dependencias para una web que no necesita comportarse como una aplicación.

Una migración no se demuestra con una puntuación

Una cifra de PageSpeed sirve para diagnosticar, no para contar toda la historia.

Una migración está justificada cuando mejora algo que importa y se puede verificar:

• el usuario encuentra antes el contenido;
• el equipo tarda menos en publicar;
• desaparecen licencias o dependencias innecesarias;
• el sitio requiere menos mantenimiento correctivo;
• las métricas de campo mejoran;
• formularios, ventas o contactos no se deterioran durante el cambio;
• las URLs, redirecciones y señales SEO se conservan.

Por eso no prometemos que cambiar de tecnología multiplique ventas. La arquitectura elimina fricción. El negocio, la oferta y el contenido siguen teniendo que convencer.

Elementor construyó una etapa. No tiene que construir la siguiente

Nueve años con Elementor dieron forma a una parte importante de Reveled. No hay nada que borrar de esa historia.

Pero conocer bien una herramienta también significa reconocer sus límites. La lealtad útil es con el problema del cliente, no con el software que aprendiste primero.

Si tu web funciona, el equipo la edita sin dificultad y el mantenimiento está controlado, conservarla puede ser la decisión correcta.

Si cada cambio cuesta más, la velocidad exige parches continuos o la arquitectura bloquea lo que el negocio necesita hacer, entonces toca medir, comparar y decidir.

No empezar de cero por impulso. No quedarse por costumbre.

Si estás en ese punto, podemos revisarlo en un análisis gratis. El resultado puede ser una migración, una optimización o la confirmación de que no necesitas tocar la base. Las tres respuestas son válidas si salen de los datos.