Renderização

TL;DR — Renderização é a etapa em que um mecanismo de busca executa o código da página — inclusive JavaScript — em um navegador para montar a versão final, de modo que consiga ver o conteúdo e os links. O Google faz isso com praticamente todas as páginas em seu Web Rendering Service, e em geral funciona. A forma como o site produz o HTML — no servidor, no navegador ou durante o build — determina o grau de segurança dessa configuração.

O que é renderização

Quando você abre uma página, o navegador baixa parte do HTML e depois executa o CSS e o JavaScript para montar a página que aparece na tela. Os mecanismos de busca fazem o mesmo. Renderização é a etapa em que o mecanismo executa o código da página para produzir sua versão final e, assim, ler o conteúdo e seguir os links como uma pessoa faria.

Ela fica no meio do processamento de uma página pelo Google:

1. Rastreamento — o Google baixa o HTML bruto da URL.
2. Renderização — o Google executa o JavaScript da página em um navegador para montar a versão final.
3. Indexação — o Google lê essa versão final e a armazena no índice.

Se o conteúdo só aparece depois que o JavaScript é executado, o Google precisa renderizar a página corretamente antes de enxergá-lo. Portanto, a renderização é a ponte entre buscar uma página e entendê-la.

O Google renderiza em um navegador real, mas incomum

O renderizador do Google se chama Web Rendering Service (WRS). Ele usa um Chrome headless “evergreen,” (tradução) «sempre atualizado», ou seja, acompanha a versão atual do Chrome e oferece suporte a recursos modernos da web. Assim, o antigo receio de que “o Google não consegue executar JavaScript” não procede. Ele consegue. Evidence for this claim Google Search runs JavaScript with an evergreen version of Chromium. Scope: Google's Web Rendering Service; browser support does not guarantee that every application-specific interaction or resource will work. Confidence: high · Verified: 2026-07-14 Google Search Central: Fix Search-related JavaScript problems

É apenas um navegador incomum. Ele não rola a tela nem clica, esquece tudo entre uma página e outra — não permanece conectado — e mantém arquivos em cache de forma agressiva. Essas peculiaridades causam a maioria das surpresas e são detalhadas na aba Avançado.

A grande escolha: onde o HTML é montado

A decisão mais importante para SEO é onde o HTML da página é produzido:

• No navegador (renderização no lado do cliente) — o servidor envia uma página quase vazia, e o JavaScript monta tudo. É a opção mais arriscada para busca.
• No servidor (renderização no lado do servidor) — o servidor envia uma página completa. É uma opção segura.
• Durante o build (estática / pré-renderização) — as páginas são montadas antecipadamente, uma única vez. É a opção mais segura e rápida.

A maioria dos frameworks modernos combina essas abordagens. A regra prática é simples: se o conteúdo importante está no HTML antes da execução do JavaScript — ou aparece quase imediatamente —, a configuração está em boa forma.

Quer a versão aprofundada — como o Web Rendering Service se comporta, se as “duas ondas de indexação” ainda existem e uma comparação completa de todas as opções de renderização? Abra a aba Avançado. Para problemas práticos de JavaScript e suas correções, consulte SEO para JavaScript.

TL;DR — O Google renderiza o JavaScript em um Chromium headless sempre atualizado — o Web Rendering Service — para montar o DOM que será indexado. Isso acontece com praticamente todas as páginas, em geral em segundos ou minutos; por isso, o modelo de “duas ondas de indexação” está em grande parte ultrapassado, e não existe orçamento de renderização por página. O WRS não mantém estado, recusa solicitações de permissão, não interage com a página e usa cache agressivamente. A opção de renderização determina o risco de SEO: SSR, renderização estática, pré-renderização e hidratação têm baixo risco; CSR integral é a alternativa arriscada; e a renderização dinâmica é uma solução provisória desaconselhada pelo Google. Para os problemas práticos de JavaScript decorrentes disso, consulte SEO para JavaScript.

Onde a renderização se encaixa

