SEO para aplicativos de página única: por que eles somem do Google

O SEO para aplicativos de página única (single page apps) quebra por um único motivo: os mecanismos de busca muitas vezes enxergam uma página em branco onde seus usuários veem um aplicativo interativo completo. Seu SPA carrega rápido e parece um software, mas ainda assim pode desaparecer do Google, porque o Googlebot nunca recebe o conteúdo de que precisa para indexar. Corrija as falhas de renderização, de roteamento e de metadados, e o mesmo aplicativo pode ranquear.

O que é um aplicativo de página única

Um aplicativo de página única (single-page application, ou SPA) carrega um único arquivo HTML e constrói o resto da experiência com JavaScript. Em vez de pedir uma página nova ao servidor a cada clique em um link, o navegador troca o conteúdo dentro da mesma página, sem recarregar e sem esperar pela rede.

Esse é o atrativo, e também a raiz de todos os problemas de SEO deste artigo.

Como os SPAs diferem de um site tradicional

Um site tradicional de várias páginas envia um documento HTML novo e completo para cada URL. O servidor faz o trabalho e o navegador exibe o resultado, então um rastreador que lê esse HTML vê o mesmo conteúdo que um visitante humano.

Um SPA inverte isso. O servidor envia um shell HTML quase vazio, mais um pacote de JavaScript, e o navegador executa esse código para buscar dados, montar a página e inserir o conteúdo no DOM. Um rastreador que para no HTML bruto encontra uma tag de script e um contêiner vazio.

A maioria dos SPAs é construída com React ou Angular, e o Vue também é comum. Eles diferem em sintaxe e ferramentas, mas compartilham a mesma troca: velocidade e interatividade de aplicativo em troca de um caminho mais difícil até a visibilidade na busca.

Exemplos comuns que você já usa

Você usa aplicativos de página única o tempo todo, muitas vezes sem perceber:

• O Gmail e o Google Maps atualizam o conteúdo no mesmo lugar conforme você rola, arrasta ou dá zoom.
• O Trello e o Asana atualizam cartões e quadros na hora, sem recarregar a página.
• O player web do Spotify mantém a navegação e a reprodução em uma única página contínua.
• A busca e os filtros do Airbnb atualizam os resultados conforme você ajusta os filtros, sem carregar uma nova página.

Esses produtos funcionam como SPAs porque o retorno instantâneo melhora a experiência; um quadro do Trello que recarregasse a cada arrastar e soltar pareceria quebrado. Nenhum deles depende principalmente de tráfego orgânico para páginas novas, como dependem um site de conteúdo, um blog ou um catálogo de e-commerce, e muitas equipes só entendem essa diferença depois de escolher essa arquitetura para um site de marketing.

Por que aplicativos de página única somem dos resultados de busca do Google

As páginas somem do Google por um de três motivos que se sobrepõem: o rastreador não consegue ver o conteúdo, o conteúdo não está em uma URL rastreável, ou o Google indexa a página, mas a trata como conteúdo raso ou duplicado. Os SPAs são propensos aos três ao mesmo tempo.

O problema do rastreamento

O Googlebot solicita uma página em dois estágios. Primeiro ele busca o HTML bruto, que em um SPA é basicamente um <div id="root"></div> e um punhado de tags <script>. Depois ele precisa analisar, compilar e executar o JavaScript antes de enxergar o seu conteúdo de fato.

O segundo estágio não acontece de imediato. O Google coloca a renderização de JavaScript em uma fila separada do rastreamento inicial, e o intervalo pode ir de segundos a vários dias, dependendo do orçamento de rastreamento (crawl budget) e do tempo de resposta do servidor do seu site. O Google Search Central documenta esse processo em duas ondas: o Google rastreia o HTML, coloca a página na fila de renderização e depois rastreia de novo o resultado renderizado quando os recursos permitem. Se o seu pipeline de gerenciamento de conteúdo, o sitemap ou os links internos não se sustentarem durante esse intervalo, a página pode ser marcada como conteúdo raso, ser ignorada ou nunca entrar na fila para a segunda passagem. Nosso guia sobre como a indexação em mecanismos de busca realmente funciona e por que páginas são ignoradas explica o processo de duas etapas com mais detalhes.

O problema do orçamento de renderização

