O que você precisa saber

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br


Você sabia que, enquanto o blog Ahrefs é desenvolvido com WordPress, grande parte do restante do site é desenvolvido com JavaScript, como o React?

A maioria dos sites usa algum tipo de JavaScript para adicionar interatividade e melhorar a experiência do usuário. Alguns o usam para menus, obter produtos ou preços, obter conteúdo de várias fontes ou, em alguns casos, para tudo no site. A realidade da web atual é que o JavaScript é onipresente.

Como John Mueller do Google disse:

Não estou dizendo que os SEOs precisam sair e aprender a programar JavaScript. É exatamente o contrário. Os SEOs precisam principalmente saber como o Google lida com JavaScript e como solucionar problemas. Em muito poucos casos, um SEO pode até tocar no código. Meu objetivo com este post é ajudar você a aprender:

Javascript SEO faz parte do Technical SEO (Search Engine Optimization), que visa facilitar o rastreamento e a indexação de sites pesados ​​em JavaScript, além de facilitar a pesquisa. O objetivo é que esses sites sejam encontrados e tenham uma classificação mais alta nos mecanismos de pesquisa.

O JavaScript é ruim para SEO; JavaScript é mau? De modo nenhum. É apenas diferente do que muitos SEOs estão acostumados e há uma curva de aprendizado. As pessoas tendem a usá-lo demais para coisas em que provavelmente há uma solução melhor, mas você precisa trabalhar com o que tem às vezes. Apenas saiba que o Javascript não é perfeito e nem sempre é a ferramenta certa para o trabalho. Não pode ser analisado progressivamente, ao contrário de HTML e CSS, e pode ser pesado no carregamento e no desempenho da página. Em muitos casos, você pode negociar desempenho por funcionalidade.

Como o Google processa páginas com JavaScript

Nos primeiros dias dos mecanismos de pesquisa, um download HTML a resposta foi suficiente para ver o conteúdo da maioria das páginas. Graças ao aumento do JavaScript, os mecanismos de pesquisa agora precisam renderizar muitas páginas como um navegador, para que possam ver o conteúdo como o usuário a vê.

O sistema que lida com o processo de renderização no Google é chamado de Serviço de renderização na Web (WRS) O Google forneceu um diagrama simplista para cobrir como esse processo funciona.

Digamos que começamos o processo em URL.

1. Crawler

O rastreador envia PEGUE solicitações ao servidor. O servidor responde com cabeçalhos e o conteúdo do arquivo, que é salvo.

É provável que a solicitação venha de um agente de usuário móvel, já que o Google está atualmente na indexação do primeiro celular. Você pode verificar como o Google está rastreando seu site com o URL Ferramenta de inspeção no Search Console. Quando você executa isso por um URL, verifique as informações de cobertura em “Rastreado como” e deve informar se você ainda está na indexação para computador ou na indexação para dispositivos móveis.

1.search console rastreado como

Os pedidos vêm principalmente de Mountain View, CA, EUA, mas também pesquisam páginas adaptáveis ​​à localidade fora dos Estados Unidos. Menciono isso porque alguns sites bloqueiam ou tratam visitantes de um país específico ou usam um determinado IP de maneiras diferentes, o que pode fazer com que seu conteúdo não seja visto pelo Googlebot.

Alguns sites também podem usar a detecção de agente do usuário para mostrar o conteúdo de um rastreador específico. Especialmente nos sites JavaScript, o Google pode estar vendo algo diferente de um usuário. É por isso que ferramentas do Google, como a URL A Ferramenta de inspeção no Google Search Console, o Teste de compatibilidade com dispositivos móveis e o Rich Results Test são importantes para solucionar problemas de JavaScript SEO problemas. Eles mostram o que o Google vê e são úteis para verificar se o Google pode estar bloqueado e se eles podem ver o conteúdo da página. Vou abordar como testar isso na seção sobre o Renderer, porque existem algumas diferenças importantes entre os arquivos baixados PEGUE solicitação, a página renderizada e até as ferramentas de teste.