O Google afirma explicitamente que aplicativos JavaScript passam por três fases: “Google processes JavaScript web apps in three main phases: 1. Crawling 2. Rendering 3. Indexing.” (tradução) «O Google processa aplicativos JavaScript em três fases principais: 1. Rastreamento, 2. Renderização, 3. Indexação.» Evidence for this claim Google documents crawling, rendering, and indexing as the three main phases for processing JavaScript web apps. Scope: Google Search processing of JavaScript web applications; the phases can overlap operationally. Confidence: high · Verified: 2026-07-14 Google Search Central: Understand the JavaScript SEO basics A renderização é a ponte. O rastreamento busca o HTML bruto; a renderização executa o JavaScript para montar o DOM final; a indexação lê esse DOM renderizado; e todos os novos links encontrados pelo renderizador voltam para o rastreamento. Nas palavras do Google: “During the crawl, Google renders the page and runs any JavaScript it finds using a recent version of Chrome, similar to how your browser renders pages you visit.” (tradução) «Durante o rastreamento, o Google renderiza a página e executa todo JavaScript encontrado usando uma versão recente do Chrome, de maneira semelhante à que seu navegador usa para renderizar as páginas visitadas.»

O Web Rendering Service

O Google renderiza no Web Rendering Service (WRS), um Chrome headless evergreen: “While Google Search runs JavaScript with an evergreen version of Chromium…” (tradução) «Enquanto a Pesquisa Google executa JavaScript com uma versão sempre atualizada do Chromium…». Ele acompanha o Chrome atual, portanto os recursos modernos de JavaScript e CSS funcionam.

A ressalva é que o WRS é um navegador peculiar, e suas particularidades causam a maioria dos problemas reais:

• Ele não mantém estado. Como escrevi no meu guia de SEO para JavaScript, “Google loads each page stateless like it’s a fresh load.” (tradução) «O Google carrega cada página sem estado, como se fosse um acesso novo.» A documentação do Google detalha isso: “Local Storage and Session Storage data are cleared across page loads” (tradução) «Os dados de Local Storage e Session Storage são apagados entre carregamentos de página» e “HTTP Cookies are cleared across page loads.” (tradução) «Os cookies HTTP são apagados entre carregamentos de página.» Não dependa de nada persistido no cliente para entregar conteúdo.
• Ele recusa permissões. “Expect Googlebot to decline user permission requests.” (tradução) «Espere que o Googlebot recuse solicitações de permissão do usuário.» Conteúdo bloqueado por uma solicitação de geolocalização, notificação ou câmera não será renderizado.
• Ele não interage. Não há rolagem, clique ou passagem do mouse; por padrão, conteúdo carregado apenas após um desses eventos fica invisível. Essa é a origem da maioria dos problemas de lazy loading e rolagem infinita; as correções estão na página de SEO para JavaScript.
• Ele usa cache agressivamente. “Googlebot caches aggressively in order to reduce network requests and resource usage. WRS may ignore caching headers.” (tradução) «O Googlebot usa cache agressivamente para reduzir solicitações de rede e consumo de recursos. O WRS pode ignorar cabeçalhos de cache.» Isso significa que o Google pode executar uma versão desatualizada do JavaScript ou CSS. Corrija com fingerprinting de arquivos: versione os nomes (app.4f2a9c.js) para que uma mudança de conteúdo force uma nova busca.

Experimento de 2026: cinco segundos não são um limite rígido de execução

Um experimento independente com o WRS, divulgado em julho de 2026, testou JavaScript e atividade de rede com atrasos, em vez de presumir um timeout de cinco segundos. O renderizador observado usou um relógio virtual e concluiu solicitações atrasadas que levaram aproximadamente de 6 a 12 segundos em tempo real. O resultado útil é restrito: ele contradiz a regra de auditoria comum de que tudo que ocorre depois de exatamente cinco segundos fica automaticamente invisível para o Google. Não prova que toda dependência atrasada será concluída, que o Google espera por tempo indefinido nem que a entrega lenta no cliente seja segura.

Considere o experimento e sua metodologia como evidência independente, ao lado da declaração oficial do Google de que não existe atraso fixo publicado para a fila de renderização. Na prática, teste o DOM final e os recursos solicitados. Uma resposta de API ausente, uma exigência de interação, um script bloqueado ou uma dependência de estado continuam sendo falhas reais de renderização, mesmo que a “regra dos cinco segundos” baseada no cronômetro não seja válida.

As “duas ondas de indexação” ainda existem?

Durante anos, o modelo mental foi o de “duas ondas de indexação”: primeiro o Google indexaria o HTML bruto e, dias ou semanas depois, voltaria para renderizar e indexar o conteúdo JavaScript. Esse modelo hoje está em grande parte ultrapassado. Martin Splitt afirmou que a ideia das duas ondas desempenha um papel cada vez menor, que muitas páginas passam pela fase de renderização mesmo sem depender de JavaScript e que rastreamento, renderização e indexação estão convergindo com o tempo.

