Page builder o código a medida: cuál conviene y cuándo

Es una de las primeras preguntas que aparece cuando alguien va a invertir en su sitio: ¿lo hacemos con un page builder o lo construimos con código a medida? Casi siempre llega con una respuesta ya cargada. El que vende constructores dice que el código es caro y lento de entregar. El que programa dice que los constructores son pesados y que arruinan el SEO.

Las dos posturas tienen algo de razón y las dos se quedan cortas. Después de revisar datos públicos de más de cuatro millones de sitios, la conclusión honesta es otra: la herramienta importa menos de lo que se cree, y lo que sí decide el resultado es quién la usa y para qué. En este artículo dejamos los datos sobre la mesa, explicamos por qué los constructores tienden a pesar más, y damos el criterio concreto que usamos para recomendar uno u otro camino.

Qué significa realmente cada opción

Antes de comparar conviene aclarar de qué estamos hablando, porque los términos se usan con mucha soltura.

Un constructor visual (page builder) es una capa que se instala sobre un gestor de contenidos y permite armar páginas arrastrando bloques. Dentro de WordPress los más usados son Elementor, Divi y WPBakery. También entran aquí las plataformas cerradas como Wix o Squarespace, donde el constructor y el alojamiento vienen en el mismo paquete.

Código a medida, o lo que muchos llaman «from scratch», casi nunca significa escribir un gestor de contenidos desde cero. En la práctica significa construir una plantilla propia —el HTML, el CSS y el JavaScript que el visitante recibe— sobre un gestor que ya existe, normalmente WordPress. El cliente sigue entrando a un panel a editar textos; lo que cambia es que nadie instaló una capa intermedia que genere el código por él.

Los datos: qué tecnología aprueba las métricas de Google

El HTTP Archive publica cada mes el porcentaje de sitios reales que aprueban las Core Web Vitals, las métricas de experiencia que Google mide con datos de usuarios de Chrome. Es la muestra más grande que existe: no son pruebas de laboratorio, son millones de sitios en producción.

Estos son los datos de junio de 2026 en escritorio:

Hay dos lecturas y las dos importan.

La primera confirma la sospecha: dentro de WordPress, los sitios con constructor aprueban las métricas con mucha menos frecuencia. Elementor está casi catorce puntos por debajo del editor de bloques nativo, y Divi está veinticinco puntos por debajo. Son muestras enormes —más de un millón cuatrocientos mil sitios solo con Elementor—, así que no es ruido estadístico.

La segunda incomoda a quienes defendemos el código: Wix aprueba en el 87.1 % de los casos y Webflow en el 81 %, muy por encima del 53.3 % de WordPress. Plataformas cerradas, de las que un desarrollador no toca el código, rinden mejor que el ecosistema abierto donde sí se puede optimizar todo.

Si quieres entender qué mide cada una de esas métricas y cómo revisarlas en tu propio sitio, lo explicamos paso a paso en velocidad de carga y Core Web Vitals.

Por qué los constructores tienden a pesar más

La diferencia no es mala fe de los fabricantes. Es una consecuencia directa de lo que un constructor promete.

Para que puedas mover cualquier elemento a cualquier lado sin escribir una línea, el constructor tiene que anticipar todos los escenarios posibles. Eso se traduce en tres costos que el visitante paga:

• Hojas de estilo genéricas. El sitio carga el CSS de decenas de componentes aunque la página solo use tres.
• Marcado anidado. Una sección simple puede terminar envuelta en cinco o seis contenedores que existen solo para que el editor pueda arrastrarla.
• JavaScript que espera al usuario. Carruseles, acordeones y animaciones se cargan por si acaso, no porque esa página los necesite.

Un buen equipo puede mitigar mucho de esto: desactivar módulos, cargar CSS por página, limpiar plugins. Lo hemos hecho y funciona. Pero es trabajo de optimización sobre una base que no se puede cambiar, y hay un techo.

Lo que el constructor te da y el código no

Sería deshonesto quedarnos solo con el rendimiento. Los constructores ganaron su lugar por razones reales.

• Velocidad de salida. Un sitio informativo puede estar en línea en días, no en semanas.
• Autonomía total. Puedes cambiar una sección completa un domingo a las diez de la noche sin llamar a nadie.
• Costo inicial menor. Menos horas de desarrollo se traducen en menos presupuesto por adelantado.
• Ecosistema enorme. Para casi cualquier necesidad ya existe un complemento hecho.
• Reversibilidad barata. Si el negocio aún está cambiando de forma, rehacer el sitio cuesta poco.

Ese último punto es más importante de lo que parece. Cuando una empresa todavía no sabe exactamente qué vende ni a quién, invertir en una estructura cuidadosamente diseñada es invertir en una hipótesis que probablemente cambie.

Lo que el código te da y el constructor no

Del otro lado, las ventajas del desarrollo a medida son menos visibles al principio y se vuelven decisivas con el tiempo.

• Control del marcado. Tú decides el HTML semántico, los encabezados y los datos estructurados que Google lee. Eso también pesa en cómo los buscadores con inteligencia artificial citan tu contenido, un tema que tratamos en AI Overviews y el tráfico que ya no llega.
• Techo de rendimiento más alto. No cargas lo que no usas porque no hay nada que desactivar.
• Integraciones reales. Conectar un CRM, un inventario o un sistema de reservas sin depender de que exista un complemento que lo haga.
• Sin dependencia de un formato propietario. El contenido vive como contenido, no dentro de códigos que solo ese constructor entiende.
• Diseño sin plantilla. El sitio no se parece al de los otros cuarenta negocios que compraron la misma plantilla.

Cuando el sitio es el canal principal de venta y no un folleto digital, esas diferencias dejan de ser teóricas. Es el terreno donde trabajamos en desarrollo web a medida.

El costo que casi nadie mira: el año dos y el año tres

La comparación de precios suele hacerse el primer día, y ahí el constructor gana casi siempre. El problema es que un sitio no vive un día.

Con un constructor, el contenido queda guardado en el formato interno de esa herramienta. Si dentro de tres años quieres migrar —porque el constructor se quedó corto, porque cambió su licencia, porque el sitio creció—, no estás mudando textos, estás desmontando estructura. Ese trabajo se paga, y se paga completo.

Se suman las licencias anuales, los complementos de pago que el constructor necesita para funciones que deberían ser básicas, y el mantenimiento de un conjunto de piezas que se actualizan por separado y a veces chocan entre sí.

Cómo decidir: el criterio que usamos

En la práctica no evaluamos la herramienta, evaluamos cinco cosas del negocio.

1. Qué papel juega el sitio. Si es una presencia necesaria pero no el canal de venta, un constructor bien configurado es suficiente. Si de ahí salen los clientes, la inversión en la base se justifica sola.

2. Cuánta competencia hay en tu búsqueda. En mercados donde el primer resultado se decide por décimas, el rendimiento y la estructura dejan de ser detalle. En búsquedas locales con poca competencia, pesan mucho menos que tu perfil de Google, como explicamos en SEO local.

3. Quién va a editar. Si el dueño del negocio va a publicar cada semana y no quiere depender de nadie, hay que diseñar para eso, se use lo que se use.

4. Cuánto va a crecer. Diez páginas y veinte páginas se manejan igual. Doscientas páginas, tres idiomas o un catálogo con filtros son otro problema.

5. Cuánto tiempo va a vivir. Es la pregunta que más cambia el resultado del cálculo y la que menos se hace.

La respuesta que damos más seguido: el camino intermedio

Y antes de decidir cómo se construye, conviene resolver cómo vas a cobrar: en Centroamérica eso condiciona la plataforma más de lo que parece. Lo desglosamos en pasarelas de pago en Centroamérica.

En la mayoría de los proyectos reales no recomendamos ninguno de los dos extremos.

Una plantilla propia y ligera para la estructura del sitio —portada, servicios, artículos, formularios—, combinada con el editor de bloques nativo de WordPress para que el cliente edite sin tocar código. Es el 57.1 % de la tabla, no el 43.4 %, y conserva casi toda la autonomía del constructor.

Y cuando hace falta una campaña puntual con una landing que cambia cada mes, un constructor liviano en esa página específica no arruina nada, porque el resto del sitio no lo carga.

Para tiendas en línea la decisión se mueve un paso antes: primero se elige la plataforma y después el método de construcción. Ese análisis está en Shopify o WooCommerce.

Errores que vemos en los dos caminos

• Elegir el constructor por el video de demostración. Lo que se ve en treinta segundos no es lo que vas a mantener durante tres años.
• Instalar tres constructores «por si acaso». Cada uno carga su propio CSS y su propio JavaScript en todas las páginas.
• Pagar código a medida para un folleto de cinco páginas. Es dinero que rendiría más en contenido o en posicionamiento.
• Entregar un sitio a medida sin capacitar a nadie. Un sitio que el cliente no puede editar se congela en la versión del día uno.
• Medir el éxito por el diseño y no por los contactos. El sitio más bonito del rubro puede no generar una sola llamada.

Entonces, ¿cuál elijo?

Si tuviéramos que resumirlo en una sola frase: elige constructor cuando necesitas salir rápido y barato de algo que probablemente cambie; elige código cuando el sitio tiene que producir y vas a vivir con él varios años.

Y desconfía de cualquiera que te dé la respuesta antes de preguntarte qué vendes, a quién y contra quién compites. Esa conversación es el trabajo; la herramienta es la consecuencia.