¿Es conveniente utilizar un sitebuilder tipo Weebly, Wix o Duda?

¿Es conveniente utilizar un Sitebuilder tipo Weebly, Wix o Duda o un constructor tipo Divi o Elementor?

Los constructores son un tipo de tecnología que se engloban dentro de los Sitebuilders.

Vamos a diferenciar un Sitebuilder de un constructor visual.

Sitebuilders:

Los Sitebuilders son una tecnología que te permite crear una web "drag and drop".

Esto pues le permite hacer una web a cualquiera sin conocimientos de desarrollo. Pero claro 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.

¿Qué ocurre en cuanto al SEO con aquellas webs que te permiten crear webs?

Si bien hacen ciertos cambios para mejorar el SEO, por ejemplos WIX antes estaba hecha en flash y era ilegible para los motores de búsqueda y 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.

Lo mejor cuando alguien tiene un proyecto de estas características y pretende invertir en SEO, es migrar a una plataforma. Aquí te enseño como hacer redirecciones desde WIX o cualquier sitebuilder.

Constructores visuales

En el caso de constructores como Elementor, Blocksy, Pagefly o DIVI simplemente se integran con el CMS correspondiente y listo.

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. Si 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 dificultan 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? Bueno 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 si 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 parte (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 que 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 request 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.

Entonces. ¿Es conveniente elementor & co para SEO?

En definitiva, si se puede optar a una solución más profesional, no. Evidentemente si no hay más remedio, si que se puede obtener buenos resultados con Elementor, pero se va a heredar una deuda técnica que no permitirá escalar hasta más de cierto punto.

Aquí hice un directo con Roberto Martinez, donde tratábamos este tema entre otros: