Agora você pode confiar no Google para rastejar sites de Ajax?

Resumo:

Em 14 de outubro, o Google anunciou que não recomenda mais o esquema de rastreamento do Ajax que eles publicaram em 2009. Isso levanta a questão de saber se você pode confiar no Google para rastejar e indexar com sucesso um site Ajax.

Pontos chave:

  1. Designers e engenheiros da web preferem usar o AJAX para criar aplicativos de página única (SPA) com estruturas como Angular e React.
  2. O AJAX permite aplicativos da Web suave e interativos que executam como aplicativos de desktop.
  3. Em um spa, o conteúdo HTML não é inicialmente carregado no navegador. Em vez disso, o Ajax usa o JavaScript para se comunicar dinamicamente com o servidor da web e renderizar o HTML.
  4. O Google conseguiu engatinhar algum conteúdo de JavaScript, mas o SEO para sites de spa puro ajax apresentou desafios.
  5. Em 2009, o Google introduziu a solução rastreável do Ajax, que envolveu o uso de URLs ou meta tags de “fragmento escapado” para instruir o Google a buscar uma versão pré-renderizada da página com o HTML completo.
  6. Apesar da capacidade do Google de rastejar JavaScript, muitos sites que permitiram ao Google rastejar seus sites de spa Ajax tiveram sucesso limitado.
  7. Alguns sites até viram uma queda significativa no tráfego orgânico depois de mudar para a implementação do Ajax.
  8. Em 14 de outubro, o Google anunciou que eles não recomendam mais sua antiga proposta de rastreamento de Ajax, mas ainda o apóia.
  9. Há um equívoco de que o Google agora pode rastejar sites de Ajax sem problemas, mas é importante observar que eles afirmam que são “geralmente capazes” de renderizar e entender páginas da web como navegadores modernos.
  10. É crucial considerar o idioma usado pelo Google e não confiar apenas na suposição de que eles podem entender completamente as páginas do Ajax.

Questões:

  1. O Google pode indexar com êxito sites Ajax?
  2. Qual é o objetivo de usar o Ajax no web design?
  3. O que acontece quando um spa é carregado inicialmente?
  4. Que desafios têm sites de Ajax historicamente enfrentados com relação a SEO?
  5. Quais foram os métodos propostos pelo Google em 2009 para tornar o Ajax rastreável?
  6. Permitindo que o Google rastreia sites de Ajax resultam em indexação bem -sucedida para muitos sites?
  7. Que impacto negativo alguns sites experimentaram depois de implementar o Ajax?
  8. O que o Google anunciou em 14 de outubro sobre sua recomendação de rastreamento de Ajax?
  9. É preciso acreditar que o Google agora pode rastejar sites de Ajax efetivamente?
  10. Por que é importante considerar o idioma do Google em seu anúncio?
  11. Você pode confiar no Google para entender e rastejar completamente seu site Ajax?
  12. Como os designers e engenheiros da web utilizam o Ajax na construção de aplicativos da web?
  13. Qual é o papel do JavaScript no processo de renderização de um site Ajax?
  14. Por que alguns sites recorreram a instantâneos HTML pré-renderizados como uma solução?
  15. O que existe equívoco sobre a capacidade do Google de rastejar sites de Ajax?

