JavaScript SEO: como fazer o Google rastrear, renderizar e indexar o seu site em JS

Você publicou a página, abriu no navegador e ficou tudo certo: texto, imagens, botões, preço. Aí vai ao Google Search Console, inspeciona a URL e descobre que o Google viu uma página quase vazia. Já vi essa cena acontecer em sites de todos os tamanhos, e ela quase sempre termina com alguém culpando o Google quando o problema está no código.

JavaScript SEO é o conjunto de práticas técnicas que garante que o conteúdo, os links e os metadados de um site construído com JavaScript sejam rastreados, renderizados e indexados corretamente pelos buscadores. Na prática, é o que separa um site React, Vue ou Angular que aparece nos resultados de um que só existe para quem tem o navegador aberto. É uma disciplina dentro do SEO técnico, e hoje, com SEO React e frameworks modernos dominando o desenvolvimento web, ignorá-la custa tráfego.

Neste guia eu explico como o Google processa JavaScript de verdade, quais estratégias de renderização funcionam, quais erros eu mais encontro em auditorias e como diagnosticar tudo isso com ferramentas gratuitas. Se o seu site depende de JavaScript para mostrar conteúdo, vale ler até o fim, inclusive o FAQ.

Se você quer que eu olhe o seu caso direto, conheça o serviço de SEO técnico que eu executo pessoalmente, sem intermediários.

O que é JavaScript SEO e por que ele importa

JavaScript SEO é a otimização de sites que dependem de JavaScript para montar a página. Em um site tradicional, o servidor entrega o HTML pronto, com título, texto e links já no código-fonte. Em um site que usa JavaScript para renderizar o conteúdo, o servidor entrega um HTML quase vazio e um script que monta a página depois, dentro do navegador.

Para o usuário, a diferença é invisível. Para o buscador, é enorme. O Google precisa de uma etapa extra, a renderização, para enxergar o que o navegador mostra. Quando essa etapa falha, atrasa ou é impedida por alguma decisão de desenvolvimento, o conteúdo existe para o visitante e não existe para o índice.

Eu comecei a trabalhar com sites em 1997, quando nenhuma página precisava de script para exibir um parágrafo. Vi o JavaScript passar de enfeite a espinha dorsal da web, e vi muita gente em SEO repetir duas frases opostas e igualmente erradas: “o Google não lê JavaScript” e “o Google lê tudo, não se preocupe”. A verdade fica no meio, e é mais trabalhosa que as duas.

Por que o problema cresceu nos últimos anos

Frameworks como React, Vue, Angular e Svelte tornaram o desenvolvimento mais produtivo, e isso fez com que muita agência e muita equipe de produto entregasse site novo em SPA (Single Page Application) sem passar pelo SEO. O resultado aparece meses depois, quando o tráfego orgânico não vem e ninguém entende por quê.

Há também o efeito colateral das buscas com IA. Diversos rastreadores de assistentes de IA, segundo testes públicos de empresas de infraestrutura web, não executam JavaScript. Se o seu conteúdo só aparece depois do script rodar, você corre o risco de ficar invisível não só no Google, mas nas respostas geradas por IA. Voltarei a isso mais adiante.

JavaScript SEO não é contra JavaScript

Um ponto que gosto de deixar claro logo no começo: JavaScript SEO não pede que você abandone JavaScript. Pede que você escolha como e onde o conteúdo é montado. Um site pode ser rico em interação e ainda assim entregar HTML completo ao Googlebot. Essa é, aliás, a meta de qualquer projeto sério.

Como o Google processa JavaScript: rastreamento, renderização e indexação

O Google processa páginas com JavaScript em três fases: rastreamento, renderização e indexação. O Googlebot busca a URL e lê o HTML bruto, coloca a página numa fila de renderização, executa o JavaScript com uma versão atual do Chromium e só então indexa o resultado final.

Entender essa sequência muda a forma como você toma decisões. A documentação oficial do Google, no guia de fundamentos de JavaScript SEO do Google Search Central, descreve exatamente esse fluxo, e vale a leitura completa.

Fase 1: rastreamento do HTML bruto

