Vue.js e SEO: como otimizar sites reativos para mecanismos de busca e bots

Estruturas JavaScript reativas (como React, Vue.js e Angular) estão na moda ultimamente, e não é de admirar que estejam sendo usadas em cada vez mais sites e aplicativos devido à sua flexibilidade, modularidade e facilidade de testes automatizados.

Essas estruturas permitem alcançar coisas novas e impensáveis ​​em um site ou aplicativo, mas como elas se comportam em termos de SEO? As páginas que foram criadas com esses frameworks são indexadas pelo Google? Como com esses frameworks toda – ou a maioria – da renderização da página é feita em JavaScript (e o HTML que é baixado pelos bots está quase vazio), parece que eles são inúteis se você quiser que seus sites sejam indexados em motores de busca ou até mesmo analisados ​​por bots em geral.

Neste artigo, falarei principalmente sobre o Vue.js, pois é o framework que mais usei e com o qual tenho experiências diretas em termos de indexação pelos motores de busca em grandes projetos, mas posso supor que a maioria o que vou abordar também é válido para outros frameworks.

Alguns antecedentes sobre o problema

Como funciona a indexação

Para que seu site seja indexado pelo Google, ele precisa ser rastreado pelo Googlebot (um software de indexação automatizado que visita seu site e salva o conteúdo das páginas em seu índice) seguindo os links em cada página. O Googlebot também procura arquivos XML de Sitemap especiais em sites para localizar páginas que podem não estar vinculadas corretamente a partir de seu site público e para receber informações adicionais sobre a frequência com que as páginas do site são alteradas e quando foram alteradas pela última vez.

Um pouco de história

Até alguns anos atrás (antes de 2009), o Google costumava indexar o conteúdo do HTML de um site — excluindo todo o conteúdo criado por JavaScript. Era do conhecimento comum de SEO que links e conteúdos importantes não deveriam ser escritos por JavaScript, pois não seriam indexados pelo Google e isso poderia causar uma penalidade para o site porque o Google poderia considerá-lo “conteúdo falso”, como se o proprietário do site estivesse tentando para mostrar aos usuários algo diferente do que foi mostrado aos motores de busca e tentar enganar estes últimos.

Era uma prática muito comum dos golpistas colocar muito conteúdo amigável para SEO no HTML e escondê-lo no JavaScript, por exemplo. O Google sempre alertou contra essa prática:

“A veiculação de conteúdo diferente do Googlebot que um usuário normal veria é considerado camuflagem e seria contra nossas Diretrizes para webmasters.”

Você pode ser penalizado por isso. Em alguns casos, você pode ser penalizado por fornecer conteúdo diferente para diferentes agentes de usuário no lado do servidor, mas também por alternar conteúdo via JavaScript após o carregamento da página. Acho que isso nos mostra que o Google indexa sites que executam JavaScript há muito tempo - pelo menos para comparar o HTML final do site (após a execução do JavaScript) e o HTML bruto que estava analisando para seus índices. Mas o Googlebot não executava JavaScript o tempo todo e o Google não estava usando o conteúdo gerado por JavaScript para fins de indexação.

Então, dado o aumento do uso de AJAX para fornecer conteúdo dinâmico em sites, o Google propôs um “esquema de rastreamento AJAX” para ajudar os usuários a indexar sites baseados em AJAX. Foi muito complicado; basicamente exigia que o site produzisse uma renderização de páginas com conteúdo AJAX incluído. Quando solicitado pelo Google, o servidor forneceria uma versão da página com todo (ou a maioria) do conteúdo que teria sido gerado dinamicamente pelo JavaScript incluído na página HTML — pré-renderizado como um instantâneo HTML do conteúdo. Esse processo de ter uma solução do lado do servidor entregando conteúdo que (para todos os outros propósitos) deveria ser gerado no lado do cliente, implicava que aqueles que desejavam ter um site que dependia fortemente de JavaScript indexado no Google tinham que passar por muitas aborrecimentos técnicos.

