При работе над оптимизацией сайта специалисты часто сталкиваются с такой дилеммой:

Сайты, использующие AJAX для загрузки данных в страницу могут быть гораздо более быстрыми и удобными для пользователя. НО: эти веб-сайты могут быть трудны (или невозможны) для сканирования Google, и таким образом использование AJAX может повредить продвижению сайта.

К счастью, Google сделал предложение о том, как веб-мастера могут убить двух зайцев. Ссылки на документацию Google будут приведены в конце, поскольку это все сводится к относительно простым понятиям.

Хотя Google сделал это предложение год назад, видимо, оно не привлекло большого внимания оптимизаторов, хотя им оно должно быть особенно полезно. Этот пост предназначен для людей, которые еще не изучили  предложение Google по сканированию  AJAX – и поэтому он написан коротко и без лишних технических деталей.

Основы

По сути, если сайт следует этому предложению, он должен сделать доступными две версии его содержания:

1. Контент для пользователей с включенным JS на адресах в “стиле AJAX”

2. Контент для поисковых систем, на статическом “традиционном” URL – Google относится к этому как “HTML-снимку”.

Исторически сложилось так, что разработчики использовали  анкорные части URL-адреса на AJAX-сайтах (это ‘хэш’ символ, #, и текст после него).  Это хорошо для пользователя, но поисковая система не может справиться с этим.

Вместо того чтобы использовать хэш, # , новое предложение требует использования хэша и восклицательного знака: #!

Сочетание ! #  иногда называют hashbang (хэшбэнг), так и будем его обозначать.

Сканирование протокола AJAX

Как только вы начнете использовать хешбэнг в URL, Google определит, что вы следуете его протоколу, и будет интерпретировать ваши URL-адреса в особым образом – они будут брать все после hashbang, и передавать его на сайт вместо параметра URL. Название, которое они используют для параметра:_escaped_fragment_

Google будет переписывать URL, и запрашивать контент со статических страниц. Чтобы показать, как выглядят  переписанные URL, вот несколько примеров:

  • www.demo.com/ #!seattle/hotels становится www.demo.com/?_escaped_fragment=seattle/hotels
  • www.demo.com/users#!name=rob становится www.demo.com/users?_escaped_fragment_=name=rob

Пока вы можете получать статические страницы (правый URL в этих примерах), чтобы отобразить тот же контент, что будет видеть пользователь (левая URL), она будет работать так, как следует.

Два предложения по поводу статических адресов

Пока Google возвращает статические URL-адреса в индекс – это имеет смысл, поскольку они не хотят, чтобы причинялся ущерб тем пользователям, которые не используют JS, отправляя их на страницу, которая требует Javascript. По этой причине, сайты могут хотеть добавить Javascript, который будут выявлять пользователей с включенным JS, и привязывать их к “расширенной” AJAX версии страницы, которую они просматривают.

Кроме того, маложелательно, чтобы ваши индексированные URL-адреса показывались в результатах поиска с параметром “_escaped_fragment_”. Этого можно легко избежать, если “статическая версия” ваших страниц находится на более привлекательных URL-адресах, и использовать 301 редирект, чтобы направить поискового паука из _escaped_parameter_ версии к более привлекательному варианту.

В примере выше, на сайте могут принять решение о 301 редиректе от

www.demo.com?_escaped_fragment=seattle/hotels к www.demo.com / каталог / Сиэтл / Гостиницы

Живой пример

К счастью для нас, есть большая уже готовая демонстрация этого предложения на довольно большом веб-сайте: новой версии Twitter .

Если вы пользователь Twitter, войдите в систему, и вы получите Javascript, по которому вы сможете увидеть свой профиль здесь:

  • http://twitter.com/ #! / RobOusbey

Тем не менее, робот Google будет распознавать это как URL в новом формате вместо запроса URL:

  • http://twitter.com/?_escaped_fragment_=/RobOusbey

Разумно, что Twitter хочет поддержать обратную совместимость (чтобы индексируемые URL-адреса не выглядели как мусор), поэтому идет 301 редирект на URL:

  • http://twitter.com/RobOusbey

(И если вы вошли в Twitter как пользователь, этот URL фактически перенаправит вас к первому).

Больше по теме

Лучшее место для дальнейшего чтения по этой теме, безусловно, страницы помощи Google. Они дают информацию о том, как сайты должны работать, чтобы соответствовать этому предложению, и содержат некоторые интересные советы по реализации, такие как использование манипуляций серверным DOM для создания моментальных снимков.

Центральной блог  веб-мастеров Google сделал официальный анонс этого , и Джон Мюллер предложил обсудить эту тему WMC форумах.

Используя блог Google, форум и справку, вы должны найти все необходимое, чтобы превратить ваши фантазии по AJAX сайтам в то, что Google будет любить, так же, как и пользователи . Удачи!