Seu site pode estar invisível para a IA (e para o Google)
Aplicações modernas montam a página no navegador. O problema é que nem todo visitante roda JavaScript, e alguns dos visitantes mais importantes hoje não rodam.
Existe um tipo de problema que não aparece em nenhum teste, não gera erro no console e não incomoda ninguém da equipe: o site funciona perfeitamente no navegador. Ele só não existe para quem lê a página sem executar JavaScript.
Este artigo descreve exatamente esse problema e como resolvemos no site que você está lendo agora. Tudo o que está aqui pode ser conferido: basta pedir o código-fonte da página.
O que o servidor realmente responde
Quando você acessa um site feito em React, Vue ou Angular no padrão mais comum, o servidor não devolve a página. Ele devolve um esqueleto vazio e um arquivo JavaScript com a instrução de montar o resto.
Na prática, a primeira resposta HTTP costuma ser algo assim:
<body>
<div id="root"></div>
<script type="module" src="/assets/index.js"></script>
</body>É isso. Nenhum título, nenhum parágrafo, nenhum link. Todo o conteúdo aparece depois, quando o navegador baixa e executa o JavaScript. Para uma pessoa com um navegador moderno, a diferença é de milissegundos e ninguém percebe.
Por que isso importa
O Google consegue executar JavaScript. Ele rastreia a página, coloca numa fila de renderização, roda o código num Chromium sem interface e só então indexa o resultado. Funciona, mas tem custo: a indexação depende de uma segunda etapa que pode demorar e que consome recursos limitados.
A própria documentação do Google recomenda não depender disso. A orientação oficial é direta: renderização no servidor ou pré-renderização continua sendo uma boa ideia, porque deixa o site mais rápido para usuários e rastreadores, e porque nem todos os bots executam JavaScript.
Essa última frase é a parte que mudou de peso nos últimos anos. Quando o tráfego vinha só de buscadores, dava para apostar na renderização. Hoje, boa parte da descoberta acontece dentro de assistentes: alguém pergunta a um chatbot quem faz determinado tipo de software, e a resposta cita fontes.
Vale ser preciso aqui, porque circula muita afirmação sem base: a documentação pública de OpenAI e Anthropic descreve a finalidade de cada rastreador e como bloqueá-los, mas não afirma que eles executem JavaScript. Na ausência de garantia documentada, a decisão de engenharia responsável é não depender de renderização. Se o conteúdo está no HTML, funciona para todos. Se não está, funciona só para quem renderiza.
Como medir isso no seu site
Não precisa de ferramenta paga nem de extensão. O teste mais honesto é pedir a página sem um navegador no meio:
curl -s https://seusite.com.br/ | grep -c "<h1"O curl não executa JavaScript. Se o resultado for zero, o seu H1 não existe na resposta do servidor. Para ver o tamanho do texto real que chega:
curl -s https://seusite.com.br/ \
| sed 's/<[^>]*>/ /g' \
| tr -s ' ' | wc -cUm site institucional que devolve poucas centenas de caracteres está entregando o esqueleto, não a página.
O que fizemos aqui
Este site é uma aplicação React. A diferença é que ele não monta a página no navegador do visitante: a montagem acontece uma vez, no build, e o resultado vira HTML estático.
O processo tem duas passagens. A primeira gera o pacote que roda no navegador. A segunda executa os mesmos componentes em Node e grava o HTML de cada rota em disco. O React continua assumindo a página depois, para manter o que é interativo, mas parte de um HTML que já está completo.
O efeito na primeira resposta do servidor:
- HTML servido: de 1,8 kB para cerca de 100 kB
- Texto extraível sem executar JavaScript: de zero para mais de 8.000 caracteres
- Títulos, links internos, perguntas frequentes e dados estruturados: presentes já na primeira resposta
Nenhuma biblioteca nova entrou no projeto para isso. A ferramenta de build já tinha o necessário.
A armadilha que quase passou
Vale contar o erro, porque ele é comum e silencioso. O site tem animações de entrada: os blocos surgem conforme você rola a página. O padrão para isso é deixar o elemento invisível no CSS e revelá-lo quando ele entra na tela.
.reveal {
opacity: 0; /* invisível até o JavaScript revelar */
}Funciona bem com JavaScript. Sem JavaScript, o elemento nunca é revelado. Ou seja: passar a entregar o conteúdo no HTML não resolveria nada, porque ele chegaria invisível. Trocaríamos uma página vazia por uma página cheia de texto com opacidade zero, que é pior, porque parece resolvido.
A correção é condicionar o estado oculto à existência de JavaScript. Um script mínimo marca o documento, e o CSS só esconde quando essa marca existe:
.js .reveal {
opacity: 0; /* só esconde se houver JavaScript */
}Sem JavaScript, nada é escondido e a página é lida por inteiro. Com JavaScript, a animação acontece igual. No nosso caso eram 29 elementos, cobrindo a maior parte do conteúdo da home.
Dados estruturados que descrevem a página de verdade
A segunda metade do trabalho é dizer, de forma legível por máquina, o que a página representa. Isso é feito com JSON-LD, um bloco de dados no padrão Schema.org que descreve as entidades da página e como elas se relacionam.
O erro frequente é tratar isso como enfeite: colar um bloco pronto que descreve coisas que a página não mostra, ou inventar avaliações e preços para tentar forçar um destaque no resultado de busca. Isso é violação de diretriz, não otimização.
Aqui o JSON-LD é gerado a partir da mesma fonte que renderiza o texto visível. Se uma pergunta some da página, ela some dos dados estruturados no mesmo build. Não existe caminho para os dois divergirem, e há teste automatizado que falha se divergirem.
O que fica
Não existe truque aqui. O resumo é quase decepcionante de tão simples: coloque o conteúdo no HTML, não esconda o que é importante atrás de interação, e descreva com precisão o que a página realmente mostra.
O que muda é o alcance. Uma página que só existe depois do JavaScript depende da boa vontade de quem a lê. Uma página que já chega pronta funciona para o buscador, para o assistente de IA, para o leitor de tela e para a conexão ruim. É a mesma página, entregue de um jeito que não exige nada de quem chega.
Se você quiser saber em que situação está o seu site, o comando curl lá de cima responde em dois segundos. E se o resultado não for o esperado, é o tipo de coisa que a gente resolve.