Por exemplo, se o conteúdo lido pelo AJAX veio de um web service externo, era necessário duplicar as mesmas chamadas de web service do lado do servidor e produzir, do lado do servidor, o mesmo HTML que teria sido produzido do lado do cliente por JavaScript — ou pelo menos um muito semelhante. Isso era muito complicado porque, antes do advento do Node.js, era necessário duplicar pelo menos parcialmente a mesma lógica de renderização em duas linguagens de programação diferentes: JavaScript para o frontend e PHP, Java, Python, Ruby e assim por diante. o back-end. Isso é chamado de “ renderização do lado do servidor ” e pode levar a um inferno de manutenção: se você fizer alterações importantes em como está renderizando conteúdo no front-end, terá que duplicar essas alterações no back-end.

A única alternativa para evitar duplicar a lógica era analisar seu próprio site com um navegador executando JavaScript e salvar os resultados finais em seu servidor e veiculá-los no Googlebot. Isso é semelhante ao que agora é chamado de “ pré-renderização ”.

O Google (com seu esquema de rastreamento AJAX) também garantiu que você evitaria penalidades devido ao fato de que, nesse caso, você estava fornecendo conteúdo diferente ao Googlebot e ao usuário. No entanto, desde 2015, o Google rejeitou essa prática com uma postagem oficial no blog que dizia aos gerentes de sites o seguinte:

“Hoje, desde que você não impeça o Googlebot de rastrear seus arquivos JavaScript ou CSS, geralmente podemos renderizar e entender suas páginas da web como navegadores modernos.”

O que isso nos disse não foi que o Googlebot de repente adquiriu a capacidade de executar JavaScript ao indexar páginas da web, pois sabemos que ele o fazia há muito tempo (pelo menos para verificar conteúdo falso e golpes). Em vez disso, ele nos disse que o resultado da execução do JavaScript seria indexado e usado em SERPs.

Isso parece implicar que não precisamos mais nos preocupar em fornecer ao Google HTML renderizado no lado do servidor. No entanto, vemos todos os tipos de ferramentas para renderização e pré-renderização do lado do servidor disponibilizadas para estruturas JavaScript, parece que esse não é o caso. Além disso, ao lidar com agências de SEO em grandes projetos, a pré-renderização parece ser considerada obrigatória. Por quê?

Como o Google realmente indexa páginas criadas com estruturas front-end?

O experimento

Para ver o que o Google realmente indexa em sites que foram criados com uma estrutura de front-end, construí um pequeno experimento. Ele não abrange todos os casos de uso, mas é pelo menos um meio de descobrir mais sobre o comportamento do Google. Eu construí um pequeno site com Vue.js e tive diferentes partes do texto renderizadas de forma diferente.

O conteúdo do site é retirado da descrição do livro Infinite Jest de David Foster Wallace no Infinite Jest Wiki ( valeu pessoal! ). Há alguns textos introdutórios para todo o livro e uma lista de personagens com sua biografia individual:

• Algum texto no HTML estático, fora do contêiner principal do Vue.js;
• Algum texto é renderizado imediatamente pelo Vue.js porque está contido em variáveis ​​que já estão presentes no código da aplicação: elas são definidas no objeto de data do componente;
• #Algum texto é renderizado pelo Vue.js a partir do objeto de data , mas com um atraso de 300ms;
• A biografia dos personagens vem de um conjunto de APIs de descanso, que construí de propósito usando o Sandbox. Como eu estava assumindo que o Google iria executar o código do site e parar depois de algum tempo para tirar um instantâneo do estado atual da página, configurei cada serviço da web para responder com um atraso incremental, o primeiro com 0ms, o segundo com 300ms, o terceiro com 600ms e assim sucessivamente até 2700ms.

