Idiomas

SEO para JavaScript

Como garantir que os mecanismos de busca possam rastrear, renderizar e indexar conteúdo dependente de JavaScript — links reais, paridade, lazy-loading, rolagem infinita, soft-404s e testes.

Publicado pela primeira vez: 23 de jun. de 2026 · Última atualização: 3 de ago. de 2026 · Avançado
Idiomas
AIEscrito porAI v2
1 sinal de evidência nesta página

JavaScript SEO trata de saber se os mecanismos de busca conseguem rastrear, renderizar e indexar conteúdo que depende de JavaScript. O Google consegue executar JS — os modos de falha são mais específicos: paridade (bruto vs renderizado), interação (o Google não rola nem clica), estado (o renderizador é sem estado) e tempo. Mantenha links como âncoras reais, não bloqueie JS/CSS, prefira SSR/prerenderização para conteúdo que precisa ranquear, e fique de olho na rolagem infinita — um viewport de renderização alto pode fazer duas páginas serem indexadas como uma.

TL;DR — O Google consegue executar seu JavaScript, então “o Google consegue ler JS?” é a pergunta errada. Os modos de falha são paridade (DOM bruto vs. renderizado), interação (o Google não rola nem clica), estado (o renderizador é sem estado) e tempo. Mantenha links como âncoras reais <a href>, não bloqueie JS/CSS, faça lazy-load com base no viewport, não na interação, retorne status reais para 404s no lado do cliente e lembre-se de que um noindex bruto pode impedir a renderização antes que o JavaScript possa removê-lo. Combine diretivas que foram realmente processadas, mas não assuma um vencedor universal entre bruto/renderizado. Cuidado especialmente com o scroll infinito: um viewport de renderização alto pode acionar o carregador e mesclar duas URLs em uma página indexada. Para os detalhes internos do renderizador e qual modo de renderização escolher, veja renderização.

O Google consegue ler JavaScript? Sim — essa não é a pergunta

Google can run your JavaScript — the real risks are parity, interaction, state, and timing. Fonte: /technical-seo/javascript-seo/

Three stages run left to right: crawl, render, and index. The render stage branches into four failure modes: parity, where the rendered DOM may not match expectations; interaction, where content requires a scroll or click; state, where content relies on cookies or storage that the renderer clears; and timing, where content is deferred behind slow JavaScript.

© Patrick Stox LLC · CC BY 4.0 ·

O Google processa aplicativos JavaScript em três fases: “Google processes JavaScript web apps in three main phases: 1. Crawling 2. Rendering 3. Indexing.” (tradução) «O Google processa aplicativos web JavaScript em três fases principais: 1. Rastreamento 2. Renderização 3. Indexação.» A fase do meio executa seu JS em um Chrome headless evergreen para construir o DOM que é indexado. “Rendering is important because websites often rely on JavaScript to bring content to the page, and without rendering Google might not see that content.” (tradução) «A renderização é importante porque os sites geralmente dependem de JavaScript para levar conteúdo à página, e sem a renderização o Google pode não ver esse conteúdo.»

Evidence for this claim Google processes JavaScript web apps in three main phases: crawling, rendering, and indexing; without rendering, Google might not see JavaScript-provided content. Scope: Google Search's processing of JavaScript pages; successful rendering does not guarantee indexing or ranking. Confidence: high · Verified: Google Search Central: Understand the JavaScript SEO basics

Então o Google consegue executar seu JavaScript. As perguntas úteis são mais específicas:

  • Paridade — o DOM renderizado realmente contém o que você pensa que contém?
  • Interação — algo exige uma rolagem/clique que o Google não realizará?
  • Estado — você depende de cookies/localStorage que o renderizador sem estado limpa?
  • Tempo — o conteúdo crítico é adiado por JavaScript lento ou tardio?

Sobre o tempo especificamente: o Google enfileira uma página rastreada (que retornou um 200) para renderização, e “the page may stay on this queue for a few seconds, but it can take longer than that.” (tradução) «a página pode permanecer nessa fila por alguns segundos, mas pode levar mais tempo do que isso.» Não há atraso ou tempo limite fixo publicado — e uma página que retorna um status diferente de 200, ou que começa com uma diretiva noindex, pode pular a fila de renderização em vez de esperar o JavaScript alterá-la.

Evidence for this claim Google queues crawled pages with a 200 response for rendering; the page may stay in that queue for a few seconds but can take longer, with no published fixed delay or timeout, and non-200 or initial noindex responses may skip rendering. Scope: Google Search's documented render-queue behavior; not a guaranteed or universal timing figure. Confidence: high · Verified: Google Search Central: Understand the JavaScript SEO basics

A mecânica de como o Google renderiza — o Web Rendering Service, a ausência de estado, o cache, o mito das “duas ondas” — está na página de renderização. Aqui vou focar nos problemas práticos e nas correções.

Este é o bug de JS-SEO mais comum. “Google can only discover your links if they are <a> HTML elements with an href attribute.” (tradução) «O Google só consegue descobrir seus links se eles forem elementos HTML <a> com um atributo href.» Um <div> clicável com um manipulador onclick é invisível para o Google como link — ele não será seguido, e páginas que dependem dele para descoberta podem ficar sem rastreamento. É perfeitamente aceitável injetar links com JavaScript, desde que eles acabem como âncoras reais <a href> no DOM renderizado. Essas âncoras renderizadas são analisadas depois que o JavaScript é executado, no entanto — cair no DOM renderizado torna um link descobrível, mas não é uma promessa de que a URL será rastreada, indexada ou tratada da mesma forma que um link presente no HTML bruto.

Evidence for this claim Google can reliably discover links only when they are HTML anchor elements with an href attribute. Scope: Link discovery by Google Search; this does not claim that every discovered URL will be crawled or indexed. Confidence: high · Verified: Google Search Central: Make your links crawlable

Conteúdo com carregamento preguiçoso e bloqueado por interação

O renderizador não se comporta como um usuário curioso: “Google Search does not interact with your page.” (tradução) «O Google Search não interage com sua página.» Sem rolagem, sem cliques, sem passar o mouse. Portanto, qualquer conteúdo que só carrega em um desses eventos não será visto.

A orientação do Google: carregue o conteúdo quando ele entrar no viewport, não quando o usuário agir — “make sure that your lazy-loading implementation loads all relevant content whenever it is visible in the viewport,” (tradução) «certifique-se de que sua implementação de carregamento preguiçoso carregue todo o conteúdo relevante sempre que ele estiver visível no viewport,» e “don’t add lazy-loading to content that is likely to be immediately visible when a user opens a page.” (tradução) «não adicione carregamento preguiçoso a conteúdo que provavelmente estará imediatamente visível quando um usuário abrir uma página.» Use IntersectionObserver ou loading="lazy" nativo para imagens — nunca um manipulador de rolagem ou clique — para que o conteúdo carregue durante uma renderização normal.

Evidence for this claim Google Search does not interact with a page, so lazy-loaded content should load when it becomes visible in the viewport rather than requiring user interaction. Scope: Google Search's documented rendering behavior for lazy-loaded content; other crawlers can behave differently. Confidence: high · Verified: Google Search Central: Fix lazy-loaded content

Rolagem infinita: quando duas páginas são indexadas como uma

Google's tall render viewport can trigger an infinite-scroll loader and merge two pages into one indexed URL. Fonte: /technical-seo/javascript-seo/

A normal browser viewport stops after the first page, but Google's render viewport expands much taller. The expansion reaches an infinite-scroll trigger, fires the loader without a real user scroll, and appends the next page into the same DOM. Google then indexes both pages' content under one URL.

© Patrick Stox LLC · CC BY 4.0 ·

Este é o ponto que quase ninguém explica, e vale a seção inteira.

O Googlebot pode renderizar em um viewport consideravelmente mais alto do que uma janela típica de navegador. O Google não publica um tamanho exato de viewport de renderização — e ele pode mudar — então não projete com base em um número específico; teste sua própria implementação. O que importa é o mecanismo: se o seu carregador de scroll infinito dispara com base na posição de rolagem ou na altura do viewport, um viewport de renderização mais alto do que o esperado pode disparar o carregador durante a própria renderização — e o conteúdo da próxima página de artigo ou produto é anexado ao mesmo DOM. Agora, o conteúdo de duas URLs distintas foi renderizado junto, e o Google pode indexá-las como uma página. Na minha própria experiência, “ocasionalmente, duas páginas são indexadas como uma” — já tive páginas relatadas como “não indexadas” que foram realmente indexadas como parte de outra página (geralmente o post anterior no feed), porque “quando o Google redimensionou o viewport para ser mais longo … ele disparou o scroll infinito e carregou outro artigo durante a renderização.” Confirme se a sua própria configuração faz isso verificando o HTML renderizado da URL Inspection para uma página que você esperaria que parasse antes — não assuma um tamanho e não assuma que você está seguro.

Há duas camadas para acertar isso.

Torne o scroll infinito amigável para busca em primeiro lugar. Suporte carregamento paginado por baixo do scroll infinito. Cada bloco deve ter “sua própria URL única e persistente,” o conteúdo em cada URL deve permanecer o mesmo a cada carregamento, você deve evitar parâmetros relativos como ?date=yesterday, você deve “linkar sequencialmente para as URLs individuais para que os mecanismos de busca possam descobrir as URLs em um conjunto paginado,” e quando um novo bloco carrega ao rolar, você deve “atualizar a URL exibida usando a History API.” Use links de paginação reais <a href> e URLs únicas — “não use identificadores de fragmento de URL” (a parte após um #) para números de página, porque o Google os ignora. Como digo no meu guia de SEO para JavaScript, “se você tem uma configuração de scroll infinito, ainda recomendo uma versão de página paginada para que o Google possa rastrear corretamente.”

Se um carregador com bug está mesclando páginas ativamente, a correção mais rápida é direta: “bloqueie o arquivo JavaScript que lida com o scroll infinito para que a funcionalidade não possa disparar.” Se o carregador não puder rodar durante a renderização, ele não pode anexar o conteúdo da próxima página, e cada URL renderiza como ela mesma novamente.

Soft-404s após roteamento no lado do cliente

Aplicativos de página única podem trocar conteúdo sem alterar o código de status HTTP, então uma visão de “não encontrado” ainda pode retornar 200. O Google pode classificar essa resposta como um soft 404 após avaliar o conteúdo retornado, mas uma busca estática sozinha não pode provar que o Google fez essa classificação. Duas correções: navegue com a History API e, para um estado genuíno de não encontrado, ou roteie para uma URL que retorne um status 404 real ou adicione uma tag noindex. E não dependa de fragmentos de URL para roteamento — “o esquema de rastreamento AJAX está obsoleto desde 2015, então você não pode confiar em fragmentos de URL para funcionar com o Googlebot.”

Um redirecionamento no lado do cliente tem o mesmo problema de evidência: a resposta inicial pode permanecer 200 até que o JavaScript seja executado. O Google suporta redirecionamentos JavaScript apenas como fallback quando redirecionamentos no lado do servidor ou meta-refresh não são possíveis. Relate o status estático e a navegação renderizada observada separadamente; não reescreva o status HTTP na auditoria nem chame toda mudança de URL renderizada de redirecionamento.

Não bloqueie JavaScript ou CSS no robots.txt

O Google não renderizará JavaScript de arquivos bloqueados ou em páginas bloqueadas. Uma regra de robots.txt que desautoriza seu bundle (ou o diretório /_next/, /static/, /assets/ em que ele está) pode quebrar a renderização completamente — o Google busca o shell, não consegue executar os scripts e indexa uma página vazia. Verifique os recursos da página da URL Inspection para qualquer coisa bloqueada.

Paridade de DOM e diretivas de robots conscientes do estágio

Compare seu HTML bruto (Ver código-fonte) com o HTML renderizado (Inspeção de URL). O conteúdo que só existe no HTML renderizado ainda é indexado — se for renderizado. O conteúdo que não está em nenhum dos dois não existe para o Google.

Há um risco de ordem de estágios que o Google documenta diretamente: “When Google encounters the noindex tag, it may skip rendering and JavaScript execution, which means using JavaScript to change or remove the robots meta tag from noindex may not work as expected.” (tradução) «Quando o Google encontra a tag noindex, ele pode pular a renderização e a execução de JavaScript, o que significa que usar JavaScript para alterar ou remover a meta tag robots de noindex pode não funcionar como esperado.» Se o seu HTML bruto envia um noindex inicial que você pretendia trocar com JavaScript, o Google pode agir com base nesse noindex bruto e nunca executar o script que o teria removido.

Não transforme isso em uma regra universal de “o renderizado vence”. A reconciliação é específica por campo:

CampoO que a comparação bruto/renderizado pode estabelecer
Conteúdo principal e linksO Google pode usar conteúdo e links reais <a href> produzidos durante a renderização se ela for bem-sucedida. A disponibilidade bruta reduz essa dependência.
Título e descriçãoO Google pode processar metadados definidos por JavaScript, mas os títulos nos resultados e as descrições são selecionados de várias fontes. Mostre os dois estados; não afirme que o valor renderizado, o primeiro ou o último é garantido.
Diretivas de robotsUm noindex bruto pode fazer o Google pular a renderização, então a remoção via JavaScript pode nunca ser vista. Adicionar restrições depois não é evidência de que uma restrição anterior foi cancelada.
CanônicoA orientação sobre JavaScript do Google diz para não definir um valor no código-fonte e depois alterá-lo com JavaScript. Use um método e verifique uma declaração no head renderizado.
Status HTTP e redirecionamentoO JavaScript não pode alterar o status de resposta já recebido. Registre o status estático e qualquer navegação renderizada observada como fatos separados.

Essa matriz é o motivo pelo qual um auditor deve manter o código-fonte, o renderizado, os cabeçalhos de resposta e o estado de pesquisa observado distintos, em vez de colapsá-los em um único valor “efetivo”.

Escolha um modo de renderização que coloque o conteúdo no DOM

A maior parte do risco de SEO com JS se resume a como o HTML é produzido. A versão curta: SSR, estático/pré-renderização e hidratação colocam o conteúdo no DOM (ou rapidamente nele), o que reduz o quanto sua visibilidade depende do renderizador ter sucesso; a renderização totalmente no lado do cliente deixa mais coisa dependendo de a renderização ser concluída corretamente, no prazo, todas as vezes. A renderização dinâmica é uma solução alternativa, não uma opção equivalente — conforme a orientação do Google atualizada pela última vez em dezembro de 2025, ela descreve a renderização dinâmica como uma solução alternativa em vez de uma solução de longo prazo e recomenda renderização no servidor, renderização estática ou hidratação. Como eu disse no meu guia de SEO para JavaScript, “any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines.” (tradução) «qualquer tipo de configuração de SSR, renderização estática e pré-renderização vai funcionar bem para os mecanismos de busca.» O menu completo — CSR, SSR, SSG, hidratação, ISR, edge, streaming e renderização dinâmica — com uma tabela de trade-offs está na página de renderização. O Google separadamente descreve a renderização no servidor ou a pré-renderização como uma boa ideia para usuários e crawlers. Evidence for this claim Google describes server-side rendering or pre-rendering as a good idea because it makes a website faster for users and crawlers. Scope: Google Search guidance for JavaScript sites; the source does not prescribe one framework or guarantee indexing. Confidence: high · Verified: Google Search Central: Understand the JavaScript SEO basics

Como testar

A Inspeção de URL no Search Console é a fonte da verdade: execute um teste ao vivo e depois observe o HTML renderizado, a captura de tela e os recursos da página / mensagens do console para ver o que carregou e o que falhou. O Teste de resultados avançados oferece uma verificação rápida do HTML renderizado. Em escala, use um crawler que execute JavaScript (Ahrefs Site Audit, Screaming Frog no modo de renderização JS) para comparar o bruto com o renderizado em todo o site.

A render diff is diagnostic, not a score: investigate essential elements that appear only after JavaScript—or disappear after rendering.

An illustrative page has 1 title in both raw and rendered HTML, 18 headings in raw HTML and 19 rendered, 42 internal links in raw HTML and 71 rendered, 0 product descriptions in raw HTML and 12 rendered, and 6 canonical tags in raw HTML but only 1 rendered. These counts are synthetic.

JavaScript não é ruim para SEO, e não é maligno. É apenas diferente do que muitos profissionais de SEO estão acostumados. Trabalhe com seus desenvolvedores, coloque seu conteúdo importante no DOM e deixe que as próprias ferramentas do Google — não suas suposições — sejam o árbitro do que foi renderizado.

Para onde ir a seguir: o cluster de SEO para JavaScript

Este hub é o mapa. Cada tópico abaixo é um mergulho profundo próprio:

Renderização e arquitetura

  • SEO para CMS headless — como frontends desacoplados afetam rastreamento, renderização, metadados, sitemaps e tags canônicas; qual modo de renderização escolher; e os modos de falha específicos de headless que você precisa conhecer.

Guias específicos por framework

  • React SEO — por que CSR-first em React cria risco de indexação, como o Google renderiza aplicativos React, React Router e History API, react-helmet-async para meta tags, e quando recorrer ao Next.js.
  • Angular SEO — padrões SPA do Angular, @angular/ssr (sucessor do Angular Universal), os serviços integrados Title e Meta, pré-renderização e hidratação incremental no Angular moderno.
  • Next.js SEO — Pages Router vs App Router, Metadata API, next/image e CWV, timing de ISR e Googlebot, sitemaps e os erros de SEO mais comuns no Next.js.
  • Nuxt SEO — SSR por padrão, useSeoMeta(), modos de renderização do Nuxt, ecossistema de módulos @nuxtjs/seo e como o Nuxt se compara ao Vue puro para indexabilidade.
  • Vue SEO — padrão CSR do Vue 3 e o que isso significa para rastreadores, createWebHistory(), @unhead/vue, opções de pré-renderização sem meta-framework e quando o Nuxt é a escolha certa.
  • Svelte SEO — Svelte vs SvelteKit, SSR por padrão no SvelteKit, <svelte:head>, a armadilha adapter-static + ssr: false, escolhas de adapters e implicações para rastreadores de IA.
  • Astro SEO — zero-JS por padrão, arquitetura de ilhas, @astrojs/sitemap, astro:assets, View Transitions e History API, comportamento de fallback de Server Islands e vantagens de Core Web Vitals do Astro.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.