Depois de lerPolítica do Google para tornar rastreável o conteúdo gerado pelo Ajax, juntamente com as postagens de blog de muitos desenvolvedores e os tópicos de perguntas e respostas sobre o assunto da Stackoverflow, conclui-se que não há como criar um site com apenas HTML rastreável por JavaScript / gerado pelo Ajax. Um site no qual estou trabalhando atualmente não está obtendo uma boa quantidade de seu conteúdo indexado. Toda a camada de apresentação para nosso conteúdo não indexado é construída em JavaScript, gerando HTML a partir de JSON retornado de chamadas de serviço da Web baseadas em Ajax, e acreditamos que o Google não esteja indexando o conteúdo por causa disso. Isso está correto?

A única solução parece ser também ter uma versão de "fall-back" do site para mecanismos de busca (especificamente o Google) onde todo o HTML e conteúdo seriam gerados como tradicionalmente tem sido, no lado do servidor. Para clientes com JavaScript ativado, parece que poderíamos usar essencialmente a mesma abordagem que fazemos agora: usar JavaScript para gerar HTML a partir de JSON carregado de forma assíncrona.

Ao ler em voz alta, meu entendimento é que a melhor prática atual para aplicar oPrincípio DRY na criação de sites gerados pelo Ajax rastreáveis, conforme descrito acima, é usado um mecanismo de modelo que pode usar os mesmos modelos no lado do cliente e no lado do servidor. Para clientes com JavaScript ativado, o mecanismo de modelo do lado do cliente, por exemplomoustache.jstransformaria os dados JSON enviados do servidor para HTML, conforme definido por sua cópia de um arquivo de modelo. E para rastreadores de pesquisa e clientes com JavaScript desativado, a implementação do lado do servidor do mesmo mecanismo de modelo, por exemplomoustache.java, operaria de forma semelhante em sua cópia do mesmo arquivo de modelo exato para saída de HTML.

Se essa solução estiver correta, então como isso é diferente das abordagens usadas 4 ou 5 anos atrás por sites pesados ​​front-end, onde os sites essencialmente precisavam manter duas cópias do código de modelo, uma cópia para usuários com JavaScript habilitado (quase todos) e outra cópia (por exemplo,FreeMarker ouVelocidade) para motores de busca e navegadores sem JavaScript habilitado (quase noone)? Parece que deveria haver um caminho melhor.

Isso implica que duas camadas de modelo de modelos precisariam ser mantidas, uma no lado do cliente e outra no lado do servidor? Como é aconselhável combinar os modelos do lado do cliente com um framework MVC (MV / MVVC) front-end comoBackbone.js, Ember.jsouYUI App Library? Como essas soluções afetam os custos de manutenção? Seria melhor tentar fazer isso sem introduzir mais estruturas - um novo mecanismo de templates e um framework MVC de front-end - na pilha de tecnologia de uma equipe de desenvolvimento? Existe uma maneira de fazer isso de forma menos redundante?

Se essa solução não estiver correta, então há algo que está faltando e poderia estar fazendo melhor com nosso JavaScript para manter nossa estrutura de JSON-de-JSON assíncrona existente e obtê-la indexada, portanto, não precisamos introduzir algo novo para a pilha de arquitetura? Nós realmente preferimos não ter que atualizar duas versões da camada de apresentação quando as necessidades do negócio mudarem.