Исследование обновления индекса сайта в Яндексе
В прошлой статье я описывал, как мы у себя в агентстве проводим анализ индексации сайта поисковой системой Яндекс при помощи нового Вебмастера. Недавно Яндекс обновил кабинет Вебмастера, добавив возможность следить за изменением индексации сайта практически в режиме реального времени.
Подробно о всех возможностях этого инструмента можно прочитать в справке Яндекса.
Мы всегда старались держать руку на пульсе, проверяя страницы своими инструментами, и появление готового сервиса от Яндекса стало для нас настоящим подарком. В этой статье я хочу рассказать о том, как мы используем «Страницы в поиске» в своей работе.
Использование инструмента «Страницы в поиске»
Мы проверяем, что изменилось в индексации сайта после каждого текстового апдейта Яндекса.
Цель проверки — узнать, какие страницы были включены в индекс, какие страницы были исключены из индекса и по какой причине. Выработать решение о том, что с этим всем делать.
Получаем список обновленных страниц
Для того, чтобы получить список обновленных страниц:
1. Заходим в Яндекс Вебмастер, выбираем нужный сайт;
2. Нажимаем в левом меню «Индексирование» — «Страницы в поиске» или нажимаем на главной странице на заголовок блока «Обновление поиска по…»;
3. На открывшейся странице спускаемся внизу и нажимаем кнопку «XLS» в блоке «Скачать таблицу»;

4. Получаем Excel-файл с последними обновлениями индексации сайта в Яндексе.
Анализируем файл обновления индекса
В полученном файле будут следующие столбцы:
- updateDate — дата обновления поисковой базы, в которую попали страницы;
- url — адрес обновленной страницы;
- httpCode — HTTP-код, полученный роботом во время последнего обхода страницы;
- status — статус страницы;
- target — адрес страницы, на которую происходит перенаправление, или отображаемый в результатах поиска адрес;
- lastAccess — дата последнего посещения страницы роботом;
- title — заголовок страницы;
- event — действие, произошедшее со страницей (добавление или исключение из поиска):
- ADD — страница добавлена в индекс;
- DELETE — страница удалена из индекса.
Приступаем к анализу файла:
Важное замечание: Если ранее вы уже анализировали индексацию страниц, в столбце updateDate выбирайте даты после последнего анализа.
Если проверяете индексацию в первый раз, то проверяйте весь список.
1. Открываем файл в Excel, выделяем всю таблицу с данными и активируем фильтр («Главная» — «Сортировка и фильтры» — «Фильтр»);

2. Проверяем, какие страницы попали в индекс. Для это в колонке «Event» оставляем значение «ADD»:

○ Просматриваем колонку «URL» на наличие подозрительных и аномальных страниц;
○ Если обнаруживаем проблему, делаем техническое задание на устранение этой проблемы.
Примеры аномальных и подозрительных страниц и способ их устранить:
Страницы |
Решение |
Страницы с параметрами |
|
Страницы с нетипичной вложенности для сайта |
|
Страницы с нетипичным окончанием. Если обычный для сайта URL заканчивается на «/», а в списке есть страницы без «/» на конце или с расширением на конце (.htm / .html / .php / …) |
|
|
|
Другие |
В зависимости от причины. |
○ URL, которые были проверен можно удалить из файла, чтобы они не мешали.
3. Проверяем, какие страницы были удалены из индекса. Для это в колонке «Event» оставляем значение «DELETE»:
○ Проверяем все причины исключения страниц из индекса. Для этого в колонке «status» поочередно оставляем каждый из видов ошибок и проверяем страницы.
Возможные статусы, что они означают и варианты лечения:
Значение status |
Расшифровка |
Как решать |
BAD_QUALITY |
Страница считается некачественной |
Смотрим страницу и ищем причину исключения.
|
CLEAN_PARAMS |
Страница работает через параметры, которые почищены в robots.txt директивой Clean-param |
Если все правильно, то нужно заменить в robots.txt clean-param на Disallow, так как на обход по Clean-param тратится краулинговый бюджет. |
DUPLICATE |
Страница является дублем страницы по другому URL |
Посмотреть причину, по которой страница оказалась дублем.
|
HOST_ERROR |
При обращении к сайту роботу не удалось установить соединение с сервером |
Проверить код ответа сервера. Скорее всего, он будет 50*. Исправить код ответа и отправить страницу в очередь на переобход. |
HTTP_ERROR |
При обращении к странице возникла ошибка |
Проверить код ответа сервера. Скорее всего он будет 50*. Исправить код ответа и отправить страницу в очередь на переобход. |
META_NO_INDEX |
На странице есть метатег robots noindex (none) |
Посмотреть, почему на странице noindex. Скорее всего, это страница пагинации. В таком случае убрать noindex и уникализировать заголовки подписью «- Страница 2 (3…)». |
NOT_CANONICAL |
На странице есть метатег canonical с указанием на другую страницу |
Посмотреть, почему на странице canonical с указанием другой страницы.
|
NOT_MAIN_MIRROR |
Страница относится к неглавному зеркалу сайта, поэтому была исключена из поиска |
Установить 301 серверный редирект со всех страниц неглавного зеркала на аналогичные страницы на главном зеркале. |
OTHER |
Страница известна роботу, но не участвует в поиске |
Проверить код ответа сервера. Скорее всего он будет 50*. Исправить код ответа и отправить страницу в очередь на переобход. |
PARSER_ERROR |
При обращении к странице роботу не удалось получить ее содержимое |
Проверить код ответа сервера. Скорее всего он будет 50*. Исправить код ответа и отправить страницу в очередь на переобход. |
REDIRECT_SEARCHABLE |
Страница осуществляет перенаправление, но находится в поиске |
На страницу есть ссылка (внешняя или внутренняя), но сама страница отдает 30* редирект. Проверить 302 это редирект, если да, то заменить на 301. Проверить внутренние ссылки, если они есть, заменить их на прямые. |
REDIRECT_NOTSEARCHABLE |
Страница осуществляет перенаправление, при котором индексируется его цель |
На страницу есть ссылка (внешняя или внутренняя), но сама страница отдает 30* редирект. Проверить 302 это редирект, если да, то заменить на 301. Проверить внутренние ссылки, если они есть, заменить их на прямые. |
ROBOTS_HOST_ERROR |
Индексирование сайта запрещено в файле robots.txt. Робот автоматически начнет посещать страницу, когда сайт станет доступен для индексирования |
Проверить robots.txt на запрещение индексации сайта. Если есть запрет, то убрать его. Если запрет нужен, проверить нет ли внутренних ссылок на эту страницу. |
ROBOTS_TXT_ERROR |
Индексирование сайта запрещено в файле robots.txt. Робот автоматически начнет посещать страницу, когда сайт станет доступен для индексирования |
Проверить robots.txt на запрещение индексации сайта. Если есть запрет, то убрать его. Если запрет нужен, проверить нет ли внутренних ссылок на эту страницу. |
SEARCHABLE |
Страница находится в поиске |
|
○ Если обнаруживаем проблему, делаем техническое задание на устранение этой проблемы.
Заключение
Проверяя таким простым способом индексацию своего сайта после каждого текстового апдейта Яндекса, можно избежать многих проблем в будущем.
Если у вас есть вопросы, пишите задавайте их здесь в комментариях. Разберемся вместе :)
![]() ![]() ![]() |
Друзья, теперь вы можете поддержать SEOnews https://pay.cloudtips.ru/p/8828f772 Ваши донаты помогут нам развивать издание и дальше радовать вас полезным контентом. |
![]() ![]() ![]() |
Есть о чем рассказать? Тогда присылайте свои материалы Марине Ибушевой
-
Руслан, если на странице пагинации есть мета-тег robots noindex, follow, очевидно, что она будет исключена из индексной базы, но зачем убирать данный мета-тег и уникализировать заголовки страниц, если на страницах пагинации по сути только дублирование информации с самих карточек товаров (например, в интернет-магазине)?
Можно оптимизировать страницы пагинации под регионы, но по факту от такой оптимизации переходов с поиска на страницы пагинации не увеличивается.
И ещ...Руслан, если на странице пагинации есть мета-тег robots noindex, follow, очевидно, что она будет исключена из индексной базы, но зачем убирать данный мета-тег и уникализировать заголовки страниц, если на страницах пагинации по сути только дублирование информации с самих карточек товаров (например, в интернет-магазине)?
Можно оптимизировать страницы пагинации под регионы, но по факту от такой оптимизации переходов с поиска на страницы пагинации не увеличивается.
И еще такой вопрос, чем отличиются статус ROBOTS_HOST_ERROR от ROBOTS_TXT_ERROR? -
Что там про краулинговый бюджет? Это с каких пор он перестал тратиться на disallow?
developers.google.com/webmasters/control-crawl-index/docs/faq#h17
Как раз в этой схеме он будет расходоваться. А вот при настройке clean-param (параметры url для гугла) - не должен.-
Филипп, спасибо за интересный вопрос.
В той ссылке, которую вы приводите, если вы пользуетесь версией справки на русском языке, в ней есть неточность в переводе. Если вы выбрать английский язык, там сказано: "However, robots.txt Disallow does not guarantee that a page will not appear in results: Google may still decide, based on external information such as incoming links, that it is relevant.". То есть речь идет не о сканировании, а о присутствуй в результатах поиска и ранжир...Филипп, спасибо за интересный вопрос.
В той ссылке, которую вы приводите, если вы пользуетесь версией справки на русском языке, в ней есть неточность в переводе. Если вы выбрать английский язык, там сказано: "However, robots.txt Disallow does not guarantee that a page will not appear in results: Google may still decide, based on external information such as incoming links, that it is relevant.". То есть речь идет не о сканировании, а о присутствуй в результатах поиска и ранжировании страницы, запрещенной при помощи disallow.
Что касается директивы clean-param, я тоже долгое время считал ее отличным решением для некоторых задач по оптимизации сайта. Пока мой коллега не обратил внимание на аномальную статистику обхода на одном из сайтов. Я решил уточнить, тратится ли бюджет на обход страниц, "подчищенных" директивой celan-param в поддержке яндекса, на что получил ответ: "Директива Clean-param не запрещает роботу индексировать страницы, поэтому робот действительно может тратить время на их посещение. Чтобы этого не происходило, лучше использовать Disallow" (скриншот письма yadi.sk/i/uJvLarko3GjeQD).
Что касается "Параметры url" в google search console, если честно, я не задавался таким вопросом, но в официальном пояснения google сказано "Any URL that is crawled affects crawl budget", а работа инструмента описывается как "Google stop crawling pages". Исходя из этого, можно сказать, что с большой вероятностью данный инструмент Google помогает сохранить краулинговый бюджет.
Надеюсь, мой ответ окажется вам полезным.-
Насчет clean-param - получается что-то странное. Налицо противоречие Платона с его же собственным хелпом yadi.sk/d/Jgo5Yh183Gk5aZ - в одном случае они говорят, что робот тратит на них время, в другом - что он умный и сразу сводит все урлы в один снижая нагрузку на сервер. Хотя, в обоих случаях фигурирует "может". А может и не может.
Мне почему больше нравится клин-парам - он (по логике) работает аналогично с rel=canonical, т.е. сводит несколько адресо...Насчет clean-param - получается что-то странное. Налицо противоречие Платона с его же собственным хелпом yadi.sk/d/Jgo5Yh183Gk5aZ - в одном случае они говорят, что робот тратит на них время, в другом - что он умный и сразу сводит все урлы в один снижая нагрузку на сервер. Хотя, в обоих случаях фигурирует "может". А может и не может.
Мне почему больше нравится клин-парам - он (по логике) работает аналогично с rel=canonical, т.е. сводит несколько адресов к одному виду, что дает какую-то надежду на передачу веса итоговой странице, тогда как запрет индексации - просто запрет.
Google - здесь я неправ, пожалуй, в том, что это вообще оффтоп. У него Немного другая политика индексирования и вообще в статье речь про яндекс :) Так что черт с ним.
-






























