Una landing tiene un trabajo: convertir. Si el tráfico viene de campañas de pago, el buscador da igual y un builder no-code es una decisión perfectamente razonable: lanzas en una tarde, iteras sin depender de nadie y mides.
El problema aparece cuando alguien decide que esas mismas landings deberían traer tráfico orgánico. Ahí empieza la frustración: se optimizan los textos, se meten las palabras clave, y la página sigue sin aparecer.
No es un problema de contenido. Es de cómo se sirve.
Lo que Google tiene que hacer para leer tu página
Cuando el rastreador llega a una URL, hay dos escenarios muy distintos.
Página renderizada en servidor. La respuesta HTTP ya trae el HTML con el contenido dentro. Google lo lee en la primera pasada y lo pasa a indexar. Fin.
Página renderizada en cliente. La respuesta trae un HTML casi vacío y un bundle de JavaScript. Para ver el contenido, Google tiene que ejecutar ese JavaScript, lo que ocurre en una segunda fase de renderizado que se encola y puede tardar. Google lo hace —esto no es 2015— pero es un paso más, con su cola y su presupuesto de recursos.
Para un sitio con autoridad establecida esa diferencia es asumible. Para una landing nueva que compite por una consulta con intención comercial, es una desventaja que no necesitas regalarle a la competencia.
Los cuatro puntos donde se pierde
El JavaScript que no puedes quitar
Un builder tiene que ser genérico: soportar cualquier bloque que cualquier cliente pueda arrastrar. Eso significa cargar el runtime del editor, el sistema de animaciones, el gestor de formularios y las utilidades de todos los bloques, uses dos o veinte.
El resultado son cientos de kilobytes de JavaScript que tu landing concreta no necesita, y que no tienes forma de eliminar porque no controlas el build.
Core Web Vitals
Ese peso se traduce directamente en las métricas que Google usa como señal:
| Métrica | Qué la degrada en un builder |
|---|---|
| LCP | El elemento principal espera a que el JS lo pinte |
| INP | El hilo principal está ocupado ejecutando el runtime |
| CLS | Bloques que se reposicionan al hidratarse |
Los Core Web Vitals no son el factor de posicionamiento más potente —el contenido y los enlaces pesan más— pero sí son un desempate real. Y en una landing tienen un efecto mucho más inmediato: cada segundo de carga se come conversión, tenga Google algo que ver o no.
La URL que no controlas
Aquí es donde más builders se quedan cortos:
- Subdominios del proveedor en lugar de tu dominio, con lo que la autoridad que ganes no se acumula en tu sitio
- Rutas impuestas del tipo
/p/12345en lugar de/agencia-nextjs-madrid - Barras finales inconsistentes que generan duplicados
- Canonical que no puedes ajustar cuando tienes variantes de la misma landing para distintas campañas
Ese último punto es el que más silenciosamente hace daño: tres variantes de una landing sin canonical bien puesto compiten entre ellas y ninguna gana.
Datos estructurados y hreflang
Si vendes en varios países necesitas hreflang correcto y recíproco. Si quieres aparecer con resultados enriquecidos necesitas JSON-LD específico de tu caso. La mayoría de builders ofrecen o un campo genérico o directamente nada, y meterlo a mano por inyección de código suele romperse en la siguiente actualización de la plataforma.
Lo que sí resuelven bien
Sería deshonesto pintarlo todo negro. Un builder resuelve tres cosas de verdad:
- Velocidad de lanzamiento. De la idea a la landing publicada en horas, sin cola de desarrollo.
- Autonomía de marketing. Quien tiene la hipótesis puede probarla sin abrir un ticket.
- Iteración barata. Cambiar un titular no cuesta un despliegue.
Ese valor es real y no lo da cualquier alternativa. La pregunta correcta no es “builder sí o no”, es qué trabajo tiene que hacer esta landing.
El criterio, en una tabla
| Si la landing… | Entonces |
|---|---|
| Recibe tráfico de campañas de pago | Un builder está bien. El SEO no es su función |
| Es una prueba que puede morir en tres semanas | Builder. No inviertas en algo que vas a tirar |
| Tiene que rankear por una consulta comercial | Renderizado en servidor, URL propia, control técnico |
| Es multi-idioma y multi-país | Renderizado en servidor: necesitas hreflang de verdad |
| Es la puerta de entrada principal de tu negocio | Renderizado en servidor, sin discusión |
La mayoría de las empresas necesitan las dos cosas a la vez, y ahí es donde el falso dilema hace daño: te obliga a elegir entre lanzar rápido y rankear, cuando el problema real es que las dos capacidades vivan en herramientas incompatibles.
Nuestro enfoque
Es exactamente el hueco para el que construimos Landing Builder: editor visual por bloques para que marketing lance sin depender de desarrollo, pero con SEO real por debajo —renderizado en servidor, slugs limpios en tu propio dominio, meta tags y datos estructurados por página— además de formularios con tracking y analítica de campañas.
Si estás decidiendo el stack para la web además de para las landings, tenemos la comparativa entre Next.js y Astro para 2026, y si buscas equipo, escribimos sobre cómo elegir agencia Next.js en España.