JavaScript SEO: evitando as armadilhas da renderização do lado do servidor

JavaScript SEO é atualmente um dos tópicos quentes na indústria de SEO, à medida que a web moderna evolui e mais e mais sites são relançados ou construídos em aplicativos da web baseados em JavaScript, principalmente em React ou AngularJS. Com isso, adiciona-se mais complexidade ao SEO, pois precisamos garantir que o Google seja capaz de renderizar o JavaScript de forma eficaz, para que as páginas possam ser indexadas e classificadas corretamente. Isso pode ser feito usando a renderização do lado do servidor. No entanto, isso não vem livre de riscos. Neste artigo, passo por cinco erros de renderização do lado do servidor e explico como você pode evitá-los.

Se procura apoio na otimização técnica do seu website, porque não marcar uma consulta sem compromisso com os nossos consultores do Grupo de Estratégias Digitais e descobrir onde o podem ajudar?

Solicite uma consulta!

Que tipos diferentes de renderização do lado do servidor existem?

Pré-renderizar seu site para o Google em seu servidor (renderização do lado do servidor, SSR) é uma opção para garantir que seu site JavaScript seja compatível com o Googlbot. Dessa forma, você pode entregar a versão HTML pré-renderizada do seu site para o Google, enquanto o usuário obtém a versão normal do navegador (ainda não renderizada).

No entanto, quando se trata de renderização do lado do servidor, também existem diferentes maneiras de renderizar, como você pode ver no gráfico a seguir, que foi útilmente fornecido pelo Google, com algumas adições úteis de Jan-Willem Bobbink.

Existem três maneiras principais de configurar e executar a renderização do lado do servidor:

1. Renderização do lado do servidor com HTML dinâmico

A renderização do lado do servidor cria uma versão HTML renderizada de cada URL sob demanda.

2. Renderização estática com HTML estático

Basicamente, isso cria uma versão HTML pré-renderizada (estática) de uma URL antecipadamente e a armazena no cache.

3. Renderização do lado do servidor com (re)hidratação com HTML dinâmico e JS/DOMs

O servidor fornece uma versão HTML estática da URL e do cliente (navegador etc.) que já inclui uma marcação estruturada do Document Object Model (DOM). O cliente pega isso e o transforma em um DOM dinâmico que pode reagir às mudanças do lado do cliente e o torna mais interativo.

O Google publicou uma ótima visão geral da renderização da web, com todos os prós e contras, além de uma explicação mais profunda, se você estiver interessado. Mas antes de tudo, se você estiver procurando por alguma ajuda sobre o tema JavaScript SEO ou Server Side Rendering, não deixe de nos contatar aqui no Searchmetrics Digital Strategies Group.

Entrar em contato!

Armadilhas ao renderizar sites JavaScript por meio do servidor

Recentemente, nos deparamos com alguns problemas de SSR com um de nossos clientes. Eles executam seu site em Angular JS e o renderizam com Rendertron por meio de um Chrome sem cabeça.

Eles usam uma abordagem de renderização SSR estática, o que significa que eles renderizam uma página e armazenam em cache o HTML renderizado no servidor (antes do tempo). O HTML armazenado em cache não será substituído automaticamente, mas é baseado na lógica de renderização. A seguir estão cinco problemas que encontramos trabalhando neste site. Estou compartilhando com você aqui, para que, se você tiver desafios semelhantes, tenha uma ideia de como lidar com eles. No entanto, isso pode ser considerado como uma lista inacabada/expansível.

1. Quando você não faz nada

Quando você não se importa e não presta atenção em como o Google renderiza sua página, deixe-me mostrar como o Google renderiza (realmente vê) sua página. Isso é baseado em um site que é construído em um aplicativo de página única (SPA) usando uma estrutura JavaScript, sem renderização do lado do servidor.

Isso não parece particularmente promissor, não é? É exatamente por isso que é importante usar o SSR, porque fica assim:

2 . Paginação