Também é importante observar que, embora o Google indique a saída do processo de rastreamento como “HTML“Na imagem acima, na realidade, eles estão rastreando e armazenando todos os recursos necessários para criar a página. HTML páginas, arquivos Javascript, CSS, XHR solicitações de, API pontos finais e muito mais.

2. Processamento

Existem muitos sistemas ofuscados pelo termo “Processando” na imagem. Vou abordar alguns deles que são relevantes para JavaScript.

Recursos e Links

O Google não navega de uma página para outra como o usuário faria. Parte de Processamento é verificar se há links para outras páginas e arquivos necessários para criar a página. Esses links são retirados e adicionados à fila de rastreamento, que é o que o Google está usando para priorizar e agendar o rastreamento.

O Google puxará links de recursos (CSS, JS, etc.) necessários para criar uma página a partir de coisas como Tag. No entanto, os links para outras páginas precisam estar em um formato específico para o Google tratá-los como links. Links internos e externos precisam ser um marcar com um href atributo. Há várias maneiras de fazer isso funcionar para usuários com JavaScript que não são amigáveis ​​à pesquisa.

Boa:

simple is good
still okay

Ruim:

nope, no href
nope, missing link
nope, missing link
not the right HTML element

no link
Button, ng-click, there are many more ways this can be done incorrectly.

Também é importante observar que os links internos adicionados ao JavaScript não serão capturados até depois da renderização. Isso deve ser relativamente rápido e não é motivo de preocupação na maioria dos casos.

Armazenamento em cache

Todo arquivo baixado pelo Google, incluindo HTML páginas, arquivos JavaScript, CSS arquivos etc. serão armazenados em cache de forma agressiva. O Google ignorará os tempos de cache e buscará uma nova cópia quando desejar. Falarei um pouco mais sobre isso e por que é importante na seção Renderer.

Eliminação duplicada

O conteúdo duplicado pode ser eliminado ou despriorizado dos arquivos baixados HTML antes de ser enviado para renderização. Nos modelos de shell de aplicativos, muito pouco conteúdo e código pode ser mostrado no HTML resposta. De fato, todas as páginas do site podem exibir o mesmo código, e esse pode ser o mesmo código mostrado em vários sites. Às vezes, isso pode fazer com que as páginas sejam tratadas como duplicatas e não sejam processadas imediatamente. Pior ainda, a página errada ou o site errado podem aparecer nos resultados da pesquisa. Isso deve resolver-se com o tempo, mas pode ser problemático, especialmente em sites mais recentes.

Diretivas mais restritivas

O Google escolherá as declarações mais restritivas entre HTML e a versão renderizada de uma página. Se o JavaScript alterar uma declaração e entrar em conflito com a declaração de HTML, O Google simplesmente obedecerá o que for mais restritivo. Noindex substituirá o índice e noindex em HTML irá pular a renderização completamente.

3. Fila de renderização

Toda página vai para o renderizador agora. Uma das maiores preocupações de muitos SEOs com JavaScript e indexação em dois estágios (HTML página renderizada) é que as páginas podem não ser renderizadas por dias ou até semanas. Quando o Google analisou isso, eles descobriram que as páginas eram enviadas para o renderizador em um tempo médio de 5 segundos, e o percentil 90 era de minutos. Portanto, a quantidade de tempo entre obter o HTML e renderizar as páginas não deve ser uma preocupação na maioria dos casos.

4. Renderer

O renderizador é onde o Google renderiza uma página para ver o que o usuário vê. É aqui que eles processam o JavaScript e quaisquer alterações feitas por JavaScript no modelo de objeto do documento (DOM)

01 javascript seo

