Avançar para o conteúdo
SilktideAjuda

Conteúdo legível sem JavaScript

O conteúdo principal da sua página — os parágrafos, cabeçalhos, tabelas e preços pelos quais o visitante veio — deve estar presente no HTML que o seu servidor devolve na primeira resposta. Melhorias via são bem-vindas. Conteúdo que só aparece depois que o JavaScript é executado fica invisível para a maioria dos rastreadores de IA e, portanto, para os assistentes que citam a partir deles.

Ao longo desta página, suponha que a Fernwood reconstruiu seu site de marketing como um aplicativo de página única. No navegador ele parece completo. Ver o código-fonte mostra uma <div id="root"></div> quase vazia. Esse casco vazio é o que GPTBot, ClaudeBot, PerplexityBot e rastreadores similares recebem.

Por que isso funciona

Os mecanismos de busca tradicionais em grande parte resolveram isso: o Google renderiza JavaScript antes de indexar. Os mecanismos de resposta ainda não. Os rastreadores que alimentam ChatGPT, Claude, Perplexity e sistemas semelhantes normalmente buscam a resposta HTML bruta e param — não esperam o seu framework hidratar, não executam seu bundle e não seguem rotas do lado do cliente. A própria comparação de rastreamento da Silktide (página renderizada vs. HTML bruto) se baseia exatamente nesse comportamento; veja Conteúdo sem JavaScript.

O modo de falha é silencioso e total:

  • Uma página que tem bom posicionamento no Google pode estar completamente ausente das respostas de IA, porque os assistentes nunca receberam o texto.
  • Todo o outro investimento em AEO naquela página — dados estruturados, datas legíveis por máquina, escrita com resposta primeiro — é inútil se o rastreador nunca vir o conteúdo que esses sinais descrevem.
  • Visitantes humanos com scripts com falha ou bloqueados veem o mesmo casco vazio, e a primeira pintura de conteúdo sofre mesmo quando os scripts acabam funcionando.

Este é um problema de arquitetura do site, não de edição de página. Corrigir um URL manualmente não corrige o template que produz os próximos cem.

Como verificar o que um rastreador vê

Antes de mudar qualquer coisa, confirme o problema. Três maneiras, da mais forte para a mais fraca:

  1. A verificação da Silktide. Conteúdo sem JavaScript compara o texto significativo do corpo da página renderizada com o HTML bruto capturado no momento do rastreamento. Ela sinaliza páginas em que o texto bruto é ao mesmo tempo inferior a ~10% do texto renderizado e minúsculo em termos absolutos — um verdadeiro casco vazio, não uma página que apenas se aprimora.
  2. Veja o código-fonte, não o Elements do DevTools. No navegador, "Exibir código-fonte da página" mostra o que o servidor enviou. O painel Elements mostra o DOM depois que o JavaScript foi executado. Se o texto do seu artigo aparece em Elements, mas está ausente do código-fonte, rastreadores que pulam JS não o verão.
  3. Busque sem um navegador. No terminal: curl -sL https:\/\/fernwood.example\/pricing | head. Ou use um navegador somente de texto. Se a tabela de preços estiver ausente nessa saída, ela também estará ausente para o rastreador.

Também confirme se o rastreador tem permissão para entrar — uma resposta HTML perfeita é inútil se o robots.txt bloqueia o rastreador de IA, ou se um firewall o bloqueia na prática (Rastreadores de IA bloqueados na prática).

Como corrigir

Escolha a abordagem que se encaixa no seu stack. As três produzem o mesmo resultado: a primeira resposta HTML contém o conteúdo.

1. Renderização no servidor (SSR)

O servidor renderiza cada página em HTML por requisição; o JavaScript depois hidrata para oferecer interatividade. Este é o caminho padrão para frameworks que já o suportam:

  • Next.js — use o App Router com Server Components, ou getServerSideProps / getStaticProps no Pages Router. Não envie um root somente no cliente que busca conteúdo após a montagem.
  • Nuxt — modo universal / SSR (o padrão), não ssr: false.
  • Remix, SvelteKit, Astro (modo SSR) e equivalentes — mesma ideia: a resposta do documento inclui o texto do corpo.

Regra prática: se é um fetch em useEffect / onMounted que coloca o artigo na página, mova essa busca de dados para o servidor.

2. Geração de site estático (SSG)

Pré-construa páginas como HTML simples no momento da publicação. Ideal para conteúdo que não muda por visitante — posts de blog, documentação, páginas de marketing, preços. Astro, Eleventy, Hugo, Next.js output: 'export' e Nuxt generate produzem arquivos que um rastreador consegue ler sem nenhum JavaScript.

Em geral, SSG é o ganho mais barato para sites de marketing e conteúdo: sem custo de renderização por requisição, e o HTML em disco é exatamente o que o rastreador recebe.

3. Pré-renderização como ponte

Se você ainda não pode mudar de framework, um serviço de pré-renderização ou uma etapa no build pode servir um snapshot de HTML renderizado para rastreadores (e, muitas vezes, para visitantes de primeira viagem) enquanto a SPA continua rodando para sessões interativas. Trate isso como uma ponte, não um destino: frescor dos snapshots, invalidação de cache e rotas autenticadas viram sua própria dor de manutenção. Prefira corrigir o modo de renderização quando puder.

A orientação do próprio Google sobre JavaScript SEO e o Rendering on the Web do web.dev cobrem o mesmo espectro — SSR, SSG e aprimoramento progressivo — pelo lado dos mecanismos de busca.

O que precisa estar no primeiro HTML

Não cada pixel. O conteúdo que uma citação usaria:

  • O corpo do artigo ou da página — cabeçalhos, parágrafos, listas, tabelas.
  • Preços, limites e outros fatos que você quer que os assistentes repitam.
  • Dados estruturados em um bloco <script type="application\/ld+json"> no HTML inicial — JSON-LD injetado apenas após a hidratação é tão invisível quanto a prosa.
  • URL canônica, título e meta description em <head>.

O JavaScript ainda pode comandar menus, personalização, gráficos que aprimoram uma tabela já presente e funcionalidades progressivas. A verificação da Silktide é propositalmente tolerante ao aprimoramento: páginas que servem seu conteúdo principal como HTML e sobrepõem comportamento por cima passam.

Padrões comuns de falha

  • SPAs somente no cliente — Create React App, SPAs do Vite e configurações semelhantes que enviam um casco vazio e buscam rotas no navegador. A correção é SSR/SSG, não mais código no cliente.
  • Conteúdo atrás de "Carregar mais" ou abas que nunca aparecem no HTML. Se a única maneira de chegar à seção três é um clique que faz fetch, os rastreadores nunca chegarão à seção três. Prefira URLs reais ou inclua o conteúdo na resposta inicial.
  • "Funciona no Google, então estamos bem." A renderização pelo Googlebot não substitui a legibilidade por rastreadores de IA. Passar no Google e falhar no GPTBot é uma divisão comum e invisível.
  • Bloquear o rastreador e culpar o JavaScript. Sempre verifique acesso do rastreador de IA e alcance efetivo junto com esta técnica.

Como a Silktide ajuda

Se a Silktide não consegue ler seu conteúdo sem JavaScript, tampouco conseguem os assistentes que você quer que o citem.

Relacionados

Última atualização

Esta página foi útil?

Conteúdo legível sem JavaScript | Ajuda da Silktide