Вік сторінки в Яндексі. Що насправді показує оператор «date:»

1. Кореляції між датами для 100 000 випадкових документів
2. Результати та обговорення
3. висновки

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

На даний момент переважно використовується два способи визначення дати першої індексації документа:

• Параметр modtime в Яндекс.XML.
• Пошук з використанням оператора "date:"

Цікаво, що згідно з довідкою Яндекса обидва методи повинні приводити до знаходження дати зміни документа. Див. офіційну інформацію по date а також аналіз застосування modtime .

Дуже чітко це протиріччя видно з статті в блозі Топексперт :

(Друга графа - "Опис", третя - "Застосування").

Отже, офіційна інформація не відповідає усталеній практиці використання оператора. Зрозуміло це сталося не просто так. Оптимізатори неодноразово помічали, що навіть регулярно змінюються сторінки (наприклад розділ "новини" або головна сторінка блогу) мають, згідно "date:", дату зміни, рівну датою появи в індексі.

Спробуємо розібратися в питанні і вирішити це протиріччя.

Відправна точка: спостерігаємо різку зміну віку відповідно до "date:" на ряді сторінок сайту

На початку грудня 2016 було зафіксовано зміну дати для ряду сторінок на alexeytrudov.com . Приклад (актуальна видача):

Перевірка в кінці листопада показувала дату 20121205, точно так само як і параметр modtime в Яндекс.XML. Примітно, що цей параметр для досліджуваного сайту не змінився:

Ймовірно, ми маємо справу з розсинхронізація основного пошуку і Яндекс.XML.

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

і

Перша дата - це час публікації статті. Але звідки взялася друга?

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

Подивимося, що написано в довідці Яндекса про це заголовку:

Наскільки критично, що мій сервер не видає 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 сторінка мала заголовок в некоректному форматі, наприклад таке:

В ході подальшого аналізу для таких 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%

Те ж саме на діаграмі:

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

Однак взаємозв'язок між "date:" і Last-Modified ще не очевидна. Вище ми бачили, що для 35% сторінок вони показують різні дані. Вивчимо їх докладніше.

Характеристики url, де дані з "date:" і Last-Modified не збігаються

Отже, в цій частині вибірки 5907 url.

З них:

• 2635 віддають Last-Modified, що співпадає з датою парсинга (найімовірніше, результат невірної настройки заголовка, коли він показує поточний час; так рекомендує зробити кілька помилкових інструкцій).
• Ще одна тисяча п'ятсот шістьдесят сім віддають 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:" не впливають інші чинники, поки не визначені.

Використання Last-Modified може бути корисним не тільки для прискорення індексації, а й для потрапляння в видачу по запитах з використанням розширеного пошуку, коли користувач шукає свіжий контент (підходить для просування новин, заходів, рекламних акцій). Ідея не нова, проте велика частина власників сайтів і оптимізаторів ігнорують цю можливість.

Автор: Олексій Трудов, SEO -аналитик і незалежний консультант. веде персональний блог про інтернет-маркетингу , Засновник сервісу аналізу сайту на основі реальної статистики SEO -прорив .

Олексій у соціальних мережах: Facebook | Telegram-канал