Para isso, o Google está usando um navegador Chrome sem cabeça que agora é “sempre-verde”, o que significa que ele deve usar a versão mais recente do Chrome e oferecer suporte aos recursos mais recentes. Até recentemente, o Google era renderizado com o Chrome 41, então muitos recursos não eram suportados.

O Google tem mais informações sobre o Web Rendering Service (WRS), Que inclui coisas como negar permissões, ser apátrida, achatar a luz DOM e sombra DOMe muito mais que vale a pena ler.

Renderizar em escala da web pode ser a 8ª maravilha do mundo. É um empreendimento sério e requer uma quantidade enorme de recursos. Devido à escala, o Google está adotando muitos atalhos no processo de renderização para acelerar as coisas. Na Ahrefs, somos os únicos grandes SEO ferramenta que renderiza páginas da Web em escala e conseguimos renderizar ~150 milhões páginas por dia para tornar nosso índice de links mais completo. Permite verificar redirecionamentos de JavaScript e também podemos mostrar links que encontramos inseridos com JavaScript, que mostramos com um JS tag nos relatórios de link:

3 js site explorer

Recursos em cache

O Google depende muito dos recursos de cache. As páginas são armazenadas em cache; arquivos são armazenados em cache; API pedidos são armazenados em cache; basicamente, tudo é armazenado em cache antes de ser enviado ao renderizador. Eles não saem e fazem o download de cada recurso para cada carregamento de página, mas usam recursos em cache para acelerar esse processo.

Isso pode levar a alguns estados impossíveis em que versões de arquivo anteriores são usadas no processo de renderização e a versão indexada de uma página pode conter partes de arquivos mais antigos. Você pode usar a versão do arquivo ou a impressão digital de conteúdo para gerar novos nomes de arquivo quando forem feitas alterações significativas, para que o Google precise fazer o download da versão atualizada do recurso para renderização.

Sem tempo limite fixo

Um comum SEO O mito é que o renderizador aguarda apenas cinco segundos para carregar sua página. Embora seja sempre uma boa ideia tornar seu site mais rápido, esse mito não faz muito sentido com a maneira como o Google armazena em cache os arquivos mencionados acima. Eles estão basicamente carregando uma página com tudo em cache já. O mito vem das ferramentas de teste como o URL Ferramenta de inspeção em que os recursos são buscados ao vivo e precisam definir um limite razoável.

Não há tempo limite fixo para o renderizador. O que eles provavelmente estão fazendo é algo semelhante ao que o Rendertron público faz. Eles provavelmente esperam algo como networkidle0, onde não há mais atividade de rede, e também definem um período máximo de tempo, caso algo fique preso ou alguém esteja tentando minerar bitcoin em suas páginas.

O que o Googlebot vê

O Googlebot não atua em páginas da web. Eles não vão clicar nas coisas nem rolar, mas isso não significa que eles não têm soluções alternativas. Para conteúdo, desde que seja carregado no DOM sem uma ação necessária, eles verão. Vou abordar isso mais na seção de solução de problemas, mas basicamente, se o conteúdo estiver no DOM mas apenas oculto, será visto. Se não estiver carregado no DOM até depois de um clique, o conteúdo não será encontrado.

O Google não precisa rolar para ver seu conteúdo, porque eles têm uma solução alternativa inteligente para ver o conteúdo. Para dispositivos móveis, eles carregam a página com um tamanho de tela de 411×731 pixels e redimensionam o comprimento para 12.140 pixels. Basicamente, torna-se um telefone muito longo com um tamanho de tela de 411×12140 pixels. Para computadores, eles fazem o mesmo e vão de 1024×768 pixels a 1024×9307 pixels.

02 javascript seo

Outro atalho interessante é que o Google não pinta os pixels durante o processo de renderização. Leva tempo e recursos adicionais para concluir o carregamento da página, e eles realmente não precisam ver o estado final com os pixels pintados. Eles só precisam conhecer a estrutura e o layout e conseguem isso sem precisar pintar os pixels. Como Martin Splitt, do Google, coloca:

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br

https://youtube.com/watch?v=Qxd_d9m9vzo%3Fstart%3D154

Na pesquisa do Google, não nos preocupamos com os pixels, porque não queremos mostrá-lo a alguém. Queremos processar as informações e as informações semânticas, de modo que precisamos de algo no estado intermediário. Na verdade, não precisamos pintar os pixels.

Um visual pode ajudar a explicar o que é cortado um pouco melhor. Nas Ferramentas de Desenvolvimento do Chrome, se você executar um teste na guia Desempenho, receberá um gráfico de carregamento. A parte verde sólida aqui representa o estágio da pintura e, para o Googlebot, isso nunca acontece, economizando recursos.

chrome dev tools

cinzento = downloads
Azul = HTML
Amarelo = JavaScript
Roxa = Layout
Verde = Pintura

5. Fila de rastreamento

O Google possui um recurso que fala um pouco sobre o orçamento de rastreamento, mas você deve saber que cada site tem seu próprio orçamento de rastreamento e que cada solicitação deve ser priorizada. O Google também precisa equilibrar o rastreamento do seu site em comparação com todos os outros sites da Internet. Sites mais recentes em geral ou sites com muitas páginas dinâmicas provavelmente serão rastreados mais lentamente. Algumas páginas serão atualizadas com menos frequência do que outras, e alguns recursos também podem ser solicitados com menos frequência.

Teste / solução de problemas

Um “truque” nos sites JavaScript é que eles podem atualizar apenas partes do DOM. Navegar para outra página como usuário pode não atualizar alguns aspectos, como tags de título ou tags canônicas, no DOM, mas isso pode não ser um problema para os mecanismos de pesquisa. Lembre-se de que o Google carrega cada página sem estado, para que não salve informações anteriores e não navegue entre as páginas. Eu já vi SEOs tropeçando pensando que há um problema por causa do que eles veem depois de navegar de uma página para outra, como uma tag canônica que não é atualizada, mas o Google nunca pode ver esse estado. Os desenvolvedores podem corrigir isso atualizando o estado usando o que é chamado de Histórico API, mas novamente não pode ser um problema. Atualize a página e veja o que você vê ou melhor, execute-a através de uma das ferramentas de teste do Google para ver o que elas veem. Mais sobre aqueles em um segundo.

Fonte de exibição x inspeção

Ao clicar com o botão direito do mouse em uma janela do navegador, você verá algumas opções para visualizar o código-fonte da página e inspecionar a página. A fonte de exibição mostrará o mesmo que um PEGUE pedido faria. Esta é a matéria-prima HTML da página. Inspecionar mostra as informações processadas DOM após as alterações terem sido feitas e mais próximas do conteúdo que o Googlebot vê. É basicamente a versão atualizada e mais recente da página. Você deve inspecionar a fonte de exibição ao trabalhar com JavaScript.

2 visualizar fonte inspecionar elemento

Cache do Google

O cache do Google não é uma maneira confiável de verificar o que o Googlebot vê. Geralmente é o inicial HTML, embora às vezes seja o renderizado HTML ou uma versão mais antiga. O sistema foi criado para ver o conteúdo quando um site está inativo. Não é particularmente útil como uma ferramenta de depuração.

Ferramentas de teste do Google

As ferramentas de teste do Google, como o URL Inspetor no Google Search Console, Mobile Friendly Tester, Rich Results Tester são úteis para depuração. Ainda assim, mesmo essas ferramentas são um pouco diferentes do que o Google verá. Eu já falei sobre o tempo limite de cinco segundos nessas ferramentas que o renderizador não possui, mas essas ferramentas também diferem no fato de extraírem recursos em tempo real e não usarem as versões em cache como o renderizador faria. As capturas de tela nessas ferramentas também mostram páginas com os pixels pintados, que o Google não vê no renderizador.

