Войти как пользователь
Вы можете войти на сайт, если вы зарегистрированы на одном из этих сервисов:
Россия +7 (909) 261-97-71
6 Апреля 2017 в 14:21

Исследование обновления индекса сайта в Яндексе

Россия +7 (909) 261-97-71
5 30345
Подпишитесь на нас в Telegram
Руслан Фатхутдинов
Веб-аналитик агентства Реаспект
Редактор Telegram-канала

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

Подробно о всех возможностях этого инструмента можно прочитать в справке Яндекса.

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

Использование инструмента «Страницы в поиске»

Мы проверяем, что изменилось в индексации сайта после каждого текстового апдейта Яндекса.

Цель проверки — узнать, какие страницы были включены в индекс, какие страницы были исключены из индекса и по какой причине. Выработать решение о том, что с этим всем делать.

Получаем список обновленных страниц

Для того, чтобы получить список обновленных страниц:

1. Заходим в Яндекс Вебмастер, выбираем нужный сайт;

2. Нажимаем в левом меню «Индексирование»«Страницы в поиске» или нажимаем на главной странице на заголовок блока «Обновление поиска по…»;

Сводка Яндекс Вебмастера

Рис. 1. Отчет «Страницы в поиске» в Яндекс.Вебмастере

3. На открывшейся странице спускаемся внизу и нажимаем кнопку «XLS» в блоке «Скачать таблицу»;

Страницы в поиске в Яндекс Вебмастере
Рис. 2. Выгрузка списка страниц

4. Получаем Excel-файл с последними обновлениями индексации сайта в Яндексе.

Анализируем файл обновления индекса

В полученном файле будут следующие столбцы:

  • updateDate — дата обновления поисковой базы, в которую попали страницы;
  • url — адрес обновленной страницы;
  • httpCode — HTTP-код, полученный роботом во время последнего обхода страницы;
  • status — статус страницы;
  • target — адрес страницы, на которую происходит перенаправление, или отображаемый в результатах поиска адрес;
  • lastAccess — дата последнего посещения страницы роботом;
  • title — заголовок страницы;
  • event — действие, произошедшее со страницей (добавление или исключение из поиска):
    • ADD — страница добавлена в индекс;
    • DELETE — страница удалена из индекса.

Приступаем к анализу файла:

Важное замечание: Если ранее вы уже анализировали индексацию страниц, в столбце updateDate выбирайте даты после последнего анализа.

Если проверяете индексацию в первый раз, то проверяйте весь список.

1. Открываем файл в Excel, выделяем всю таблицу с данными и активируем фильтр («Главная» — «Сортировка и фильтры» — «Фильтр»);

Включение фильтров в Excel по страницам в поиске
Рис. 3. Включение фильтров в Excel

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

Фильтрация по страницам в индексе
Рис. 4. Задание фильтра попавших в индекс страниц

○ Просматриваем колонку «URL» на наличие подозрительных и аномальных страниц;

○ Если обнаруживаем проблему, делаем техническое задание на устранение этой проблемы.

Примеры аномальных и подозрительных страниц и способ их устранить:

Страницы

Решение

Страницы с параметрами

  • Закрыть параметры в robots.txt;
  • Найти причину появления подобных страниц, устранить ее;
  • Настроить 301 редирект с таких страниц на правильные;
  • Настроить 404 код ответа для таких страниц.

Страницы с нетипичной вложенности для сайта

  • Найти причину появления подобных страниц, устранить ее;
  • Настроить 301 редирект с таких страниц на правильные;
  • Настроить 404 код ответа для таких страниц.

Страницы с нетипичным окончанием. Если обычный для сайта URL заканчивается на «/», а в списке есть страницы без «/» на конце или с расширением на конце (.htm / .html / .php / …)

  • Найти причину появления подобных страниц, устранить ее;
  • Настроить 301 редирект с таких страниц на правильные;
  • Страницы с кириллицей для сайтов, у которых только латинские символы в URL
  • Найти причину появления подобных страниц, устранить ее;
  • Настроить 404 код ответа для таких страниц.

Другие

В зависимости от причины.

○ URL, которые были проверен можно удалить из файла, чтобы они не мешали.

3. Проверяем, какие страницы были удалены из индекса. Для это в колонке «Event» оставляем значение «DELETE»:

○ Проверяем все причины исключения страниц из индекса. Для этого в колонке «status» поочередно оставляем каждый из видов ошибок и проверяем страницы.

Фильтр с причинами удаления страниц их индекса Яндекса

Рис. 5. Задание фильтра с причинами удаления страниц

Возможные статусы, что они означают и варианты лечения:

Значение status

Расшифровка

Как решать

BAD_QUALITY

Страница считается некачественной

Смотрим страницу и ищем причину исключения.

  • Наиболее частые ошибки:
  • Это технический дубль;
  • Дублируется Title;
  • На странице мало контента или его нет.

CLEAN_PARAMS

Страница работает через параметры, которые почищены в robots.txt директивой Clean-param

Если все правильно, то нужно заменить в robots.txt clean-param на Disallow, так как на обход по Clean-param тратится краулинговый бюджет.

DUPLICATE

Страница является дублем страницы по другому URL

Посмотреть причину, по которой страница оказалась дублем.

  • Если это дубль, настроить 301 редирект на основную страницу;
  • Если это уникальная страница, поменять ее контент на уникальный;
  • Если это очень похожие страницы (например разные размеры одного товара), установить canonical на правильную страницу. В будущем уникализировать страницу и убрать canonical.