O Googlebot começa fazendo uma requisição HTTP, como qualquer cliente. Ele lê o HTML bruto, que é o que você vê em “exibir código-fonte” no navegador, e extrai os links que encontra ali. Também consulta o robots.txt para saber se pode acessar a URL e os arquivos que ela carrega.

Aqui mora o primeiro risco: se o seu HTML bruto não contém links em tags <a href>, o Google não descobre as páginas seguintes por esse caminho. E se o robots.txt bloqueia os arquivos JavaScript ou CSS, a renderização seguinte falha.

Fase 2: a fila de renderização

Depois do rastreamento, a página entra numa fila para renderização. Quando chega a vez dela, o Google executa o JavaScript com um Chromium headless e gera o HTML final, o chamado DOM renderizado. Segundo a documentação do Google, a página pode ficar nessa fila de alguns segundos a mais tempo, dependendo dos recursos disponíveis.

Esse intervalo importa para sites que publicam muito conteúdo novo, como portais e e-commerces. Se o conteúdo crítico só existe depois da renderização, ele pode demorar mais para ser indexado do que o de um site que entrega HTML completo. Isso conversa diretamente com o crawl budget do seu domínio.

Fase 3: indexação do conteúdo renderizado

Com o DOM renderizado em mãos, o Google extrai texto, links, imagens e dados estruturados e decide o que indexar. Os links descobertos nessa fase voltam para a fila de rastreamento, e o ciclo recomeça. É por isso que um site 100% dependente de JavaScript demora mais para ser descoberto por inteiro.

O que o Googlebot não faz

O Googlebot renderiza, mas não se comporta como um usuário. Ele não clica em botões, não preenche formulários, não rola a página infinitamente e não passa o mouse sobre elementos. Conteúdo que só aparece depois de uma dessas interações geralmente fica de fora. Esse é o padrão de erro que mais encontro quando rodo uma auditoria em sites de e-commerce e de serviços.

JavaScript SEO Google: o que a documentação oficial realmente diz

Vale separar o que é fato do que é folclore. O Google afirma que renderiza JavaScript e que usa um Chromium atualizado para isso. Também afirma, na própria documentação, que renderizar tem custo e que sites devem facilitar o trabalho do Googlebot. Não existe promessa de que “tudo será indexado”. Existe a recomendação de entregar as informações essenciais da forma mais direta possível.

Tipos de renderização e o impacto de cada um no SEO

A estratégia de renderização é a decisão mais importante em JavaScript SEO. Existem quatro caminhos principais: renderização no cliente (CSR), no servidor (SSR), geração estática (SSG) e renderização dinâmica. Para SEO, as três últimas entregam HTML completo ao rastreador, e a primeira exige que o Google execute o script.

Estratégia	Onde o HTML é montado	Impacto no SEO	Quando faz sentido
CSR (Client-Side Rendering)	No navegador, depois do script rodar	Depende da renderização do Google; mais risco	Áreas logadas, painéis, apps sem necessidade de indexação
SSR (Server-Side Rendering)	No servidor, a cada requisição	HTML completo na primeira resposta; baixo risco	Sites com conteúdo dinâmico e muitas páginas
SSG (Static Site Generation)	Na hora do build, antes de publicar	HTML completo e rápido; baixíssimo risco	Blogs, sites institucionais, documentação
Renderização dinâmica	Servidor entrega HTML pré-renderizado só para bots	Solução paliativa; Google não recomenda como estratégia de longo prazo	Sistemas legados que não dá para migrar já

Client-Side Rendering (CSR)

No CSR puro, o servidor entrega um HTML com uma div vazia e um pacote de JavaScript. O navegador baixa o script, executa e monta a página. É o comportamento padrão de muito projeto React criado sem framework de servidor. Para páginas que precisam ranquear, é a opção que mais exige cuidado, porque tudo depende da renderização do Google ter sucesso.

Server-Side Rendering (SSR)

No SSR, o servidor monta o HTML completo antes de responder. O Googlebot recebe título, texto e links já no código-fonte, e o JavaScript entra depois só para dar interatividade, num processo chamado hidratação. Next.js, Nuxt e Angular com SSR trabalham assim. É a abordagem que eu mais recomendo para sites com muito conteúdo dinâmico.

Static Site Generation (SSG)

No SSG, as páginas são geradas uma vez, no build, e servidas como arquivos estáticos. É a opção mais rápida e mais segura para SEO, e funciona muito bem para blogs, páginas institucionais e documentações. O limite aparece quando o conteúdo muda a cada minuto, o que exige regeneração incremental ou outra estratégia.

Renderização dinâmica: o paliativo

Na renderização dinâmica, o servidor detecta rastreadores e entrega uma versão pré-renderizada só para eles. O Google descreve a técnica como uma solução alternativa, e não como recomendação de longo prazo, em sua documentação sobre renderização dinâmica. Eu só considero quando existe uma restrição real para mexer na arquitetura, e trato como ponte para uma migração.

Como escolher a estratégia certa

A pergunta que faço ao time de desenvolvimento é simples: esta página precisa aparecer no Google? Se a resposta é não, como em um painel logado, CSR resolve e não há nada a otimizar. Se é sim, parto de SSG quando o conteúdo é estável, SSR quando é dinâmico, e deixo CSR só para os elementos que não precisam ser indexados.

Ação prática desta seção: liste as páginas do seu site que precisam ranquear e confirme, uma a uma, se o texto principal aparece no HTML bruto. É um teste de cinco minutos que mostra em que cenário você está.

Os erros mais comuns de JavaScript SEO e como corrigir