Renderizar JavaScript custa muito mais do que ler HTML estático. O Google precisa iniciar um ambiente semelhante a um navegador, baixar todos os scripts e dependências, executar o código e esperar as chamadas assíncronas de dados serem resolvidas antes de ter a página completa. Em um site com milhares de URLs, você pede ao Google que gaste muito mais capacidade de processamento do que um concorrente em HTML estático exige.

A infraestrutura de rastreamento do Google agora roda em um mecanismo de renderização evergreen que acompanha o Chromium moderno, então ela consegue executar a maior parte do JavaScript atual. Isso é um avanço real em relação a alguns anos atrás, mas "consegue renderizar" é diferente de "vai renderizar rápido, sempre, para todas as páginas". Sites com muitas páginas ou com sinais de rastreamento fracos podem ter pedidos de renderização despriorizados, o que aparece como páginas paradas em "Descoberto: no momento não indexado" ("Discovered, currently not indexed") no Search Console por semanas.

O problema da URL: uma página, várias visualizações

O problema estrutural mais profundo é que um SPA clássico tem exatamente uma URL. Você clica em dez páginas de produto e a barra de endereço pode continuar igual ou apenas acrescentar um fragmento como #/product/42. Para um rastreador, um fragmento depois de um # historicamente significa "mesma página, outra posição de rolagem", e não um novo documento que valha a pena indexar.

Assim, o Google pode ver uma única URL para todo o seu catálogo, blog ou aplicativo, por mais páginas distintas que uma pessoa consiga acessar. Uma URL significa uma entrada no índice, uma tag de título, uma meta descrição e uma chance de ranquear para uma única consulta. Todo o resto fica invisível.

Um aplicativo de página única é bom para SEO?

Sim, mas só com engenharia deliberada. Um SPA renderizado no cliente e sem modificações é ruim para SEO por padrão. O mesmo framework com renderização no servidor, URLs reais para cada visualização e metadados por visualização pode ranquear tão bem quanto um site tradicional. Ou seja, o problema é a configuração padrão, e a arquitetura em si está certa.

A finalidade da página também importa. Algumas telas de recursos dentro de um painel com login não precisam ranquear, já que ninguém pesquisa pela sua tela de faturas. Um blog público, um catálogo de produtos ou um site de marketing construído como um SPA puro precisa ranquear, e é aí que acontece a maior parte do estrago.

Arquitetura	SEO de fábrica	Caso de uso típico	Principal troca
SPA (renderizado no cliente)	Fraco: URL única, HTML inicial vazio	Painéis, ferramentas internas, aplicativos com login	Interações mais rápidas no aplicativo, mais difícil de rastrear
MPA (várias páginas, renderizado no servidor)	Forte por padrão	Blogs, sites de notícias, catálogos de e-commerce	Simples de rastrear, mas recarregamentos completos parecem mais lentos
SPA com SSR/SSG (híbrido)	Forte, com trabalho de configuração	Sites de marketing, SaaS, lojas que precisam de UX de aplicativo e tráfego de busca	O melhor dos dois mundos, mas aumenta a complexidade de build e de infraestrutura
PWA (aplicativo web progressivo)	Forte quando construído sobre SSR/SSG	Produtos mobile-first que querem suporte offline e capacidade de ranquear	Instalável e com suporte offline, mas ainda exige trabalho de renderização para os rastreadores

Se o seu site precisa de tráfego orgânico e de uma sensação de aplicativo, a resposta realista é um modelo híbrido: SSR ou geração estática por baixo de um framework de SPA.

A troca pela velocidade: por que as equipes escolhem SPAs mesmo assim

As equipes não escolhem a arquitetura SPA por acaso. Escolhem porque velocidade e responsividade movimentam a receita. Depois que o pacote inicial carrega, a navegação parece instantânea porque cada clique evita a ida e volta ao servidor, e o tempo de carregamento tem um efeito bem documentado sobre a conversão.

