Индексация AJAX глазами поискового робота

in Гостевые посты

Поисковой робот, crawler

Автор: Александр Денисенко

В предыдущей статье «Индексация AJAX с точки зрения пользователя и программиста» был рассмотрен один из современных подходов к построению интерактивных веб-интерфейсов с помощью AJAX. Эта технология была описана с позиции пользователя и программиста. В этой статье будет освещен еще один взгляд на AJAX, но уже с позиции поискового робота.

Рассмотрим наглядный пример — стена пользователя или группы ВКонтакте. На странице вы видите только несколько последних записей. Если пролистать страницу вниз, то подгрузятся новые записи. К тому же, чтобы найти информацию месячной давности (не имея прямой ссылки на нее), вам придется долго листать стену вниз. Данные подгружаются средствами JavaScript. Поисковые боты (ПБ) не поддерживают JavaScript. ПБ отличаются от веб-браузеров, и у них нет возможности подгрузить новые данные. Как правило, ПБ не делает клик, а лишь запоминает ссылку для проверки. То есть, будет проиндексирована лишь страница, которую в самом начале отдал веб-сервер.

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

Как видите, AJAX может быть как удобен, так и обладать недостатками. Для ПС отсутствие AJAX на страницах было бы предпочтительнее. Этот подход скрывает полезный контент и прячет некоторые страницы от индексации. Для поисковых ботов индексация таких сайтов раньше была попросту невозможной. Пользователи получали более динамичный и анимационный интерфейс, а SEO-специалисты только разводили руками.

Сегодня часто можно встретить «одностраничные» сайты. Загружается главная страница и только потом нужный контент догружается в ответ на действие пользователя с помощью фонового AJAX запроса. Поскольку технология начала набирать популярность, ПС были вынуждены отреагировать.

В 2009-м году в блоге Google появилась публикация с предложением сделать AJAX сайты индексируемыми.

Яндекс публично заявил о способности индексировать динамический контент в мае 2012 года http://webmaster.ya.ru/replies.xml?item_no=13754.

Читайте также  Мотивация сотрудников, или «Не время браться за голову, хватайтесь за ум»

Оба предложенных решения к счастью веб-разработчиков оказались одинаковы.

Вот как описывает свое решение Яндекс в заметке «Индексирование AJAX сайтов»:

  1. Заменить в URL страниц символ # на #!. Так робот будет понимать, что он может обратиться за HTML-версией контента этой страницы.
  2. HTML-версия контента этой страницы размещается на URL, где #! заменен на ?_escaped_fragment_=.

Сразу же в голове возникает мысль, что можно вручную подставлять вместо хэш-тега в URL _escaped_fragment_, однако Google говорит следующее на своем сайте поддержки в ответе на вопрос «Когда нужно использовать _escaped_fragment_ и #! в URL AJAX?»:

«Сайт должен использовать синтаксис #! во всех URL, поддерживающих схему сканирования AJAX. Робот Googlebot не переходит по гиперссылкам в формате _escaped_fragment_.»

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

ajax индексация сайтовСвязка #! нужна для реализации обхода прямой индексации AJAX. Когда поисковый бот встречает эти два символа, то понимает, что эту ссылку проверять в чистом виде бесполезно. Часть контента по этой ссылке будет скрыта. Вместо этого, делается другой запрос на специальный URL, где #! будут заменены на ?_escaped_fragment_=. Технически, вместо AJAX запроса будет сделан прямой запрос по новому URL с заменой, чтобы получить контент этой страницы. Хэш-теги будут работать только в браузере с поддержкой JavaScript.

На самом деле ПС не реализовали нативной, независимой от кода сайта  индексации AJAX страниц и ссылок. Но они предложили способ, который работает. Решение выглядит не самым лучшим и многих оно до сих пор не устраивает. Вебмастерам приходится делать лишние ухищрения, чтобы выглядеть профессионалами как в глазах пользователей, так и в глазах ПС. Страницы, которые будут запрашиваться с параметром _escaped_fragment_ зачастую приходится создавать дополнительно, что усложняет внутреннее устройство сайта. Многие (большинство) сайтов даже не реализовывают этот вариант, оставляя динамический контент вне поиска.

Еще одно лаконичное описание, из которого видно, насколько AJAX усложняет жизнь разработчиков на примере Twitter

http://www.tbray.org/ongoing/When/201x/2011/02/09/Hash-Blecch.

PushState — часть HTML5 History API

(ссылка на спецификацию).

Кроме подмены URL стандартными средствами JavaScript, в  спецификации HTML5 появился метод pushState, который делает использование AJAX более дружественным. Фактически метод только изменяет текущий URL, который отображается в адресной строке браузера.

Недавно на канале Matt Cutts в Youtube появился видеоответ на вопрос

«Should I use pushState to update my URLs instead of using the hashbang (#!) style to manage AJAX navigation?».

В ответе прозвучало, что для Google предпочтительнее встретить на сайте навигацию, сделанную с помощью pushState. В этом случае ПБ не нужно делать дополнительную работу по перестраиванию запроса с отлавливанием связки #! и использованием замены для получения хорошей ссылки. Это уже весьма радостная новость, но в официальных документах Google детального описания метода обработки использования pushState для навигации пока не обнаружено.

Навигация продолжает работать и ссылки не выглядят так ужасно, как в случае использования хэш-тега.

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

В частности, Twitter объявил хэш-тегам войну http://engineering.twitter.com/2012/05/improving-performance-on-twittercom.html и пошел по пути использования pushState http://engineering.twitter.com/2012/12/implementing-pushstate-for-twittercom_7.html.

2 анекдота в рассылке Гарантированно!
А также получайте всевозможные бонусы, бесплатные билеты и скидки на конференции!