Na prática, a renderização ocorre com praticamente todas as páginas e costuma ser rápida. A documentação atual do Google diz que uma página rastreada “may stay on this queue for a few seconds, but it can take longer than that” (tradução) «pode permanecer nessa fila por alguns segundos, mas pode levar mais tempo»; não há atraso fixo ou timeout publicado. Evidence for this claim Google says a crawled page may stay on the rendering queue for a few seconds, but it can take longer than that. Scope: Google's rendering queue for a page that returns a 200 status and is eligible for rendering. The source gives a variable duration, not a fixed timeout or service-level guarantee. Confidence: high · Verified: 2026-07-25 Google Search Central: rendering-queue duration Supports: A page may remain on the rendering queue for a few seconds or longer. Como dado histórico, profissionais do Google (Martin Splitt e Tom Greenaway) já situaram a mediana em cerca de cinco segundos, com o 90º percentil em minutos — não nas “semanas” sugeridas pelo receio antigo. Cito esse número no meu guia de SEO para JavaScript, mas ele deve ser tratado como dado antigo de conferência, e não como métrica publicada atual: o Google não o republicou como número contínuo, e a citação sobre a fila acima é o enquadramento oficial vigente.

Também não existe orçamento de renderização como muitas pessoas imaginam. O Google não mantém, por página, uma pontuação de “quanto custou renderizar” que precise ser economizada. A renderização é barata na escala do Google; otimize para usuários e desempenho, não para um orçamento de renderização imaginário.

As opções de renderização

“Onde o HTML é montado?” é a pergunta que determina o risco de SEO. Estas são as opções:

• Renderização no lado do cliente (CSR). O servidor envia uma estrutura quase vazia; o navegador — ou o WRS — executa JavaScript para montar tudo. É “the most problematic one … full client-side rendering where all of the rendering happens in the browser.” (tradução) «a opção mais problemática… renderização integral no lado do cliente, em que toda a renderização acontece no navegador». Pode funcionar, mas tudo depende do sucesso da renderização, e é a opção mais lenta para ser indexada.
• Renderização no lado do servidor (SSR). O servidor monta o HTML completo a cada solicitação. O conteúdo está no HTML bruto, portanto o risco para busca é baixo.
• Geração de site estático (SSG) / pré-renderização. O HTML é montado uma vez, durante o deploy. É a opção de menor risco: o conteúdo está no HTML bruto e carrega rapidamente.
• Hidratação (isomórfica / universal). A primeira exibição vem de SSR ou SSG; depois, o JavaScript “hidrata” a página no navegador para adicionar interatividade. É o que a maioria dos frameworks modernos faz e traz pouco risco ao conteúdo; apenas monitore divergências de hidratação que apaguem ou substituam conteúdo.
• Regeneração estática incremental (ISR). Páginas estáticas são regeneradas em intervalos ou sob demanda. É semelhante à SSG, mas com conteúdo mais recente, e funciona bem para catálogos grandes.
• Renderização na edge. SSR executada nos nós de borda da CDN: mesmo baixo risco da SSR, com time to first byte menor para um público global.
• SSR com streaming. O HTML é transmitido ao navegador em partes, conforme fica pronto. O risco é baixo, mas o conteúdo indexável não deve ficar preso apenas em uma parte tardia ou adiada.

Minha conclusão no guia de SEO para JavaScript é: “Any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines. Gatsby, Next, Nuxt, etc., are all great.” (tradução) «Qualquer configuração de SSR, renderização estática e pré-renderização funcionará bem para os mecanismos de busca. Gatsby, Next, Nuxt etc. são todos ótimos.» O framework importa menos do que o modo de renderização entregue: o mesmo aplicativo Next.js pode ser seguro ou arriscado, dependendo de servir SSR/SSG ou CSR integral.

Renderização dinâmica: solução provisória, não estratégia

Renderização dinâmica significa detectar robôs e entregar a eles uma versão pré-renderizada, sem JavaScript, enquanto usuários recebem a versão renderizada no cliente. Hoje o Google é direto: “Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines,” (tradução) «A renderização dinâmica era uma solução provisória, e não uma solução de longo prazo para problemas com conteúdo gerado por JavaScript nos mecanismos de busca», e “Dynamic rendering is a workaround and not a recommended solution, because it creates additional complexities and resource requirements.” (tradução) «A renderização dinâmica é uma solução provisória e não recomendada, porque cria complexidades e exigências adicionais de recursos.» Evidence for this claim Google describes dynamic rendering as a workaround and does not recommend it as a long-term solution. Scope: Google Search guidance for JavaScript-generated content; server-side rendering, static rendering, or hydration are the recommended alternatives. Confidence: high · Verified: 2026-07-14 Google Search Central: Dynamic rendering as a workaround Eu concordo e sempre concordei: para ser franco, nunca a recomendei, e fico satisfeito que o Google também a desaconselhe hoje. Servir conteúdo diferente para robôs e usuários chega muito perto de cloaking. Prefira SSR, renderização estática ou hidratação.

