После чтения Политика Google по обеспечению возможности сканирования контента, сгенерированного Ajax, наряду с сообщениями многих разработчиков в блоге и вопросами и ответами Stackoverflow на эту тему, я остаюсь с выводом, что невозможно сделать сайт с использованием только HTML / Ajax-генерируемого HTML-кода, который можно сканировать. Сайт, на котором я сейчас работаю, недостаточно проиндексирован. Весь уровень представления для нашего неиндексированного контента построен на JavaScript путем генерации HTML из JSON, возвращаемого из вызовов веб-сервисов на основе Ajax, и мы считаем, что Google не индексирует контент из-за этого. Это верно

Единственное решение, по-видимому, состоит в том, чтобы также иметь «запасную» версию сайта для поисковых систем (в частности, Google), где весь HTML и контент будут генерироваться, как это было традиционно, на стороне сервера. Похоже, что для клиентов с включенным JavaScript мы могли бы использовать тот же подход, что и сейчас: использовать JavaScript для генерации HTML из асинхронно загруженного JSON.

Читая, я понимаю, что текущая лучшая практика для применения DRY принцип при создании сканируемых Ajax-сгенерированных веб-сайтов, как описано выше, необходимо использовать механизм шаблонов, который может использовать одинаковые шаблоны на стороне клиента и на стороне сервера. Для клиентов с включенным JavaScript - механизм шаблонов на стороне клиента, например Mustache.js, преобразует данные JSON, отправленные с сервера, в HTML, как определено его копией файла шаблона. А для поисковых роботов и клиентов с отключенным JavaScript - серверная реализация того же механизма шаблонов, например Mustache.java, аналогично, будет работать со своей копией того же самого файла шаблона для вывода HTML.

Если это решение верное, то чем оно отличается от подходов, которые использовались 4 или 5 лет назад на тяжелых сайтах, где сайты должны были поддерживать две копии шаблонного кода, по одной для пользователей с включенным JavaScript (почти для всех ) и другой экземпляр (например, в FreeMarker илиСкорост) для поисковых систем и браузеров без JavaScript (почти нет)? Кажется, должен быть лучший способ.

Означает ли это, что необходимо поддерживать два уровня шаблонных моделей, один на стороне клиента и один на стороне сервера? Насколько целесообразно объединить эти клиентские шаблоны с интерфейсной средой MVC (MV / MVVC), такой как Backbone.js, Ember.js, илиYUI App Library? Как эти решения влияют на стоимость обслуживания? Было бы лучше попробовать сделать это, не добавляя больше фреймворков - новый движок шаблонов и интерфейсный MVC-фреймворк - в технологический стек команды разработчиков? Есть ли способ сделать это менее излишне?

Если это решение не является правильным, то есть что-то, чего мы упускаем и могли бы работать лучше с нашим JavaScript, чтобы сохранить существующую асинхронную структуру HTML-from-JSON и проиндексировать ее, поэтому нам не нужно вводить что-то нового в стеке архитектуры? На самом деле, нам бы не пришлось обновлять две версии уровня представления, когда потребности бизнеса меняются.