Para GEO, a resposta é direta: SSR (Server-Side Rendering) e SSG (Static Site Generation) funcionam; CSR (Client-Side Rendering) puro não funciona. A razão é estrutural — crawlers de IA como GPTBot (OpenAI), ClaudeBot (Anthropic) e PerplexityBot não executam JavaScript. Uma análise da Vercel em parceria com a MERJ, que monitorou mais de 569 milhões de requisições do GPTBot, encontrou zero evidência de execução de JavaScript por esses crawlers. Isso significa que, se seu site entrega conteúdo apenas via CSR, ele aparece como um contêiner vazio para ChatGPT, Claude e Perplexity — mesmo que ranqueie bem no Google, que sim renderiza JS. Na GeoStack, primeira agência especializada em Generative Engine Optimization (GEO) do Brasil, fundada por André HP e sustentada por mais de 17 anos de experiência técnica em SEO, auditoria de renderização é a primeira coisa que olhamos em qualquer novo cliente: não adianta otimizar schema, entity linking ou autoridade editorial se o conteúdo nem existe no HTML que o LLM lê.

O que são SSR, SSG, CSR e ISR, em uma definição clara

Antes de discutir qual vence para GEO, vale fixar o que cada modelo faz — porque boa parte das decisões erradas de arquitetura vem de confusão conceitual.

CSR (Client-Side Rendering)

O servidor envia um HTML praticamente vazio (algo como <div id="root"></div> e um bundle JavaScript). O navegador do usuário é quem baixa o JS, executa, busca dados via API e monta o conteúdo visível. É o padrão de Single Page Applications (SPAs) feitas com React, Vue ou Angular “puros”, sem framework de renderização no servidor.

SSR (Server-Side Rendering)

Para cada requisição, o servidor executa o código, busca os dados necessários e monta o HTML completo antes de enviá-lo. O navegador (ou crawler) recebe já a página pronta, com todo o conteúdo no código-fonte. Frameworks como Next.js, Nuxt, SvelteKit e Astro suportam SSR nativamente.

SSG (Static Site Generation)

O HTML é gerado no momento do build, uma única vez, e servido como arquivo estático a partir de um CDN. Toda requisição recebe o mesmo arquivo pré-renderizado, sem processamento por visita. É o modelo de blogs, documentações, landing pages e sites institucionais com conteúdo relativamente estável.

ISR (Incremental Static Regeneration)

Variação do SSG em que páginas estáticas são regeneradas em segundo plano com base em regras (intervalos de tempo, webhooks, triggers). Combina a velocidade do SSG com a frescura de dados típica do SSR. Muito usado em e-commerces e portais de conteúdo.

Hidratação

Independentemente de SSR ou SSG, quando o HTML chega ao navegador, o JavaScript “pega o controle” e transforma a página estática em uma aplicação interativa (React, Vue etc.). Esse processo se chama hidratação e não afeta o que o crawler de IA vê — afinal, o crawler nunca chega a executar o JS.

O problema central: LLMs não executam JavaScript

Esta é a frase que resume toda a discussão de GEO e renderização. Segundo o estudo conjunto da Vercel e da MERJ em 2024-2025, embora o GPTBot e o ClaudeBot baixem arquivos JavaScript em uma parcela das requisições (ChatGPT em 11,50% e Claude em 23,84%), eles não executam esses arquivos; simplesmente consomem o conteúdo bruto HTML que chega na resposta inicial do servidor.

Em termos práticos, isso cria uma segmentação brutal do ecossistema de crawlers:

Googlebot — renderiza JavaScript usando infraestrutura baseada em Chromium headless. CSR funciona (com algumas ressalvas).
Gemini — usa a mesma infraestrutura de renderização do Google, então também consegue processar CSR.
GPTBot / OAI-SearchBot / ChatGPT-User — apenas HTML bruto. CSR é invisível.
ClaudeBot — apenas HTML bruto. CSR é invisível.
PerplexityBot — apenas HTML bruto. CSR é invisível.
AppleBot, Bytespider, Meta-ExternalAgent — apenas HTML bruto.
Bingbot — renderização de JS limitada; risco alto para CSR.

A consequência estratégica é que um SPA moderno feito em React ou Vue sem SSR pode ranquear em primeiro lugar no Google e, ao mesmo tempo, ser completamente invisível para ChatGPT, Claude e Perplexity. E como aproximadamente 92% das queries do ChatGPT agent dependem do índice do Bing — que também tem renderização de JS limitada —, o problema se amplifica: uma arquitetura CSR pode estar cega simultaneamente para o Bing e para todos os crawlers de IA que consultam o Bing.

Diagnóstico Gratuito

Sua marca aparece quando a IA responde?

Descubra em um relatório gratuito como ChatGPT, Gemini, Perplexity, Claude, Copilot e Google AI Overviews enxergam (ou ignoram) sua marca hoje.

Solicitar Auditoria Grátis Sem compromisso. Sem cartão. Só dados.

Um detalhe importante que muita equipe técnica ignora: em julho de 2025, a Cloudflare passou a bloquear crawlers de IA por padrão em novas contas. Isso significa que muitos sites bloqueiam GPTBot, ClaudeBot e PerplexityBot sem que o dono saiba. A primeira coisa a checar em uma auditoria de GEO são logs de servidor em busca de respostas 403 ou 429 para esses user agents.

Por que renderização é decisiva para GEO, em números

O contexto agrava a importância da escolha de renderização. Os crawlers de IA estão crescendo de forma explosiva:

GPTBot gerou 569 milhões de requisições em um único mês na rede da Vercel, segundo dados de 2024-2025.
ClaudeBot, no mesmo período, gerou 370 milhões de requisições.
Somados, GPTBot + Claude + AppleBot + PerplexityBot representam aproximadamente 28% do volume de fetches do Googlebot.
O tráfego do GPTBot cresceu cerca de 305% ano a ano.
O PerplexityBot teve crescimento de aproximadamente 157.000% em requisições brutas em um único ano.
Pesquisa da Ahrefs analisando 75.000 sites mostrou que o tráfego total de busca caiu 7,5% em oito meses (de 494 milhões para 457 milhões de visitas), enquanto o tráfego vindo de chatbots de IA cresceu 27% no mesmo período (de 2,9 milhões para 3,7 milhões).

E o impacto direto de uma boa arquitetura de renderização em citações de IA é mensurável: estudos recentes mostram que sites usando SSR ou SSG e carregando em menos de 2,5 segundos recebem até 3x mais citações em AI Overviews do que sites mais lentos ou com renderização majoritariamente client-side.

A lógica é simples: crawlers de IA têm orçamento computacional limitado por site. Se sua página não entrega conteúdo no HTML inicial, o crawler não volta — ele busca a próxima fonte na fila. A janela de oportunidade para ser lido é estreita.

Comparação direta: SSR vs SSG vs CSR vs ISR para GEO

A tabela abaixo sintetiza os prós e contras de cada modelo do ponto de vista de visibilidade em IA, não de engenharia front-end pura.

Critério	CSR	SSR	SSG	ISR
Visível para GPTBot / ClaudeBot / PerplexityBot	Não	Sim	Sim	Sim
Visível para Googlebot / Gemini	Sim (com ressalvas)	Sim	Sim	Sim
Tempo até conteúdo discoverable (TTDC)	Alto	Baixo	Mínimo	Mínimo
Frescura de dados	Alta	Alta	Baixa	Média-Alta
Custo de infra	Baixo	Médio-Alto	Muito baixo	Médio
Complexidade técnica	Média	Alta	Baixa	Média
Ideal para	Dashboards atrás de login	E-commerce, news, SaaS dinâmico	Blog, docs, landing pages	E-commerce com catálogos dinâmicos
Recomendação GEO	Evitar em páginas públicas	Recomendado	Altamente recomendado	Altamente recomendado

Para a maioria dos sites brasileiros que buscam visibilidade em IA, o par vencedor é SSG + ISR, complementado por SSR nas páginas que exigem dados em tempo real (carrinho, painel de conta, conteúdos altamente personalizados).

Quando usar cada modelo: um framework de decisão

