Сверхбыстрый хостинг

2,014 просмотров

Для ряда задач SEO-аналитики требуется определение возраста страниц в поисковой базе Яндекса. Типичные примеры таких задач – анализ конкурентов, проверка корректности склейки зеркал, отслеживание динамики добавления контента.

В настоящий момент преимущественно используется два способа определения даты первой индексации документа:

  • Параметр modtime в Яндекс.Xml.
  • Поиск с использованием оператора “date:”

Интересно, что согласно справке Яндекса оба метода должны приводить к нахождению даты изменения документа. См. официальную информацию по date а также анализ применения modtime.

Очень четко это противоречие видно из статьи в блоге Топэксперт:

Документация по работе оператора date:
(Вторая графа – “Описание”, третья – “Применимость”).

Итак, официальная информация не соответствует сложившейся практике использования оператора. Разумеется это произошло не просто так. Оптимизаторы неоднократно замечали, что даже регулярно изменяющиеся страницы (например раздел “новости” или главная страница блога) имеют, согласно “date:”, дату изменения, равную дате появления в индексе.

Попробуем разобраться в вопросе и разрешить это противоречие.

Отправная точка: наблюдаем резкую смену возраста согласно “date:” на ряде страниц сайта

В начале декабря 2016 было зафиксировано изменение даты для ряда страниц на alexeytrudov.com. Пример (актуальная выдача):

Изменение дат в индексе для страниц блога

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

Данные из Яндекс.XML

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

5 декабря 2016 удалось зафиксировать две разные даты для одного документа одновременно:

Две разные даты для одного документа

и

Вторая дата для того же документа

Первая дата – это время публикации статьи. Но откуда взялась вторая?

На сайте в изучаемый период не было резких изменений в плане контента или структуры. Однако был подключен и активно тестировался плагин WP-Cache.com. Он сохраняет страницы сайта в виде простых html-файлов и отдает пользователям и поисковым роботам их. А для статичных файлов сервер также генерирует заголовок Last-Modified, содержащий время их последнего изменения.

HTTP-заголовки страницы

Посмотрим, что написано в справке Яндекса об этом заголовке:

Насколько критично, что мой сервер не выдает last-modified? Я пытался настроить этот параметр, но ничего не вышло.

Даже если сервер не выдает дату последней модификации документа (last-modified), ваш сайт будет проиндексирован. Однако в этом случае следует учитывать следующее:

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

Чаще всего SEO-специалисты обращают внимание на третий пункт. Если же мы сопоставим первые два минуса с описанием оператора “date:”, то получим стройную гипотезу, объясняющую противоречия в его использовании.

А именно:

При поиске с помощью оператора “date:” Яндекс действительно пытается отобразить дату изменения страницы. Однако если на сайте не настроена отдача корректного заголовка Last-Modified, то сделать это технически невозможно, так как робот не может мониторить изменения всего Интернета каждую секунду.

Поэтому для url, где Last-Modified не работает, Яндекс показывает дату первой индексации (либо повторной, что может наблюдаться при неполной склейке зеркал или выпадении из индекса; возможны и другие причины).

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

Переходим к исследованию.

Корреляции между датами для 100 000 случайных документов

Массив данных для анализа был получен следующим образом:

  1. Выполнен поиск документов с помощью Яндекс.xml c ограничением по оператору “date:” для 100 разных дат из 2015 года и запросов в виде букв. Пример запроса: “а date:20151028”. Всего собрано 100000 документов, для каждого у нас имеется показатель “изменения” из “date:” и из modtime.
  2. Отсеяны повторяющиеся url. В выборке осталось 97949 документов.
  3. Для каждого документа запрошены заголовки сервера. Если среди них содержался Last-Modified, он записывался в базу.

Итого у нас оказалась база данных из 97949 тестовых url, для которых собраны:

  • дата согласно оператору date:
  • дата из modtime (если этот параметр содержался в xml-ответе)
  • дата из Last-Modified (если документ отдавал этот заголовок).

41 страница имела заголовок в некорректном формате, например таком:

Некорректный формат заголовка Last-Modified

В ходе дальнейшего анализа для таких url считалось, что Last-Modified отсутствует.

Какую картину мы получим, если изложенная выше гипотеза верна?

  • Во-первых, дата согласно оператору и дата, полученная из Last-Modified будут совпадать на значительном числе тестовых url.
  • Во-вторых, если при этом обнаружится, что для url с Last-Modified дата из оператора отличается от даты из modtime, то мы получим дополнительный сильный аргумент “за”. Логика проста – тут будет очевидно, что мы имеем дело с изменившимся документом, а не просто тем, для которого Last-Modified совпадает с датой создания и никогда не менялся.

Итак, это наш прогноз на основе гипотезы. Подтвердится ли он?

Результаты и обсуждение

Разберем частоту встречаемости разных типов url среди всей выборки.

Сначала базовые данные, для понимания общих закономерностей.