Os erros mais comuns de JavaScript SEO são links sem href, conteúdo que depende de interação, metadados injetados tarde demais, rotas com fragmento (#), soft 404 em SPAs e bloqueio de recursos no robots.txt. Cada um tem correção objetiva, e a maioria nasce de um padrão de código que ninguém questionou.

Links que não são links

Um link que o Google segue precisa ser uma tag <a> com atributo href apontando para uma URL real. Elementos como <div onclick=”…”> ou <span> com roteamento por script não são seguidos. A orientação do Google sobre links rastreáveis é explícita nesse ponto.

Como corrigir: use sempre <a href=”/url-real”> e deixe o JavaScript interceptar o clique para a navegação suave. Assim o usuário tem a experiência de SPA e o rastreador tem um link de verdade. Isso também fortalece sua estratégia de link interno, que depende de links rastreáveis para distribuir autoridade.

Conteúdo que só aparece após interação

Abas, acordeões e botões “ver mais” que carregam o conteúdo somente após o clique escondem esse conteúdo do Googlebot. Se o texto já está no DOM e é apenas ocultado por CSS, normalmente não há problema. Se ele é buscado via requisição depois do clique, o rastreador não o vê.

Como corrigir: carregue o conteúdo importante no carregamento inicial e use CSS para mostrar e esconder. Para listagens longas, prefira paginação com URLs reais a rolagem infinita sem fallback.

Metadados e canonical injetados por JavaScript

O Google consegue ler título, meta description e canonical definidos por JavaScript depois da renderização. O problema é a inconsistência: quando o HTML bruto traz um canonical e o script troca por outro, você cria sinais conflitantes. A recomendação mais segura é definir esses elementos já no HTML do servidor. Se quiser rever o conceito, escrevi um guia sobre a tag canonical.

O mesmo vale para a diretiva noindex. Se o HTML bruto traz noindex, o Google pode não renderizar a página, de modo que um script que “remova o noindex depois” nunca será executado. Já vi site perder semanas assim.

Rotas com fragmento (#)

URLs como site.com/#/produto foram o padrão de SPAs antigas. O Google não trata o fragmento como parte da URL para indexação, então todas as rotas parecem a mesma página. Use a History API para URLs limpas, como site.com/produto, e garanta que cada uma responda por si só quando acessada diretamente.

Soft 404 em aplicações de página única

Numa SPA, o servidor muitas vezes responde 200 mesmo para URLs que não existem, e o script exibe uma mensagem de “página não encontrada”. Para o Google, isso é um soft 404, e esse tipo de página consome rastreamento sem gerar valor. Retorne o status HTTP 404 de verdade para rotas inexistentes. Tenho um material sobre como resolver o erro 404 que cobre o raciocínio completo.

Bloqueio de JavaScript e CSS no robots.txt

Se o robots.txt proíbe o acesso aos arquivos que montam a página, o Googlebot renderiza um esqueleto. Revise as regras Disallow e garanta que scripts, estilos e endpoints de API que alimentam o conteúdo estejam liberados.

Se você suspeita que o seu site tem um ou mais desses problemas, uma auditoria de SEO com renderização JavaScript ativada mostra o diagnóstico completo, página por página.

SEO React, Vue e Angular: o que muda em cada framework

O SEO React depende de como o projeto foi montado. React puro, criado só com a biblioteca, renderiza no cliente. React com Next.js, Remix ou outro framework de servidor entrega HTML completo. A regra vale para os demais: o framework define o risco, e a configuração define a solução.

SEO React: da biblioteca ao framework

O React é uma biblioteca de interface, e não traz renderização no servidor por conta própria. Quem faz SEO React com seriedade costuma adotar Next.js, que oferece SSR, SSG e regeneração incremental. Cada rota pode escolher sua estratégia, o que dá flexibilidade: páginas de marketing em SSG, páginas de catálogo em SSR, painel em CSR.

Para quem herdou um projeto em React puro e não pode migrar agora, os caminhos são pré-renderização das páginas críticas ou, como último recurso, renderização dinâmica. Antes de qualquer decisão, meça o que o Google realmente vê. Já peguei casos em que o SEO React estava “quebrado” só por um erro de roteamento, sem necessidade de reescrever nada.

Vue e Nuxt

O Vue segue a mesma lógica. Vue puro renderiza no cliente, e o Nuxt adiciona SSR e geração estática. Atenção ao uso de rotas em modo hash, que gera o problema do fragmento visto antes. Configure o modo history e confirme que o servidor responde às rotas diretas.

Angular e Angular com SSR

O Angular tradicional renderiza no cliente, e o suporte a SSR e pré-renderização melhorou bastante nas versões recentes. Se o seu site em Angular precisa ranquear, habilite o SSR e verifique o HTML que sai do servidor, não o que aparece no navegador. O erro típico é ativar SSR e continuar testando só no navegador.

E o WordPress e os temas com muito JavaScript?

O WordPress entrega HTML renderizado no servidor, então o problema não é o núcleo. Ele aparece em temas e construtores de página que carregam conteúdo por script, ou em arquiteturas “headless” que colocam um front-end JavaScript sobre o WordPress. Nesse segundo caso, tudo o que descrevi acima passa a valer para o seu site.

Como aplicar JavaScript SEO na prática: diagnóstico passo a passo

O diagnóstico de JavaScript SEO compara o HTML bruto com o HTML renderizado e verifica se tudo o que importa está nos dois. O passo a passo abaixo é o roteiro que sigo, e você consegue executar a maior parte com ferramentas gratuitas.

Passo 1: compare HTML bruto e HTML renderizado

Abra a página, clique com o botão direito e escolha “exibir código-fonte”. Procure o texto principal, o título e os links. Se não estão ali, o conteúdo depende de renderização. Depois compare com o DOM renderizado nas ferramentas do desenvolvedor, na aba Elementos.

Passo 2: use a inspeção de URL do Search Console

No Google Search Console, inspecione a URL e use “Testar URL ao vivo”. Em “Ver página testada”, você enxerga o HTML renderizado, a captura de tela e as mensagens do console JavaScript. É o dado mais próximo do que o Google realmente processa.

Passo 3: rastreie o site com renderização JavaScript

Rastreadores como o Screaming Frog permitem ativar o modo de renderização JavaScript e comparar o que muda entre as duas versões da página. Escrevi um guia sobre o Screaming Frog com os ajustes que uso no dia a dia. Qualquer JavaScript SEO checker sério precisa fazer essa comparação, então desconfie de verificadores que olham só o HTML bruto.

Passo 4: audite links, status HTTP e dados estruturados

Confirme que os links internos são tags <a href>, que URLs inexistentes retornam 404 e que o schema markup aparece no HTML renderizado. Dados estruturados injetados por script funcionam, mas precisam ser validados no teste de resultados aprimorados do Google.

Passo 5: confira sitemap e robots.txt

O sitemap ajuda o Google a descobrir URLs mesmo quando a navegação depende de script. Garanta que ele liste as URLs canônicas finais e que o robots.txt não bloqueie recursos necessários para a renderização.

Passo 6: monitore depois de publicar

JavaScript SEO não é uma entrega única. Cada deploy pode mudar a forma como o conteúdo é montado. Eu acompanho o relatório de indexação do Search Console e rodo rastreamentos periódicos, principalmente depois de atualização de framework ou de tema.

Checklist rápido de JavaScript SEO

• O texto principal da página está no HTML bruto ou, no mínimo, no HTML renderizado?
• Todos os links internos usam <a href> com URL real?
• Título, meta description e canonical são definidos no servidor?
• URLs inexistentes retornam status 404 verdadeiro?
• O robots.txt libera scripts, estilos e APIs usados na renderização?
• Há erros de JavaScript no console do teste de URL?
• Imagens importantes estão em tags <img> com alt, e não só como background por script?

Se você fez o checklist e encontrou três ou mais respostas negativas, a decisão sobre qual estratégia de renderização adotar deve entrar na pauta antes de qualquer outra otimização. Isso é trabalho para consultoria de SEO junto ao time de desenvolvimento.

JavaScript SEO, Core Web Vitals e buscas com IA

JavaScript SEO afeta diretamente a velocidade percebida e a visibilidade em respostas de IA. Scripts pesados pioram métricas como INP e LCP, e conteúdo que depende de execução de script pode não ser lido por rastreadores de IA que não renderizam JavaScript.

Impacto nos Core Web Vitals

Pacotes grandes de JavaScript atrasam o carregamento do maior elemento visível e travam a resposta a cliques. Divisão de código, carregamento adiado de scripts de terceiros e SSR costumam melhorar esses números. Detalho essas métricas no guia sobre Core Web Vitals.

JavaScript SEO e GEO

Na otimização para mecanismos generativos (GEO), a lógica é a mesma: quanto mais direta a entrega do conteúdo no HTML, maior a chance de ele ser lido e citado. Não tenho um número mágico sobre isso, e desconfio de quem tem. O que recomendo é testar: peça ao desenvolvimento os logs do servidor, identifique os rastreadores de IA que visitam o site e verifique o que eles recebem de resposta.

Perguntas e respostas sobre JavaScript SEO

O que é JavaScript SEO?

JavaScript SEO é a prática de garantir que sites que dependem de JavaScript tenham conteúdo, links e metadados rastreados, renderizados e indexados pelos buscadores. Ele cobre escolhas de arquitetura, como SSR, SSG ou CSR, a forma de construir links e rotas, o uso de status HTTP corretos e o diagnóstico com ferramentas como a inspeção de URL do Search Console. O objetivo é simples: tudo o que o usuário vê e que deve ranquear precisa estar acessível ao Googlebot sem depender de interações, para que o site apareça nos resultados com título, descrição e conteúdo corretos.

O Google consegue ler JavaScript?

JavaScript SEO funciona porque o Google executa JavaScript: ele renderiza páginas com uma versão atual do Chromium e indexa o resultado. Mas isso não significa que tudo seja lido sem problema. A renderização consome recursos, acontece depois do rastreamento inicial e pode falhar por causa de bloqueios no robots.txt, erros de script ou conteúdo que só aparece após cliques. Por isso a recomendação prática é entregar o conteúdo essencial no HTML sempre que possível e usar JavaScript para complementar a experiência.

Qual a diferença entre CSR, SSR e SSG para SEO?

No CSR, o navegador monta a página com JavaScript, o que exige que o Google renderize para ver o conteúdo. No SSR, o servidor entrega o HTML pronto a cada requisição. No SSG, as páginas são geradas antes da publicação e servidas como arquivos estáticos. Para JavaScript SEO, SSR e SSG são mais seguros, porque o HTML completo chega na primeira resposta. O CSR continua válido para áreas que não precisam ser indexadas, como painéis logados e aplicações internas.

Como fazer SEO React sem perder ranqueamento?

O SEO React exige escolher uma estratégia de renderização compatível com ranqueamento. Em vez de React puro, adote um framework como Next.js ou Remix, que oferece SSR e SSG. Use links com href real, defina título e canonical no servidor, retorne 404 de verdade para rotas inexistentes e libere os arquivos de script no robots.txt. Depois valide cada template com a inspeção de URL do Search Console, comparando o HTML bruto com o renderizado, e monitore a indexação a cada deploy.

Como testar se o Google vê o meu conteúdo em JavaScript?

Para testar JavaScript SEO, use a inspeção de URL do Google Search Console e escolha “Testar URL ao vivo”. Em “Ver página testada” você acessa o HTML renderizado, a captura de tela e as mensagens de erro do console. Complemente com um rastreamento em modo de renderização JavaScript, no Screaming Frog, por exemplo, e compare o HTML bruto com o renderizado. Se um trecho de texto aparece no navegador e não aparece nas ferramentas do Google, você encontrou um problema de renderização.

Renderização dinâmica ainda vale a pena?

A renderização dinâmica serve de paliativo, e o Google a descreve como solução alternativa, não como recomendação de longo prazo. Ela entrega HTML pré-renderizado para rastreadores e a versão normal para usuários, o que adiciona complexidade e risco de divergência entre as versões. Eu só considero quando não há como mexer na arquitetura em curto prazo. Para JavaScript SEO sustentável, o caminho é migrar para SSR ou SSG nas páginas que precisam ranquear.

JavaScript SEO atrapalha a velocidade do site?

JavaScript SEO bem feito costuma melhorar a velocidade, e o inverso também é verdadeiro: scripts pesados prejudicam Core Web Vitals, principalmente LCP e INP. SSR, SSG, divisão de código e adiamento de scripts de terceiros reduzem o trabalho do navegador. Como o Google considera a experiência de página nos seus sistemas de ranqueamento, vale tratar renderização e desempenho como o mesmo projeto, e não como duas listas separadas de tarefas.

Posso usar hash (#) nas URLs de um site JavaScript?

Não é recomendável. O Google não usa o fragmento depois do # para identificar páginas distintas, então rotas como site.com/#/produto parecem uma única URL. Em JavaScript SEO, o correto é usar a History API para URLs limpas, como site.com/produto, e garantir que cada rota responda corretamente quando acessada diretamente. Configure o servidor para devolver o conteúdo ou o status adequado em qualquer rota válida, e retorne 404 para as inexistentes.

Rastreadores de IA conseguem ler sites em JavaScript?

Segundo testes públicos de empresas de infraestrutura web, vários rastreadores de IA não executam JavaScript, e por isso só enxergam o HTML bruto. Isso torna o JavaScript SEO relevante também para GEO: conteúdo que depende de execução de script pode ficar invisível a esses sistemas. Não existe regra única para todos os rastreadores, então o caminho é verificar nos logs do servidor quem visita o site e testar o que cada um recebe. Entregar o conteúdo essencial no HTML é a escolha mais segura.

Como a AgênciaSEO (Roberto Grozinski) ajuda com JavaScript SEO?

Eu executo pessoalmente o diagnóstico de JavaScript SEO: comparo HTML bruto e renderizado, rastreio o site com renderização ativada, reviso links, status HTTP, robots.txt, metadados e dados estruturados e entrego um plano priorizado para o seu time de desenvolvimento aplicar. Trabalho no mercado de SEO desde 1997 e tenho mais de 1.000 palavras-chave posicionadas. Sem intermediários, você fala direto comigo, e juntos definimos a estratégia de renderização mais adequada ao seu projeto.

Veja também

• Crawl Budget: o que é e como otimizar para ranquear mais rápido
• Screaming Frog Software: o que é, como usar e o que ele revela sobre o seu site
• SEO Técnico: guia completo para iniciantes e avançados (2026)

“Em 25 anos de SEO, aprendi que o problema raramente é o Google ler pouco: é o site entregar pouco no momento em que o Google chega. Em JavaScript SEO, o conteúdo precisa estar pronto antes de qualquer interação. — Roberto Grozinski, AgênciaSEO”