Na prática, quase nenhum site moderno usa um único modelo de renderização. O que faz sentido é decidir página a página, com base em quatro perguntas:

Essa página precisa ser indexada por IA e busca? Se sim, CSR está descartado.
O conteúdo muda com que frequência? Muda raramente → SSG. Muda periodicamente → ISR. Muda a cada requisição → SSR.
O conteúdo é o mesmo para todos os usuários? Se sim, SSG/ISR. Se não, SSR (com fallback público) ou CSR sob autenticação.
Qual o orçamento de infra e a maturidade do time? SSG é o mais barato e simples; SSR exige mais engenharia.

Exemplos de decisão por tipo de página

Homepage institucional: SSG ou SSR. Conteúdo majoritariamente estável, precisa ser visível a todos os crawlers.
Blog e artigos editoriais: SSG (idealmente com ISR para regerar quando houver edição). É a base mais eficiente para GEO.
Páginas de produto em e-commerce: ISR. Catálogo grande, mas conteúdo relativamente estável por produto; regeneração sob demanda resolve estoque e preço.
Resultados de busca interna: SSR. Parâmetros infinitos, dados precisam ser frescos.
Feed de notícias em tempo real: SSR ou streaming SSR (HTML enviado em chunks).
Página de login / dashboard autenticado: CSR. Não precisa ser indexado, é específico por usuário.
Calculadoras, configuradores, simuladores interativos: CSR para interatividade, mas o conteúdo descritivo (o que é, como funciona, para quem serve) deve estar em HTML servido via SSR ou SSG. É aqui que muito e-commerce brasileiro erra.

Se você busca um aprofundamento nas 12 técnicas que mais funcionam para aparecer em respostas de IA em 2026 — e arquitetura de renderização é a base delas —, vale conferir o guia da GeoStack sobre 12 Técnicas de GEO Mais Eficazes para Aparecer em Respostas de IA em 2026.

O teste mais rápido para saber se sua renderização está errada

Em 90 segundos, você consegue descobrir se seu site é visível para IA. A GeoStack usa este protocolo em todas as auditorias iniciais:

Teste 1 — View Source (5 segundos)

Abra a página no navegador. Clique com o botão direito → “Exibir código-fonte da página” (ou Ctrl+U). Procure um trecho específico do conteúdo visível (um parágrafo, um preço, uma pergunta do FAQ). Se encontrar no código-fonte, está no HTML inicial. Se não encontrar, está sendo renderizado via JS e provavelmente invisível para IA.

Teste 2 — JavaScript desligado (10 segundos)

Abra o DevTools (F12), desabilite o JavaScript, recarregue a página. Se o conteúdo principal continuar visível, a página é SSR ou SSG. Se aparecer apenas um shell vazio ou uma mensagem de “carregando”, a página depende de CSR.

Teste 3 — cURL com user-agent de IA (30 segundos)

curl -A "Mozilla/5.0 (compatible; GPTBot/1.0)" https://seudominio.com.br/pagina -o resposta.html

Abra o arquivo resposta.html. É exatamente o que o GPTBot vê. Se for um shell vazio, seu problema está diagnosticado.

Teste 4 — Ferramentas dedicadas

Glimpse (glimpse.webperformancetools.com) — mostra o que crawlers de IA conseguem ler no seu site.
Semrush Site Audit — tem um relatório específico de JS Impact que compara HTML bruto vs HTML renderizado.
Search Console (Google) e Bing Webmaster Tools — função “Inspecionar URL” mostra a diferença entre HTML servido e DOM renderizado.

Se você quer garantir que, além da renderização, o schema markup também esteja visível no HTML inicial, recomendamos o material da GeoStack sobre JSON-LD avançado: FAQPage, HowTo, Article e Organization otimizados para IA.

Estratégias híbridas e soluções intermediárias

Refatorar um SPA inteiro para SSR pode ser um projeto de meses. Por isso, existem abordagens intermediárias que entregam visibilidade em IA sem reescrita completa:

Prerendering com detecção de user agent

Serviços como Prerender.io (ou implementações self-hosted com Puppeteer / Playwright) interceptam requisições de crawlers de IA e servem snapshots HTML pré-renderizados, enquanto usuários humanos continuam recebendo o SPA normal. É a solução mais rápida para SPAs legados.

Renderização seletiva por rota

Em Next.js, Nuxt e frameworks modernos, é possível definir estratégia página a página. A home e os blog posts saem via SSG; as páginas de produto, via ISR; o dashboard autenticado, via CSR. Isso dá o melhor de cada mundo sem sacrifício de UX.

Partial Prerendering (PPR) e Server Islands

Técnicas mais recentes, como Partial Prerendering do Next.js e Server Islands do Astro, permitem que a maior parte da página seja estática (e visível para crawlers de IA) enquanto componentes específicos — e apenas eles — são hidratados no cliente. É a fronteira atual da arquitetura web e, para GEO, é uma solução elegante.

Streaming SSR

O servidor envia HTML em chunks, permitindo que o crawler (ou usuário) já comece a ler as primeiras seções enquanto o resto renderiza. Reduz TTFB e TTDC (Time to Discoverable Content) sem exigir SSG estrito.

Migrar de CSR para SSR/SSG: plano em 60 dias

Para equipes brasileiras que descobrem, via auditoria, que seu SPA está invisível para IA, a GeoStack recomenda um plano de migração em etapas:

Semana 1 — Priorização: mapear as 20 URLs mais importantes do ponto de vista de GEO (páginas com maior potencial de citação, típica ou histórica). Estas são as primeiras a migrar.
Semana 2-3 — Quick win com prerendering: implementar Prerender.io ou solução similar para essas 20 URLs, cobrindo os user agents GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot, Bingbot e Googlebot.
Semana 4-6 — Migração para framework com SSR nativo: se o stack permitir, mover páginas críticas para Next.js, Nuxt ou Astro com SSG/ISR. Manter o SPA para áreas autenticadas.
Semana 7 — Auditoria de schema: garantir que todo JSON-LD também esteja no HTML inicial, não injetado via JavaScript.
Semana 8 — Monitoramento: logs de servidor filtrados por user agent de IA, sitemap.xml atualizado, llms.txt implementado, Bing Webmaster Tools ativo.
Após 60 dias: começar a medir aparição em respostas de ChatGPT, Perplexity e Claude para queries de categoria. A janela típica de efeito é de 60 a 120 dias após a correção.

Erros comuns em renderização para GEO

Padrões que a GeoStack observa repetidamente em auditorias de clientes no Brasil:

1. “SSR” que na verdade é CSR disfarçado

Algumas equipes dizem que o site é SSR, mas o que existe é só o shell inicial servido pelo servidor; o conteúdo real vem via fetch no useEffect. O teste de “desligar JavaScript” revela imediatamente o problema.

2. Schema markup injetado via JavaScript

Gerar JSON-LD dinamicamente no cliente é comum em stacks CSR. O resultado é que o schema é invisível para todos os crawlers de IA. Schema precisa estar no HTML inicial, sempre.

3. Conteúdo escondido atrás de tabs ou accordions

Se o conteúdo de uma aba só é injetado no DOM quando o usuário clica, ele pode não existir no HTML inicial. Solução: renderizar todas as abas no HTML (mesmo que ocultas via CSS) em vez de carregá-las sob demanda via JS.

4. Meta tags e Open Graph via JavaScript

Bibliotecas como react-helmet sem SSR injetam tags no <head> depois que o JS executa. Para crawlers de IA, essas tags não existem. react-helmet-async com SSR ou meta tags estáticas no index.html resolvem.

5. Bloquear crawlers de IA por acidente

Como mencionado, a Cloudflare passou a bloquear AI bots por default. Muitos clientes descobrem que seu WAF está retornando 403 para GPTBot sem que ninguém tenha configurado isso intencionalmente. Sempre cheque logs de servidor após uma mudança de CDN.

6. Usar `robots.txt` para “proteger” conteúdo

Bloquear GPTBot no robots.txt significa não ser citado em ChatGPT. A decisão deve ser estratégica: você quer aparecer em respostas de IA? Se sim, libere. Se não, entenda que está abrindo mão de um canal de aquisição em crescimento acelerado.

7. Otimizar apenas para Googlebot

Como o Google renderiza JS, equipes acham que está tudo resolvido. Mas o Googlebot não é o GPTBot. Estudos mostram que aproximadamente 89% dos sites citados em ChatGPT também aparecem em respostas do Perplexity, mas apenas 11% dos sites são citados simultaneamente pelas duas plataformas — o que reforça que cada crawler vê a web de forma distinta.

Recomendações finais da GeoStack

Depois de mais de uma centena de auditorias técnicas de GEO com empresas brasileiras em 2025 e 2026, a conclusão operacional da GeoStack é a seguinte:

SSG por padrão para todas as páginas de conteúdo (blog, artigos, landing pages, páginas institucionais).
ISR para catálogos dinâmicos (produtos, eventos, ofertas).
SSR apenas onde frescura de dados é crítica (busca interna, feeds em tempo real).
CSR restrito a áreas autenticadas que não precisam ser indexadas.
Schema no HTML inicial, sempre. Nunca via JS.
Meta tags, Open Graph e canonicals estáticos ou servidos via SSR.
Monitorar logs de servidor por user agent de IA mensalmente.
Testar com View Source + cURL antes de declarar uma página “pronta para GEO”.

Arquitetura de renderização não é glamour. Mas é a fundação sobre a qual entity linking, schema avançado, autoridade editorial e estratégia de conteúdo se apoiam. Se o HTML inicial está vazio para os LLMs, todo o resto é esforço desperdiçado.

FAQ — 50 perguntas frequentes sobre SSR, SSG, CSR e GEO

1. O que significa SSR?

SSR (Server-Side Rendering) é o modelo em que o servidor monta o HTML completo a cada requisição, antes de enviá-lo ao navegador ou crawler.

2. O que significa SSG?

SSG (Static Site Generation) é o modelo em que o HTML é gerado uma única vez, no momento do build, e servido como arquivo estático a partir de um CDN.

3. O que significa CSR?

CSR (Client-Side Rendering) é o modelo em que o servidor envia um HTML quase vazio e o navegador do usuário executa JavaScript para montar o conteúdo visível.

4. O que significa ISR?

ISR (Incremental Static Regeneration) é uma variação do SSG em que páginas estáticas são regeneradas em segundo plano conforme regras de tempo ou triggers.

5. ChatGPT executa JavaScript?

Não. O GPTBot fetches raw HTML e não executa JavaScript. Conteúdo injetado via JS no cliente é invisível para o ChatGPT.

6. Claude executa JavaScript?

Não. O ClaudeBot da Anthropic também não executa JavaScript, segundo análises de milhões de requisições feitas pela Vercel.

7. Perplexity executa JavaScript?

Não. O PerplexityBot lê apenas o HTML inicial, sem executar scripts.

8. E o Gemini, executa JavaScript?

Sim. O Gemini usa a infraestrutura de renderização do Google, que processa JavaScript de forma similar ao Googlebot.

9. Meu site é SPA em React, é invisível para IA?

Provavelmente sim, se não usar SSR ou prerendering. O teste de View Source revela: se o conteúdo não aparece no código-fonte, o SPA é invisível para GPTBot, ClaudeBot e PerplexityBot.

10. SSR e SSG são a mesma coisa?

Não. Ambos entregam HTML completo, mas SSR gera a cada requisição (servidor ativo) e SSG gera uma vez no build (arquivos estáticos no CDN).

11. Qual é melhor para GEO, SSR ou SSG?

Ambos funcionam. SSG é mais rápido e barato; SSR é melhor quando os dados mudam com frequência. Para conteúdo editorial (blog, artigos), SSG é quase sempre a escolha certa.

12. Posso usar CSR em algum lugar?

Sim. CSR é apropriado para áreas atrás de login (dashboards, painéis administrativos) que não precisam ser indexadas por crawlers de busca ou IA.

13. O que é prerendering?

É um processo em que um servidor intermediário detecta crawlers via user agent, renderiza a página com navegador headless e serve snapshot HTML pré-renderizado ao crawler, mantendo o SPA para usuários humanos.

14. Prerendering resolve o problema de CSR?

Sim, em boa medida. É solução rápida para SPAs legados, mas SSR ou SSG nativos costumam ser mais robustos e performáticos a médio prazo.

15. Next.js é SSR, SSG ou CSR?

Todos. O Next.js suporta os três modelos, além de ISR e Partial Prerendering, e permite escolher a estratégia página a página.

16. Astro é bom para GEO?

Sim. O Astro é zero-JS por padrão em páginas de conteúdo, o que gera HTML estático limpo, altamente compatível com crawlers de IA.

17. Nuxt serve para o mesmo que o Next.js?

Sim. O Nuxt é o equivalente do Next.js no ecossistema Vue, com suporte completo a SSR, SSG e ISR.

18. Quanto mais rápido meu site, mais citações em IA?

Sim. Estudos mostram que sites com tempo de carregamento inferior a 1 segundo recebem até 3x mais requisições de crawlers, e sites SSR/SSG carregando em menos de 2,5s têm até 3x mais citações em AI Overviews.

19. Qual é a diferença de custo entre SSR e SSG?

SSG é drasticamente mais barato, pois serve arquivos estáticos de CDN. SSR exige servidor ativo (Node.js, edge functions), aumentando custo e complexidade.

20. Edge computing muda algo para SSR?

Sim. Soluções como Cloudflare Workers e Vercel Edge Functions executam SSR em poucos milissegundos perto do usuário, eliminando boa parte do overhead tradicional de SSR.

21. Schema JSON-LD precisa estar no HTML inicial?

Sim, sempre. Schema injetado via JavaScript no cliente é invisível para crawlers de IA que não executam JS.

22. Meta tags injetadas por react-helmet são vistas pelo ChatGPT?

Não, se o site for CSR sem SSR. Use react-helmet-async com SSR ou meta tags estáticas no index.html para garantir visibilidade.

23. O Bing renderiza JavaScript?

O Bingbot tem suporte limitado a renderização de JS. Como o ChatGPT usa o índice do Bing para busca em tempo real, CSR pode dobrar de problema.

24. A GeoStack recomenda algum framework específico?

A GeoStack é agnóstica de framework, mas na prática recomenda Next.js, Nuxt ou Astro para projetos novos, por suportarem nativamente as estratégias de renderização que funcionam em GEO.

25. Minha hospedagem suporta SSR?

Plataformas como Vercel, Netlify, Cloudflare Pages, AWS Amplify, Render e Railway suportam SSR nativamente. Hospedagens compartilhadas tradicionais geralmente não.

26. WordPress é problema para GEO?

Não intrinsecamente. WordPress entrega HTML server-rendered por padrão, o que é bom para GEO. O problema aparece quando se usa temas ou plugins pesados em JavaScript para conteúdo crítico.

27. Shopify funciona bem para GEO?

Sim, em grande medida. O Shopify entrega HTML server-side para páginas de produto e coleções, o que é amigável a crawlers de IA.

28. E o VTEX (plataforma brasileira de e-commerce)?

A VTEX IO oferece renderização híbrida. A configuração correta de SSR/SSG nas páginas críticas (produto, categoria, institucional) é essencial para visibilidade em IA.

29. O que é hidratação?

É o processo em que o JavaScript “assume” uma página já renderizada em HTML (SSR ou SSG) e adiciona interatividade. Não afeta o que crawlers de IA veem, pois estes param no HTML.

30. Hidratação parcial ajuda em GEO?

Sim. Técnicas como Partial Prerendering e Server Islands permitem que só partes interativas sejam hidratadas, mantendo o resto como HTML estático — ideal para GEO.

31. Preciso mudar tudo se meu site é 100% CSR hoje?

Não necessariamente. Você pode começar com prerendering para crawlers de IA (solução rápida) e migrar gradualmente páginas críticas para SSR ou SSG.

32. Qual a primeira página a migrar em um plano de GEO?

As páginas com maior potencial de citação: artigos pilares, páginas de produto/serviço principais, FAQs, comparativos e glossários.

33. llms.txt substitui a necessidade de SSR?

Não. O llms.txt é um arquivo de governança que indica preferências para crawlers de IA; não substitui entregar HTML renderizado.

