Taxa de renderização
A taxa de renderização é a proporção do texto de uma página que já existe no HTML que o servidor envia, antes de qualquer JavaScript rodar.
Uma página a 95 % é lida por qualquer coisa capaz de baixar uma URL. Uma a 10 % é uma casca quase vazia que só vira página dentro de um navegador, e a maioria dos rastreadores não é navegador. É a verificação que mais sites reprovam.
Por que a taxa de renderização decide se a IA pode citar você?
Um modelo não navega. Alguma coisa baixa a sua URL, fica com o texto que recebe, e esse texto é tudo o que o modelo vai ter de você. Se o seu conteúdo é montado no cliente, o que sobra é uma barra de navegação e um estado de carregamento.
O Google é a exceção que causa a confusão. Ele executa JavaScript, numa fase separada depois da varredura, e a documentação dele continua recomendando renderizar no servidor porque, nas palavras deles, nem todos os bots conseguem rodar JavaScript. Os bots que trazem respostas estão em grande parte nesse segundo grupo.
Que taxa de renderização é boa?
Medida como a proporção do texto final presente no HTML bruto. As faixas são grosseiras de propósito: acima de 90 % a página está praticamente completa sem scripts, e abaixo de 60 % um rastreador vê algo diferente do que você publicou.
- Acima de 90 % — a página está praticamente completa sem JavaScript.
- Entre 60 % e 90 % — o conteúdo principal está lá e partes não. Costumam ser avaliações, preços ou abas.
- Abaixo de 60 % — um rastreador que não executa JavaScript vê uma página diferente da que você publicou.
- Perto de 0 % — uma casca vazia. O site existe só para navegadores.
Como se corrige uma taxa de renderização baixa?
Renderização no servidor ou geração estática para o conteúdo que importa, algo que qualquer framework moderno suporta e que a maioria dos projetos simplesmente nunca ligou. Nem o design muda nem a tecnologia: o que muda é quem monta o HTML.
Quando uma reconstrução não está em jogo, o remendo barato é servir uma versão em texto para quem pedir, por negociação de conteúdo ou com uma cópia em Markdown documentada. Não conserta a página, mas faz o conteúdo existir em algum lugar onde um rastreador chegue.
Em que isso se apoia?
A documentação do próprio Google é aqui a fonte mais forte, e é a que costuma ser citada ao contrário. As três se leem por inteiro e de graça.
- JavaScript SEO basics, Google Search Central
Documenta as três fases —varredura, renderização, indexação— e afirma que renderizar no servidor continua sendo boa ideia porque nem todos os bots conseguem rodar JavaScript. Essa frase é o argumento inteiro.
- GEO: Generative Engine Optimization
Mede o que torna um conteúdo visível dentro das respostas geradas. Nada disso se aplica a um conteúdo que o rastreador nunca recebeu.
- A convenção llms.txt
O remendo parcial de sempre: publicar uma versão em Markdown do que a página diz, para agentes que não vão executar um script.
Perguntas frequentes sobre Taxa de renderização
O Google não executa JavaScript de qualquer jeito?
- Executa, numa fase de renderização posterior à varredura. Isso cobre o Google e não diz nada sobre o resto, e a documentação do próprio Google continua recomendando renderizar no servidor porque nem todos os bots conseguem rodar JavaScript. Otimizar para o único rastreador que renderiza é apostar no rastreador errado.
Ter boa taxa de renderização significa abrir mão do React?
- Não. React, Vue e Svelte renderizam no servidor, e os frameworks construídos sobre eles fazem isso por padrão. Uma taxa baixa é quase sempre uma configuração que nunca foi ligada, e não um limite da tecnologia.