Há uma ressalva: o Bing ainda sugere renderização dinâmica. A Microsoft afirma que “bingbot is generally able to render JavaScript” (tradução) «o bingbot geralmente consegue renderizar JavaScript», mas que fazer isso em escala é difícil; por isso, “we recommend dynamic rendering as a great alternative for websites relying heavily on JavaScript.” (tradução) «recomendamos a renderização dinâmica como ótima alternativa para sites que dependem muito de JavaScript.» A conclusão prática é que SSR/SSG satisfaz os dois mecanismos e evita toda a discussão.

O que isso significa para seu conteúdo

A renderização determina se o Google chegará a ver o conteúdo JavaScript, mas enxergá-lo é apenas metade do trabalho. Depois que a página é renderizada, as preocupações práticas são links <a href> reais, paridade específica por campo entre HTML bruto e renderizado, ordem das etapas das diretivas de robôs, conteúdo lazy, rolagem infinita e soft-404s. Tudo isso está na página de SEO para JavaScript, junto com o fluxo de teste — HTML renderizado, captura de tela e console da Inspeção de URL.

Esta é a etapa de renderização do pipeline de busca. Para as etapas ao redor, consulte rastreamento — como as páginas são buscadas — e indexação — o que ocorre em seguida com a página renderizada — ou o hub Como a busca funciona para ver o percurso completo.

Uma regra de auditoria merece ser mantida: renderizado é um estado, não um vencedor universal. Para conteúdo do corpo e links rastreáveis, o DOM renderizado mostra o que o JavaScript executado adicionou ou removeu. Para títulos e descrições, ele mostra entradas adicionais, mas o Google ainda pode gerar um link de título ou snippet a partir de outras fontes. No caso de diretivas de robôs, um noindex no HTML bruto pode impedir a renderização, portanto a remoção por JavaScript é assimétrica. Para canonical, o Google recomenda usar uma única fonte ou um único valor definido por JavaScript, em vez de alterar um valor existente. E o JavaScript não pode mudar o status da resposta HTTP já recebida. Mantenha essas colunas separadas nas evidências e use as orientações atuais do Google sobre SEO para JavaScript para o comportamento específico de cada campo.

Resumo de IA

Uma síntese da versão Avançado:

• Renderização é a ponte entre rastreamento e indexação. O Google executa o JavaScript em um Chromium headless sempre atualizado — o Web Rendering Service — para montar o DOM que será indexado. São três fases: rastrear → renderizar → indexar.
• As “duas ondas de indexação” estão em grande parte ultrapassadas (Splitt). A renderização ocorre com praticamente todas as páginas e costuma ser rápida. A documentação atual do Google diz que uma página “may stay on this queue for a few seconds, but it can take longer than that” (tradução) «pode permanecer nessa fila por alguns segundos, mas pode levar mais tempo»; nenhum atraso fixo foi publicado. Há um dado histórico de mediana de aproximadamente 5 segundos e 90º percentil em minutos, mas ele vem de uma conferência e não é uma métrica atual. Não existe orçamento de renderização por página.
• O WRS é um navegador peculiar: não mantém estado — localStorage e cookies são apagados entre carregamentos —, recusa solicitações de permissão, não rola, clica nem passa o mouse e usa cache agressivo de JavaScript e CSS — pode ignorar cabeçalhos de cache. Portanto, use fingerprint nos nomes dos arquivos.
• Opções de renderização por risco de SEO: SSG/pré-renderização — menor risco — ≈ SSR ≈ hidratação ≈ ISR ≈ edge/streaming — baixo risco — ≪ CSR integral — maior risco. Patrick: “SSR, static rendering, and prerendering … are all great” (tradução) «SSR, renderização estática e pré-renderização… são todos ótimos»; CSR integral é “the most problematic one” (tradução) «a opção mais problemática».
• Renderização dinâmica é uma solução provisória desaconselhada pelo Google e próxima de cloaking. O Bing ainda a recomenda, mas SSR/SSG satisfaz os dois mecanismos.
• O framework não determina o risco; o modo de renderização, sim. O mesmo aplicativo é seguro ou arriscado conforme entregue SSR/SSG ou CSR integral.
• Renderizar é apenas metade do trabalho. Os problemas práticos de JavaScript — links, paridade, conteúdo lazy, rolagem infinita, soft-404s e testes — estão na página de SEO para JavaScript.

Documentação oficial

Documentação de fonte primária dos mecanismos de busca.

Google

• Entenda os fundamentos de SEO para JavaScript — as três fases — rastrear → renderizar → indexar — e o renderizador Chromium sempre atualizado.
• Corrija problemas de JavaScript relacionados à Pesquisa — as restrições do WRS: armazenamento e cookies sem estado, permissões recusadas e cache agressivo.
• Renderização dinâmica como solução provisória — por que a renderização dinâmica é uma solução provisória, e não uma alternativa recomendada a longo prazo.
• Guia detalhado sobre como a Pesquisa Google funciona — onde a renderização se encaixa em rastrear → indexar → veicular.

Bing / Microsoft

• Série bingbot: JavaScript, renderização dinâmica e cloaking — a posição do Bing: ele consegue renderizar JavaScript, mas recomenda renderização dinâmica em escala.
• O novo Bingbot sempre atualizado — renderização do Bingbot no Microsoft Edge baseado em Chromium.

Citações das fontes

Declarações registradas do Google e do Bing, além de algumas do meu próprio trabalho. Cada link dos mecanismos de busca leva diretamente ao trecho citado na página de origem.

Google — o pipeline de renderização

• “Google processes JavaScript web apps in three main phases: 1. Crawling 2. Rendering 3. Indexing.” (tradução) «O Google trata aplicativos que usam essa linguagem em três etapas principais: 1. Rastreamento, 2. Renderização, 3. Indexação.» Ir para a citação
• “During the crawl, Google renders the page and runs any JavaScript it finds using a recent version of Chrome, similar to how your browser renders pages you visit.” (tradução) «Ao rastrear, o Google renderiza a página e executa o código encontrado em um navegador recente, de modo semelhante à exibição das páginas visitadas.» Ir para a citação
• “While Google Search runs JavaScript with an evergreen version of Chromium…” (tradução) «A Pesquisa Google executa JavaScript em uma versão continuamente atualizada do Chromium…» Ir para a citação
• “The page may stay on this queue for a few seconds, but it can take longer than that.” (tradução) «A página pode ficar nessa fila por alguns segundos, embora o processo possa demorar mais.» — esse é o enquadramento oficial atual para o tempo da fila de renderização; nenhum atraso fixo foi publicado. Ir para a citação

Google — o Web Rendering Service

• “Local Storage and Session Storage data are cleared across page loads.” (tradução) «Os dados do Local Storage e do Session Storage são removidos entre carregamentos de páginas.» Ir para a citação
• “HTTP Cookies are cleared across page loads.” (tradução) «Os cookies HTTP são removidos entre carregamentos de páginas.» Ir para a citação
• “Expect Googlebot to decline user permission requests.” (tradução) «Considere que o Googlebot recusará pedidos de permissão do usuário.» Ir para a citação
• “Googlebot caches aggressively in order to reduce network requests and resource usage. WRS may ignore caching headers.” (tradução) «O Googlebot mantém cache de forma agressiva para reduzir solicitações de rede e uso de recursos. O WRS pode desconsiderar cabeçalhos de cache.» Ir para a citação

Google — renderização dinâmica

• “Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines.” (tradução) «A renderização dinâmica servia como contorno, não como resposta duradoura a problemas de conteúdo gerado por JavaScript nos mecanismos de busca.» Ir para a citação
• “Dynamic rendering is a workaround and not a recommended solution, because it creates additional complexities and resource requirements.” (tradução) «A renderização dinâmica é um contorno não recomendado, pois acrescenta complexidade e demanda de recursos.» Ir para a citação

Microsoft Bing

• “bingbot is generally able to render JavaScript…” (tradução) «Em geral, o bingbot consegue renderizar JavaScript…» Ir para a citação
• “we recommend dynamic rendering as a great alternative for websites relying heavily on JavaScript.” (tradução) «Indicamos a renderização dinâmica como boa alternativa para sites muito dependentes de JavaScript.» Ir para a citação

Martin Splitt, Google (transmitido pela transcrição da Onely de um hangout da Webmaster Central de 2019)

• Sobre o modelo das duas ondas: Splitt afirmou que ele desempenha um papel cada vez menor, que muitos sites passam pela fase de renderização mesmo sem JavaScript e que rastreamento, renderização e indexação estão convergindo. Leia a cobertura

Patrick Stox (meu próprio trabalho — SEO para JavaScript: guia definitivo)

• “Google loads each page stateless like it’s a fresh load.” (tradução) «O Google abre cada página sem estado anterior, como em uma visita nova.»
• “pages went to the renderer at a median time of five seconds” (90º percentil em minutos) — dado antigo da época de conferências, e não uma métrica publicada atual; consulte acima a citação oficial vigente sobre o tempo da fila. (tradução) «A mediana para as páginas chegarem ao renderizador era de cinco segundos.»
• “The most problematic one is going to be full client-side rendering where all of the rendering happens in the browser.” (tradução) «O caso mais problemático tende a ser a renderização integral no cliente, na qual todo o processo ocorre no navegador.»
• “Any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines. Gatsby, Next, Nuxt, etc., are all great.” (tradução) «Configurações com SSR, renderização estática ou pré-renderização atendem bem aos mecanismos de busca. Gatsby, Next e Nuxt, entre outros, funcionam muito bem.»

Os modelos mentais

1. Rastrear → renderizar → indexar. A renderização é a ponte. O rastreamento busca o HTML bruto; a renderização executa o JavaScript para montar o DOM; a indexação lê esse DOM. Quando conteúdo JavaScript desaparece, pergunte qual etapa falhou: ele foi buscado? Renderizado? O DOM renderizado continha o conteúdo?

2. O renderizador é um navegador real com amnésia. Ele usa um Chrome sempre atualizado, mas não mantém estado — esquece cookies e armazenamento entre páginas —, não interage — não rola nem clica — e adora cache — pode executar JavaScript ou CSS desatualizado. Projete como se todo acesso fosse o primeiro, novo e intocado.

3. O modo de renderização determina o risco, não o framework. SSR, renderização estática, pré-renderização e hidratação colocam o conteúdo no DOM — ou o fazem rapidamente — e trazem baixo risco. A CSR integral aposta tudo na renderização e oferece o maior risco. O mesmo aplicativo Next.js pode ser seguro ou arriscado conforme o modo entregue.

4. As “duas ondas” são o mapa antigo. Não planeje com base em uma segunda onda de renderização adiada por dias. A renderização ocorre com praticamente todas as páginas, em geral em segundos ou minutos, e não existe orçamento de renderização a racionar.

5. Renderização dinâmica é um sinal de problema, não uma estratégia. Servir aos robôs um HTML diferente do recebido pelos usuários é uma solução provisória que o Google desaconselha e se aproxima de cloaking. Se você cogita essa opção, a correção real costuma ser SSR/SSG.

6. Coloque o conteúdo no DOM e depois verifique. Escolha um modo que leve rapidamente o conteúdo ao DOM renderizado e confirme o resultado no HTML renderizado da Inspeção de URL. Seu navegador não é o Googlebot.

Opções de renderização — contrapartidas de SEO

Web Rendering Service — fatos rápidos

Checklist de auditoria da prontidão para renderização

Uma verificação para confirmar que o conteúdo importante realmente sobrevive à renderização:

• O conteúdo principal e os links da navegação principal estão presentes na resposta HTML bruta — veja o código-fonte, não o DOM inspecionado no DevTools — e não são injetados apenas depois que o JavaScript é executado.
• Todo link interno que uma pessoa precisa seguir é um <a href="..."> real, e não um <div onclick>, uma rota somente com hash — #/page — ou um botão que altera o estado no cliente sem um link correspondente.
• Nenhum arquivo crítico de JavaScript ou CSS está bloqueado no robots.txt — um bundle bloqueado pode impedir o WRS de montar a página que precisa renderizar.
• Conteúdo carregado ao rolar, passar o mouse ou clicar também tem um caminho que renderiza sem interação, pois o WRS não rola, clica nem passa o mouse.
• Nada importante depende de localStorage, sessionStorage ou cookies persistentes entre solicitações: o WRS não mantém estado e apaga tudo isso entre carregamentos de página.
• Nada importante fica atrás de uma solicitação de permissão de geolocalização, notificação ou câmera: o WRS as recusa por padrão.
• Os nomes dos arquivos JavaScript e CSS têm fingerprint — app.4f2a9c.js — para que uma mudança de conteúdo force uma nova busca, em vez de usar o cache agressivo do WRS.
• O HTML renderizado e a captura de tela da Inspeção de URL no Google Search Console mostram o mesmo conteúdo e os mesmos links vistos em seu navegador.
• O site não usa renderização dinâmica como resposta para um problema de CSR: a correção é SSR, renderização estática ou hidratação, e não servir outra versão da página aos robôs.

Erros de renderização que realmente causam problemas

Bloquear no robots.txt o JavaScript ou CSS necessário para renderizar a página. Se o WRS não consegue buscar um script ou uma folha de estilo de que a página depende, ele não consegue montar um DOM renderizado fiel; o resultado é uma renderização quebrada ou vazia, não a página pretendida. Faça o seguinte: permita o rastreamento dos recursos JavaScript e CSS. O robots.txt deve afastar robôs de áreas de pouco valor, não dos recursos exigidos pelas próprias páginas.

Entregar páginas cujo conteúdo é crítico em CSR integral, sem fallback. A CSR é “the most problematic one … full client-side rendering where all of the rendering happens in the browser” (tradução) «a opção mais problemática… renderização integral no lado do cliente, em que toda a renderização acontece no navegador». Ela faz toda a página depender do sucesso da renderização e é a opção mais lenta para chegar ao índice. Faça o seguinte: use SSR, geração estática, pré-renderização ou hidratação para que o conteúdo esteja no HTML bruto — ou chegue a ele muito rapidamente.

Depender de rotas baseadas em hash — #/product/123 — como única navegação. O WRS segue links <a href> reais; um fragmento hash que só altera o estado no cliente, sem uma URL equivalente renderizada no servidor, não oferece ao renderizador um caminho que possa ser rastreado. Faça o seguinte: use caminhos reais aos quais o servidor possa responder diretamente — /product/123 — mesmo em um aplicativo muito dependente do cliente.

Carregar conteúdo de forma lazy sem um caminho que dispense interação. Como o WRS “doesn’t scroll, click, or hover,” (tradução) «não rola, clica nem passa o mouse», conteúdo que só aparece após um desses eventos fica invisível para ele por padrão. Faça o seguinte: carregue sem exigir interação o conteúdo acima da dobra e razoavelmente próximo do viewport; reserve o lazy loading verdadeiro para conteúdo realmente abaixo da dobra e ofereça um fallback adequado sem JavaScript.

Tratar a renderização dinâmica como correção de longo prazo, e não como solução provisória. O Google afirma explicitamente que “dynamic rendering is a workaround and not a recommended solution, because it creates additional complexities and resource requirements” (tradução) «a renderização dinâmica é uma solução provisória e não recomendada, porque cria complexidades e exigências adicionais de recursos». Além disso, servir aos robôs conteúdo diferente do recebido pelos usuários chega muito perto de cloaking. Faça o seguinte: corrija o próprio modo de renderização — SSR, estática ou hidratação — em vez de criar uma camada de detecção de robôs ao redor de um problema de CSR.

Testes de validação

Verificações de aprovação ou reprovação para confirmar que uma correção de renderização entrou em vigor. Execute-as depois de publicar a mudança, não como métrica contínua de integridade.

Teste: o conteúdo agora aparece no DOM renderizado

• Teste a executar — Envie a URL à ferramenta Inspeção de URL do Google Search Console, use “Testar URL publicada” e abra a aba do HTML renderizado. Outra opção é executar a página na ferramenta Render Gap para comparar diretamente o HTML bruto e o renderizado.
• Resultado esperado — O conteúdo adicionado ou corrigido aparece na visualização do HTML/DOM renderizado, não apenas nas ferramentas de desenvolvimento do seu navegador.
• Interpretação da falha — Se ele ainda estiver ausente do HTML renderizado, mas aparecer na visualização normal da página, o WRS continua sem conseguir montá-lo. Antes de considerar a correção concluída, procure um recurso JavaScript/CSS bloqueado, carregamento que exige interação ou dependência do armazenamento do cliente.
• Janela de monitoramento — Imediata; o teste publicado da Inspeção de URL reflete de imediato o estado atual da URL.
• Gatilho de rollback — O HTML renderizado ainda não contém o conteúdo depois da correção, ou o teste publicado apresenta um novo erro de rastreamento/renderização que não ocorria antes.

Teste: links importantes sobrevivem à renderização

• Teste a executar — Verifique no HTML renderizado — Inspeção de URL ou Render Gap — se há tags <a href> reais em todos os links que uma pessoa precisa seguir, não apenas elementos visíveis e clicáveis.
• Resultado esperado — Cada link no DOM renderizado tem um href resolvível que aponta para uma URL real e rastreável.
• Interpretação da falha — Um href ausente ou vazio em algo que parece um link funcional costuma indicar um <div> ou <button> com manipulador de clique no cliente e sem caminho renderizável no servidor; o WRS não consegue segui-lo.
• Janela de monitoramento — Imediata.
• Gatilho de rollback — Links que eram importantes antes da mudança perderam o atributo href ou apontam apenas para um fragmento hash na saída renderizada.