Respostas:

  1. O Google pode rastejar sites de Ajax, mas o sucesso da indexação varia e não é garantido.
  2. O AJAX é usado no web design para criar aplicativos de página única (SPA) que oferecem uma experiência de usuário suave e interativa semelhante aos aplicativos de desktop dedicados.
  3. Quando um spa é carregado inicialmente, o conteúdo HTML não é buscado e renderizado. Em vez disso, o navegador conta com JavaScript para se comunicar com o servidor e rendericamente o HTML.
  4. Historicamente, os sites do Ajax enfrentaram desafios com o SEO porque a capacidade do Google de rastejar o conteúdo de javascript era limitada. Isso levou a dificuldades na indexação e classificação das páginas.
  5. Em 2009, o Google propôs dois métodos para tornar o Ajax rastreável. Um envolvido no uso de URLs de “fragmento escapado”, o que resultou em URLs feios. O outro método usou um Meta = “fragmento” Tag na página para instruir o Google a buscar uma versão pré-renderizada com html completo.
  6. Permitir que o Google rastreie sites Ajax nem sempre resultou em indexação bem -sucedida para muitos sites. Alguns sites viram apenas uma parte de suas páginas totalmente renderizadas e indexadas, enquanto outros sofreram uma queda significativa no tráfego orgânico.
  7. Depois de implementar o Ajax, alguns sites tiveram um impacto negativo em seu tráfego orgânico e tiveram que se recuperar da queda dos visitantes.
  8. Em 14 de outubro, o Google anunciou que eles não recomendam mais sua antiga proposta de rastreamento de Ajax, mas continuam a apoiá -la. Isso significa que eles não estão sugerindo ativamente seu uso, mas ainda reconhecem sua funcionalidade.
  9. Não é preciso supor que o Google agora possa rastejar sites de Ajax de maneira eficaz sem problemas. Enquanto afirmam que são “geralmente capazes” de renderizar e entender páginas da web como navegadores modernos, é essencial considerar o idioma usado e não apenas confiar nessa declaração.
  10. É importante considerar o idioma do Google em seu anúncio porque eles não fornecem uma garantia de indexação perfeita para sites Ajax. A frase “geralmente capaz” implica o potencial de limitações e desafios para entender e rastejar as páginas do Ajax.
  11. Confiar no Google para entender e rastejar completamente um site Ajax não é aconselhável sem testes e monitoramento adicionais. O sucesso da indexação pode variar, e é crucial considerar soluções alternativas como instantâneos html pré-renderizados.
  12. Designers e engenheiros da web usam Ajax para criar spa com estruturas como Angular e React, permitindo o desenvolvimento de aplicativos da Web que oferecem uma experiência interativa e suave do usuário semelhante a aplicativos de desktop dedicados.
  13. JavaScript desempenha um papel significativo no processo de renderização de um site Ajax. Ele se comunica dinamicamente com o servidor da web para criar e renderizar o conteúdo HTML para o usuário interagir com.
  14. Os sites recorreram à pré-renderização de instantâneos HTML como uma solução, porque algumas estruturas de Ajax, como Angular, ainda não suportam a renderização do lado do servidor. A pré-renderização permite a criação de instantâneos HTML que são servidos para mecanismos de pesquisa, garantindo indexação e visibilidade completas.
  15. Há um equívoco de que a capacidade do Google de rastejar sites de Ajax agora é impecável. No entanto, é importante observar que sua capacidade de entender e rastejar o conteúdo de JavaScript melhorou, mas os desafios e limitações ainda podem existir.

Agora você pode confiar no Google para rastejar sites de Ajax

E então, em 14 de outubro, o Google disse o seguinte:

O Google Crawl Ajax Content? [fechado]

Quero melhorar esta pergunta? Atualize a pergunta para que ela se concentre em um problema apenas editando esta postagem.

Fechado 7 anos atrás .

Na página inicial do meu site, eu uso a função Ajax do jQuery para retirar uma lista de atividades recentes de usuários. A atividade recente é exibida na página e cada linha da atividade recente inclui um link para o perfil do usuário do usuário que fez a atividade. O Google realmente fará a chamada do AJAX para retirar essas informações e usá -las no cálculo do fluxo de suco de relevância / link da página? Eu espero que isso não Como as páginas de perfil de usuário não são dignas de índice do Google, e eu não quero todos esses links para as páginas de perfil de usuário diluindo o suco de link da minha página inicial fluindo de outros links mais importantes.

Agora você pode confiar no Google para rastejar sites de Ajax?

Em 14 de outubro, o Google anunciou que não recomenda mais o esquema de rastreamento do Ajax que eles publicaram em 2009. O colunista Mark Munroe mergulha na questão de saber se isso significa que agora você pode contar com o Google para rastejar com sucesso e indexar um site Ajax.

Mark Munroe em 13 de novembro de 2015 às 9h18 | Tempo de leitura: 7 minutos

JavaScript-JS-SS-1920

Designers e engenheiros da web adoram Ajax para criar aplicativos de página única (SPA) com estruturas populares como Angular e React. As implementações puras do AJAX podem fornecer um aplicativo web suave e interativo que tem mais desempenho como um aplicativo de desktop dedicado.

Com um spa, geralmente, o conteúdo HTML não é carregado no navegador na busca inicial da página da web. O Ajax usa o JavaScript para se comunicar dinamicamente com o servidor da web para criar o HTML para renderizar a página e interagir com o usuário. (Existe uma técnica chamada “Renderização do lado do servidor” onde o JavaScript é realmente executado no servidor e a solicitação de página é retornada com o HTML renderizado. No entanto, essa abordagem ainda não é suportada em todas as estruturas de spa e acrescenta complexidade ao desenvolvimento.)

Um dos problemas com sites de spa Ajax foi o SEO. O Google está realmente rastejando algum conteúdo de JavaScript há um tempo. De fato, esta série recente de testes confirmou o Google’S Capacidade de rastejar links, metadados e conteúdo inserido via JavaScript. No entanto, os sites que usam estruturas Pure Spa Ajax tiveram desafios historicamente experimentados com SEO.

Em 2009, o Google criou uma solução para tornar o Ajax rastreável. Esse método cria “fragmento escapado” URLs (URLs feios) ou mais recentemente, URLs limpos com um Meta =”fragmento” Tag na página.

O URL de fragmento escapado ou a tag meta fragmentada instrui o Google a sair e obter uma versão pré-renderizada da página que executou todo o JavaScript e tem o HTML completo que o Google pode analisar e indexar. Neste método, a aranha serve um código -fonte de página totalmente diferente (html vs. Javascript).

Com a notícia de que o Google rasteja JavaScript, muitos sites decidiram deixar o Google rastejar seus sites de spa ajax. Em geral, isso não teve muito sucesso. No ano passado, consultei alguns sites com uma implementação angular do Ajax. O Google teve algum sucesso e cerca de 30 % das páginas no Google’s cache foi totalmente renderizado. Os outros 70 % estavam em branco.

Um local de comida popular mudou para o Angular, acreditando que o Google poderia rastejá -lo. Eles perderam cerca de 70 % do tráfego orgânico e ainda estão se recuperando daquele desastre. Por fim, ambos os sites foram para a pré-renderização de instantâneos HTML, a solução recomendada de rastejamento de Ajax no momento.

E então, em 14 de outubro, o Google disse o seguinte:

Não estamos mais recomendando a proposta de rastreamento do Ajax que fizemos em 2009.

Observe que eles ainda estão Apoio sua antiga proposta. (Houve alguns artigos anunciando que eles não estão mais apoiando, mas isso não é verdade – eles simplesmente não estão mais recomendando essa abordagem.)

Ao depreciar a recomendação antiga, eles pareciam estar dizendo que agora podem rastejar Ajax.

Então, apenas uma semana após o anúncio, um cliente com um site recém -lançado me pediu para conferir. Este era um local angular, novamente uma implementação de spa ajax.

Ao examinar o Google’s índice e cache, vimos algumas páginas parcialmente indexadas sem todo o conteúdo ficando rastejado. Reiturei minha recomendação anterior de usar instantâneos HTML ou aprimoramento progressivo.

Este site foi construído com o Angular, que ainda não suporta a renderização do lado do servidor (novamente, neste caso, o servidor renderiza inicialmente uma página para servir o documento HTML), portanto, o aprimoramento progressivo seria difícil de suportar, e os instantâneos HTML ainda são a melhor solução para eles.

Ela respondeu, “Mas por que? Tudo o que leu me diz que o Google pode rastejar Ajax.”

Eles podem? Deixar’s Dê uma olhada mais profunda na nova recomendação em relação ao Ajax.

Google’s Novas recomendações do Ajax

Ao explicar por que eles estão depreciando a antiga recomendação, eles dizem (ênfase minha):

Nós somos geralmente capaz Para renderizar e entender suas páginas da web, como navegadores modernos.

Muitas pessoas podem ser rápidas em concluir que agora podem rastejar Ajax sem problemas. Mas olhe para o idioma: “geralmente capaz”? Você apostaria sua receita comercial no conhecimento de que o Google é “geralmente capaz” Para entender sua página?

Será que estou apenas escolhendo semântica? Deixar’s examinar mais o anúncio. Mais tarde, em seu anúncio, eles afirmam em relação ao Ajax:

Como as suposições para nossa proposta de 2009 não são mais válidas, recomendamos seguir os princípios de aprimoramento progressivo.

Eles não’t soletrou em seu anúncio, mas recomendando o aprimoramento progressivo (que carrega algum html para navegadores que não’t Suporte JavaScript), eles parecem estar implicitamente dizendo, “Vestir’t Conte conosco rastejando seu javascript.” Por que recomendar este método, se de fato o Google pode rastejar de forma consistente sites spa Ajax?

Eu me preocupei que talvez estivesse analisando demais o Google’s Palavras, mas então ..

John Mueller confirma que o Google ainda tem problemas com o Ajax

Em 27 de outubro (menos de duas semanas após o anúncio do Google), John Mueller, em seu hangout do Webmaster Central, confirmou que o Google ainda tem problemas com o Ajax.

Você pode ver a troca por volta de 1:08:00 no vídeo, onde havia uma pergunta relacionada a uma implementação angular específica:

Eles ainda têm problemas com a renderização e esperam melhorar com o tempo. John recomenda algumas ações para ajudar a depurar os problemas.

Por fim, ele recomendou o uso de instantâneos HTML até o Google melhorar no Ajax (sim, o método que foi oficialmente depreciado).

Então o que fazer?

  • Aprimoramento progressivo. A renderização do lado do servidor seria necessária para aprimoramento progressivo e ainda não é suportado por angular. No entanto, o próximo angular 2.0 apoiará a renderização do lado do servidor. React, de fato, suporta a renderização do lado do servidor hoje. Este é, no entanto, mais trabalho do que simplesmente criar instantâneos HTML. Você precisa garantir que os links necessários para que o Google possa rastejar e indexar conteúdo adicional carregado na página. No entanto, para sites usando uma estrutura Ajax, essa seria minha abordagem recomendada. (E, claro, é Google’s abordagem recomendada.)
  • Instantâneos HTML de pré-renderização. Novamente, Don’estar confuso se você já ouviu ou lê que o Google não suporta mais este método. Eles continuarão a apoiá -lo no futuro próximo. Eles não estão mais recomendando. Este método funciona; No entanto, escrever o código para pré-renderizar e servir os instantâneos não é trivial. A boa notícia é que existem vários fornecedores por aí, como o Prerender.io que fará o trabalho para você a um custo relativamente baixo. Essa é provavelmente a abordagem mais simples. Este método não é ideal. Servindo código -fonte diferente para rastreadores vs. navegadores (html vs. Javascript) pode ser problemático. Pode ser considerado uma técnica de camuflagem, e não é necessariamente óbvio o que os bots estão sendo servidos. Isto’É importante monitorar o Google’s cache para garantir que eles não estejam sendo servidos na página errada. No entanto, se você usar uma plataforma que não suporta a renderização do lado do servidor, essa pode ser sua única solução.

Melhor prevenir do que remediar

Mesmo se eu tivesse visto evidências de que o Google estava consistentemente rastejando sites de Ajax, eu ainda estaria cauteloso. Leva muito mais recursos e muito mais tempo para renderizar totalmente uma página do que simplesmente servir HTML.

O que acontecerá com sites com centenas de milhares ou milhões de páginas? Como isso afetará o orçamento de rastreamento? A taxa de rastreamento permanecerá consistente?

Antes de recomendar essa abordagem, eu’D Aguarde e veja fortes evidências de que o Google pode e rastreia consistentemente grandes aplicativos de página única Ajax, sem impacto negativo na taxa de rastreamento, indexação e classificação. Por favor, compartilhe suas próprias experiências.

As opiniões expressas neste artigo são as do autor convidado e não necessariamente pesquisam terrenos do mecanismo. Os autores da equipe estão listados aqui.

Como JavaScript e Ajax afetam a indexação no Google?

Com o tempo, o Google melhorou bastante seu Indexação de JavaScript e Ajax. No começo, não fez’t indexa qualquer coisa, ou seguiu qualquer link que apareça no conteúdo carregado por essas estruturas. Mas então, pouco a pouco, começou a indexar algumas implementações e melhorar suas capacidades. Atualmente, ele pode indexar muitas implementações diferentes, e siga os links carregados através Ajax ou API buscar. No entanto, Ainda haverá casos em que pode deixar de fazê -lo.

Para analisar casos em que o Google pode acabar não indexando nosso site, primeiro precisamos entender o conceito de Renderização do lado do cliente (CSR). Isso implica isso O HTML é pintado ao lado do cliente com JavaScript, geralmente usando Ajax em excesso. Originalmente, os sites sempre pintam o lado do servidor HTML (Renderização do lado do servidor ou SSR), mas há algum tempo, A RSE tornou -se popular, com a chegada de estruturas JavaScript como Angular, React e Vue. No entanto, RSE afeta negativamente a indexação, desempenho de renderização de sites e, consequentemente, SEO.

Como nós’já expliquei antes, Para garantir a indexação em todos os mecanismos de pesquisa e situações, Além de alcançar um bom desempenho, A melhor solução é usar uma estrutura universal, Como com essas medidas, acabamos com algo chamado Renderização híbrida. Ele consiste em pintando o site no servidor na primeira carga e depois no cliente por meio de JavaScript e Ajax enquanto a navegação se move para os links a seguir. Embora, na realidade, haja mais situações em que o uso do termo de renderização híbrido também é válido.

Às vezes, a empresa de desenvolvimento usa RSE e não’T nos oferece a opção de usar uma estrutura universal. Esse Desenvolvimento da Web baseado em RSE nos causará problemas, em um grau maior ou menor, dependendo do rastreador e de seus algoritmos de classificação. Neste post, vamos analisar O que esses problemas com o Google’s rastreador são e como resolvê -los.

Problemas de RSE durante a carga inicial de uma página

Primeiro, vamos analisar os problemas de indexação acontecendo Assim que entramos em um URL fora do site, e quando o HTML é renderizado ao lado do cliente com JavaScript.

Questões como resultado de renderização lenta

Google’S O processo de indexação passa pelas seguintes etapas:

Diagrama do Googlebot

  1. Rastejando: GoogleBot solicita um URL ao servidor.
  2. Primeira onda de indexação: Ele indexa o conteúdo pintado no servidor instantaneamente e recebe novos links para rastejar.
  3. Ele gera o HTML pintado do lado do cliente executando JavaScript. Esse processo é computacionalmente caro (pode ser feito no momento ou levar vários dias, até, esperando para obter os recursos necessários para fazê -lo).
  4. Segunda onda de indexação: Com o lado do cliente pintado de HTML, o conteúdo restante é indexado e novos links a serem rastreados são obtidos.

Além do fato de que As páginas podem levar mais tempo para indexar totalmente, atrasando a indexação das páginas subsequentes vinculadas a partir delas, se a renderização de uma página for lenta, Googlebot’O renderizador pode deixar peças não pintadas. Nós’testou isso usando a opção de “Buscar como o Google” Fornecido pelo Google Search Console, e a captura de tela que gera não’t pintar qualquer coisa que leva mais de 5 segundos a ser exibida. No entanto, gera o HTML que leva mais tempo do que esses 5 segundos. Para entender por que isso acontece, temos que ter em mente que Console de pesquisa do Google’O renderizador S primeiro constrói o HTML executando o JavaScript com o Googlebot’S Renderizador e depois pinta a página’s pixels. A primeira tarefa é a que deve ser considerada para indexação, à qual nos referimos ao termo RSE. No Google Search Console, podemos ver o HTML gerado durante a primeira onda de indexação, e não a gerada pelo Googlebot’s renderizador.

Google

No Google Search Console, não podemos ver o HTML pintado pelo JavaScript, executado pelo Googlebot e usado na última fase de indexação. Para fazer isso, temos que usar esta ferramenta: https: // pesquisa.Google.com/teste/compatível com celular �� Clique para tweet

Nos testes nós’conduzi, quando a renderização de HTML levou mais de 19 segundos, não’T Conseguir qualquer coisa. Embora este seja muito tempo, em alguns casos, pode ser superado, especialmente se usarmos o Ajax intensivamente, e nesses casos o Google’O renderizador, assim como qualquer renderizador, realmente, tem que esperar que as seguintes etapas ocorram:

  1. Html é baixado e processado para solicitar arquivos vinculados e criar DOM.
  2. CSS é baixado e processado, para solicitar arquivos vinculados e criar CSSOM.
  3. JavaScript é baixado, compilado e executado, para lançar solicitações de Ajax.
  4. A solicitação do Ajax é movida para uma fila de solicitação, Esperando para ser respondido, juntamente com outros arquivos solicitados.
  5. O pedido de Ajax é lançado e tem que viajar pela rede para o servidor.
  6. O servidor responde aos pedidos através da rede e, finalmente,, Temos que esperar que o JavaScript seja executado, a fim de pintar o conteúdo da página’S Modelo HTML.

A solicitação e o download dos tempos do processo que acabamos de descrever dependem da carga de rede e do servidor durante esse período. Além disso, O GoogleBot usa apenas http/1.1, que é mais lento que o HTTP/2, porque os pedidos são tratados com um após o outro, e nem todos ao mesmo tempo. Isto’é necessário que o cliente e o servidor permitam que o HTTP/2 seja usado, e é por isso que GoogleBot usará apenas HTTP/1.1, mesmo que nosso servidor permita HTTP/2. Para resumir, isso significa que o GoogleBot espera que cada solicitação termine para lançar o próximo e ele’é possível que ganhou’T Tente paralisar certos pedidos abrindo várias conexões, como os navegadores fazem (embora nós não’eu sei exatamente como isso faz). Portanto, estamos em uma situação em que Poderíamos exceder esses 19 segundos que estimamos anteriormente.

Imagine, por exemplo, que com imagens, CSS, JavaScript e solicitações de Ajax, mais de 200 solicitações são lançadas, cada uma tomando 100 ms. Se solicitações de Ajax forem enviadas para o fundo da fila, nós’provavelmente exceder o tempo necessário para o conteúdo ser indexado.

Por outro lado, devido a esses problemas de desempenho de RSE, Teremos uma marca pior para a métrica FCP (Primeira Pintura Conteúdo) no PagesPeed em termos de renderização e seu WPO, e como conseqüência, pior rankings.

Problemas de indexação:

Ao indexar o conteúdo pintado do lado do cliente, O Googlebot pode ser executado nos seguintes problemas, o que impedirá a indexação do HTML gerado por JavaScript:

  • Eles usam um Versão do JavaScript O rastreador não’t reconhecer.
  • Eles usam um API JavaScript Não reconhecido pelo GoogleBot (atualmente, conhecemos soquetes da Web, WebGL, WebVR, IndexedDB e WebSQL não são suportados – mais informações em https: // desenvolvedores.Google.com/search/docs/guides/rendering).
  • Os arquivos JavaScript são bloqueados por robôs.TXT.
  • Os arquivos JavaScript são servidos através do HTTP enquanto o site usa HTTPS.
  • Existem javascript erros.
  • Se o aplicativo solicitar permissão do usuário Para fazer alguma coisa, e depende da renderização do conteúdo principal, ele venceu’eu fico pintado, porque o googlebot nega qualquer permissão’S solicitado por padrão.

Para descobrir se estamos sofrendo de algum desses problemas, devemos usar o Google’s Teste amigável para dispositivos móveis. Ele nos mostrará uma captura de tela de como uma página é pintada na tela, semelhante ao console de pesquisa do Google, mas também nos mostra o Código HTML gerado pelo renderizador (como mencionado anteriormente), registros de log de erros no código JavaScript, e JavaScript apresenta que o renderizador ainda não pode interpretar. Devemos usar esta ferramenta para testar todos os URLs representativos de cada modelo de página em nosso site, para garantir que o site seja indexível.

Devemos ter em mente que no Html gerado pela ferramenta anterior, todos Metadados (incluindo o URL canônico) será ignorado pelo Googlebot, pois só leva em consideração as informações quando elas’s pintado no servidor.

Problemas de RSE em relação à navegação para a próxima página

Agora deixe’s ver o que acontece quando usamos um link para navegar, uma vez que’já está no site, e o HTML é pintado no lado do cliente.

Questões de indexação

Ao contrário da RSE durante a carga inicial, A navegação para a próxima página alternando o conteúdo principal via JavaScript é mais rápido que o SSR. Mas nós’terá problemas de indexação se:

  • Links Don’T tem um URL válido retornando 200 OK em seus atributo href.
  • O servidor retorna um erro ao acessar o URL diretamente, sem JavaScript, ou com JavaScript ativado e excluindo todos os caches. Tenha cuidado com isso: se navegarmos para a página clicando em um link, pode parecer’está funcionando, porque é carregado por JavaScript. Mesmo ao acessar diretamente, se o site usar um trabalhador de serviço, o site poderá simular uma resposta correta, carregando seu cache. Mas o Googlebot é um rastreador apátrida, razão pela qual não’T Leve em consideração qualquer cache do trabalhador do servidor ou qualquer outra tecnologia JavaScript, como armazenamento local ou armazenamento de sessão, para que ele receba um erro.

Além disso, para o site estar acessível, o URL deve mudar usando JavaScript com o API da história.

O que acontece com os fragmentos agora que o Google pode indexar Ajax?

Fragmentos fazem parte de um URL que pode aparecer no final, precedido por um hash #. Por exemplo:

http: // www.HumanLevel.com/blog.HTML#Exemplo

Este tipo de URLs nunca chega ao servidor, Eles são gerenciados apenas do lado do cliente. Isso significa que, ao solicitar o URL acima para o servidor, ele receberia o pedido para “http: // www.HumanLevel.com/blog.html”, e no cliente, o navegador rolará para o fragmento do documento que está sendo referido. Este é o uso comum e originalmente pretendido para esses URLs, comumente conhecido como Âncoras HTML. E uma âncora, na realidade, é qualquer link (o “a” tag em html vem de âncora). No entanto, nos velhos tempos, Fragmentos também foram usados ​​para modificar URLs através de JavaScript em páginas carregadas de Ajax, com a intenção de deixar o usuário navegar pelo histórico de navegação. Foi implementado dessa maneira, porque naquela época o fragmento era a única parte do URL que poderíamos modificar usando o JavaScript, e é por isso que os desenvolvedores se aproveitaram disso para usá -los de uma maneira que eles não fossem’t pretendido. Isso mudou com a chegada da API da história, porque permitiu modificar todo o URL através do JavaScript.

Quando o Google não poderia’T índice Ajax, se um URL mudou seu conteúdo através do Ajax, com base na parte do fragmento, sabíamos que ele apenas indexaria o URL e o conteúdo sem levar em consideração o fragmento. Então … o que acontece com as páginas com fragmentos agora que o Google pode indexar Ajax? O comportamento é exatamente o mesmo. Se vincularmos uma página a um fragmento e altera seu conteúdo quando acessado através do fragmento, ele indexará o conteúdo ignorando o fragmento, e a popularidade irá para este URL, Porque o Google confia que o fragmento será usado como âncora, e não para alterar o conteúdo, pois deveria.

No entanto, o Google atualmente indexa URLs com um hashbang (#!). Isso pode ser implementado por simples adicionando o ponto de exclamação ou Bang, E o Google fará com que funcione, para manter a compatibilidade com versões anteriores com uma especificação obsoleta para tornar o AJAX indexível. Essa prática, no entanto, não é recomendada, porque agora deve ser implementada com a API da história e além, O Google pode parar de indexar de repente os URLs de hashbang a qualquer momento.

Bloqueando a indexação de respostas parciais através do Ajax

Quando um Ajax O pedido é enviado para URLs de uma API de descanso ou grafql, nós’re devolvido a Json ou um pedaço de uma página que não’não quero indexar. Portanto, devemos bloquear a indexação dos URLs aos quais essas solicitações são direcionadas.

Naquela época, poderíamos bloqueá -los usando robôs.TXT, Mas desde o Googlebot’S Renderer veio a existir, não podemos bloquear nenhum recurso usado para pintar html.

Atualmente, o Google é um pouco mais inteligente e não’t normalmente tente indexar respostas com o JSONS, mas se queremos ter certeza de que eles não’T é indexado, A solução universal aplicável a todos os mecanismos de pesquisa é fazer com que todos os URLs usados ​​com Ajax para aceitar apenas solicitações feitas através do método de postagem, Porque não é’T usado por rastreadores. Quando uma solicitação de get atingir o servidor, ele deve retornar um erro 404. Em termos de programação, não’t Forçou -nos a remover os parâmetros do URL’s Querystring.

Existe também a possibilidade de adicionar o HTTP “X-ROBOTS-TAG: Noindex” Cabeçalho (inventado pelo Google) para as respostas do Ajax, ou para fazer essas respostas ser devolvidas com 404 ou 410. Se usarmos essas técnicas no conteúdo carregado diretamente do HTML, ele venceu’T fomos indexados, como se tivéssemos bloqueado através dos robôs.arquivo txt. No entanto, dado isso’é o javascript pintando a resposta na página, o google não’t estabelece uma relação entre essa resposta e o javascript pintando o conteúdo, Então faz exatamente o que esperamos disso. E isso é: não indexe a resposta parcial e indexe totalmente o html gerado. Cuidado com isso, porque esse comportamento pode mudar algum dia, e todo o nosso conteúdo carregado através do Ajax se aplicarmos essa técnica.

Conclusão

O Google agora pode indexar JavaScript e Ajax, mas inevitavelmente implica um maior custo para indexação já processou HTML no servidor. Isso significa que o SSR é e continuará sendo a melhor opção por algum tempo. Se você não tem outra alternativa a não ser lidar com um site de RSE, total ou parcialmente, agora sabe como fazer isso.