¿Es conveniente utilizar un Sitebuilder tipo Weebly, Wix o Duda, un constructor tipo Divi o Elementor, o un AI builder como Lovable?
Los constructores son un tipo de tecnología que se engloban dentro de los Sitebuilders. Y recientemente han aparecido los AI builders, que prometen crear aplicaciones web completas mediante prompts.
Vamos a diferenciar estas tres categorías y analizar sus implicaciones para el SEO y la escalabilidad de tu proyecto.
Los Sitebuilders son una tecnología que te permite crear una web "drag and drop".
Esto permite hacer una web a cualquiera sin conocimientos de desarrollo. Pero todo tiene sus desventajas.
Las webs construidas en Sitebuilders son perfectas para cuando alguien necesita una web donde mostrar información de forma rápida sin necesidad de posicionarla y sin intención de invertir. Como en el caso de poner un menú de un restaurante.
Si bien hacen ciertos cambios para mejorar el SEO (por ejemplo, WIX antes estaba hecha en flash y era ilegible para los motores de búsqueda, ahora utiliza HTML5 y permite metaetiquetas), este tipo de webs permiten poca personalización y casi ninguna implementación técnica.
Además, aunque se contrate el dominio, la web y su base de datos no os pertenece.
Pero básicamente este tipo de tecnología intenta abarcar todas las posibilidades en unos pocos clics. Por lo que la performance suele ser escasa afectando directamente a la visibilidad que se puede conseguir.
Puede que algún día se pueda hacer SEO decente con este tipo de webs, pero a día de hoy les queda mucho.
El problema más grave de los Sitebuilders es su nula escalabilidad. Cuando tu proyecto crece y necesitas funcionalidades avanzadas, personalizaciones específicas o simplemente mejor rendimiento, te encuentras con un muro. No puedes acceder al código, no puedes optimizar a bajo nivel, no puedes implementar soluciones técnicas que otros CMS sí permiten.
Y aquí viene el verdadero drama: las migraciones.
Si no tienes dominio propio (es decir, tu web está en algo tipo tuempresa.wixsite.com), migrar a una plataforma profesional se convierte en un proceso manual, URL por URL. En el mejor de los casos, si el Sitebuilder permite insertar código HTML en el head, puedes implementar redirecciones mediante meta refresh para cada página. Es tedioso, pero al menos conservas algo del SEO acumulado.
Si ni siquiera permiten eso, pierdes todo el posicionamiento conseguido. Todo el trabajo de linkbuilding, todo el histórico, todo. Empiezas de cero.
Lo mejor cuando alguien tiene un proyecto de estas características y pretende invertir en SEO, es migrar a una plataforma cuanto antes. Aquí te enseño cómo hacer redirecciones desde WIX o cualquier sitebuilder (si es que tu caso lo permite).
En el caso de constructores como Elementor, Blocksy, Pagefly o DIVI simplemente se integran con el CMS correspondiente.
A diferencia de los Sitebuilders, el control de tu web y las limitaciones te las pondrá el CMS. Y aunque nunca será tan eficiente como hacer una web con conocimiento de código, sí se podrá hacer un SEO competitivo con estas herramientas.
También está la opción de utilizar una de estas herramientas en un Headless CMS y permitirle a los editores de la web utilizar una herramienta de bloques con estas características, pero sin cargar código basura en el front.
Los constructores visuales están pensados para ser capaces de generar múltiples funciones para funcionar y crear cualquier tipo de web sin necesidad de saber código.
Esto es genial pero acarrea una deuda tecnológica que afecta directamente al rendimiento y dificulta la sostenibilidad.
Si cargas todo un código prehecho (que es lo que hace un builder para sus funciones) para la posibilidad de cualquier tipo de web, es menos eficiente que si cargas un código para la web que quieres ejecutar finalmente. Pero ¿por qué? ¿Es así de simple? Lo desarrollo más:
A nivel del Back-end produce una cantidad ingente de llamadas y cambios con el servidor (ya tienes que desembolsar un extra para lo mismo).
A nivel de Front-End los builders competentes (que no todos lo son) solo deberían cargarte el código ya hecho. No obstante por el mismo motivo que he comentado, ponen una cantidad de código extra (código basura) con una cantidad tal de llamadas a clases que ya de por sí acaban petando el DOM. Por si fuera poco los archivos de CSS son gigantescos aunque solo utilicemos una parte, por lo que por mucho que lo intentes optimizar estás llamando a archivos gigantescos de CSS aunque solo uses una fracción (una solución a este problema sería que utilizasen por ejemplo Tailwind con su purge.css). Pero en el mejor de los casos algunos cargan librerías como Bootstrap y bueno... Resumiendo: cargan más CSS del que usan.
Para hacer ciertos efectos como sliders, utilizan librerías no muy eficientes como jQuery (aunque con gran historia pese a sus haters). jQuery se creó en su día para poder hacer Javascript que se leyese igual en todos los exploradores (en otro momento hago un post al respecto), a día de hoy todos siguen el mismo estándar y jQuery no es especialmente eficiente.
Si se utiliza un builder para la web, evidentemente todo el resto de la web va a ser plugin sobre plugin para cualquier funcionalidad. Cargando más y más CSS y JS sin miramientos. Hacer un mantenimiento real de este tipo de web es un quebradero de cabeza.
La optimización mobile de los builders tampoco es de lo más eficiente. Pero para desarrollar este tema tendría que hacer un post particular a cada builder y bueno, para extenderme en todo este tipo de cuestiones ya creé un master.
Por último, aunque estas herramientas sean "sencillas y medianamente intuitivas" (que ya digo que una vez aprendes código se vuelven una pesadilla en comparación) no cubren todas las necesidades, por lo que a meter más plugins que te cargan más JS y más CSS por otros lados.
Resultado: Webs con posibilidad de petar en cualquier momento, con bajo rendimiento y que hacen cantidad ingente de requests al servidor.
El problema es cuando webs de este tipo se venden como profesionales y a precio de oro, cuando el motivo es que no saben hacer otro tipo de webs.
La última moda son los AI builders como Lovable, Bolt.new o Cursor. La promesa es seductora: describes tu aplicación en lenguaje natural y la IA te genera una web funcional en minutos. "20 veces más rápido que programar", dicen.
Y es cierto que para prototipos rápidos o MVPs pueden tener su utilidad. Pero aquí viene la trampa.
Desarrolladores experimentados están advirtiendo que nunca han visto la deuda técnica acumularse tan rápido como con el código generado por IA. El problema es que la IA genera código que funciona... hasta que deja de funcionar. Y cuando algo falla, te encuentras con un código que ni tú ni la propia IA entienden del todo.
Cada "arreglo rápido" que le pides a la IA es como poner un parche sobre otro parche. Al final pasas más tiempo arreglando agujeros que avanzando con el proyecto.
Lovable funciona con un sistema de créditos donde cada acción (generar código, arreglar bugs, hacer cambios) consume créditos. El problema es que acabas pagando por los propios errores de la IA. Usuarios reportan quemar créditos intentando arreglar el mismo problema que la IA insistía en que ya había solucionado.
Lo que empieza siendo "barato y rápido" puede convertirse en un pozo sin fondo cuando el proyecto crece.
Una queja recurrente: Lovable genera interfaces visualmente atractivas, pero en el momento que integras cualquier funcionalidad real (autenticación, bases de datos, lógica de negocio), las cosas empiezan a romperse. Y arreglar algo puede romper otra cosa que funcionaba perfectamente.
Desde el punto de vista del SEO técnico, los AI builders presentan los mismos problemas que los constructores visuales multiplicados:
Si con un constructor visual ya era difícil hacer SEO técnico avanzado, con un AI builder donde el código cambia cada vez que le pides algo, es prácticamente imposible mantener una estrategia coherente.
Los AI builders pueden valer para:
Pero si tu proyecto tiene vocación de crecer, necesita posicionarse en buscadores, o requiere cualquier tipo de funcionalidad robusta, vas a acabar pagando muy cara la velocidad inicial. Lo que te ahorraste en desarrollo inicial lo multiplicarás en arreglos, migraciones y deuda técnica.
Banner promocionado:
En definitiva, si se puede optar a una solución más profesional, no. Evidentemente si no hay más remedio, sí que se puede obtener buenos resultados con Elementor, pero se va a heredar una deuda técnica que no permitirá escalar más allá de cierto punto.
Con Lovable y los AI builders la situación es aún más delicada: la deuda técnica se acumula más rápido, el código es menos predecible, y el modelo de negocio puede hacer que un proyecto "barato" acabe siendo muy caro.
La regla general: cuanto más control tengas sobre el código, mejor podrás optimizar para SEO. Y estas herramientas, por diseño, te quitan ese control.
Aquí hice un directo con Roberto Martinez, donde tratábamos este tema entre otros:
Te falta mi máster. Accede a una formación avanzada que te permitirá aplicar e implementar SEO en cualquier tipo de WEB
¡Accede al Máster de SEO Técnico!Si te ha gustado esta publicación, siempre me lo puedes agradecer dándome like en esta publicación de LinkedIn sobre este mismo artículo.