As ferramentas são úteis para verificar se o conteúdo está carregado no DOM. o HTML mostrado nessas ferramentas é o renderizado DOM. Você pode procurar um trecho de texto para ver se ele foi carregado por padrão.

4 ferramenta compatível com dispositivos móveis

As ferramentas também mostrarão recursos que podem estar bloqueados e mensagens de erro do console, úteis para depuração.

Pesquisando texto no Google

Outra verificação rápida que você pode fazer é simplesmente procurar um trecho de seu conteúdo no Google. Pesquise “alguma frase do seu conteúdo” e veja se a página é retornada. Se for, seu conteúdo provavelmente foi visto. Observe que o conteúdo oculto por padrão pode não aparecer no seu snippet nos SERPs.

Ahrefs

Juntamente com as páginas de renderização do índice de links, você pode ativar o JavaScript nos rastreamentos do Site Audit para desbloquear mais dados em suas auditorias.

Javascript de auditoria de 5 sites

A barra de ferramentas Ahrefs também suporta JavaScript e permite comparar HTML para versões renderizadas de tags.

ahrefs seo toolbar js

Existem muitas opções para renderizar JavaScript. O Google tem um gráfico sólido que eu apenas vou mostrar. Qualquer tipo de SSR, renderização estática, configuração de pré-renderização será boa para os mecanismos de pesquisa. A principal que causa problemas é a renderização completa do lado do cliente, onde toda a renderização acontece no navegador.

Embora o Google provavelmente esteja bem, mesmo com a renderização do lado do cliente, é melhor escolher uma opção de renderização diferente para oferecer suporte a outros mecanismos de pesquisa. O Bing também tem suporte para renderização JavaScript, mas a escala é desconhecida. O Yandex e o Baidu têm suporte limitado do que eu vi, e muitos outros mecanismos de pesquisa têm pouco ou nenhum suporte ao JavaScript.

Há também a opção de renderização dinâmica, que é renderizada para determinados agentes do usuário. Isso é basicamente uma solução alternativa, mas pode ser útil para renderizar certos bots, como mecanismos de pesquisa ou mesmo bots de mídia social. Os bots de mídia social não executam JavaScript, então coisas como OG as tags não serão vistas, a menos que você renderize o conteúdo antes de veiculá-lo.

Se você estava usando o antigo AJAX esquema de rastreamento, observe que isso foi descontinuado e não pode mais ser suportado.

Tornando seu site JavaScript SEO amigáveis

Muitos processos são semelhantes aos que os SEOs já estão acostumados a ver, mas pode haver pequenas diferenças.

Na página SEO

Todo o normal na página SEO ainda se aplicam regras para conteúdo, tags de título, meta descrições, atributos alt, meta tags de robô etc. Consulte Na página SEO: Um guia acionável.

Alguns problemas que vejo repetidamente ao trabalhar com sites JavaScript são que títulos e descrições podem ser reutilizados e que atributos alt em imagens raramente são definidos.

Permitir rastreamento

Não bloqueie o acesso a recursos. O Google precisa acessar e baixar recursos para que eles possam renderizar as páginas corretamente. No seu robots.txt, a maneira mais fácil de permitir o rastreamento dos recursos necessários é adicionar:

User-Agent: Googlebot
Allow: .js
Allow: .css

URLs