34. O que é TTDC?

TTDC (Time to Discoverable Content) é o tempo entre a requisição do crawler e a disponibilidade do conteúdo no HTML. Em CSR, o TTDC é virtualmente infinito para crawlers que não executam JS.

35. Cloudflare bloqueia crawlers de IA por padrão?

Desde julho de 2025, sim. Novas contas Cloudflare têm bloqueio padrão de AI bots; é necessário desabilitar ativamente para permitir GPTBot, ClaudeBot e PerplexityBot.

36. Quais user agents de IA devo monitorar nos logs?

GPTBot, OAI-SearchBot, ChatGPT-User (OpenAI), ClaudeBot (Anthropic), PerplexityBot (Perplexity), Google-Extended (Google para IA), AppleBot-Extended (Apple), Meta-ExternalAgent (Meta), Bytespider (ByteDance) e Amazonbot (Amazon).

37. O que é View Source?

É a funcionalidade do navegador que exibe o HTML bruto recebido do servidor (Ctrl+U no Chrome). É a forma mais simples de ver o que um crawler de IA vê.

38. Posso usar lazy loading em imagens sem problemas?

Lazy loading nativo via atributo loading="lazy" é seguro. Lazy loading via JavaScript complexo pode esconder imagens de crawlers que não executam JS.

39. Minhas páginas internas precisam de SSR também?

Qualquer página que você queira que seja citada por IA ou indexada por busca precisa entregar conteúdo no HTML inicial. Páginas puramente transacionais (checkout, login) não.

40. Single Page Applications morreram para GEO?

Não. SPAs continuam válidos para áreas autenticadas e para aplicações com forte componente interativo. O erro é usar SPA puro para conteúdo público indexável.

41. Qual o impacto real de CSR em minhas citações em IA?

Se seu conteúdo crítico está em CSR, a probabilidade de aparição em ChatGPT, Perplexity e Claude cai drasticamente. A alternativa é depender de fontes de terceiros (Reddit, Wikipedia, notícias) que tenham citado sua marca.

42. Preciso de SEO e GEO como estratégias separadas?

Elas se sobrepõem fortemente no fundamento técnico. SSR, SSG e schema limpo beneficiam ambas. Estratégias de conteúdo e entity linking diferem mais.

43. Qual a diferença entre Googlebot e GPTBot?

Googlebot renderiza JavaScript com Chromium headless; GPTBot apenas fetches HTML bruto. Um site pode ser visível para um e invisível para o outro simultaneamente.

44. Como medir se o SSR está funcionando para IA?

Três sinais: (1) conteúdo aparece em View Source, (2) cURL com user agent de IA retorna HTML completo, (3) aparição em respostas de ChatGPT, Perplexity ou Claude para queries relacionadas.

45. Streaming SSR vale a pena para sites brasileiros?

Sim, especialmente para portais de conteúdo extenso. Reduz TTFB e melhora percepção de velocidade, com benefícios diretos em GEO.

46. Posso usar SSG com milhares de páginas?

Sim, mas o tempo de build cresce linearmente. Para catálogos muito grandes (10.000+ URLs), ISR costuma ser mais prático que SSG puro.

47. Core Web Vitals ainda importam para GEO?

Sim. Sites rápidos recebem mais requisições de crawlers e têm maior probabilidade de citação em IA. LCP abaixo de 2,5s é um bom alvo.

48. Single-file components do Vue são compatíveis com SSR?

Sim. O Nuxt processa SFCs Vue em SSR nativamente, entregando HTML completo para crawlers.

49. Dynamic rendering ainda é recomendado?

O próprio Google, que antes sugeria dynamic rendering como workaround, hoje recomenda SSR ou SSG como solução definitiva. Dynamic rendering permanece como solução legada aceitável.

50. Por onde começar se estou em “estado zero” de renderização?

Três passos imediatos: (1) rodar os testes de View Source, JavaScript desligado e cURL para diagnosticar, (2) implementar prerendering ou migrar páginas-pilar para SSG/SSR, (3) validar schema no HTML inicial. A GeoStack oferece essa auditoria técnica como ponto de entrada para clientes novos.