Como lidar com suas páginas paginadas na hora de renderizar? Bem, especialmente na publicação, páginas paginadas ainda podem ser uma boa coisa para servir ao Google com seus artigos (mais recentes) enquanto o Google os está rastreando. Se você der uma olhada em seus arquivos de log, verá como o Google está acessando sua paginação, para saber onde faz sentido fornecer uma versão pré-renderizada (Spoiler: você não precisa fornecer 399 URLs com uma versão renderizada )

Como nosso cliente renderiza com uma abordagem SSR estática, eles apenas renderizaram a primeira página e espelharam a versão em cache da Página 1 até a página 10. Sem qualquer versão renderizada da página 11 em diante. Aqui estão duas capturas de tela que mostram o problema muito bem, com exatamente o mesmo conteúdo da página 1 também fornecido nas páginas 2-10.

Isso significa que você dá ao Google 10 páginas com o mesmo conteúdo e artigos. Idealmente, você deseja que o Google renderize todas as páginas como exclusivas com artigos paginados corretamente.

3 . Renovar a versão renderizada das páginas da categoria após a publicação de um novo artigo/produto

Nosso cliente aumentou sua classificação em quase todas as propriedades do Google Notícias de maneira bastante significativa, como carrosséis de AMP, caixas de notícias do Google e caixas de notícias para dispositivos móveis, com exceção dos carrosséis de editores. Começamos a investigar isso e descobrimos que nosso cliente não atualizou sua versão em cache quando houve um novo artigo publicado. Descobrimos que eles renovaram sua versão em cache das categorias principais uma semana depois:

e em subcategorias mesmo um mês depois.

Isso levou ao fato de que eles ainda tinham um artigo antigo sobre o tema do Brexit em sua versão pré-renderizada, mas não tinham todos os artigos novos publicados sobre o tema. Nossa suposição aqui é que, devido a esse problema, não havia artigos novos suficientes para o Google preencher um carrossel e isso teve um grande impacto negativo em seu desempenho. Ainda estamos investigando o impacto da mudança.

4 . A renderização pode causar conteúdo duplicado e a canonização errada

Fornecer uma versão pré-renderizada de um URL pode causar problemas baseados no sistema. Como nosso cliente entregava páginas pré-renderizadas, cada uma com sua própria URL criada pelo mecanismo de renderização, essas URLs tinham os parâmetros “p=1; render=1” e eram totalmente indexáveis:

Houve até uma nova configuração canônica pelo mecanismo SSR para esse URL. Bem assustador, hein?

Idealmente, você deseja excluir esses parâmetros do rastreamento do Google.

5 . Alteração do título da página ao renderizar

Também descobrimos que os títulos das páginas atuais foram renderizados por meio de JavaScript. Isso foi feito de uma forma que significava que o meta-título HTML sempre mostrava o nome da marca quando o JavaScript estava desabilitado. E quando o agente do usuário não é o Googlebot, ele apenas renderiza o título da página HTML. Veja os dois exemplos a seguir. A primeira mostra a URL com JavaScript desabilitado. A segunda é a mesma URL, mas com JavaScript habilitado.

Para garantir que os metadados sejam sempre renderizados corretamente, você deve incluí-los na versão não renderizada (JavaScript) da URL.

Conclusão

A renderização do lado do servidor não pode ser usada como uma abordagem simplificada para renderizar aplicativos de página única. Atenção especial é necessária para abordagens estáticas em que você apenas fornece um instantâneo. Como você pode ver no exemplo do nosso cliente, você precisa garantir que o mecanismo SSR sempre forneça uma versão atualizada do URL, caso contrário, o Google não verá e capturará seus artigos mais recentes e você será perdendo tráfego valioso.

Antes de reiniciar de um site baseado em HTML para uma estrutura baseada em JavaScript, certifique-se de que a renderização do lado do servidor esteja incluída e que esteja sempre servindo dinamicamente!

Se você está com problemas de JavaScript ou está procurando suporte na otimização técnica do seu site, por que não marcar uma consulta sem compromisso com nossos consultores do Grupo de Estratégias Digitais e descobrir onde eles podem ajudá-lo?

Solicite uma consulta!