A Amazon já afirmou que um segundo a mais de atraso no carregamento da página pode custar cerca de 1% das vendas, valor estimado em aproximadamente US$ 1,6 bilhão por ano na escala da Amazon. Benchmarks mais recentes contam uma história parecida. A pesquisa de 2025 da Queue-it concluiu que reduzir o tempo de carregamento em um segundo pode aumentar as taxas de conversão do e-commerce em cerca de 5,6%, e um benchmark da Portent concluiu que cada segundo adicional de carregamento entre zero e cinco segundos pode reduzir as taxas de conversão em cerca de 4,42%. A pesquisa "Milliseconds Make Millions", do Google e da Deloitte, concluiu que cortar 0,1 segundo do tempo de carregamento no celular pode gerar um aumento de até 10% na conversão. Os dados de 2025 da BrowserStack indicam que cerca de 40% dos visitantes abandonam um site que leva mais de três segundos para carregar.

Esse é o argumento de negócio a favor da interatividade no estilo SPA, e é por isso que abrir mão da visibilidade na busca orgânica para obtê-la é uma troca tão cara. Você pode ter velocidade e SEO juntos se projetar a arquitetura para os dois, e é isso que as próximas seções abordam.

Como o Google rastreia e renderiza JavaScript hoje

A capacidade do Google de processar JavaScript melhorou bastante nos últimos anos, mas melhorar não significa igualar o HTML estático. Entender a mecânica mostra onde o seu SPA tem mais chance de perder visibilidade.

Indexação em duas ondas na prática

Pense nisso como duas passagens. Na primeira onda, o Googlebot busca o seu HTML e extrai os links, o texto e os metadados presentes sem JavaScript. Na segunda onda, que roda em um cronograma separado, o Google renderiza a página em um navegador headless e extrai o conteúdo de novo, incluindo tudo o que o JavaScript inseriu.

Se o seu conteúdo só existe depois da segunda onda, você depende da fila de renderização do Google, que disputa recursos com todos os outros sites da web com muito JavaScript. Um estudo da Vercel e da empresa de SEO técnico MERJ, que analisou mais de 100.000 requisições do Googlebot, concluiu que o Google em geral renderiza com sucesso o conteúdo em JavaScript, mas com atrasos significativos e lacunas ocasionais, dependendo de como o script é carregado e da complexidade do caminho de renderização.

Renderizar custa processamento de verdade, o seu e o do Google

Cada página renderizada com JavaScript custa mais recursos de servidor e de rastreador do que uma página em HTML estático. Para um SPA, isso tem duas consequências:

1. O Google pode rastrear seu site com menos frequência do que um site estático comparável, porque cada rastreamento custa mais para processar.
2. Seus próprios servidores e APIs recebem mais carga se você busca dados no cliente a cada requisição, inclusive as de bots.

Nenhuma das duas é fatal sozinha. Em um site grande, as duas se combinam e reduzem a rapidez com que páginas novas ou atualizadas são descobertas e reindexadas. Para uma visão mais aprofundada de por que isso importa no site inteiro e de como a eficiência do rastreamento se liga aos rankings, veja nossa análise sobre a importância do SEO técnico.

O que isso significa para o seu orçamento de rastreamento

Sites com milhares de URLs renderizadas no cliente são os que mais correm o risco de ter páginas paradas sem indexação. Um site de marketing de dez páginas construído como SPA provavelmente será renderizado e indexado por completo, porque o Google tem orçamento de sobra. Um catálogo de e-commerce de 5.000 páginas construído da mesma forma é uma aposta bem mais arriscada, já que a fila de renderização se acumula.

Corrigindo o SEO de SPAs: comparação das estratégias de renderização

Esta é a parte que de fato corrige o SEO de aplicativos de página única. Todas as soluções abaixo partem da mesma ideia: colocar HTML real e legível diante do rastreador já na primeira requisição, em vez de depois que o JavaScript é executado.

Estratégia de renderização	O que acontece	Rastreabilidade	Melhor para
Renderização no cliente (CSR)	O navegador constrói a página inteira a partir do JS depois do carregamento	Mais fraca: o conteúdo pode ser perdido ou atrasado	Ferramentas com login, painéis que não precisam ranquear
Renderização no servidor (SSR)	O servidor renderiza o HTML completo a cada requisição e depois faz a hidratação com JS	Forte: o rastreador recebe o HTML completo imediatamente	Páginas com conteúdo que muda com frequência ou é personalizado
Geração de site estático (SSG)	O HTML é pré-construído no momento do deploy para cada rota	Mais forte: HTML rápido e completo sempre	Blogs, páginas de marketing, documentação, conteúdo que muda em um cronograma
Pré-renderização	Um navegador headless renderiza o SPA uma vez e serve o HTML em cache para os rastreadores (ou para todos)	Forte: alternativa eficaz para SPAs já existentes	Adaptar o SEO a um aplicativo que você não consegue reconstruir por completo
Híbrido / Regeneração Estática Incremental	Mistura de SSG, SSR e renderização sob demanda por rota	Forte e flexível	Sites grandes com seções estáticas e dinâmicas

