Site em JavaScript: por que o modelo não vê o que você vê

O teste que mostra o problema

# o HTML cru, do jeito que o leitor automático recebe
curl -sS https://seusite.com.br/ | wc -c

# procure um trecho do seu texto principal dentro dele
curl -sS https://seusite.com.br/ | grep -c "um pedaço da sua frase de abertura"

Se a contagem der zero, o texto não está no HTML: ele é montado depois, no navegador. Você vê a página perfeita porque o seu navegador executa o script. O leitor automático, na maioria dos casos, não executa.

Por que o modelo não espera o script

Executar JavaScript de um site desconhecido custa tempo e computação, para cada página, em escala de internet inteira. Quem lê para responder uma pergunta agora tem orçamento de milissegundos. A escolha racional é ler o que veio e seguir. O seu site não é rejeitado: ele é lido vazio.

O que fazer sem reescrever o site

1. Renderize no servidor as páginas que importam. Não precisa ser o site inteiro. As páginas que respondem perguntas de mercado são as que precisam existir no HTML.
2. Coloque o texto essencial no HTML inicial, mesmo que o resto seja dinâmico. Título, primeira resposta, dados de contato e marcação podem vir do servidor enquanto filtros e carrossel continuam no navegador.
3. Não esconda o conteúdo atrás de interação. Texto que só aparece depois de clicar numa aba costuma estar no HTML, e aí tudo bem. Texto que só é buscado depois do clique não existe para quem não clica.
4. Marque os dados no HTML, não por script. Marcação inserida depois pelo navegador tem o mesmo destino do texto inserido depois.

O caso da página que existe só depois do clique

O padrão mais caro é o catálogo ou a listagem que carrega por rolagem infinita. Cada item existe, mas nenhum tem endereço próprio no HTML inicial. Para o leitor automático, aquilo é uma página com um título e nada dentro. Enquanto isso, o concorrente com uma página estática por produto é citado com o nome do produto na resposta.

Perguntas frequentes

Meu site é feito num construtor visual. Tem problema?

Depende do construtor. Vários entregam HTML pronto do servidor e ficam bem; outros montam tudo no navegador. O teste de terminal responde em dez segundos, sem precisar saber a arquitetura.

Renderizar no servidor deixa o site mais lento?

Costuma deixar mais rápido para quem lê, porque o texto aparece antes de o script terminar. O que pesa é o servidor, e para páginas de conteúdo isso se resolve com cache.

Como sei se melhorou?

O mesmo comando encontrando o seu texto no HTML cru. Depois, a régua de entrada: 7 dias para o Google e 15 para as buscas com IA antes de o resultado significar alguma coisa.