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

Продолжаю цикл постов об индексации сайта (см. ранее об основных способах ее ускорения и использовании 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: а вот и продолжение.