К постам Опубликовано: 2016-12-23

Як краулери пошукачів обробляють 503 помилку на вашому сайті

Рано чи пізно на сайті необхідно проводити технічні роботи, це може бути оновлення движка, переробка структури або просто модернізація. Тут виникає питання, як це зробити максимально безболісно для SEO? Правильно в цьому випадку буде використовувати 503 код статусу в http заголовках віддаються сторінок, який якраз і говорить, що "сервіс тимчасово недоступний, спробуйте пізніше". Але саме в цьому випадку ведуть себе пошукові системи?

В ідеалі, роботи повинні працювати за інтернет-стандартами, в яких описано:

503 код статусу говорить про те, що сервіс не може обробити запит з-за тимчасової перевантаження або внутрішніх робіт. Якщо відома тривалість робіт, її можна вказати в заголовку Retry-After. Якщо цього заголовку не буде, клієнт може розпізнати відповідь як 500 (внутрішня помилка сервера).

Але тут безліч нюансів і питань. Наприклад, сторінки, яка віддає зараз 503 код, раніше не могло бути в індексі, повинен краулер обробляти їх також, як і сторінки, які вже були в індексі? Через деякий час недоступності можна викидати сторінку з індексу? Чи повинно воно вимірюватися годинами-днями або ж кількістю додаткових звернень? А що, якщо robots.txt буде віддавати 503 код статусу, чи варто в цьому випадку індексувати сайт?

Питань багато, відповідей поки мало. Яндекс по 503 кодами статусів нічого не описує, Google в 2011 дав кілька рекомендацій з яких ясно лише, що:

— Retry-After використовується не як чітке правило, а як додатковий сигнал для визначення відповідного моменту переіндексації URL.

— Тривала видача 503 може розцінюватися 410. Наскільки тривала не коментується.

У цій статті представлені результати аналізу логів експериментального сайту для розуміння процесу краулинга. Трохи пізніше також планується опублікувати серію статей з детальним аналізом кожного питання по 503 помилок.

Проведення дослідження

Для розуміння логіки роботи краулеров пошукових систем було проведено невелике дослідження.

— Створена сторінка на сайті, який часто відвідують пошукові роботи
— Сторінка віддає 503 код статусу, а також заголовок Retry-After із зазначенням роботам спробувати зайти на сторінку через годину.

HTTP/1.1 503 Service Temporarily Unavailable
Retry-After: 3600

— На сторінку в меню поставлена наскрізна посилання, щоб роботи її швидше помітили.
— Також була взята друга, вже існуюча в індексі сторінка, для якої виконані аналогічні дії.
— 30 годин пошуковики намагалися отримати доступ до цих сторінок, вся інформація записувалася в логи.

Результати

Що ж показали нам логи?

1. Яндекс намагається проіндексувати нову сторінку кожні 30 хвилин.

Серверні логи - відвідування нової 503 сторінки Яндексом

Незважаючи на те, що ми попросили Retry-After звернутися до сайту через годину, Яндекс стукався до неї кожні пів години (без винятків) і продовжує стукати досі. Причому, перші 4 звернення з точністю до секунди, далі (на 9-ту спробу) час трохи змістилося, і Яндекс помістив URL в чергу краулинга на кругле час — стукав в 00 та 30 хвилин кожної години.

2. Google економить краулинговые бюджети

На відміну від Яндекса, гугл звернувся до нової сторінці за добу всього 8 разів (Яндекс – 56). Час звернення гуглбота не має загальних властивостей, мінімальний період обігу до экспериментируемой сторінці — 10 хвилин (правда з різних серверів, можливо різні краулеры), середня затримка між зверненнями — 4-5 годин.

3. До старої сторінці Яндекс звертається набагато рідше

До існуючої в базі Яндекса сторінці, для якої був налаштований 503 код статусу, Яндекс звертався набагато рідше, всього 5 разів за добу. Перше звернення через 5 хвилин, друге через 11 годин (з точністю до хвилини), третє звернення через 8 годин, наступні приблизно через 6 годин.

4. Google до старих сторінок звертається частіше, ігноруючи Retry-After

За добу гугл стукав до старої сторінці близько 45 разів через абсолютно різні проміжки часу. Іноді спостерігається затримка між зверненнями трохи більше години, але також часто запити йшли через 10 хвилин з того ж сервера.

Мої висновки

Аналізу одного лода, звичайно ж, недостатньо для відповіді на всі питання, але поки що мої висновки будуть наступними:

  • Пошуковики обробляють 503 помилку для існуючих і неіснуючих у своїй базі сторінок по-різному. Ймовірно, тут використовуються різні черги (або краулеры) для індексації і переіндексації. Це ж підтверджується різними IP серверів Яндекса, до нових сторінок він стукався в основному з 141.8.142.86, до старих з 93.158.* і 178.154.*, у Google айпишники також не перетинаються для різних типів сторінок.
  • Google враховує час в Retry-After для нових сторінок, але не враховує для старих. Для сторінок в індексі, повинно бути вибрано параметр, як часто вони оновлюються і коли потрібно пересканувати в наступний раз. Це час перевизначає параметр в Retry-After.
  • Яндекс оперує чергою на краулинг, де кожному URL у ній відповідає точний час, коли сторінка повинна бути запитана. Правда неясно, який мінімальний проміжок часу між двома запитами, якщо вони йдуть з одного сервера. Попередньо це 1 секунда, але все залежить від технічної реалізації черги.
  • Для проведення тех. робіт в Яндексі немає сенсу Retry-After ставити менше 4-5 годин.
  • Пояснення того, що Google звертається до старих сторінок дуже часто, ігноруючи Retry-After, можливо в тому, що він це робить різними краулерами, кожен зі своїм автономним розкладом. Тобто, інструкції ви даєте не взагалі гуглу, а конкретного його серверу (або кластера серверів), яких сотні під різні країни.