it-swarm.dev

pushState e SEO

Muitas pessoas têm dito, use pushState ao invés de hashbang.

O que eu não entendo é, como você seria motor de busca amigável sem usar hashbang?

Presumivelmente, seu conteúdo pushState é gerado pelo código JavaScript do lado do cliente.

O cenário é assim:

Eu estou no example.com. Meu usuário clica em um link: href="example.com/blog"

o pushState captura o clique, atualiza o URL, pega um arquivo JSON de algum lugar e cria a listagem de postagens do blog na área de conteúdo.

Com hashbangs, o google sabe como acessar o URL escape_fragment para obter o conteúdo estático.

Com o pushState, o Google simplesmente não vê nada, pois não pode usar o código JavaScript para carregar o JSON e, subsequentemente, criar o modelo.

A única maneira de fazê-lo que eu posso ver é renderizar o modelo no lado do servidor, mas isso nega completamente os benefícios de empurrar a camada de aplicativo para o cliente.

Então, estou conseguindo isso, o pushState não é SEO amigável para aplicativos do lado do cliente?

76
Harry

Que tal usar a metatag que o Google sugere para aqueles que não querem hash-bangs em seus URLs: <meta name="fragment" content="!">

Veja aqui para mais informações: https://developers.google.com/webmasters/ajax-crawling/docs/getting-started

Infelizmente, não acho que a NickC tenha esclarecido a questão que achei que o OP estava tendo. O problema é simplesmente que não sabemos para quem estamos servindo conteúdo se não usarmos o hash-bang. O Pushstate não resolve isso para nós. Não queremos que os mecanismos de pesquisa avisem os usuários finais sobre algum URL que gere JSON não formatado. Em vez disso, criamos URLs (que acionam outras chamadas para mais URLs) que recuperam dados via AJAX e os apresentam ao usuário da maneira que preferirmos. Se o usuário não é humano, então, como alternativa, podemos servir um instantâneo html, para que os mecanismos de pesquisa possam direcionar corretamente os usuários humanos para a URL na qual esperariam encontrar os dados solicitados (e de uma forma apresentável). Mas o desafio final é como determinamos o tipo de usuário? Sim, podemos possivelmente usar o .htaccess ou algo para reescrever a URL dos bots do mecanismo de pesquisa que detectamos, mas não tenho certeza de como essa atualização é à prova de erros e futura. Também pode ser possível que o Google penalize as pessoas por fazer esse tipo de coisa, mas não pesquisei completamente. Portanto, a combinação (pushstate + meta tag do google) parece ser uma solução provável.

16
prograhammer

pushState é ruim se você precisar de mecanismos de pesquisa para ler seu conteúdo?

Não, a conversa sobre pushState é voltada para a realização do mesmo processo geral para hashbangs, mas com URLs de melhor aparência. Pense no que realmente acontece quando você usa hashbangs ...

Você diz:

Com hashbangs, o Google sabe como acessar o URL escape_fragment para obter seu conteúdo estático.

Então, em outras palavras,

  1. O Google vê um link para example.com/#!/blog
  2. Google pede example.com/?_escaped_fragment_=/blog
  3. Você retorna um instantâneo do conteúdo que o usuário deve ver

Como você pode ver, ele já depende do servidor. Se você não estiver exibindo um instantâneo do conteúdo do servidor, o site não está sendo indexado corretamente.

Então, como o Google verá algo com o pushState?

Com o pushState, o google simplesmente não vê nada, pois não pode usar o javascript para carregar o json e, subsequentemente, criar o modelo.

Na verdade, o Google verá o que pode solicitar em site.com/blog. Um URL ainda aponta para um recurso no servidor e os clientes ainda obedecem a esse contrato. É claro que, para clientes modernos, o Javascript abriu novas possibilidades de recuperação e interação com o conteúdo sem uma atualização de página, mas os contratos são os mesmos.

Assim, a elegância pretendida de pushState é que ele serve o mesmo conteúdo para todos os usuários, antigos e novos, compatíveis com JS e não, mas os novos usuários obtêm uma experiência aprimorada .

Como você faz o Google ver seu conteúdo?

  1. A abordagem do Facebook - serve o mesmo conteúdo na URL site.com/blog que seu aplicativo cliente transformaria quando você pressiona /blog no estado. (Facebook não usa pushState ainda que eu saiba, mas eles fazem isso com hashbangs)

  2. A abordagem do Twitter - redireciona todos os URLs recebidos para o hashbang equivalente. Em outras palavras, um link para "/ blog" envia /blog para o estado. Mas se for solicitado diretamente, o navegador acaba em #!/blog. (Para o Googlebot, isso seria roteado para _escaped_fragment_ como você deseja. Para outros clientes, você poderia pushState voltar para a URL bonita).

Então você perde o recurso _escaped_fragment_ com pushState?

Em alguns comentários diferentes, você disse

fragmento de escape é completamente diferente. Você pode exibir conteúdo puro e sem tema, conteúdo em cache e não ser colocado sob o carregamento das páginas normais.

A solução ideal é que o Google faça sites JavaScript ou implemente alguma maneira de saber que há um URL de fragmento com escape mesmo para sites pushstate (robots.txt?).

Os benefícios que você mencionou não estão isolados para _escaped_fragment_. Isso faz a reescrita para você e usa um parâmetro GET especialmente nomeado é realmente um detalhe de implementação. Não há nada realmente especial sobre isso que você não poderia fazer com URLs padrão - em outras palavras, reescreva /blog para /?content=/blog por conta própria usando mod_rewrite ou o equivalente do seu servidor.

E se você não veicular conteúdo do lado do servidor?

Se você não pode reescrever URLs e servir algum tipo de conteúdo em /blog (ou qualquer estado que você tenha inserido no navegador), então seu servidor não está mais cumprindo o contrato HTTP.

Isso é importante porque um recarregamento de página (por qualquer motivo) atrairá conteúdo para esse URL. (Veja https://wiki.mozilla.org/Firefox_3.6/PushState_Security_Review - "view-source e reload buscarão o conteúdo no novo URI se um for pressionado.")

Não é que desenhar interfaces de usuário uma vez no lado do cliente e carregar conteúdo por meio de APIs JS seja um objetivo ruim, é apenas que não é realmente considerado com HTTP e URLs e, basicamente, não é compatível com versões anteriores.

No momento, esta é a coisa exata para a qual os hashbangs se destinam - para representar estados de página distintos que são navegados no cliente e não no servidor. Um recarregamento, por exemplo, carregará o recurso mesmo, que poderá ler, analisar e processar o valor com hash.

Acontece que eles têm também foram usados ​​ (principalmente pelo Facebook e Twitter) para alterar o histórico para um local do lado do servidor sem uma atualização de página. É nesses casos de uso que as pessoas estão recomendando o abandono de hashbangs pelo pushState.

Se você renderizar todo o conteúdo do lado do cliente, você deve pensar em pushState como parte de uma API de histórico mais conveniente, e não uma maneira de usar hashbangs.

97
Nicole

Todas as conversas interessantes sobre pushState e #!, e eu ainda não consigo ver como o pushState substitui o propósito de #! Como o pôster original pergunta.

Nossa solução para tornar nosso site/aplicativo de Ajax 99% baseado em JavaScript SEOable está usando #!, é claro. Como a renderização do cliente é feita via HTML, JavaScript e PHP, usamos a seguinte lógica em um carregador controlado pelo nosso pouso de página. Os arquivos HTML são totalmente separados do JavaScript e do PHP porque queremos o mesmo HTML em ambos (na maioria das vezes). O JavaScript e PHP fazem basicamente a mesma coisa, mas o código PHP é menos complicado, já que o JavaScript é uma experiência de usuário muito mais rica.

O JavaScript usa o jQuery para injetar no HTML o conteúdo que deseja. PHP usa PHPQuery para injetar no HTML o conteúdo que deseja - usando 'quase' a mesma lógica, mas muito mais simples que a versão PHP só será usada para exibir uma versão SEOable com links SEOable e não ser interagido com a versão do JavaScript.

Todos são os três componentes que compõem uma página, page.htm, page.js e page.php existem para qualquer coisa que use o fragmento de escape para saber se deve carregar a versão PHP no lugar da versão do JavaScript. A versão PHP não precisa existir para conteúdo não-SEOable (como páginas que só podem ser vistas após o login do usuário). Tudo é simples.

Ainda estou intrigado sobre como alguns desenvolvedores de front-end conseguem desenvolver ótimos sites (com a riqueza do Google Docs) sem usar tecnologias do lado do servidor em conjunto com os do navegador ... Se o JavaScript não estiver ativado, nossa solução 99% JavaScript obviamente não fará nada sem o PHP no lugar.

É possível ter uma URL legal para acessar uma página PHP exibida e redirecionar para uma versão JavaScript se o JavaScript estiver ativado, mas isso não é interessante do ponto de vista do usuário, já que os usuários são o público mais importante.

Em uma nota lateral. Se você está criando apenas um site simples que pode funcionar sem qualquer JavaScript, então eu posso ver o pushState sendo útil se você quiser melhorar progressivamente a sua experiência de usuário de um simples conteúdo renderizado estaticamente em algo melhor, mas se você quiser dar ao seu usuário melhor experiência em movimento ... digamos que o seu mais recente jogo escrito em JavaScript ou algo parecido com o Google Docs, então, o uso dessa solução é um pouco limitante, já que a recuperação pode ir tão longe antes que a experiência do usuário seja dolorosa comparada à visão do site.

0
Julian