Сеть для ботов: ещё один способ улучшить сканирование сайта поисковиками (и не только)

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

Ловец ботов

Схема предложена Евгением и Олегом Шестаковыми, затем доработана Дмитрием Шаховым. Вот его доклад на SEMPro 2016:

 

Для тех, кому лень листать презентацию (напрасно, кстати) — основные тезисы, кратко.

В продвижении многостраничных сайтов есть ряд типичных затруднений:

  • Не до всех страниц роботы могут добраться легко и быстро.
  • Размер проекта как таковой: не хватает краулингового бюджета, чтобы в индексе была актуальная версия сайта. Особенно остро эта проблема стоит в связи с тем, что Яндекс в последние пару лет стал менее активно следовать инструкциям, которые связаны с заголовками Last-Modified и If-Modified-Since.
  • Трудно отслеживать появление проблемных страниц (где срезало трафик, с исчезнувшим контентом и т.д.) — а их накопление может серьезно влиять на посещаемость.

Эти проблемы и решает ловец ботов — программный комплекс для автоматизированного контроля за индексом и качеством страниц а также оперативного подсовывания поисковику нужных ссылок (да простят меня разработчики за это упрощение).

Зачем изобретать что-то еще?

Схема ловца видится мне весьма элегантной и практичной. Однако и у нее есть некоторые сомнительные места.

  1. Фильтрация по User-Agent. Хотя Дмитрий вполне убедительно показывает, что «Это не клоака!» (слайд 9) идея формировать контент для роботов и для людей по-разному мне несколько неприятна. Особенно — если работаем не с заброшенным сателлитом, а с серьезным порталом.
  2. Против стратегии «роботам так, людям — этак» есть и более весомые аргументы, чем сеошная профессиональная деформация. Вряд ли кто-то будет спорить в 2016 году, что доступность страницы для робота по внутренней ссылке — это не единственное, что влияет на попадание документа в индекс привередливых поисковиков. Например, неплохо, если по ссылке будут кликать. А клики зафиксируются Метрикой или Яндекс.Браузером. Не повредит, если на непроиндексированную страницу указывает не одна, а 20-30 ссылок. Ну и так далее.
  3. Взгляните на слайд 9 внимательно. На одной странице представлены анкоры, весьма слабо соотносящиеся по тематике. Не слишком удачно выглядит уже соседство краски для бровей и туалетной воды. Под еще большим вопросом — добавление к косметическим средствам литых дисков и сетевого фильтра. Наконец, в одном и том же блоке смешаны ссылки на товары и на теговые страницы. Не думаю, что это будет высоко оценено поисковыми системами.
  4. Предыдущие пункты тем более важны, что качество контента (еще один фактор, влияющий на допуск в индекс) на многостраничниках зачастую невысоко. Например, предложения на доске объявлений бывают идентичны на десятке ресурсов и состоят из пары неграмотных предложений. Агрегаторы интернет-магазинов далеко не всегда могут обеспечить развернутые и структурированные описания для карточек товаров. На мой взгляд, проблема в индексации больших сайтов не столько в том, чтобы заставить Яндекс пробежаться по всем страницам. На это успешно работает множество разных методов. «Узкое горло» — в попадании посещенных роботом страниц в индекс. Поэтому нужно выжать максимум из других внутренних факторов. По возможности — в автоматическом режиме.
  5. На страницах с рандомным блоком ссылок, куда транслируется стек «на индексацию» нельзя/нет смысла отдавать 304 в ответ на If-Modified-Since (а ведь для Google это работает, и неплохо).
  6. Внедрение системы требует времени и ресурсов («2 месяца одного программиста + авторский надзор сеошника»). На самом деле не так уж много для большого проекта, но всегда есть желание сэкономить, упростив некоторые детали.

Как можно устранить эти недостатки?

Я использую схему, где есть несколько принципиальных изменений.

Во-первых, информация о посещенных роботами и пользователями поисковиков страницах мониторится с помощью логов сервера.

Это очень просто реализовать: access.log для того и создан, чтобы из него было просто извлекать данные. Кроме того, такая система нетребовательна к ресурсам (а real-time отслеживание роботов требует лишних запросов к БД во время генерации страницы).

Во-вторых, не используются специальные блоки «для пауков», весь контент ориентирован одновременно и на людей, и на поисковики.

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