Teste: a correção não regride silenciosamente no próximo deploy

• Teste a executar — Repita a verificação do HTML renderizado — teste publicado da Inspeção de URL ou Render Gap — depois do próximo deploy que alterar os templates ou o pipeline de build desta página.
• Resultado esperado — O mesmo conteúdo e os mesmos links continuam presentes no DOM renderizado, tal como na primeira confirmação da correção.
• Interpretação da falha — Se um conteúdo antes presente desaparecer novamente, uma mudança posterior provavelmente reintroduziu uma dependência exclusiva do cliente ou quebrou um caminho renderizado no servidor.
• Janela de monitoramento — Verifique novamente após cada deploy que alterar os templates afetados; não é um controle único.
• Gatilho de rollback — Conteúdo ou links cuja presença havia sido confirmada voltaram a sumir do DOM renderizado.

Recursos que valem seu tempo

Meus textos relacionados

• SEO para JavaScript: guia definitivo — meu guia completo sobre renderização, modos de renderização, paridade do DOM, rolagem infinita e o problema das duas páginas tratadas como uma.
• Guia de SEO técnico para iniciantes — onde a renderização se encaixa entre rastreamento e indexação.

Minhas palestras

• Como a busca funciona (SlideShare) — minha explicação de rastreamento, renderização — WRS, carregamentos sem estado e ausência de interação —, indexação e ranqueamento. Aplica-se meu aviso habitual: “This is my understanding of systems… not going to be 100% complete or accurate.” (tradução) «Este é meu entendimento dos sistemas… não será 100% completo nem preciso.»

De outras fontes

• web.dev — Renderização na web — explicação de referência da equipe do Chrome sobre as contrapartidas de CSR, SSR, SSG e hidratação.
• Onely — As duas ondas de indexação do Google — cobertura baseada na transcrição de uma sessão de Martin Splitt explicando por que o modelo das duas ondas está desaparecendo; citada no corpo do artigo.
• Search Engine Roundtable — Google: não há custo por página na busca — representante do Google esclarece que não existe custo por página de rastreamento, renderização e indexação a racionar.
• Search Engine Journal — SEO para JavaScript — cobertura do setor sobre práticas recomendadas de SEO para JavaScript, fluxos de teste e considerações sobre frameworks.
• Vercel — Estratégias de renderização — documentação sobre Next.js e renderização na edge; útil ao escolher entre CSR, SSR, SSG, ISR e SSR com streaming em um projeto real.
• r/TechSEO — comunidade para depurar problemas de renderização e indexação.

Vídeos

• Google Search Central (YouTube) — a série JavaScript SEO de Martin Splitt e os vídeos explicativos sobre renderização são as melhores apresentações oficiais em vídeo sobre como o Web Rendering Service processa seu JavaScript. Canal

Estatísticas que vale citar

• Enquadramento oficial atual: nenhum atraso fixo. A documentação do Google diz que uma página rastreada “may stay on this queue for a few seconds, but it can take longer than that” (tradução) «pode permanecer nessa fila por alguns segundos, mas pode levar mais tempo»; não existe atraso fixo ou timeout publicado para a fila de renderização.
• Dado histórico com data: mediana de aproximadamente 5 segundos para renderizar. Em declarações antigas de conferências, profissionais do Google — Martin Splitt e Tom Greenaway — disseram que as páginas chegavam ao renderizador em uma mediana de cerca de 5 segundos, com o 90º percentil em minutos, não nas “semanas” sugeridas pelo receio das duas ondas. Cito isso no meu guia de SEO para JavaScript, mas como dado histórico, não como métrica publicada atual: o Google não o republicou como valor contínuo.
• As duas ondas de indexação estão desaparecendo. Segundo Martin Splitt, o modelo desempenha um papel cada vez menor à medida que rastreamento, renderização e indexação convergem; hoje a renderização ocorre com praticamente todas as páginas. Cobertura
• Não existe orçamento de renderização por página. O Google indicou que não acompanha o custo de rastrear, renderizar, indexar ou veicular uma página individual; portanto, não há “orçamento de renderização” a economizar como ocorre nas discussões sobre crawl budget. Cobertura

Teste seus conhecimentos: renderização

Cinco perguntas rápidas sobre como o Google renderiza páginas. Escolha uma resposta para cada uma e depois confira o resultado.

Registro de alterações