Cada biografia de personagem é encurtada e contém um link para uma subpágina, que está disponível apenas por meio do Vue.js (os URLs são gerados pelo Vue.js usando a API de histórico), mas não do lado do servidor (se você chamar o URL do página diretamente, você não obtém resposta do servidor), para verificar se eles também foram indexados. Presumi que eles não seriam indexados, pois não são links adequados que renderizam no lado do servidor e não há como o Google direcionar os usuários diretamente para esses links. Mas eu só queria verificar.

Publiquei este pequeno site de teste nas minhas páginas do Github e solicitei a indexação - dê uma olhada.

Os resultados

Os resultados da experiência (relativos à página inicial) são os seguintes:

• Os conteúdos que já estão no conteúdo HTML estático são indexados pelo Google (o que é bastante óbvio);
• Os conteúdos gerados pelo Vue em tempo real sempre são indexados pelo Google;
• Os conteúdos que são gerados pelo Vue, mas renderizados após 300ms também são indexados;
• O conteúdo que vem do serviço web, com algum atraso, pode ser indexado, mas nem sempre. Eu verifiquei a indexação da página do Google em diferentes momentos, e o conteúdo que foi inserido por último (após alguns segundos) às vezes foi indexado, às vezes não. O conteúdo que é renderizado rapidamente é indexado na maioria das vezes, mesmo que venha de uma chamada assíncrona para um serviço da Web externo. Isso depende do Google ter um orçamento de renderização para cada página e site, que depende de seus algoritmos internos, e pode variar muito dependendo da classificação do seu site e do estado atual da fila de renderização do Googlebot. Portanto, você não pode confiar no conteúdo proveniente de serviços da Web externos para ser indexado;
• As subpáginas (já que não são acessíveis como um link direto) não são indexadas conforme o esperado.

O que esse experimento nos diz? Basicamente, que o Google indexa conteúdo gerado dinamicamente, mesmo que venha de um serviço web externo, mas não é garantido que o conteúdo será indexado se “chegar tarde demais”. Eu tive experiências semelhantes com outros sites reais de produção além deste experimento.

SEO competitivo

Ok, então o conteúdo é indexado , mas o que esse experimento não nos diz é: o conteúdo será classificado de forma competitiva? O Google preferirá um site com conteúdo estático a um site gerado dinamicamente? Esta não é uma pergunta fácil de responder.

Pela minha experiência, posso dizer que o conteúdo gerado dinamicamente pode ser classificado nas primeiras posições do SERPS. Trabalhei no site de um novo modelo de uma grande montadora, lançando um novo site com um novo domínio de terceiro nível. O site foi totalmente gerado com Vue.js — com muito pouco conteúdo no HTML estático além das tags <title> e meta descrições.

O site começou a ser classificado para buscas menores nos primeiros dias após a publicação, e os trechos de texto nas SERPs relataram palavras vindas diretamente do conteúdo dinâmico.

Em três meses, ele estava em primeiro lugar na maioria das pesquisas relacionadas a esse modelo de carro - o que era relativamente fácil, pois estava hospedado em um domínio oficial pertencente ao fabricante do carro, e o domínio estava fortemente vinculado a sites respeitáveis.

Mas como tivemos que enfrentar forte oposição da empresa de SEO responsável pelo projeto, acho que o resultado ainda foi notável.

Devido aos prazos apertados e falta de tempo dado para o projeto, íamos publicar o site sem pré-renderização.

Texto animado

O que o Google não indexa é texto com muita animação. O site de uma das empresas com quem trabalho, Rabbit Hole Consulting, contém muitas animações de texto, que são executadas enquanto o usuário rola e exigem que o texto seja dividido em vários pedaços em diferentes tags.

Os principais textos da página inicial do site não se destinam à indexação do mecanismo de pesquisa, pois não são otimizados para SEO. Eles não são feitos de tech-speak e não usam palavras-chave: eles servem apenas para acompanhar o usuário em uma jornada conceitual sobre a empresa. O texto é inserido dinamicamente quando o usuário entra nas várias seções da página inicial.