Renderização no servidor como correção principal

O SSR renderiza seus componentes React, Vue ou Angular em HTML completo no servidor e o envia ao navegador, que o "hidrata" e o transforma em um aplicativo interativo. O rastreador recebe conteúdo real na primeira requisição, sem uma segunda passagem de renderização. Frameworks construídos em torno desse padrão, como o Next.js para React, existem para tornar o SSR e a geração estática o padrão. Se você usa ou está avaliando o Next.js, nosso guia de SEO para Next.js percorre a configuração de metadados, sitemap e robots na ordem que importa.

Pré-renderização como ajuste mais rápido e barato

Se reconstruir tudo com SSR não é realista agora, a pré-renderização é o meio-termo prático. Um serviço renderiza seu SPA uma vez com um navegador headless e guarda o HTML estático em cache. Ele serve essa versão aos rastreadores, e muitas vezes a todos os visitantes de primeira viagem, enquanto a versão interativa em JavaScript carrega para quem volta. É menos elegante que o SSR de verdade, mas fecha a lacuna de rastreabilidade sem uma migração de framework.

Aprimoramento progressivo como rede de segurança

Aprimoramento progressivo (progressive enhancement) significa construir primeiro a experiência essencial para funcionar sem JavaScript e só depois adicionar a interatividade por cima, para os navegadores e rastreadores que a suportam. A detecção de recursos, que verifica se uma capacidade existe antes de depender dela, mantém a página funcional mesmo que um script não carregue ou que um rastreador não o execute por completo. Ela não substitui o SSR nem a pré-renderização em um site com muito conteúdo, mas é um bom hábito defensivo para qualquer recurso que dependa de JavaScript.

Exemplo passo a passo de migração de SPA para SSR

Estratégias de renderização em abstrato não dizem quanto tempo leva uma migração nem em que ordem o trabalho acontece. Aqui está um passo a passo de como um SPA típico de médio porte, digamos um diretório SaaS de 400 páginas construído em React com roteamento no cliente, migra para o SSR do Next.js sem uma reescrita completa.

Passo 1: audite o que o Google vê hoje (1 a 3 dias). Extraia todas as URLs indexadas do relatório de Indexação de páginas (Page Indexing) do Search Console e compare com a sua lista real de rotas. Um site com 400 visualizações reais pode descobrir que só 60 ou 70 estão indexadas, e o restante fica em "Descoberto: no momento não indexado" ("Discovered, currently not indexed") ou "Rastreado: no momento não indexado" ("Crawled, currently not indexed"). Essa diferença é a sua linha de base.

Passo 2: configure o Next.js ao lado do aplicativo existente (1 a 2 semanas). Em vez de reescrever todos os componentes de uma vez, a maioria das equipes roda o Next.js como um shell em volta dos componentes React existentes. Elas convertem as rotas em páginas do Next.js (ou segmentos do app router) um template por vez, começando pelas páginas de maior tráfego.

Passo 3: mova a busca de dados para loaders no servidor (1 a 2 semanas, em paralelo com o Passo 2). Qualquer chamada useEffect que busca os dados de que uma página precisa para renderizar tem de ir para uma função no servidor (getServerSideProps, um route handler ou o próprio fetch de um server component), para que o HTML chegue completo na primeira requisição.

Passo 4: redirecione as URLs antigas baseadas em hash ou em query string (1 a 2 dias). Todo endereço antigo no estilo #/product/42 precisa de um 301 no servidor para o novo caminho limpo, /product/42. Pular esta etapa é o motivo mais comum de migrações perderem os rankings existentes em vez de melhorá-los, porque as URLs antigas desaparecem sem nada que indique aos mecanismos de busca a substituta.

Passo 5: reenvie o sitemap e solicite a indexação das URLs prioritárias (1 dia, depois espere). Envie ao Search Console um sitemap XML novo ou atualizado, listando todas as rotas limpas, logo depois de cada lote de páginas publicado. A própria documentação do Google Search Central observa que reenviar um sitemap acelera a descoberta, mas não garante renderização ou ranqueamento mais rápidos, já que a prioridade de rastreamento ainda depende da autoridade e do orçamento de rastreamento já existentes do site.

Passo 6: monitore a curva de indexação por 4 a 8 semanas. As equipes que acompanham isso de perto costumam ver a contagem de "Descoberto: no momento não indexado" cair de forma constante ao longo de várias semanas, à medida que o Google rastreia de novo os templates convertidos. Uma página convertida na primeira semana pode só mostrar o novo status de indexada na terceira ou quarta semana.

Executar os seis passos template por template, em vez de tentar uma reescrita única e radical, evita que a migração derrube os rankings existentes enquanto o trabalho está em andamento.

Uma estimativa aproximada de custo: para uma equipe que já domina o React, converter um SPA de médio porte (algumas centenas de rotas) para o SSR do Next.js costuma levar de quatro a oito semanas de trabalho focado de engenharia, segundo estudos de caso de migração publicados pela própria equipe de engenharia de clientes da Vercel. A maior parte desse tempo vai para o Passo 3, e não para o roteamento ou a configuração, então planeje o orçamento de acordo em vez de prometer aos stakeholders um prazo de duas semanas.

Erros comuns das equipes durante a migração

Mesmo com a estratégia de renderização certa, um punhado de erros evitáveis responde pela maior parte das migrações de SPA paralisadas ou fracassadas.

Esquecer de redirecionar as URLs antigas com hash. Isso já foi abordado acima, mas é comum o bastante para listar de novo: se #/shoes/running não tiver um 301 para /shoes/running, os backlinks e os rankings que apontam para o endereço antigo caem em um beco sem saída em vez de passar para a nova URL.

Entregar SSR só para o shell e continuar carregando com lazy loading o conteúdo que importa. Uma página pode devolver HTML completo para o cabeçalho, o rodapé e a navegação, enquanto a descrição do produto ou o corpo do artigo ainda carrega por uma busca no cliente depois da hidratação. Para um rastreador, isso é pouco melhor do que o problema original, já que o conteúdo que ranquearia continua fora da resposta inicial.

Quebrar as tags canonical durante a transição. A maioria das migrações roda os padrões de URL antigo e novo lado a lado por um tempo, o que cria risco de conteúdo duplicado se os dois continuarem rastreáveis sem uma tag canonical apontando para o que você quer indexar. Decida qual URL vence antes de as duas irem ao ar.

Tratar a migração como concluída quando o HTML parece certo no navegador. Ver a página renderizada você mesmo não confirma o que o Googlebot recebeu. Use a ferramenta Inspeção de URL (URL Inspection) do Search Console, ou uma requisição HTTP com JavaScript desativado, para ver o HTML real da primeira resposta, e não o DOM depois que o seu navegador executou tudo.

Subestimar quanto tempo a reindexação leva em um site grande. Uma migração de dez páginas pode aparecer por completo no Search Console em uma semana, enquanto um catálogo de 5.000 páginas pode levar de dois a três meses para passar por todo o ciclo, porque o Google rastreia e renderiza as páginas de novo em lotes. Planejar um anúncio de lançamento ou um prazo de relatório em torno de um cronograma mais rápido é uma fonte comum de falsos alarmes quando os rankings não se mexem na primeira semana.

Dê a cada visualização a própria URL

Uma página sem URL própria não consegue ranquear para nada, por melhor que seja o conteúdo. Esse é o erro estrutural mais comum no SEO de SPAs, e também o mais fácil de corrigir.

History API vs. roteamento baseado em hash

SPAs mais antigos costumavam usar roteamento baseado em hash, com URLs como example.com/#/shoes/running, porque a parte depois do # podia mudar sem disparar um recarregamento completo da página. O problema é que os mecanismos de busca historicamente tratam tudo o que vem depois de um # como parte do mesmo documento.

A correção é a History API do navegador, em especial pushState() e replaceState(). Elas permitem que o seu JavaScript atualize a URL para um caminho limpo e real, como example.com/shoes/running, sem recarregar a página por completo. Os mecanismos de busca, e os usuários que salvam ou compartilham o link, recebem um endereço distinto e rastreável para aquela visualização exata.

Uma lista de verificação para um roteamento que os mecanismos de busca consigam usar:

• Cada conteúdo distinto tem o próprio caminho real, em vez de um fragmento com hash.
• As URLs são descritivas e estáveis: /shoes/running em vez de /view?id=4471.
• Cada URL devolve o conteúdo correto diretamente quando um usuário ou bot a carrega do zero, sem depender do histórico de navegação no cliente.
• Um sitemap XML adequado lista todas essas rotas, inclusive as abaixo da raiz.
• As tags canonical apontam para a versão limpa da URL de cada visualização, para que os caminhos com parâmetros e os limpos não enviem sinais concorrentes.

Metadados e dados estruturados que se atualizam a cada visualização

A maior falha silenciosa de um aplicativo de página única são os metadados que nunca mudam. Se a sua tag <title> e a meta descrição estão fixas no único shell HTML, cada "página" do seu SPA compartilha o mesmo título e a mesma descrição nos resultados de busca, o que para o Google parece conteúdo duplicado.

Títulos e descrições precisam mudar com a visualização

Cada rota precisa do próprio título e da própria meta descrição, atualizados à medida que o usuário (ou o Googlebot) navega até aquela visualização. Na prática, você gerencia as tags do head do documento pela camada de roteamento do seu framework, em vez de defini-las uma única vez em um index.html estático. Nosso guia prático de SEO on-page mostra como escrever títulos e descrições que geram cliques depois que são únicos para cada página, e a visão geral do recurso de SEO on-page mostra como isso fica auditado em um site inteiro de uma só vez.

Os metadados são um dos sinais mais claros que você controla diretamente, e um erro no nível do template se multiplica por todas as visualizações do seu aplicativo. Para o raciocínio mais amplo, veja a real importância dos metadados para o SEO. Para saber quais tags os mecanismos de busca usam e quais eles ignoram em silêncio, leia nosso texto sobre meta tags de SEO que o Google realmente usa antes de montar a lógica do template.

Open Graph e pré-visualizações sociais

O mesmo problema atinge as tags Open Graph, que controlam a aparência de um link quando ele é compartilhado em redes sociais ou aplicativos de mensagens. Se essas tags forem estáticas, todo link compartilhado do seu SPA mostra o mesmo título, a mesma descrição e a mesma imagem, seja qual for o produto ou o artigo que alguém compartilhou. Atualize og:title, og:description e og:image por rota, do mesmo jeito que você atualiza a tag de título.

Os dados estruturados precisam do mesmo tratamento por visualização

Os dados estruturados em JSON-LD, a marcação que pode render rich snippets como avaliações em estrelas, menus suspensos de FAQ ou preços de produtos nos resultados de busca, precisam ser gerados por visualização, e não injetados uma única vez de forma global. Um SPA de páginas de produto, por exemplo, precisa de um schema Product que reflita o preço e a disponibilidade daquele produto, e não de um bloco genérico repetido em todo lugar.

O Schema.org define o vocabulário dessa marcação. Um schema quebrado ou ausente desperdiça uma oportunidade de visibilidade que seus concorrentes em HTML puro já estão aproveitando. Nossa explicação sobre schema markup mostra o que cada tipo de schema faz pelos rankings, e a ferramenta de auditoria de schema markup verifica o seu JSON-LD e entrega uma marcação corrigida que você pode colar nos seus templates.

Como evitar soft 404s e outras armadilhas de indexação

Um soft 404 acontece quando uma página retorna o status normal "200 OK", mas o conteúdo parece vazio, quebrado ou como uma página de erro para o Google. Os SPAs são especialmente propensos a isso, porque uma rota que não consegue carregar seus dados ainda pode renderizar um shell quase em branco. O Google lê isso como uma página ruim, mesmo que o seu servidor nunca tenha devolvido um erro.

Armadilhas de indexação comuns em SPAs:

• Estados vazios servidos com status 200. Se um produto está esgotado ou foi descontinuado, ou se uma rota não é resolvida, sirva um código de status correto ou um conteúdo claro e rastreável, em vez de uma div em branco com status de sucesso.
• Rolagem infinita sem alternativa paginada. Se o conteúdo só aparece depois de um evento de JavaScript disparado pela rolagem, um rastreador que não rola pode nunca vê-lo. Por baixo da rolagem, ofereça URLs paginadas reais que apontem umas para as outras.
• Redirecionamentos no cliente em vez de no servidor. Um redirecionamento tratado em JavaScript depois que a página carrega é mais lento e menos confiável para os rastreadores do que um 301 HTTP vindo do servidor.
• Meta tags robots deixadas em noindex desde o ambiente de staging. Uma tag <meta name="robots" content="noindex"> usada durante o desenvolvimento pode facilmente chegar à produção dentro de um template compartilhado.
• Scripts ou endpoints de API bloqueados no robots.txt. Se os scripts ou os endpoints de dados dos quais o seu SPA depende estão proibidos para rastreamento, o Googlebot não consegue renderizar a página corretamente, mesmo quando tenta.

Nosso guia de correções de SEO técnico que realmente movem os rankings mostra como auditar problemas como esses em um site inteiro. Isso importa mais em um SPA do que em quase qualquer outra arquitetura, já que um único erro de template pode afetar todas as rotas ao mesmo tempo, sem alarde.

Pontos cegos de rastreamento e analytics em SPAs

As ferramentas de analytics criadas para sites tradicionais partem do princípio de que uma nova visualização de página é disparada sempre que o servidor envia um novo documento. Os SPAs quebram essa suposição, porque navegar entre visualizações não dispara um novo carregamento de página. O JavaScript cuida de tudo dentro de uma única sessão contínua.

Na prática, sem configuração extra, a sua ferramenta de analytics pode registrar apenas uma visualização de página por visita, não importa quantas páginas o visitante tenha navegado. Isso subestima muito o engajamento e torna impossível saber quais visualizações estão funcionando.

A solução é disparar um evento de visualização de página virtual toda vez que o seu roteador mudar a URL, ligado à atualização da History API discutida antes. As plataformas de analytics modernas oferecem suporte a isso por meio das configurações de medição aprimorada e da configuração do gerenciador de tags, mas é preciso configurar de propósito. Quando o roteamento e o rastreamento disparam corretamente, o rastreamento de rankings e os relatórios de tráfego no Google Analytics, no Search Console e nas fontes de referência de IA passam a fazer sentido, porque os dados de visualização de página por baixo são precisos.

Um ponto de partida framework por framework

Os principais frameworks de SPA têm todos um caminho maduro para resolver esses problemas de SEO, embora o ponto de partida varie.

Framework	Opção de renderização para SEO	Pelo que é conhecido
React (via Next.js)	SSR, geração estática e regeneração incremental integrados	Maior comunidade, escolha mais comum para reconstruções de SPA focadas em SEO
Vue (via Nuxt)	Renderização no servidor e na edge integrada ao framework	Leve, popular entre equipes que querem SSR sem o peso do React
Angular (via Angular Universal)	Complemento oficial de SSR para aplicativos Angular existentes	Comum em aplicativos corporativos que adaptam o SEO a uma base de código existente
Svelte (via SvelteKit)	SSR e geração estática por padrão	Pacotes menores e adoção crescente em sites sensíveis a desempenho

O padrão é o mesmo em todos eles. Se você tem a escolha, prefira a camada de renderização oficial do framework a um serviço de pré-renderização separado. Dá mais trabalho no início e é menos frágil a longo prazo.

Sua lista de verificação de auditoria de SEO para SPA

Antes de presumir que o seu SPA tem um problema de SEO, ou de declarar que ele foi corrigido, percorra esta lista. Este guia de SEO para aplicativos de página única vale ser salvo como referência, já que a maioria das equipes corrige esses itens em etapas.

1. Veja a sua página com o JavaScript desativado. Se o conteúdo some, some também a visão da primeira passagem do Google sobre ele.
2. Use a ferramenta Inspeção de URL (URL Inspection) do Google Search Console em algumas páginas importantes e compare o HTML renderizado com o que você espera.
3. Confirme que toda visualização importante tem uma URL única e rastreável, sem fragmento com hash nem identificador apenas em query string.
4. Verifique se os títulos e as meta descrições mudam por rota e não se limitam à página inicial.
5. Confira se o seu sitemap XML lista todas as rotas indexáveis e se está referenciado corretamente no robots.txt.
6. Teste os seus dados estruturados por template, usando as orientações de Resultados Avançados do Google (Rich Results), em mais de uma página de amostra.
7. Confirme que o analytics dispara uma visualização de página virtual a cada mudança de rota, além do carregamento inicial.
8. Procure soft 404s no relatório de indexação do Search Console. Estados vazios servidos com status 200 costumam ser a causa.
9. Faça o benchmark das Core Web Vitals. O web.dev define os limites atuais em cerca de 2,5 segundos para o Largest Contentful Paint, 200 milissegundos para o Interaction to Next Paint e 0,1 para o Cumulative Layout Shift. Os SPAs costumam se sair bem aqui depois que a renderização é corrigida, já que a interatividade de base já é rápida.

Executar essa lista à mão em um site grande é lento, e é fácil deixar passar um template que afeta centenas de páginas. Um relatório de SEO de exemplo mostra como é uma passagem automatizada completa por rastreabilidade, metadados e schema, sem o trabalho manual de planilha.

Perguntas frequentes

Um aplicativo de página única consegue ranquear no Google?

Sim. O Google consegue rastrear e indexar conteúdo renderizado em JavaScript, desde que o conteúdo apareça no HTML renderizado, cada visualização tenha a própria URL e os metadados sejam atualizados por visualização. O SPA renderizado no cliente e sem modificações, sem renderização no servidor, é a versão que tem dificuldade para ranquear.

O React é ruim para SEO?

Não, o React em si não é o problema. Um aplicativo React simples, renderizado no cliente e sem renderização no servidor, é mais difícil de indexar bem, e o Next.js ou outro framework que ofereça renderização no servidor ou geração estática resolve a maioria dos problemas de SEO que as pessoas associam ao React.

Qual é a diferença entre SSR e pré-renderização para SEO?

A renderização no servidor gera HTML novo a cada requisição, o que funciona bem para conteúdo personalizado ou que muda com frequência. A pré-renderização renderiza a página uma vez, com antecedência, e serve uma versão estática em cache. É mais rápida de implementar, mas menos adequada a conteúdo que muda por visitante ou por requisição.

Por que o meu SPA aparece como uma página em branco no cache do Google ou na ferramenta Inspeção de URL?

Isso geralmente significa que o Googlebot ainda não renderizou a página, ou que o JavaScript falhou ao executar corretamente durante a renderização. Muitas vezes os scripts ou as chamadas de API necessários foram bloqueados, estouraram o tempo limite ou dependiam de algo indisponível no ambiente de renderização do Google. Verifique se o seu robots.txt bloqueia recursos e teste a página ao vivo com a Inspeção de URL no Search Console.

Aplicativos de página única precisam de URLs separadas para cada página, ou uma URL basta?

URLs separadas. Um mecanismo de busca só consegue indexar e ranquear uma URL individual, então, se todo o seu SPA vive em um único endereço, o Google tem uma única entrada para trabalhar, não importa quanto conteúdo esteja por trás da navegação no cliente. Use a History API para dar a cada visualização relevante um caminho real e rastreável.

Corrija o SEO do seu SPA na ordem certa

Corrigir o SEO de aplicativos de página única costuma exigir várias mudanças: renderização, roteamento, metadados e schema, atacadas nessa ordem nos templates que tocam o maior número de páginas. Comece pela visualização que mais moveria tráfego se começasse a ranquear amanhã e vá ampliando a partir dela. Se você quer uma lista priorizada do que corrigir primeiro no seu próprio site, fale com a equipe e peça um relatório de SEO de exemplo feito a partir das suas páginas reais.

Recursos / Referências

1. Google Search Central
2. web.dev

Leia também: SEO para JavaScript: por que suas páginas ficam invisíveis para o Google.

Fontes

• What is a Single Page Application? SPA vs MPA 2025
• How single page applications work and when to use them
• How do you optimize a large SPA (single page application) ...
• When to consider Single Page Applications?

Aviso: este artigo traz informações gerais de saúde e não substitui uma orientação médica individual. Ele não leva em conta o seu histórico, os seus medicamentos nem os achados do seu exame. Para orientação sobre os seus próprios sintomas, fale com um profissional de saúde qualificado; se os sintomas forem graves ou estiverem piorando, procure atendimento de urgência.