Индексирование на практике

Вопросы, связанные с индексированием, не теряют актуальности. Почему страница не в индексе? Почему поисковик не хочет брать в индекс новые страницы? Что делать, чтобы контент своевременно и в полном объёме попадал в базу данных поисковых систем?

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

В предыдущей статье мы разобрали базовые понятия, связанные с индексами поисковых систем и процессами индексирования. Здесь рассмотрим более практические вопросы, которые помогут вам понять, почему страница не в индексе, или почему сайт в принципе плохо индексируется.

Разумеется, начинать всегда стоит с проверки разрешений. И Гугл, и Яндекс по итогам достаточно послушны, и если им прямо запретить индексирование – они индексировать и не будут.

Помешать им могут несколько основных причин:

Какая логика? Тут могут быть сюрпризы: ПС может запросто склеить не только совершенно разные страницы сайта, но склеить вашу страницу со страницей совсем другого сайта – по совпадению контента или даже части URL. И это не такая уж редкая ситуация – просто её редко вылавливают.

Второй шаг: сопоставьте страницы, открытые для индексирования, с данными из консолей поисковых систем.

Здесь всё достаточно просто. В Screaming Frog SEO Spider можно сразу подключить выгрузку данных Google по API. Да, там есть ограничения, которые можно снять, если сайт вы регистрировали в консоли как доменный ресурс. А можно просто выгрузить данные в табличном формате и работать с ними в Excel для сопоставления со своим списком URL.

Задача этого этапа – получить статистику индексирования и узнать, какие страницы ещё не проиндексированы или уже деиндексированы, и понять почему. Яндекс и Google предоставляют для этого собственные средства и отличающиеся данные, поэтому оценивать стоит исключительно раздельно, не пытаясь обобщать.

Хорошая идея – это сопоставить эти данные со статистикой из серверных логов. Если объём их не слишком велик, а период достаточно продолжителен, можно обнаружить интересные моменты.

Если вам нужно примерно прикинуть состояние пациента (скорее жив, скорее уже мертв и т.п) – эта команда годится. Но даже в благие времена она не давала вам никакой информации о том, что именно и почему не попало в индекс. И разумеется, это хороший вариант, если у вас нет доступа к консоли для вебмастеров.

А теперь небольшая интерлюдия на тему индексов. В статье об индексах и индексировании я уже затрагивал эту тему: не существует единого поискового индекса. Нет даже чёткой и понятной системы взаимосвязанных индексов. Есть множество разрозненных списков URL, метаданных, ключевых слов, текстовых фрагментов, картинок и т.д. и т.п. Пытаясь понять, что происходит вообще и что пошло не так, надо помнить, что цельной системы индексирования не существует. От вас вообще мало что зависит в этом вопросе, есть лишь некоторый обязательный минимум действий, которые вы должны выполнить, чтобы улучшить шансы.

И очистить совесть, разумеется.

Кэшированная версия страницы – это всего лишь то, что поисковая система скачала в последний раз. Сохраненная копия страницы. Можно ли о чём-то судить по кэшу? – Нет.

Кэшированная версия на выдаче предназначена для единственной цели: если сайт по какой-то причине недоступен, можно посмотреть кэш.

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

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

В этом, кстати, и дополнительная ценность кэшированной версии для анализа: вы можете узнать дату последнего сканирования без серверных логов. Если сервер на запрос не ответил кодом 304 (контент не обновлялся), дата всё равно будет обновлена в случае обращения робота к странице

К слову: Google анонсировал ликвидацию ссылок на кэшированные данные. Сами данные пока доступны (актуальность – февраль 2024). Будут ли они доступны впредь – неизвестно.

Что нужно сделать, чтобы уменьшить вероятность ошибок индексирования и увеличить шансы попадания данных в базы данных поисковых систем? Разберем последовательно.

robots.tхt

Убедитесь, что поисковые роботы имеют возможность скачать/просканировать заданный URL. Эта возможность регулируется файлом директив для поисковых роботов robots.txt. Не используйте robots.txt для управления индексированием: директивы на этом уровне управляют сканированием, не индексированием. Поисковым роботам совершенно нечего делать в административной части сайта, тратить время на сканирование пользовательских ресурсов (например, «Избранного» или «Корзины»).

Запрет доступа на уровне robots.txt вовсе не значит, что URL не попадёт в поисковую выдачу. Более того, если запретить доступ к URL, то поисковая система и не узнает, можно ли индексировать страницу или нельзя, потому что не сможет прочитать контент. Но оценить страницу поисковик может и не сканируя страницу, просто используя данные других страниц в рамках сайта и за его пределами.

Директива Noindex

Директива Noindex – прямое указание роботу, индексировать страницу или нет. Реализуется она двумя способами:

Вы должны учитывать, что URL вполне может содержать две противоречивые директивы: одна в HTTP-заголовке, другая - в метатеге. Проверяйте обе, а не только метатег в коде. По умолчанию x-robots-tag имеет приоритет перед метатегом.

Тег Canonical

Этот тег указывает поисковой системе, что этот URL не должен быть внесен в индекс, а должен быть склеен с другой страницей. Разумеется, такие страницы должны быть фактически идентичны, иначе склеивания не произойдёт. Если на вашем сайте есть много практически повторяющихся страниц, с помощью тега Canonical вы можете указать предпочтительную версию страницы.

Фактически Canonical работает как своего рода редирект. Важно, чтобы URL, указанный как канонический, был разрешен для сканирования, индексирования и отдавал код 200.

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

Итак, мы убедились, что страница не закрыта для сканирования в robots.txt, не содержит тега noindex ни в серверном заголовке (x-robots-tag), ни в метатеге "robots". У неё нет канонической ссылки, указывающей на другую страницу, а URL не содержит параметров, на основании которых поисковая система решит склеить этот URL с каким-то другим.

Clean-param

Эту директиву понимает только Яндекс, но пренебрегать ей не стоит: Яндекс в рамках рунета намного активнее гуглобота, и в процессе этой активности может много ресурсов потратить на обход и индексирование ненужных URL. С помощью Clean-param вы указываете, что URL с заданными параметрами нужно склеить с основным URL без этих параметров.

Это очень удобная и практичная опция: вместо того, чтобы просто запрещать сканирование и индексирование технических адресов или каких-нибудь UTM-меток, вы добавляете «веса» целевым URL.

Sitemap.xml

Да, карта сайта в формате sitemap.xml – тоже важный сигнал для поисковой системы, определяющий, нужно ли индексировать страницу. Изначально карта сайта имела две основные цели:

Фактически, сейчас sitemap.xml используется как простой список адресов для обхода. Всё, что попадает в этот список, рассматривается как индексируемое и важное. Поэтому следите за тем, чтобы в списке не было «битых» URL, отдающих что-то кроме кода 200, закрытых от сканирования и индексирования, с другим каноническим URL и т.п. Отсутствие URL в sitemap.xml почти ничего не значит (если страницу вообще можно найти по ссылкам), а вот присутствие влияет на индексирование этой страницы и процессы индексирования всего хоста. Если sitemap.xml предоставляет роботу ложные данные, ПС может счесть хост неоптимизированным технически.

Sitemap.xml должен содержать только канонические индексируемые URL, отдающие код 200. Без исключения.

С картой сайта в формате sitemap.xml связан один важный нюанс: если на страницу есть ссылка только из сайтмапа, индексироваться и ранжироваться страница будет всё-таки плохо. Это изолированная страница, полностью выпадающая из общей структуры и не имеющая никакого веса.

Альтернативные версии страницы

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

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

Внутренняя перелинковка и внешние ссылки

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

Правильная перелинковка помогает поисковой системе оценить важность страницы в рамках сайта. Важность (или «вес») определяется возможностью перехода посетителя на эту страницу с другой страницы. Чем выше вероятность – тем выше статический вес.

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

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

Микроразметка

Если вы до сих пор рассматриваете микроразметку как способ формировать желаемый сниппет на выдаче, время понемножку пересматривать взгляды. Schema.org предоставляет средства, позволяющие связать воедино данные как в рамках сайта, так и с другими сайтами.

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

Фактически, сейчас это используется в минимальных объёмах и едва ли на что-то влияет всерьёз. Однако вы должны понимать, что в метаданных вашей страницы могут быть ссылки, благодаря которым поисковые алгоритмы могут определять каноническую страницу, источник информации и связывать опубликованные данные с графом знаний. Как минимум, поисковые роботы видят URL в микроразметке и могут переходить по таким ссылкам.

Сложность аудита индексирования заключается в том, что вы не можете оценить страницу изолированно. Оценивается только комплекс. Почему? – Несколько примеров.

Для того, чтобы понимать причины и следствия, нужна максимально полная картина. Составить её можно благодаря данным SEO-сканеров уровня Screaming Frog SEO Spider, данных серверных журналов access_log и данных из консолей поисковых систем. Но даже это не может дать вам абсолютно полной картины: поисковые системы не предоставляют всех имеющихся у них данных.

Хуже того: эти данные нигде в готовом виде и не собираются. Пример: ваша совершенно новая страничка с уникальным текстом склеивается с другой, с чужого сайта, даже без совпадения контента. Почему? – Кусок URL совпадает в точности. Это баг, такого не должно быть. Но это бывает – и не так уж и редко. Если у вас есть привычка изучать сохраненные версии на выдаче – вы наверняка такое видели.

А ведь это только техническая сторона вопроса – самое простое. Следующая стадия – оценка реальной ценности и значимости страницы и сайта для поисковой системы.

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

Как уже было сказано, эта стадия оценки страницы намного сложнее технического аудита, поскольку оценивает уже не количественные, а качественные характеристики: тематику, релевантность, полноту соответствия пользовательским запросам. Одна и та же страница может соответствовать множеству непересекающихся кластеров ключевых слов. И выбор запросов далеко не всегда основывается на словах конкретной страницы. Вместо этого может использоваться история запроса, история конкретного URL, текст входящих ссылок и т.п.

Для базовой оценки релевантности на этом уровне достаточно оценить текстовый контент (tf-idf, bm25, word2vec и т.п.) чтобы понять, насколько страница укладывается в общие шаблоны. Помимо этого, нужно оценить и тематику, определяемую классификаторами. Вы, к примеру, считаете свою статью научной, а Google счёл её посвященной теме оккультизма и паранормального – и всё, по каким-то запросам вас показывать не будут.

На этом же этапе оценивается и семантическое дублирование. На вашем сайте может быть несколько страниц, одинаково хорошо соответствующих одному и тому же запросу (чаще всего общего характера). Технически это не дубли. Такие документы могут иметь совершенно разный тип, структуру, реальный смысл. Классика жанра: тонны однотипного UGC на vc.ru (см. скриншот).

Не надо стремиться загнать в индекс абсолютно всё. Оценивайте свой сайт здраво: можете ли вы уверенно сказать, что в индексе нужны вот эти теговые страницы, фактически не содержащие полезного контента? Или однообразные и почти одинаковые товарные карточки?

С точки зрения поисковой системы всё это – напрасный расход вычислительных мощностей и других машинных ресурсов. Если поисковик признает сайт недостаточно качественным и востребованным пользователями, он по итогам сократит ресурсы на обход и действительно ценных и важных страниц. Попадание в индекс некачественных страниц вредит сайту.

Проблема с индексированием никуда не денется в ближайшее время. Напротив, она будет только расти, и это совершенно нормально.

Индексирование выходит далеко за пределы разрешающих директив в robots.txt или метатегах. Оценивайте задачи комплексно, не ограничиваясь данными одной страницы, раздела и даже сайта.