SEO para Single Page Applications

Se você leu meu artigo anterior onde mostrei uma curiosidade sobre a indexação de sites nas buscas, aqui eu desenvolvo um pouco mais o assunto. Se não leu, sem problemas, mas fique à vontade para ler se quiser...

Até hoje, ainda vejo muita gente publicando artigos pela Internet dizendo que Single Page Applications (SPA) têm problemas de SEO e precisam de "otimizações", com recursos como pré-render ou Server Side Render (SSR), para resolver esses problemas e ter boa indexação nas buscas.

Mas eu sou obrigado a discordar disso... Escrevi este artigo explicando o motivo e falando sobre um caso em produção em que testei e vi que essas "otimizações" estão mais para complicações, não são necessárias e na verdade nem fazem sentido.

Entenda o que você realmente quer

Esses recursos citados (pré-reder e SSR) geralmente exigem configurações complexas do lado servidor e praticamente fazem o que uma aplicação web escrita com uma linguagem de programação backend faz: processa as páginas no servidor antes de entregá-las para o cliente.

A diferença, resumindo, é que o pré-render processa a página antes, gerando o HTML estático para a entrega, enquanto que o SSR processa em tempo de execução para entregar a página processada no momento do acesso.

Por isso não faz sentido! Se você quer fazer qualquer uma dessas coisas, então na verdade não quer uma SPA!

Se você quer entregar a página estática já processada, então gere HTML estático e sirva-o pronto, existem frameworks para isso, são os atualmente conhecidos Static Site Generators (SSG para os íntimos).

E se você quer processar as páginas em tempo de execução, no momento do acesso, então precisa de uma aplicação web com backend entregando suas páginas da forma mais tradicional. Ou uma aplicão já desenvolvida com um framework SSR desde o início.

Simples assim!

SPA indexada nas buscas sem nenhuma "otimização"

Falando de SPA, será que realmente não precisa de nada disso?

Basicamente a resposta é: NÃO. Mas há detalhes a respeito disso, dependendo do contexto da aplicação e seus objetivos.

Mas para entender porque uma SPA não precisa desses recursos, vamos ao caso de teste.

O caso é este próprio site, que teve sua primeira versão como uma SPA feita com o framework Vue (mais especificamente, com Vite), que ficou online por alguns meses, testando a indexação do conteúdo nas buscas.

Isso foi feito sem nenhuma "otimização" de pré-render ou SSR. E mesmo assim, todo o conteúdo estava indexado no Google e podia ser encontrado nas buscas. Inclusive o Google identificava até mesmo detalhes do conteúdo como termos no meio do texto, a data de publicação de um artigo como este, <title> e <meta name="description" /> e até mesmo <link rel="canonical" /> dinâmicos, gerados do lado cliente por JS.

Como isso é possível?

Com todo respeito ao trabalho de outros profissionais, mas há muita informação bastante obsoleta nessa conversa!

Buscadores conseguem indexar conteúdo AJAX e SPA

Talvez, em algum momento de um passado distante, quando os primeiros sites que começaram a usar AJAX e não tinham seus conteúdos indexados, isso realmente poderia ser uma preocupação. Mas isso já mudou a bastante tempo.

Desde de muitos anos atrás, o Google já era capaz de indexar páginas com conteúdo carregado dinamicamente via AJAX. Inclusive, em Outubro de 2015 houve uma atualização que otimizou ainda mais essa capacidade, levando o Google a descontinuar os requisitos limitadores antes necessários para indexar conteúdos com renderização dinâmica do lado cliente, no navegador (link no final do artigo).

Hoje, a indexação do Google é feita com robôs que utilizam os mecanismos de renderização do Google Chrome para desktop e mobile. Ou seja, o Google não só é capaz de indexar qualquer conteúdo que o navegador consegue renderizar como também pode avaliar o desempenho dos sites quando acessados no computador ou em dispositivos móveis.

Com isso, veja o que ele pode avaliar no seu site:

• Identificar todos os detalhes de um HTML bem (ou mal) feito.
• Entender estilos de CSS e avaliar se o contraste entre as cores de texto e background são boas para a leitura.
• Verificar se acontecem erros de JS e se os arquivos carregados são muito grandes e bloqueantes.
• Simular o tempo de carregamento da aplicação em uma média de velocidade de Internet para desktop e mobile.
• Testar se o site é responsivo. (É por isso que há muitos anos atrás a prática de se fazer uma versão desktop e outra mobile em subdomínios diferentes foi abandonada.)

Essas verificações (e muitas outras) são hoje usadas pelo Google para indexar e qualificar o ranking de sites, essas são apenas alguns exemplos.

Single Page Applications tornaram-se fortes tendências

Aplicações web do tipo "frontend construído em componentes que requisitam dados via AJAX ao backend e renderizam conteúdo dinâmico condicional aos dados recebidos" tornaram-se fortes tendências nos últimos anos por vários motivos. E foi exatamente isso que deu grande importância aos frameworks de frontend como Vue, Angular e React. (Talvez isso seja assunto para outro artigo).

Além disso, a Google é a principal idealizadora e mantenedora do framework Angular, desde sua primeira versão em 2009 (AngularJS). Pensando nisso, você acha que ela tem interesse em indexar o conteúdo de sites feitos com esse framework (ou qualquer outro)? Aliás, como eu já perguntei no meu artigo anterior sobre indexação nas buscas:

Quem será o maior interessado em que o buscador seja capaz de encontrar qualquer conteúdo na Internet: nós ou a Google?

Então, perceba que há muito tempo a questão da indexação de conteúdos desse tipo está muito além do pré-render e do SSR.

Por isso, se você tem ou quer lançar um site SPA e está preocupado com o que vê e ouve por aí sobre a indexação do seu conteúdo nas buscas, provavelmente não há motivo para se preocupar tanto.

Mas nem tudo é assim tão simples...

Apesar de conteúdo SPA ser indexado, pode sofrer com outros problemas...

O primeiro é que se alguém compartilhar um link para uma de suas páginas em redes sociais, o crawler da rede social, que lê o conteúdo e cria uma visualização legal na postagem para o link, não conseguirá fazer isso e provavelmente vai mostrar dados como se fosse da página inicial do site, e não do conteúdo em si. Isso acontece porque esses crawlers de redes sociais não são tão "inteligentes" quanto o robô do Google (ou outros buscadores) e não consegue ler conteúdos dinâmicos do tipo que são renderizados do lado cliente (no navegador).

Outro problema que afeta o ranking de sites e que na verdade deve ser a preocupação principal nesse caso é: performance.

Como assim? Os frameworks de frontend não foram projetados para ter performance?

Sim, foram, mas não é sobre o funcionamento do framework que estamos falando e sim da maneira como ele é usado por quem desenvolve para produzir o resultado final. Mais especificamente, estou falando do build, o código final da aplicação compilado para publicar.

Por exemplo, o "pacote" JS de uma SPA pode se tornar muito grande e "perder pontos" de performance principalmente no carregamento inicial das páginas. É preciso conhecer técnicas avançadas e configurações específicas de cada framework para evitar isso.

Além disso, existem algumas técnicas e boas práticas aplicáveis a qualquer projeto HTML/CSS/JS que podem ajudar a vencer esse problema.

Mas isso também já é assunto para outro artigo... 😄

Então, resumindo, a menos que você queira um resultado na 1ª página das buscas (que todos sabemos ser uma missão quase impossível a curto prazo), não há motivos para se preocupar com SEO em sua SPA.

E se a sua SPA é um produto ou serviço com fins lucrativos, talvez compense muito mais investir em "resultados patrocinados" (anúncios).

Como uma dica final, caso você não conheça, existem ferramentas para testar como o Google indexa e qualifica o seu site, confira algumas:

• web.dev - Measure
• Google Search Console
• Lighthouse (presente nas ferramentas de desenvolvedor do navegadores baseados em Chromium: Google Chrome, Microsoft Edge, etc)

Até o próximo!

---

Referências:

• Making AJAX applications crawlable: AJAX Crawling (Derecated)