Nenhum dos textos nessas seções do site é indexado pelo Google. Para que o Google mostre algo significativo nas SERPs, adicionamos um texto estático no rodapé abaixo do formulário de contato, e esse conteúdo é exibido como parte do conteúdo da página nas SERPs.

O texto no rodapé é indexado e mostrado em SERPs, mesmo que não seja imediatamente visível para os usuários, a menos que eles rolem até o final da página e cliquem no botão “Perguntas” para abrir o formulário de contato. Isso confirma minha opinião de que o conteúdo é indexado mesmo que não seja mostrado imediatamente ao usuário, desde que seja renderizado logo no HTML — em vez de ser renderizado sob demanda ou após um longo atraso.

E quanto à pré-renderização?

Então, por que todo o alarido sobre a pré-renderização - seja no lado do servidor ou no tempo de compilação do projeto? É realmente necessário? Embora alguns frameworks, como o Nuxt, tornem muito mais fácil de executar, ainda não é um piquenique, então a escolha de configurá-lo ou não não é fácil.

Acho que não é obrigatório . Certamente é um requisito se muito do conteúdo que você deseja indexar pelo Google vier de um serviço da Web externo e não estiver disponível imediatamente no momento da renderização e pode, em alguns casos infelizes, não estar disponível devido, por exemplo, , tempo de inatividade do serviço web. Se durante as visitas do Googlebot algum conteúdo chegar muito devagar, talvez ele não seja indexado . Se o Googlebot indexar sua página exatamente no momento em que você estiver realizando manutenção em seus serviços da web, talvez ele não indexe nenhum conteúdo dinâmico.

Além disso, não tenho provas de diferenças de classificação entre conteúdo estático e conteúdo gerado dinamicamente. Isso pode exigir outro experimento. Eu acho que é muito provável que, se o conteúdo vier de um serviço web externo e não carregar imediatamente, isso possa impactar na percepção do Google sobre o desempenho do seu site, que é um fator muito importante para a classificação.

Leitura recomendada : Como o design da web móvel afeta a pesquisa local (e o que fazer sobre isso)

outras considerações

Compatibilidade

Até recentemente, o Googlebot usava uma versão bastante antiga do Chromium (o projeto de código aberto no qual o Google Chrome se baseia), ou seja, a versão 41. Isso significava que alguns recursos JavaScript ou CSS recentes não podiam ser renderizados pelo Google corretamente (por exemplo, IntersectionObserver, sintaxe ES6 e assim por diante).

O Google anunciou recentemente que está executando a versão mais recente do Chromium (74, no momento da redação) no Googlebot e que a versão será atualizada regularmente. O fato de o Google estar executando o Chromium 41 pode ter grandes implicações para sites que decidiram desconsiderar a compatibilidade com o IE11 e outros navegadores antigos.

Você pode ver uma comparação do suporte do Chromium 41 e do Chromium 74 para recursos aqui, no entanto, se o seu site já estava preenchendo recursos ausentes para permanecer compatível com navegadores mais antigos, não deve ter havido nenhum problema.

Sempre use polyfills , pois você nunca sabe qual navegador não tem suporte para recursos que você acha que são comuns. Por exemplo, o Safari não suportava um novo recurso importante e muito útil como o IntersectionObserver até a versão 12.1, lançada em março de 2019.

Erros de JavaScript

Se você depender do Googlebot para executar seu JavaScript para renderizar conteúdo vital, os principais erros de JavaScript que podem impedir a renderização do conteúdo devem ser evitados a todo custo. Embora os bots possam analisar e indexar HTML que não é perfeitamente válido (embora seja sempre preferível ter um HTML válido em qualquer site!), se houver um erro de JavaScript que impeça o carregamento de algum conteúdo , não há como o Google indexar esse conteúdo.

