Заголовки last-modified і if-modified-since

У процесі індексації сайту пошуковий робот регламентує кількість запитуваних за один обхід документів згідно виділеної квоти, що залежить від безлічі параметрів сайту. При цьому для досить великих сайтів, у яких розмір цієї квоти набагато менше загальної кількості документів, доступних для індексації, дуже важливо раціональне витрачання квоти на індексацію. А саме, щоб роботом скачували тільки нові, ще не проіндексовані документи, а також документи, реально змінилися з часу попереднього обходу, і квота не витрачалася б даремно на переіндексацію незмінно контенту. Для грамотного управління індексацією необхідно розуміти, які процеси при цьому відбуваються, і як можна на них впливати.

Останнім часом мені довелося неодноразово зіткнутися з тим, що деякі SEO-фахівці, що позиціонуються як не слабкі професіонали в галузі, демонстрували не зовсім повне розуміння того, як правильно управляти індексуванням сторінок сайту і вели мову лише про віддачу заголовку Last-Modified, упускаючи з уваги обробку запиту з заголовком If-Modified-Since. Тому хотілося б зупинитися на цьому питанні більш детально.

Отже, що таке заголовок Last-Modified і яку роль він відіграє при індексації?

Тема Last-Modified віддає час останньої зміни документа. Ця інформація, безсумнівно, в якійсь мірі корисна, і якщо цей заголовок не віддавати, то, наприклад, в Яндексі в сниппета стане нормальним дата документа, і він також буде відсутній в результатах пошуку, відсортованих за датою. Однак, власне управляти індексацією за допомогою цього заголовка неможливо.

І ось вже для відповіді на запит з заголовком If-Modified-Since згідно з протоколом RFC2616 можливі наступні варіанти.

a) If the request would normally result in anything other than a 200 (OK) status, or if the passed If-Modified-Since date is invalid, the response is exactly the same as for a normal GET. A date which is later than the server's current time is invalid. (Якщо результат відповіді на звичайний запит повинен бути відмінний від 200 (ОК), або якщо дата в If-Modified-Since некоректна, то відповідь має точно збігатися з відповіддю на звичайний запит GET. Дата, пізніша, ніж поточний час сервера, є некоректної).

b) If the variant has been modified since the If-Modified-Since date, the response is exactly the same as for a normal GET. (Якщо документ змінений з дати, зазначеної в If-Modified-Since, то відповідь має точно збігатися з відповіддю на звичайний запит GET.)

c) If the variant has not been modified since a valid If-Modified-Since date, the server SHOULD return a 304 (Not Modified) response. (Якщо документ не змінений з дати, зазначеної в If-Modified-Since, то сервер повинен повернути відповідь 304 Not Modified.)

Таким чином, для документів, що не змінилися з дати попередньої індексації, яка вказується пошуковим роботом в заголовку If-Modified-Since, він повинен отримати відповідь 304 і не викачувати їх вміст, витрачаючи квоту лише на реально змінилися з часу попередньої індексації або ж нові документи , що, як було сказано вище, особливо важливо для сайтів з великою кількістю сторінок. Однак слід звернути увагу, що при цьому вміст віддається заголовка Last-Modified не має значення, важливий саме результат відповіді на запит з заголовком If-Modified-Since, і саме його необхідно коректно налаштовувати в першу чергу. І, до речі, непоодинокі випадки, коли веб-майстра обмежуються налаштуванням тільки віддачі заголовка Last-Modifed, забуваючи при цьому про налаштування коректної обробки відповіді на запит з заголовком If-Modified-Since. І в підсумку завдання управління індексацією залишається невирішеною.

Ну, і на завершення я хотів би навести приклад помилки, від якої я і хотів застерегти в даній статті, а саме, коли розробник обмежився тільки віддачею заголовка Last-Modified, що не налаштувавши при цьому коректну обробку запиту If-Modified-Since: