Uma landing tem um trabalho: converter. Se o tráfego vem de campanhas pagas, o motor de busca é indiferente e um builder no-code é uma decisão perfeitamente razoável: lança numa tarde, itera sem depender de ninguém e mede.
O problema aparece quando alguém decide que essas mesmas landings deveriam trazer tráfego orgânico. Aí começa a frustração: otimizam-se os textos, metem-se as palavras-chave, e a página continua sem aparecer.
Não é um problema de conteúdo. É de como é servida.
O que o Google tem de fazer para ler a sua página
Quando o rastreador chega a um URL, há dois cenários muito diferentes.
Página renderizada no servidor. A resposta HTTP já traz o HTML com o conteúdo lá dentro. O Google lê-o na primeira passagem e passa a indexar. Fim.
Página renderizada no cliente. A resposta traz um HTML quase vazio e um bundle de JavaScript. Para ver o conteúdo, o Google tem de executar esse JavaScript, o que acontece numa segunda fase de renderização que fica em fila e pode demorar. O Google fá-lo — isto não é 2015 — mas é um passo a mais, com a sua fila e o seu orçamento de recursos.
Para um site com autoridade estabelecida essa diferença é suportável. Para uma landing nova que compete por uma consulta com intenção comercial, é uma desvantagem que não precisa de oferecer à concorrência.
Os quatro pontos onde se perde
O JavaScript que não consegue retirar
Um builder tem de ser genérico: suportar qualquer bloco que qualquer cliente possa arrastar. Isso significa carregar o runtime do editor, o sistema de animações, o gestor de formulários e os utilitários de todos os blocos, use dois ou vinte.
O resultado são centenas de kilobytes de JavaScript que a sua landing concreta não precisa, e que não tem forma de eliminar porque não controla o build.
Core Web Vitals
Esse peso traduz-se diretamente nas métricas que o Google usa como sinal:
| Métrica | O que a degrada num builder |
|---|---|
| LCP | O elemento principal espera que o JS o pinte |
| INP | A thread principal está ocupada a executar o runtime |
| CLS | Blocos que mudam de posição ao hidratar |
Os Core Web Vitals não são o fator de posicionamento mais forte — o conteúdo e as ligações pesam mais — mas são um desempate real. E numa landing têm um efeito muito mais imediato: cada segundo de carregamento come conversão, tenha o Google alguma coisa a ver ou não.
O URL que não controla
É aqui que mais builders ficam curtos:
- Subdomínios do fornecedor em vez do seu domínio, pelo que a autoridade que ganhar não se acumula no seu site
- Rotas impostas do tipo
/p/12345em vez de/agencia-nextjs-lisboa - Barras finais inconsistentes que geram duplicados
- Canonical que não consegue ajustar quando tem variantes da mesma landing para campanhas diferentes
Este último ponto é o que faz mais estrago em silêncio: três variantes de uma landing sem canonical bem posto competem entre si e nenhuma ganha.
Dados estruturados e hreflang
Se vende em vários países precisa de hreflang correto e recíproco. Se quer aparecer com resultados enriquecidos precisa de JSON-LD específico do seu caso. A maioria dos builders oferece ou um campo genérico ou nada, e metê-lo à mão por injeção de código costuma partir-se na atualização seguinte da plataforma.
O que resolvem bem
Seria desonesto pintar tudo de negro. Um builder resolve três coisas a sério:
- Velocidade de lançamento. Da ideia à landing publicada em horas, sem fila de desenvolvimento.
- Autonomia de marketing. Quem tem a hipótese pode testá-la sem abrir um ticket.
- Iteração barata. Mudar um título não custa um deploy.
Esse valor é real e não é qualquer alternativa que o dá. A pergunta certa não é “builder sim ou não”, é que trabalho tem esta landing de fazer.
O critério, numa tabela
| Se a landing… | Então |
|---|---|
| Recebe tráfego de campanhas pagas | Um builder está bem. O SEO não é a sua função |
| É um teste que pode morrer em três semanas | Builder. Não invista em algo que vai deitar fora |
| Tem de rankear por uma consulta comercial | Renderização no servidor, URL próprio, controlo técnico |
| É multi-idioma e multi-país | Renderização no servidor: precisa de hreflang a sério |
| É a porta de entrada principal do negócio | Renderização no servidor, sem discussão |
A maioria das empresas precisa das duas coisas ao mesmo tempo, e é aí que o falso dilema faz mal: obriga a escolher entre lançar depressa e rankear, quando o problema real é as duas capacidades viverem em ferramentas incompatíveis.
A nossa abordagem
É exatamente a lacuna para a qual construímos o Landing Builder: editor visual por blocos para que o marketing lance sem depender do desenvolvimento, mas com SEO real por baixo — renderização no servidor, slugs limpos no seu próprio domínio, meta tags e dados estruturados por página — além de formulários com tracking e analítica de campanhas.
Se está também a decidir a stack para o site, temos a comparação entre Next.js e Astro para 2026.