Не мешает ли Angular / Knockout / BackBone поисковым роботам?

Question

[HoHsi]

Собственно решил добавить в арсенал Angular / Knockout / BackBone , но все они меня смущают {{ своими скобочками }}. Мешает ли это при SEO, ведь если meta decription не совпадает в должной мере с контентом, он считается невалидным.

Знаю, что можно делать две версии страницы:
* С зарендаренными элементами.
* С Angular.
Но тогда какой в этом смысл, если я и так могу все зарендарить на стороне сервера?

Answer 1

[_ _]

Используйте Node.JS + JsDom для рендера ангулярного приложения на сервере.
https://github.com/saymedia/angularjs-server
Делайте стабы для компонент, которые гарантированно не участвуют в рендеринге контента, при запуске в режиме сервера.
Сохраняйте результат в кеш.

Answer 2

[malroc]

Поисковой выдаче мешают. Смысл в удобстве для пользователя.
Обычно либо SPA делаются там где в принципе поисковая индексация не предполагается, либо действительно рендеринг дублируется на стороне сервера.

Answer 3

[Алексей П]

Что мешает сделать progressive enhancement?

Comments

[HoHsi]

В таком случае скобочки будут раздражать не только роботов, но и людей

[Алексей П]

HoHsi: значит вы меня не поняли.
Вам нужно сделать 2 версии приложения, грубо говоря, для тех кто понимает js и других, которые не понимают.
Вообще, никто не мешает совместить подход, пример - github.

Answer 4

[Евгений Петров]

на стороне сервера для поисковика пишется отдельный роутинг, на стороне клиента ссылки прописываются в формате например "localhost/developer/carbon/public/#!/catalog" (#!/catalog),

Comments

[HoHsi]

Дзен питона гласит:
"Простое лучше, чем сложное."

Зачем делать одно и тоже по 2 раза, если все можно сделать на сервере?

[Евгений Петров]

на стороне сервера на сделать обработку "_escaped_fragment_" с примесью "отображаемого" контента.. короче ещё много, у гугла есть в api про индексацию web приложений

[malroc]

Так это древний костыль который не нужен после введения history api (т.е. уже года три как). Смысл костыля только в том чтобы поисковик понимал, что URL в таком формате - это именно полноценный роут а не просто хэш. После history api хэш-навигация в SPA не нужна вообще, соответственно не нужен и этот костыль.

[Алексей П]

malroc: напомните об этом Яндексу и бингу

[malroc]

Алексей П о чём? Вы читаете комментарии прежде чем на них отвечать? Джаваскрипт даже в гугле до сих пор нормально не индексируется, это понятно всё. Но при чём тут вот этот костыль с /#!/ ? Он не про индексацию джаваскрипта, а про распознавание хэш-урлов. При этом контент по этим урлам предполагается рендерить, внимание, НА СЕРВЕРЕ.
Никто сейчас не мешает рендерить на сервере контент по тем хе url-ам, которые используются на фронтенде, т.к. на фронтенде после появления history api можно спокойно использовать нормальные url-ы, а не это убожество с хэшем.

[HoHsi]

malroc: а ради каких богов все это? Почему нельзя все по-старинке рендарить на сервере?

[malroc]

HoHsi: ради пользователей конечно же. Скорость, удобство и т.д. Удобно вам будет пользоваться Вконтакте если каждая страница будет грузиться с нуля? Ну то есть вы же представляете как выглядит для пользователя рендеринг каждой страницы на сервере?

[HoHsi]

malroc: представляю. Но к слову, за контактом такого не наблюдал, мне казалось, что они как раз все рендарят на бэке

[malroc]

HoHsi: он рендерит всё на фронтенде ещё со времён когда для этого нужна была хэш-навигация. Да и как бы по-вашему там музыка иначе игралась при навигации?

Answer 5

[namitos]

раз https://github.com/prerender/prerender
два https://gist.github.com/thoop/8165802
три https://yandex.ru/support/webmaster/robot-workings...

сам пререндер подтекает, конечно, надо иногда его перезапускать, но это не смертельно :)