O que muda quando o código do site é seu
Refizemos o leal.st de um construtor de sites para código próprio e medimos as mesmas 16 páginas antes e depois. O HTML por página caiu de 254 KB para 59 KB, as descriptions únicas foram de 1 para 16, os H1 de 0 para 16, os blocos de dados estruturados de 0 para 32, e 1.406 elementos quase invisíveis foram a zero. O construtor não era lento: pintava mais rápido e transferia menos bytes. O que ele não permitia era acrescentar o que os agentes leem, como um llms.txt, um espelho em markdown de cada artigo e dados estruturados que a gente controla. Ser dono do código é o que transformou cada um desses de impossível em uma tarde.
Publicado · 5 min de leitura
Em resumo
- O construtor pintava mais rápido e transferia menos bytes, e ainda assim tirou 70 contra 100. A diferença inteira eram 1.490ms de main thread travada.
- Zero de 15 páginas internas tinham H1 e 16 de 17 dividiam a mesma description. Isso é padrão de plataforma, não desleixo de alguém.
- Os títulos eram servidos como 1.406 elementos com opacity 0.001. Crawler que não roda JavaScript lê aquilo como letras invisíveis.
- Saia de um construtor quando o que você precisa deixar de ser expressável por ele, o que hoje quase sempre é a camada voltada a agentes. Não por velocidade.
Refizemos este site. Ele rodava num construtor de sites e agora roda em código próprio, nas mesmas 16 URLs, sem um único redirect. Antes de virar, medimos as duas versões do mesmo jeito, então isto não é opinião sobre ferramenta. É um antes e depois.
O que o construtor fazia bem
Ele entregava HTML de verdade. O Googlebot nunca precisou rodar JavaScript para ler uma página, e essa é a coisa mais importante que uma plataforma pode acertar. Também pintava rápido: first contentful paint de 0,3s contra os nossos 0,4s, e largest contentful paint de 0,3s contra os nossos 0,6s. E transferia menos bytes no total, 377 KB contra os nossos 411 KB.
Começamos por aí porque é verdade, e porque comparação desse tipo costuma omitir em silêncio as partes em que o lado antigo ganhou.
O que foi medido
As mesmas 16 URLs indexadas, buscadas com requisição HTTP simples dos dois lados, sem JavaScript, em 10 de agosto de 2026.
- HTML por página: 254,4 KB no construtor, 58,8 KB no site novo. O construtor repete o mesmo texto em três variantes de breakpoint dentro do mesmo documento, então a maior parte desse peso é a mesma frase escrita três vezes.
- Descriptions únicas: 1 em 17 páginas, contra 16 em 16. Dezesseis páginas disputavam a busca com a mesma description.
- Páginas com H1: 0 das 15 páginas internas, contra 16 de 16.
- Blocos de dados estruturados: 0, contra 32, em nove tipos.
- Imagens sem texto alternativo: 75 de 85, contra 0 de 70.
- Elementos servidos com opacity 0.001 no HTML: 1.406, contra 0.
O último número é o que mais importa
O construtor anima títulos quebrando cada um em um span por caractere, e faz isso no HTML que entrega, antes de qualquer JavaScript rodar. Cada span carrega opacity 0.001. Um navegador conserta isso em milissegundos. Um crawler que não executa JavaScript não conserta: ele lê o título como um monte de letras invisíveis.
O Google roda JavaScript, então isso raramente aparece como problema de ranking. GPTBot, ClaudeBot e PerplexityBot, na maior parte, não rodam. Em 2026 isso deixou de ser caso de borda, e é exatamente o tráfego que um estúdio quer.
A nota que parece errada até você ler direito
PageSpeed Insights, desktop, no mesmo dia: 70 para o construtor e 100 para o site novo. Só que o construtor pintou mais rápido e pesou menos. A diferença inteira está numa métrica só, o total blocking time: 1.490ms contra 0ms.
Não é peso, é trabalho. O construtor entrega HTML estático depressa e depois gasta um segundo e meio de main thread hidratando componentes e picotando texto em spans. Nada está baixando nesse tempo. A página simplesmente não está respondendo.
Por que os agentes mudaram a conta
Há dois anos este artigo terminaria nos números de SEO. Não termina, porque o jeito como as pessoas chegam mudou. Cada vez mais times trabalham por agentes que leem sites direto, resumem, comparam fornecedores e devolvem uma lista curta. Esse leitor não rola a página, não espera hidratação e não liga para o seu hover. Ele lê texto e estrutura.
Atender bem esse leitor não é uma funcionalidade. São algumas coisas pequenas que precisam ser verdade ao mesmo tempo:
- Um llms.txt, para o agente achar o mapa em vez de adivinhar. O construtor servia 0 byte ali porque o arquivo não pode existir nele. Este site serve 3.099 bytes, mais 10.543 no llms-full.txt.
- Um espelho em markdown puro de cada artigo, num endereço previsível, marcado noindex para nunca competir com a página que ele espelha.
- Dados estruturados escritos de propósito, dizendo quem você é e o que é cada página, em vez do que a plataforma emitir por conta.
- Texto completo no HTML servido, que é a mesma exigência do problema de opacity lá em cima, chegando por outro caminho.
O que ser dono do código comprou de fato
Nenhum dos quatro itens acima é difícil. Cada um é uma tarde. O que ser dono do código muda é que eles passam a ser possíveis. Em plataforma fechada você abre um pedido de funcionalidade e espera; você não acrescenta uma rota que serve markdown, nem decide o que o seu JSON-LD diz, nem move o cache de etiquetas para outro serviço porque mediu que o antigo estava no continente errado.
Esse último não é hipotético. A primeira versão deste site respondia em 142ms porque uma consulta de cache atravessava de São Paulo até a América do Norte a cada requisição. Descobrir levou uma tarde. Consertar levou uma linha. Nenhuma das duas coisas estava disponível antes.
O que a migração não consertou
O tempo até o primeiro byte continua pior que o do construtor. Ele serve HTML estático de CDN em 19ms; nós rodamos um worker e respondemos em 49ms, contra os 142ms de antes do conserto acima. É rápido o bastante para ninguém notar, e é honesto dizer que essa a gente não ganhou.
A contagem de palavras que um bot enxerga também caiu, de 3.368 para 2.230. Parece perda e não é: a diferença são as mesmas frases repetidas nas variantes de breakpoint. O vocabulário distinto subiu.
Então vale sair do seu construtor?
Não por SEO. Quase tudo da lista acima dá para consertar dentro de um construtor, e foi o que dissemos no artigo sobre o Framer ser bom para busca. Saia quando o que você precisa deixar de ser expressável pela plataforma, o que hoje quase sempre significa a camada voltada a agentes. Esse é motivo de verdade. Velocidade sozinha não é.
O que medimos
- Peso médio do HTML por página, no construtor
- 254.4 KB
- Buscamos as mesmas 16 URLs indexadas dos dois lados com requisição HTTP simples, sem JavaScript, e medimos o HTML servido sem os assets. O site novo ficou em 58,8 KB de média. A maior parte da diferença é o mesmo texto repetido em três variantes de breakpoint dentro do mesmo documento. · n=16
- Elementos servidos com opacity 0.001 no site inteiro
- 1406 elements
- Contamos os elementos com opacity 0.001 no HTML cru das 16 páginas indexadas do construtor, antes de qualquer JavaScript rodar. O site novo serve zero: o texto só é recortado por linha depois da hidratação. · n=16
- Total blocking time na home, desktop
- 1490 ms
- PageSpeed Insights, perfil desktop, os dois sites no mesmo dia. O site novo mediu 0ms. O first contentful paint favoreceu o construtor, 0,3s contra 0,4s, e o total de bytes também, 377 KB contra 411 KB.
- Bytes servidos em /llms.txt pelo construtor
- 0 bytes
- Pedimos /llms.txt e /llms-full.txt nos dois sites. O construtor não devolveu nada em nenhum dos dois, porque o arquivo não pode ser acrescentado nele. O site novo serve 3.099 e 10.543 bytes.
- Tempo até o primeiro byte, depois de mover o cache de etiquetas
- 49 ms
- Seis requisições na mesma conexão reaproveitada, então o handshake é pago uma vez e fica de fora do resto. Eram 142ms antes, porque o cache de etiquetas vivia na América do Norte e o worker roda em São Paulo. O construtor ainda ganha essa, com 19ms, servindo HTML estático de CDN.
Perguntas
- Construtor de site é ruim para SEO?
- Não. Medidos lado a lado, o construtor servia HTML de verdade, pintava mais rápido e transferia menos bytes. Os pontos fracos eram padrões que dá para mudar dentro dele: uma description para todas as páginas, nenhum H1 nas internas e nenhum dado estruturado.
- O que é llms.txt e isso importa mesmo?
- É um mapa do site em texto puro, escrito para modelos e não para navegadores. É uma proposta, não um padrão, e nenhum motor promete lê-lo. Custa uma hora para gerar a partir de conteúdo que você já tem, e é uma das poucas coisas que uma plataforma fechada não deixa você acrescentar.
- Preciso sair do meu construtor para consertar algo disso?
- Para a maior parte da lista, não. Descriptions, títulos, texto alternativo e dados estruturados são editáveis dentro de um construtor. A camada voltada a agentes é onde trava: um llms.txt, um espelho em markdown numa rota sua, e JSON-LD escrito por você.
- A migração deixou tudo mais rápido?
- Não. O tempo até o primeiro byte continua em 49ms contra os 19ms do construtor, e o total de bytes transferidos subiu. O que mudou é que a página deixa de travar: 0ms de main thread bloqueada contra 1.490ms.
Fontes
- PageSpeed Insights · Google
- The /llms.txt file · llmstxt.org
- JavaScript SEO basics · Google Search Central
Os projetos por trás disso
- Glass · Moldado pela natureza, lapidado no Brasil.
- Ligga Telecom – ESG Annual Report · Traduzir dados técnicos num sistema visual refinado.