Группа url Количество Доля Примечание
Modtime отсутствует 12661 12,93%  
Date и Modtime не совпадают 15336 15,66% Только для тех url. где modtime есть
Date и Modtime совпадают 69952 71,42%  
Присутствует корректный по формату Last-Modified 16706 17,10%  

Данные по наличию различных дат для страниц

А теперь перейдем к типам url, которые могут подтвердить или опровергнуть выдвинутую гипотезу.

Сравнение дат из разных источников

Всего в выборке найдено 10799 url, для которых данные для date и Last-Modified совпадают. Это довольно много – 64,6% от всех документов, имеющих Last-Modified.

Есть ли среди них те, где не совпадает date и modtime? Да, их нашлось 10557 или 97,8%. Если дополнительно ограничить поиск только существующими modtime, то получаем только 3215 результатов.

Что это может означать?

Сравним две части выборки по встречаемости пустого modtime:

  Без Last-Modified
(всего 81243)
С Last-Modified
(всего 16706)
Количество url с пустым modtime 3599 9062
Доля url c пустым modtime 4,43% 54,24%

То же самое на диаграмме:

Количество modtime для разных частей выборки

Разница в доле весьма высока. Можно предположить с достаточно высокой степенью уверенности, что страницы, отдающие Last-Modified, в 10 раз чаще имеют пустой modtime. Также очевидно, что наличие этого заголовка тесно связано с несовпадением между датами из modtime и оператора date.

Однако взаимосвязь между “date:” и Last-Modified еще не очевидна. Выше мы видели, что для 35% страниц они показывают разные данные. Изучим их подробнее.

Характеристики url, где данные из “date:” и Last-Modified не совпадают

Итак, в этой части выборки 5907 url.

Из них:

  • 2635 отдают Last-Modified, совпадающий с датой парсинга (вероятнее всего, результат неверной настройки заголовка, когда он показывает текущее время; так рекомендует сделать несколько ошибочных инструкций).
  • Еще 1567 отдают Last-Modified с разными датами 2016 года, преимущественно ноябрьскими.
  • У 85 в этом заголовке указано 1 января 1970.

Несовпадение для этих случаев в рамках нашей гипотезы находится легко: либо Last-Modified не соответствует реальной дате изменения, либо робот еще не успел его учесть.

Итоговая статистика

Таким образам потенциально противоречат нашей гипотезе только 1620 документов или 9,7%. Иначе говоря, в 90% случаев, если у робота была возможность учесть корректный Last-Modified, информация в нем совпадает с той датой, что можно определить с помощью “date:”.

При этом большинство документов, отдающих Last-Modified демонстрируют отличие между данными из modtime и “date:”.

Выводы

  1. Оператор date действительно предназначен для поиска страниц по дате изменения. Однако в условиях, когда большая часть страниц (83%, согласно нашей выборке) не отдают Last-Modified, возможности Яндекса по корректному отображению даты изменения ограничены.
  2. В случае использования корректного заголовка Last-Modified он используется для определения времени, отображаемого в “date:”, но не используется для modtime.
  3. Несмотря на сходное описание в официальной справке, даты изменения согласно “date:” и modtime формируются по-разному. Альтернативное объяснение – в том, что новые данные попадают в выдачу Яндекс.xml с задержкой.
  4. На практике следует учитывать возможность наличия Last-Modified у анализируемых url. Если страница отдает (или отдавала в прошлом) этот заголовок, то при помощи оператора “date:” установить дату первой индексации не представляется возможным.
  5. Едва ли не самое важное следствие. Нет оснований полагать, что “date:” как таковой служит надежным индикатором для реального возраста страницы, который может учитываться в ранжировании по принципу “чем старше тем лучше”. В противном случае страницы, отдающие Last-Modified согласно рекомендациям Яндекса, ранжировались бы хуже. В свете приведенных данных “возраст” по “date:” выглядит скорее техническим параметром для удобства пользователя.
  6. Предыдущий пункт отчасти актуален и для страниц, где Last-Modified не формируется. Взаимосвязь “date:” и Last-Modified достаточно хорошо выражена, но это не значит, что на результаты поиска с “date:” не влияют другие факторы, пока не определенные.

Алексей Трудов, SEO-аналитик и независимый консультант Использование Last-Modified может быть полезно не только для ускорения индексации, но и для попадания в выдачу по запросам с использованием расширенного поиска, когда пользователь ищет свежий контент (подходит для продвижения новостей, мероприятий, рекламных акций). Идея не нова, однако большая часть владельцев сайтов и оптимизаторов игнорируют эту возможность.

Автор: Алексей Трудов, SEO-аналитик и независимый консультант. Ведет персональный блог об интернет-маркетинге, основатель сервиса анализа сайта на основе реальной статистики SEO-прорыв.

Алексей в соцсетях: Facebook | Telegram-канал

  • 0 Нет
  • 12 Да
  • Мне понравилось!

Если вам понравилась статья, вы можете подписаться на RSS или E-mail рассылку. Для получения обновлений по электронной почте, введите ваш e-mail адрес в эту форму (Доставка от FeedBurner):