HOST_ERROR

При обращении к сайту роботу не удалось установить соединение с сервером

Проверить код ответа сервера. Скорее всего, он будет 50*.

Исправить код ответа и отправить страницу в очередь на переобход.

HTTP_ERROR

При обращении к странице возникла ошибка

Проверить код ответа сервера. Скорее всего он будет 50*.

Исправить код ответа и отправить страницу в очередь на переобход.

META_NO_INDEX

На странице есть метатег robots noindex (none)

Посмотреть, почему на странице noindex. Скорее всего, это страница пагинации. В таком случае убрать noindex и уникализировать заголовки подписью «- Страница 2 (3…)».

NOT_CANONICAL

На странице есть метатег canonical с указанием на другую страницу

Посмотреть, почему на странице canonical с указанием другой страницы.

  • Если это ошибка, убрать canonical и отправить страницу в очередь на переобход;
  • Если это очень похожие страницы (например: разные размеры одного товара), уникализировать страницу и убрать canonical;
  • Если это пагинация, убрать canonical и уникализировать. заголовки подписью «- Страница 2 (3…)».

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

Страница находится в поиске


○ Если обнаруживаем проблему, делаем техническое задание на устранение этой проблемы.

Заключение

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

Если у вас есть вопросы, пишите задавайте их здесь в комментариях. Разберемся вместе :)

5 комментариев
Подписаться 
Подписаться на дискуссию:
E-mail:
ОК
Вы подписаны на комментарии
Ошибка. Пожалуйста, попробуйте ещё раз.
  • Jail
    1
    комментарий
    0
    читателей
    Jail
    больше года назад
    Руслан, если на странице пагинации есть мета-тег robots noindex, follow, очевидно, что она будет исключена из индексной базы, но зачем убирать данный мета-тег и уникализировать заголовки страниц, если на страницах пагинации по сути только дублирование информации с самих карточек товаров (например, в интернет-магазине)?
    Можно оптимизировать страницы пагинации под регионы, но по факту от такой оптимизации переходов с поиска на страницы пагинации не увеличивается.

    И ещ...
    Руслан, если на странице пагинации есть мета-тег robots noindex, follow, очевидно, что она будет исключена из индексной базы, но зачем убирать данный мета-тег и уникализировать заголовки страниц, если на страницах пагинации по сути только дублирование информации с самих карточек товаров (например, в интернет-магазине)?
    Можно оптимизировать страницы пагинации под регионы, но по факту от такой оптимизации переходов с поиска на страницы пагинации не увеличивается.

    И еще такой вопрос, чем отличиются статус ROBOTS_HOST_ERROR от ROBOTS_TXT_ERROR?
    -
    0
    +
    Ответить
  • филипп лоывлов
    10
    комментариев
    0
    читателей
    филипп лоывлов
    больше года назад
    Что там про краулинговый бюджет? Это с каких пор он перестал тратиться на disallow?
    developers.google.com/webmasters/control-crawl-index/docs/faq#h17
    Как раз в этой схеме он будет расходоваться. А вот при настройке clean-param (параметры url для гугла) - не должен.
    -
    1
    +
    Ответить
    • Руслан Фатхутдинов
      19
      комментариев
      0
      читателей
      Филипп, спасибо за интересный вопрос.
      В той ссылке, которую вы приводите, если вы пользуетесь версией справки на русском языке, в ней есть неточность в переводе. Если вы выбрать английский язык, там сказано: "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 помогает сохранить краулинговый бюджет.
      Надеюсь, мой ответ окажется вам полезным.
      -
      0
      +
      Ответить
      • филипп лоывлов
        10
        комментариев
        0
        читателей
        Да, и еще туда же: Вот пример из вебмастера [история обхода] yadi.sk/d/GFLDGGzy3Gk8gV
        При этом в роботсе сайта закрыты вообще все динамические страницы yadi.sk/d/cMaBAr0b3Gk8qE
        А робот все-таки полез на них, т.е. потратил пресловутый краулинговый бюджет. Ну не редиска ли :)
        -
        0
        +
        Ответить
      • филипп лоывлов
        10
        комментариев
        0
        читателей
        Насчет clean-param - получается что-то странное. Налицо противоречие Платона с его же собственным хелпом yadi.sk/d/Jgo5Yh183Gk5aZ  - в одном случае они говорят, что робот тратит на них время, в другом - что он умный и сразу сводит все урлы в один снижая нагрузку на сервер. Хотя, в обоих случаях фигурирует "может". А может и не может.

        Мне почему больше нравится клин-парам - он (по логике) работает аналогично с rel=canonical, т.е. сводит несколько адресо...
        Насчет clean-param - получается что-то странное. Налицо противоречие Платона с его же собственным хелпом yadi.sk/d/Jgo5Yh183Gk5aZ  - в одном случае они говорят, что робот тратит на них время, в другом - что он умный и сразу сводит все урлы в один снижая нагрузку на сервер. Хотя, в обоих случаях фигурирует "может". А может и не может.

        Мне почему больше нравится клин-парам - он (по логике) работает аналогично с rel=canonical, т.е. сводит несколько адресов к одному виду, что дает какую-то надежду на передачу веса итоговой странице, тогда как запрет индексации - просто запрет.

        Google - здесь я неправ, пожалуй, в том, что это вообще оффтоп. У него Немного другая политика индексирования и вообще в статье речь про яндекс :) Так что черт с ним.
        -
        0
        +
        Ответить

Отправьте отзыв!
X | Закрыть