Pages e domínios

Há uma distância grande entre "eu fiz uma landing page" e "eu tenho um site no meu domínio". Boa parte das ferramentas de landing page te deixa parado no primeiro: você constrói a página, mas ela mora numa URL feia do fornecedor, e juntar várias páginas num site coerente sob www.suaempresa.com é outro problema, frequentemente outro produto.

O produto Pages da LaunchWithAgency foi modelado para atravessar essa distância inteira. Ele tem duas camadas — a página, construída por blocos, e o site, um domínio customizado que reúne páginas e um blog. Este artigo percorre as duas e mostra como elas se encaixam.

A camada 1: a página como blocos

Uma landing page (landing_pages) na LaunchWithAgency não é um documento de HTML que você edita à mão. Ela é uma composição de blocos.

A fonte da verdade do conteúdo é o campo blocksJson: uma estrutura com uma versão e um array de blocos, cada bloco com um id, um kind e suas props. Os tipos de bloco são os componentes do próprio design system da suíte — hero, bento, CTA, comparison. Construir uma página é compor esses blocos e preencher suas propriedades; a estrutura inteira é serializada como JSON na tabela.

Ao salvar, o sistema renderiza essa estrutura para HTML e guarda o resultado em bodyHtml. Isso é uma escolha de desempenho deliberada: a rota pública não recompõe a página a cada visita — ela serve o HTML já renderizado, direto. A página tem blocksJson como verdade editável e bodyHtml como cache servível. Há ainda os campos de SEO próprios (seoTitle, seoDescription, ogImage) e um theme. E, como tudo na suíte, ela carrega locale — uma landing existe por idioma, com unicidade em (ownerId, slug, locale).

> Você não edita o HTML da página. Você compõe blocos, e o HTML é a consequência. A verdade do conteúdo é uma estrutura, não uma string.

A camada 2: o site como domínio

Uma página sozinha já é servível — sob dominio.com/<seu-handle>/lp/<slug>. Mas o salto de "página" para "site" acontece quando entra a segunda camada: o domínio customizado.

No schema, um site é uma linha em domain_routes. E o comentário do próprio schema é claro sobre o que essa linha é: "uma linha de domain_routes É um site". Ela tem um domain — um hostname como www.cliente.com, único globalmente, porque um hostname só pode apontar para um site —, e um blogId opcional, referenciando o blog que será servido sob /blog daquele site.

Como as páginas se ligam a esse site? Do lado delas. Uma landing page tem dois campos — domainRouteId e sitePath — pelos quais ela se anexa a um site. O sitePath é onde ela aparece naquele domínio. Uma página anexada com sitePath igual a / é a home do site. Uma anexada com /precos é servida em www.cliente.com/precos. O blog referenciado pelo blogId aparece em www.cliente.com/blog.

O resultado: um domínio customizado, várias landing pages em caminhos limpos, e um blog — tudo compondo um site completo, e tudo ainda dentro da mesma suíte, do mesmo banco, do mesmo login.

Como o domínio aponta para a suíte: o CNAME

Para www.cliente.com servir o seu site, o DNS desse domínio precisa apontar para a plataforma. Isso é feito com um registro CNAME: você configura, no provedor de DNS do seu domínio, que www.cliente.com é um apelido para o host da plataforma.

O schema trata isso com cuidado e honestidade. A linha de domain_routes tem um campo verifiedAt, e o comentário é explícito: ele é preenchido apenas quando uma checagem de DNS confirma que o CNAME de fato resolve para o host da plataforma. E — a parte importante — "um site não verificado não serve tráfego". Você não pode roubar um domínio que não controla: enquanto o CNAME não estiver provadamente apontando para a plataforma, o site fica inerte. A verificação não é burocracia; é a garantia de que só quem controla o DNS de um domínio pode publicar sob ele.

Há ainda um detalhe de robustez no schema: se o blog referenciado por um site for apagado, o blogId vira nulo, mas o site sobrevive. O comentário explica: assim o dono pode re-apontar o site para outro blog. A infraestrutura do domínio é tratada como mais durável que o conteúdo que ela serve.

Por que isso pertence à suíte de banco único

Seria possível imaginar Pages como um produto isolado. Mas repare em quanto da sua utilidade vem de ele não ser isolado.

A landing page captura um lead — e esse lead é uma linha em newsletter_subscribers, a mesma tabela que o produto News lê, sem export. O site customizado serve, sob /blog, um blog que é o mesmo blog do produto Blogs, bilíngue, com SEO. Uma automação do Flows pode reagir a uma inscrição feita numa landing sem nenhuma integração, porque a inscrição é um evento no mesmo banco.

Pages, sozinho, seria um bom builder de landing pages. Dentro da suíte de banco único, ele é a camada de publicação de uma operação inteira: o lugar onde o conteúdo, a captura e o domínio se encontram — e onde "eu fiz uma página" finalmente vira "eu tenho um site".