在阅读了 Google 关于使 Ajax 生成的内容可抓取的政策,以及许多开发人员的博客文章和有关该主题的 Stackoverflow 问答线程之后,我得出的结论是,没有办法制作一个仅使用 JavaScript/Ajax 生成的网站可抓取的 HTML。我目前正在工作的网站没有获得相当数量的内容索引。我们的非索引内容的所有表示层都是用 JavaScript 构建的,通过从基于 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 结构并将其编入索引,因此我们不需要引入新的东西到架构堆栈?当业务需求发生变化时,我们真的宁愿不必更新表示层的两个版本。