Поясню этот момент. Допустим, нам нужно продумать, как реализовать вывод похожих товаров в интернет-магазине. Простейший способ: выделяем признаки моделей, которые могут заинтересовать потенциального покупателя, отталкиваясь от факта его нахождения на странице конкретного товарного предложения. Удобно отражать эти критерии с помощью диаграммы Венна:

 

На пересечении кругов находятся товары, которые будет уместно демонстрировать с точки зрения удобства пользователя и конверсии. Это базовый алгоритм. А теперь мы закладываем в него дополнительные параметры и получаем немного другой список ссылок.

 

С помощью SEO-настройки базового алгоритма добиваемся массового появления ссылок на непроиндексированные документы. А благодаря тому, что они располагаются сразу после основного контента и полезны для посетителей — им обеспечено и некоторое количество кликов. Это (см. выше) способствует индексации. Периодически будут появляться ссылки на другие не посещенные роботом страницы (ротация в соответствии с накоплением статистики о визитах). Но ссылки выводятся всегда только уместные на конкретной странице!

Учитывая, насколько критична на данном этапе задача обеспечить полное сканирование сайта, можно менять «вес» SEO-нужд в алгоритме, показывать больше или меньше ссылок, на которые требуется заманить робота. Также никто не запрещает вынести долго сидящие в стеке «на индексацию» страницы в отдельный хаб. Разумеется — опять же принимая во внимание пользовательскую логику; таким образом добиваемся еще и улучшения структуры сайта.

По аналогии с «ловцом ботов» назвал схему «сеть для ботов». Ловец — это активный рыбак со спиннингом, чутко реагирующий на каждое движение поисковых пауков. А сеть мы просто ставим на некоторое время, затем вытаскиваем, считаем улов и забрасываем в другое место (а может, слегка латаем или меняем размер ячеек).

Из этого сравнения легко понять сравнительные преимущества и недостатки обоих подходов. «Ловец» обеспечивает максимально возможное количество попаданий ссылок на непроиндексированные документы в поле зрения робота. «Сеть» отчасти жертвует количеством попаданий ради большей естественности и в надежде положительно воздействовать на внутренние факторы.

«Сеть», пожалуй, проще сделать на новом проекте, когда не надо менять налаженные схемы перелинковки. Вообще, мой вариант требует более глубокой интеграции с сайтом; «ловца» же можно использовать как отдельное решение, надстройку. Точнее, максимальной самостоятельностью будет обладать гибрид: мониторим с помощью логов, а ссылки выводим рандомно в дополнительном блоке.

Что касается поиска плохих страниц («трэшбокс»), то особой разницы здесь нет. Так как работа с плохими страницами ведется значительно позже регистрации действий роботов, то фактор «real-time отслеживание или нет» не играет роли.

Что с практикой?

Я реализовал эту схему на паре проектов. Опыт сравнительно небольшой, так как она уместна только на крупных сайтах. Кроме того, для нее требуется хорошая координация с заказчиком и его реальная готовность к серьезным доработкам (а таких клиентов немного). С индексацией и трафиком там все хорошо. Честно говоря, не представляю, как можно достоверно отследить вклад именно «сети для ботов», если она была на сайте с самого начала. В обоих случаях внедрялось немало других рекомендаций по повышению полноты индекса, каждый сайт такого размера уникален.

Могу сказать, что «сеть» точно не повредила. Да и вообще, система нужна не только для контроля индексации. Собранные данные полезны как исходный материал для обоснованных решений по другим вопросам оптимизации. Но об этом — как-нибудь в другой раз. Оставайтесь на связи!

UPD: а вот и продолжение.

Поделиться
Отправить
Плюсануть

Читайте также
  • seoonly.ru
    24.03.2016

    Спасибо, презенташка и правда крутая

    Ответить
  • Марго
    30.03.2016

    Интересная идея. Нужно попробовать на каком-нибудь сайте)

    Ответить
    • Алексей Трудов
      30.03.2016

      Спасибо, буду рад если потом расскажите о результатах!

      Ответить
  • Лютый Бомж
    11.01.2017

    Грамотно, а про техническую реализацию можно где-то поподробней посмотреть. Ну там готовый плагин для wordpress или типо того? 🙂

    Ответить
    • Алексей Трудов
      11.01.2017

      Такое пишется под конкретный проект 😉
      Не думаю, что кто-то озаботится универсальным решением — система актуальна для штучных больших сайтов.

      Ответить

Добавить комментарий

 

Публикуя комментарий, вы соглашаетесь с правилами http://alexeytrudov.com/terms/