Какой самый простой способ сделать сайт с HTML-кодом, созданным с помощью JavaScript, доступным для сканирования?

После прочтения Google политики в отношении возможности сканирования контента, созданного с помощью Ajax, наряду со многими сообщениями в блогах разработчиков и потоками вопросов и ответов Stackoverflow по этому вопросу, я пришел к выводу, что нет никакого способа сделать сайт только с помощью JavaScript/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или Velocity) для поисковых систем и браузеров без включенного JavaScript (почти ни у кого)? Кажется, должен быть лучший способ.

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

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