Altere os URLs ao atualizar o conteúdo. Eu já mencionei a História API, mas você deve saber que, com estruturas JavaScript, eles terão um roteador que permite mapear para limpar URLs. Você não deseja usar hashes (#) para o roteamento. Isso é especialmente um problema para o Vue e algumas das versões anteriores do Angular. Então, para um URL como abc.com/#something, qualquer coisa após um # normalmente é ignorada por um servidor. Para corrigir isso no Vue, você pode trabalhar com seu desenvolvedor para alterar o seguinte:

Vue router: 
Use ‘History’ Mode instead of the traditional ‘Hash’ Mode.

const router = new VueRouter ({
mode: ‘history’,
router: [] //the array of router links
)}

Conteúdo duplicado

Com JavaScript, pode haver vários URLs para o mesmo conteúdo, o que leva a problemas de conteúdo duplicados. Isso pode ser causado por letras maiúsculas, IDs, parâmetros com IDs, etc. Portanto, tudo isso pode existir:

domain.com/Abc
domain.com/abc
domain.com/123
domain.com/?id=123

A solução é simples. Escolha uma versão que você deseja indexar e defina tags canônicas.

SEO Opções do tipo “plugin”

Para estruturas JavaScript, elas geralmente são chamadas de módulos. Você encontrará versões para muitas das estruturas populares, como React, Vue e Angular, pesquisando o nome da estrutura + do módulo como “React Helmet”. Meta tags, Helmet e Head são módulos populares com funcionalidade semelhante, permitindo que você defina muitas das tags populares necessárias para SEO.

Páginas de erro

Como as estruturas JavaScript não são do lado do servidor, elas realmente não podem gerar um erro de servidor como o 404. Você tem algumas opções diferentes para páginas de erro:

  1. Use um redirecionamento JavaScript para uma página que responde com um código de status 404
  2. Adicione uma tag noindex à página que está falhando, juntamente com algum tipo de mensagem de erro como “Página 404 não encontrada”. Isso será tratado como um 404 suave, pois o código de status real retornado será 200.

Mapa do site

As estruturas JavaScript geralmente têm roteadores que mapeiam para limpar URLs. Esses roteadores geralmente têm um módulo adicional que também pode criar sitemaps. Você pode encontrá-los pesquisando pelo sistema + sitemap do roteador, como “Sitemap do roteador Vue”. Muitas das soluções de renderização também podem ter opções de mapa do site. Mais uma vez, encontre o sistema que você usa e pesquise no Google o sistema + sitemap, como “Gatsby sitemap”, e você certamente encontrará uma solução que já existe.

Redirecionamentos

Os SEOs são usados ​​para redirecionamentos 301/302, que são do lado do servidor. Mas o Javascript normalmente é executado no lado do cliente. Tudo bem, pois o Google processa a página da seguinte maneira: o redirecionamento. Os redirecionamentos ainda passam todos os sinais como o PageRank. Geralmente, você pode encontrar esses redirecionamentos no código procurando por “window.location.href”.

Internacionalização

Geralmente, existem algumas opções de módulo para diferentes estruturas que suportam alguns recursos necessários para a internacionalização, como o hreflang. Eles geralmente são portados para os diferentes sistemas e incluem i18n, intl ou muitas vezes os mesmos módulos usados ​​para tags de cabeçalho como Helmet, que podem ser usados ​​para adicionar as tags necessárias.

Carregamento lento

Geralmente, existem módulos para lidar com carregamento lento. Se você ainda não percebeu, existem módulos para lidar com praticamente tudo o que você precisa fazer ao trabalhar com estruturas JavaScript. Lazy e Suspense são os módulos mais populares para carregamento lento. Você deseja carregar imagens com preguiça, mas tome cuidado para não carregar conteúdo com preguiça. Isso pode ser feito com JavaScript, mas pode significar que ele não foi captado corretamente pelos mecanismos de pesquisa.

Pensamentos finais

O JavaScript é uma ferramenta a ser usada com sabedoria, e não algo que os SEOs possam temer. Felizmente, este artigo ajudou você a entender como trabalhar melhor com ele, mas não tenha medo de entrar em contato com seus desenvolvedores, trabalhar com eles e fazer perguntas. Eles serão seus maiores aliados para ajudar a melhorar seu site JavaScript para os mecanismos de pesquisa.

Tem perguntas? Deixe-me saber no Twitter.



cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br
Leia Também  Por que o Google mostra o capitalismo em busca de socialismo e racismo

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *