在阅读了Google关于使Ajax生成的内容可抓取的政策以及许多开发人员的博客文章和Stackoverflow问答主题之后,我得出的结论是,没有办法建立只有JavaScript/Ajax生成的网站HTML可抓取.我目前正在工作的网站没有获得相当数量的内容索引.我们的非索引内容的所有表示层都是通过从基于Ajax的Web服务调用返回的JSON生成HTML而构建的,我们相信Google并没有因此而对内容编制索引.那是对的吗？
唯一的解决方案似乎是拥有搜索引擎(特别是谷歌)网站的"后备"版本,其中所有HTML和内容都将按照传统方式在服务器端生成.对于启用了JavaScript的客户端,似乎我们可以使用与现在基本相同的方法:使用JavaScript从异步加载的JSON生成HTML.
回顾一下,我的理解是,如上所述,当前在创建可抓取的Ajax生成的网站时应用DRY原则的最佳实践是使用可以在客户端和服务器端使用相同模板的模板引擎.对于启用了JavaScript的客户端,客户端模板引擎(例如mustache.js)会将从服务器发送的JSON数据转换为HTML,如其模板文件的副本所定义.对于禁用了JavaScript的搜索爬虫和客户端,同一模板引擎(例如mustache.java)的服务器端实现将类似地对其相同的模板文件的副本进行操作以输出HTML.
如果该解决方案是正确的,那么这与4或5年前由前端重型站点使用的方法有何不同,其中站点基本上必须维护两个模板代码副本,一个副本用于启用JavaScript的用户(几乎每个人)和没有启用JavaScript的搜索引擎和浏览器的另一个副本(例如在FreeMarker或Velocity中)(几乎没有人)？似乎应该有更好的方法.
这是否意味着需要维护两个模板模型层,一个在客户端,另一个在服务器端？将这些客户端模板与Backbone.js,Ember.js或YUI App Library等前端MVC(MV/MVVC)框架相结合是多么可取？这些解决方案如何影响维护成本？如果不将更多框架(一个新的模板引擎和一个前端MVC框架)引入开发团队的技术堆栈,尝试这样做会更好吗？有没有办法减少冗余？
如果该解决方案不正确,那么我们是否缺少某些东西,并且可以通过我们的JavaScript做得更好,以保持我们现有的异步HTML-from-JSON结构并将其编入索引,因此我们不需要引入新的东西到架构堆栈？当业务需求发生变化时,我们确实不必更新表示层的两个版本.