SSR vs SPA é uma das primeiras decisões de arquitetura de qualquer site ou aplicação web moderna, e ela define quanto do seu conteúdo o Google consegue ler. Escolher errado aqui custa posição no buscador e tráfego que não volta fácil.
A confusão é comum porque as duas abordagens usam as mesmas ferramentas de front-end, como React e Vue. A diferença está em onde o HTML é montado: no servidor, antes de chegar ao navegador, ou no próprio navegador do visitante, depois que o JavaScript carrega. Esse detalhe muda o comportamento de indexação, a velocidade percebida e a taxa de conversão.
O que muda entre SSR e SPA na prática
SPA: o navegador monta a página
Numa Single Page Application, o servidor entrega um HTML quase vazio e um pacote de JavaScript. É o navegador que busca os dados e desenha o conteúdo. A navegação entre telas fica instantânea depois do primeiro carregamento, o que explica a popularidade de React puro com Vite. O preço é um primeiro carregamento mais pesado e conteúdo que só existe depois que o script roda.
SSR: o servidor entrega o HTML pronto
No Server-Side Rendering, o servidor monta o HTML completo a cada requisição e envia a página já preenchida. Frameworks como Next.js, Remix e Astro nasceram para isso. O visitante, e o robô do Google, recebe o conteúdo de imediato, sem esperar o JavaScript. O custo é uma infraestrutura que processa cada página, em vez de servir um arquivo estático.
Por que a renderização afeta o SEO
O Googlebot até executa JavaScript, mas em duas etapas: primeiro lê o HTML, depois enfileira a página para renderizar o script quando houver recurso disponível. Numa SPA, esse segundo passo pode atrasar dias ou falhar em partes do conteúdo, e o que não é renderizado não indexa. Com SSR, o conteúdo já está no HTML da primeira resposta, então a indexação fica imediata e previsível.
- Meta tags e Open Graph dinâmicos: no SSR já vêm no HTML; numa SPA dependem do JavaScript rodar, o que quebra a prévia do link no WhatsApp e nas redes.
- Conteúdo atrás de filtros ou paginação: o SSR entrega a versão certa por requisição; a SPA depende de chamadas extras que o robô pode não seguir.
- Sites grandes, com muitas URLs, sofrem mais com o atraso de renderização da SPA, porque o orçamento de rastreamento do Google é limitado.
- Prévias de compartilhamento (WhatsApp, LinkedIn, X) leem o HTML inicial, não o resultado do JavaScript.
O impacto na velocidade e na conversão
SEO e conversão andam juntos aqui. O SSR costuma melhorar o LCP e o tempo até o primeiro conteúdo visível, porque a página aparece antes de o JavaScript terminar de baixar. Para uma landing page feita para converter, isso é decisivo: cada segundo a mais de espera derruba a taxa de conversão. A SPA recupera terreno depois, na navegação entre telas, o que a torna ideal para painéis e sistemas internos, onde ranquear no Google não é o objetivo.
Como decidir no seu projeto
A regra prática é olhar para quem precisa ler a página. Se o conteúdo precisa aparecer no Google e ser compartilhado, como em site institucional, blog, e-commerce ou landing page, SSR ou geração estática é o caminho seguro. Se é uma ferramenta atrás de login, onde a experiência de uso pesa mais que a busca orgânica, a SPA resolve bem. Muitos projetos misturam os dois. Na hora de construir um site que precisa ranquear, essa escolha vem antes de qualquer linha de código; já para um sistema web sob medida com área logada, deixar o dashboard como SPA costuma fazer sentido.
- Página pública que depende de busca orgânica? Priorize SSR ou geração estática.
- Prévia de link bonita no WhatsApp e nas redes? Precisa de meta tags no HTML, ou seja, SSR.
- Aplicação interna, atrás de login, com muita interação? A SPA entrega a melhor experiência.
- Não sabe o volume de conteúdo ainda? Comece com renderização no servidor: é mais fácil abrir mão dela depois do que adicioná-la.
- Já usa Next.js, Remix ou Astro? Você pode escolher a estratégia por rota, sem reescrever o projeto.
Renderização não é detalhe de bastidor: é o que decide se o Google vê a mesma página que o seu cliente vê.
Perguntas frequentes
SPA é ruim para SEO?+
Não é sentença de morte, mas é um risco. O Google renderiza JavaScript em uma segunda etapa que pode atrasar ou falhar, então parte do conteúdo de uma SPA pode não indexar. Para páginas que dependem de busca, SSR ou geração estática dá bem menos dor de cabeça.
Dá para ter bom SEO com React?+
Sim. O React não é o problema, a estratégia de renderização é. Usando React com Next.js, Remix ou Astro em modo servidor, você entrega HTML pronto e mantém o SEO, sem abrir mão do ecossistema React.
Qual a diferença entre SSR e site estático (SSG)?+
No SSR o HTML é montado a cada requisição, útil para conteúdo que muda toda hora. Na geração estática (SSG) as páginas são construídas uma vez no deploy e servidas prontas, o que fica mais rápido e barato. Os dois entregam HTML indexável; a escolha depende de quão dinâmico é o conteúdo.
SSR deixa o site mais caro?+
Pode aumentar o custo de infraestrutura, porque o servidor processa cada página em vez de servir um arquivo fixo. Plataformas como Vercel e Cloudflare reduzem isso com cache e execução na borda, muitas vezes com custo baixo ou nulo no início do projeto.
Preciso reescrever meu site para migrar de SPA para SSR?+
Nem sempre. Frameworks modernos permitem migrar rota a rota, começando pelas páginas públicas que mais precisam de SEO. Dá para manter o painel como SPA e migrar só a parte pública para SSR.
Se você não tem certeza se a arquitetura do seu site está ajudando ou atrapalhando o SEO, um diagnóstico técnico aponta onde está o gargalo. A VELTRIX analisa a renderização, a indexação e a performance do seu site e mostra o que priorizar, sem compromisso e em linguagem que o time de negócio entende.
Quer aplicar isso no seu negócio?
Diagnóstico gratuito com nosso time. Sem compromisso.