De qualquer forma, se você confiar no JavaScript para renderizar conteúdo vital para seus usuários finais, é provável que você já tenha testes de unidade extensivos para verificar erros de bloqueio de qualquer tipo. No entanto, lembre-se de que os erros de Javascript podem surgir de cenários imprevisíveis, por exemplo, no caso de tratamento inadequado de erros nas respostas da API.

É melhor ter algum software de verificação de erros em tempo real (como Sentry ou LogRocket) que irá alertá-lo sobre quaisquer erros de casos extremos que você pode não escolher durante o teste manual ou unitário. Isso aumenta a complexidade de confiar em JavaScript para conteúdo de SEO.

Outros motores de busca

Os outros motores de busca não funcionam tão bem quanto o Google com conteúdo dinâmico. O Bing não parece indexar conteúdo dinâmico, nem o DuckDuckGo ou o Baidu. Provavelmente, esses mecanismos de pesquisa não têm os recursos e o poder de computação que o Google tem em abundância.

Analisar uma página com um navegador headless e executar JavaScript por alguns segundos para analisar o conteúdo renderizado certamente consome mais recursos do que apenas ler HTML simples. Ou talvez esses mecanismos de pesquisa tenham optado por não verificar conteúdo dinâmico por outros motivos. Seja qual for a causa disso, se o seu projeto precisar oferecer suporte a qualquer um desses mecanismos de pesquisa, você precisará configurar a pré-renderização.

Nota : Para obter mais informações sobre os recursos de renderização de outros mecanismos de pesquisa, consulte este artigo de Bartosz Goralewicz. É um pouco antigo, mas de acordo com minha experiência, ainda é válido.

Outros bots

Lembre-se de que seu site também será visitado por outros bots. Os exemplos mais importantes são Twitter, Facebook e outros bots de mídia social que precisam buscar meta-informações sobre suas páginas para mostrar uma visualização de sua página quando ela é vinculada por seus usuários. Esses bots não indexarão conteúdo dinâmico e mostrarão apenas as metainformações que encontrarem no HTML estático. Isso nos leva à próxima consideração.

Subpáginas

Se o seu site for um chamado “site de uma página” e todo o conteúdo relevante estiver localizado em um HTML principal, você não terá problemas em ter esse conteúdo indexado pelo Google. No entanto, se você precisar que o Google indexe e mostre qualquer página secundária no site, ainda será necessário criar HTML estático para cada uma delas - mesmo que você dependa de seu JavaScript Framework para verificar o URL atual e fornecer o conteúdo relevante para colocar nessa página. Meu conselho, neste caso, é criar páginas do lado do servidor (ou estáticas) que pelo menos forneçam a tag de title correta e a meta descrição/informações.

Conclusões

As conclusões a que cheguei ao pesquisar este artigo são as seguintes:

1. Se você segmentar apenas o Google, não é obrigatório usar a pré-renderização para que seu site seja totalmente indexado, no entanto:
2. Você não deve confiar em serviços da web de terceiros para conteúdo que precisa ser indexado, especialmente se eles não responderem rapidamente.
3. O conteúdo que você insere em seu HTML imediatamente por meio da renderização do Vue.js é indexado, mas você não deve usar texto animado ou texto inserido no DOM após ações do usuário, como rolagem, etc.
4. Certifique-se de testar os erros de JavaScript, pois eles podem resultar na não indexação de páginas/seções inteiras ou no seu site não ser indexado.
5. Se seu site tiver várias páginas , você ainda precisará ter alguma lógica para criar páginas que, embora dependam do mesmo sistema de renderização de front-end da página inicial, possam ser indexadas pelo Google como URLs individuais.
6. Se você precisar ter uma descrição diferente e imagens de visualização para mídia social entre páginas diferentes, precisará resolver isso também, seja do lado do servidor ou compilando páginas estáticas para cada URL.
7. Se você precisar que seu site funcione em mecanismos de pesquisa que não sejam o Google , você definitivamente precisará de algum tipo de pré-renderização.