Last-Modified, которого нет: робот заново качает две тысячи неизменных страниц

Last-Modified, которого нет на сайте, — это молчаливый налог на индексацию: робот приходит с ограниченным лимитом обхода, спрашивает у сервера каждую страницу и в ответ получает полный HTML даже там, где не менялась ни одна буква с 2019 года. Две тысячи неизменных страниц скачиваются заново, лимит на сегодня заканчивается, а свежая карточка товара, которую вы выложили утром, остаётся неувиденной до следующего визита. Внешне сайт исправен: коды 200, ошибок в Вебмастере нет, тексты на месте. Просто робот тратит выделенное на вас время на пересчёт того, что и так знает.

Механика тут короткая и полностью проверяемая руками — это не гипотеза про «поведенческие», а два HTTP-заголовка и один код ответа. Ниже разбираю по шагам: что должен отдавать сервер, что происходит при встречном запросе робота, чем ETag отличается от даты, как проверить свой сайт за пять минут и что чинить на WordPress, где корректного Last-Modified из коробки чаще всего просто нет. Если разбираться самому некогда, а сайт большой, это ровно тот случай, когда имеет смысл заказать SEO-продвижение сайта и снять техническую часть с себя.

Коротко

• Сервер обязан отдавать заголовок Last-Modified — дату последнего изменения страницы в формате GMT.
• Робот при повторном визите присылает встречный заголовок If-Modified-Since с той датой, которую запомнил.
• Если страница не менялась, сервер отвечает 304 Not Modified — заголовки без тела страницы. Трафик не расходуется, обход дешевеет в разы.
• Альтернатива дате — ETag (отпечаток содержимого) и встречный If-None-Match. Работают вместе или по отдельности.
• Самая частая поломка — CMS подставляет в Last-Modified текущее время каждого запроса. Формально заголовок есть, пользы ноль.
• На сайте до нескольких сотен страниц выигрыш почти не заметен. Смысл появляется от тысяч URL и на медленном сервере.

Почему робот вообще качает страницу, которая не менялась

Поисковый робот не хранит ваш сайт целиком. Он хранит адрес, содержимое последней копии и служебные метки — в том числе дату, которую вы ему сообщили. Когда подходит очередь адреса на переобход, робот делает обычный GET-запрос. Сервер отдаёт код 200 и весь HTML — тридцать, сто, двести килобайт. Робот сравнивает полученное с сохранённой копией, видит, что ничего не изменилось, и выбрасывает скачанное.

Скачивание всё равно состоялось. Оно заняло соединение, время сервера на генерацию страницы из базы, трафик и — главное — одну единицу лимита обхода. Лимит этот не резиновый: он зависит от того, насколько быстро отвечает ваш хостинг и насколько сайт в целом интересен поиску. Подробно про сам лимит я писал в материале краулинговый бюджет: почему Яндекс не обходит половину сайта.

Теперь считаем. Сайт на 3000 страниц, средняя страница — 90 КБ HTML. Полный обход всего сайта — около 260 МБ, и почти всё это скачивание страниц, которые не менялись. Если сервер умеет отвечать 304, ответ на неизменённую страницу — это несколько сотен байт заголовков и, что важнее, отсутствие генерации: PHP не запускается, база не опрашивается, шаблон не собирается. Обход того же сайта из мегабайтов превращается в килобайты, а освободившееся время робот тратит на адреса, которые действительно новые.

Это та же логика, что и в истории про мусорные URL: робот не злонамеренный, он просто идёт по списку. Куда именно утекает его внимание на типовом сайте, я разбирал в статье почему Яндекс обходит мусорные URL чаще, чем важные страницы. Отсутствие Last-Modified — тот же слив, только незаметный: адреса-то правильные, лишними их не назовёшь.

Как устроен диалог: Last-Modified, If-Modified-Since и 304

Разберём один цикл по шагам. Первый визит робота на страницу выглядит так — сервер отдаёт содержимое и сообщает дату:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Last-Modified: Tue, 11 Mar 2026 09:14:22 GMT
Content-Length: 92418

Формат даты жёсткий: день недели, число, трёхбуквенный месяц по-английски, год, время и обязательная зона GMT. Никакого местного времени, никакого «+03:00» — только GMT. Робот запоминает эту строку вместе с адресом.

Второй визит, через неделю. Робот добавляет к запросу встречный заголовок:

GET /catalog/nasosy/ HTTP/1.1
Host: example.ru
If-Modified-Since: Tue, 11 Mar 2026 09:14:22 GMT

Сервер сравнивает эту дату с реальной датой изменения страницы. Если страница не менялась — отвечает без тела:

HTTP/1.1 304 Not Modified
Last-Modified: Tue, 11 Mar 2026 09:14:22 GMT

Всё. У ответа 304 не должно быть тела вообще — ни HTML, ни пробела. Робот понимает: копия актуальна, перекачивать нечего, идём дальше по очереди. Если же страница менялась, сервер игнорирует условие и отвечает обычным 200 с новым содержимым и новой датой.

Важная тонкость, о которую спотыкаются на динамических сайтах: дата в Last-Modified должна отражать изменение того, что видно на странице, а не факт обращения к серверу. Если у вас под текстом статьи выводятся комментарии, то новый комментарий — это изменение страницы, и дату надо двигать. Если в сайдбаре крутится блок «случайные товары», меняющийся при каждой загрузке, то честной даты изменения у такой страницы нет в принципе — сначала уберите случайный вывод, потом занимайтесь заголовками.

ETag и If-None-Match: второй механизм

Дата — не единственный способ сказать «не изменилось». Второй механизм работает через отпечаток содержимого. Сервер считает от тела страницы короткую метку и отдаёт её в заголовке:

HTTP/1.1 200 OK
ETag: "a3f19c7b204e"
Last-Modified: Tue, 11 Mar 2026 09:14:22 GMT

При следующем визите робот присылает If-None-Match: "a3f19c7b204e". Сервер заново считает отпечаток, сравнивает со строкой из запроса и при совпадении отвечает тем же самым 304 Not Modified. Разница только в критерии сравнения: там дата, здесь — содержимое.

ETag бывает сильный и слабый. Слабый помечается префиксом W/ — например W/"a3f19c7b204e" — и означает «содержимое эквивалентно по смыслу, хотя байты могли отличаться». Для поисковых роботов разница непринципиальна, слабый ETag их устраивает.

Критерий	Last-Modified + If-Modified-Since	ETag + If-None-Match
Что сравнивается	Дата изменения	Отпечаток содержимого
Точность	До секунды: правка в ту же секунду будет пропущена	Побайтная, ловит любое изменение
Нагрузка на сервер	Минимальная: сравнили два числа	Выше: чтобы посчитать отпечаток, страницу надо сгенерировать
Понятность при отладке	Видно глазами, когда менялась страница	Строка ничего не говорит человеку
Где уместен	Динамические страницы CMS, где есть поле «дата изменения»	Статика: картинки, CSS, JS, PDF — их отдаёт веб-сервер сам
Риск	Дата «врёт», если её подставляет кэш или сама CMS	Ломается при сжатии на лету и при работе с нескольких серверов

Практический вывод простой. Для HTML-страниц, которые генерирует CMS, основной механизм — Last-Modified: он дешевле и его легко привязать к дате правки записи в базе. Для статических файлов ничего делать не нужно вовсе — nginx и Apache отдают и Last-Modified, и ETag автоматически по времени файла на диске. Оба механизма спокойно работают вместе: сервер отдаёт оба заголовка, робот присылает оба условия, и 304 отдаётся при выполнении обоих.

Отдельная ловушка с ETag на Apache: модуль сжатия mod_deflate дописывает к метке суффикс -gzip. Робот сохранил метку без суффикса, вернул её в If-None-Match, сервер сравнил с версией с суффиксом и не нашёл совпадения — и вместо 304 приходит 200 с полным телом. Механизм формально включён, а работает вхолостую. Поэтому проверять надо не наличие заголовка, а фактический код ответа на условный запрос.

Что отдаёт сервер сейчас, что должен и как проверить за пять минут

Сначала общая карта: что смотреть, какая норма и чем именно это измеряется. Дальше — по шагам, с командами.

Что смотрим	Типичная ситуация	Как должно быть	Чем проверить
Заголовок Last-Modified на странице записи	Отсутствует	Есть, дата = дата последней правки записи	curl -sI URL | grep -i last-modified
Стабильность даты	Меняется при каждой перезагрузке	Одна и та же при пяти запросах подряд	Пять раз тот же curl, сравнить строки
Ответ на If-Modified-Since с текущей датой	200 OK и полный HTML	304 Not Modified	curl -sI -H "If-Modified-Since: ..." URL
Ответ на If-Modified-Since со старой датой	—	200 OK с новым телом	Тот же запрос с датой годичной давности
Тело ответа 304	Иногда прилетает HTML	Пусто, ноль байт	curl -s -H "If-Modified-Since: ..." URL | wc -c
ETag на статике (CSS, картинки)	Обычно есть	Есть и стабильный между запросами	curl -sI /файл.css | grep -i etag
Реакция на изменение страницы	Дата не двигается после правки	Дата обновилась, ответ снова 200	Правка текста → повтор проверки
Ответ 304 у робота Яндекса	Не проверяли ни разу	Совпадает с проверкой curl	Вебмастер → Инструменты → Проверка ответа сервера

Первый шаг — узнать, что сервер отдаёт вообще. В терминале (на macOS и Linux он есть из коробки, на Windows подойдёт встроенный curl из PowerShell):

curl -sI https://example.ru/catalog/nasosy/

В выводе ищем строку Last-Modified. Если её нет — механизм не работает, потому что роботу нечего запоминать и нечего прислать обратно. Если она есть, копируем значение и делаем условный запрос:

curl -sI -H "If-Modified-Since: Tue, 11 Mar 2026 09:14:22 GMT" \
  https://example.ru/catalog/nasosy/

Правильный ответ — первая строка HTTP/1.1 304 Not Modified или HTTP/2 304. Если пришло 200 OK, значит сервер получил условие и проигнорировал его: заголовок для галочки есть, экономии нет.

Второй шаг — проверить, что дата не врёт. Запускаем тот же первый запрос пять раз подряд с паузой в несколько секунд и сравниваем значения. Разные даты в каждом ответе означают, что CMS подставляет текущее время. Такой заголовок хуже, чем никакого: робот каждый раз видит «страница только что изменилась» и приходит снова и снова.

Третий шаг — контрольный запрос со старой датой. Подставляем дату годичной давности и ждём код 200 с полным телом. Если и на неё сервер отвечает 304, у вас обратная поломка: робот никогда не увидит обновлений страницы, потому что сервер всегда рапортует «не менялось».

Четвёртый шаг — глазами робота Яндекса. В Вебмастере есть раздел «Инструменты» → «Проверка ответа сервера». Вставляете адрес, выбираете нужного робота и получаете полный список заголовков ответа именно для него. Смотреть там надо три вещи: код ответа, наличие строки Last-Modified и её значение. Инструмент полезен ещё и тем, что показывает ответ на реальный запрос от инфраструктуры Яндекса — если у вас настроена отдача разного контента по User-Agent или стоит защита от ботов, отличия сразу вылезут. Про расхождения между тем, что видите вы и что видит робот, я подробно писал в материале Google и Яндекс видят ваш сайт по-разному.

Пятый шаг для тех, у кого есть доступ к серверу, — логи. В них видно, сколько ответов 200 и 304 реально получил робот за сутки и на каких адресах. Это единственный способ увидеть не гипотезу, а факт. Что ещё вытаскивается из логов, я собрал в статье логи сервера в SEO: что в них видит робот. После настройки 304 доля таких ответов в логах по старым разделам должна заметно вырасти — это и есть измеримый результат работы.

Пять типичных поломок и что с ними делать

Симптом	Что происходит на самом деле	Что делать
Дата в Last-Modified разная при каждом запросе	CMS или плагин пишут gmdate() текущего момента вместо даты правки записи	Привязать значение к полю даты изменения записи в базе
Заголовок есть, но на If-Modified-Since приходит 200	Сервер отдаёт дату, но не читает встречный заголовок — обработчика условия просто нет	Добавить сравнение и явную отдачу 304 с выходом до генерации страницы
Дата прыгает после чистки кэша	Значение берётся из времени файла кэша, а не из даты контента	Отвязать от кэша: источник даты — запись в базе
В ответе 304 приходит тело страницы	Код выставлен через http_response_code(), но выполнение не остановлено	После отправки заголовков — немедленный exit
На статике 304 не отдаётся при включённом сжатии	Apache дописывает -gzip к ETag, метки перестают совпадать	Опираться на Last-Modified или убрать суффикс в конфиге
Разные ETag с разных серверов балансировщика	Метка считается от inode файла, а он на каждой машине свой	Считать ETag только от размера и времени, либо отключить и оставить дату

Отдельно про кэширующие плагины. Полностраничный кэш и условные запросы — вещи совместимые, но их надо развести по источникам данных: страницу отдаёт кэш, а дату — база. Когда дату берут из времени файла кэша, получается абсурд: почистили кэш перед выходными, и в понедельник робот считает, что за одну ночь у вас изменился весь сайт целиком. Как кэш вообще перекраивает то, что видит робот, я разбирал в статье кэш в WordPress: почему вы видите старую страницу, а робот — новую.

Что делать на WordPress

Из коробки WordPress обрабатывает условные запросы для RSS-лент и для файлов, которые отдаёт веб-сервер напрямую. Для обычных HTML-страниц — записей, рубрик, главной — заголовка Last-Modified в ответе чаще всего нет. Причина не в халатности разработчиков, а в осторожности: движок не может знать, что вы выводите в шаблоне. Виджет «последние комментарии», случайные товары, счётчик просмотров, персонализация по региону — всё это меняет страницу без изменения самой записи, и универсально угадать дату нельзя. Поэтому решение отдано на откуп сайту.

Правильный источник даты для записи или страницы — поле post_modified_gmt, то самое, которое WordPress пишет при каждом сохранении. Забирается оно функцией get_post_modified_time(). Минимальный рабочий вариант выглядит так — в файл темы functions.php или, что надёжнее, в отдельный mu-плагин:

add_action('template_redirect', function () {
    if (is_admin() || is_user_logged_in() || !is_singular()) {
        return;
    }
    if (is_preview() || post_password_required()) {
        return;
    }

    $ts = get_post_modified_time('U', true);
    if (!$ts) {
        return;
    }

    // если под записью есть комментарии, дата последнего из них тоже двигает страницу
    $last_comment = get_comments(array(
        'post_id' => get_the_ID(),
        'status'  => 'approve',
        'number'  => 1,
        'orderby' => 'comment_date_gmt',
        'order'   => 'DESC',
    ));
    if (!empty($last_comment)) {
        $ts = max($ts, strtotime($last_comment[0]->comment_date_gmt . ' GMT'));
    }

    header('Last-Modified: ' . gmdate('D, d M Y H:i:s', $ts) . ' GMT');

    $ims = !empty($_SERVER['HTTP_IF_MODIFIED_SINCE'])
        ? strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE'])
        : 0;

    if ($ims && $ims >= $ts) {
        header($_SERVER['SERVER_PROTOCOL'] . ' 304 Not Modified', true, 304);
        exit;
    }
});

Что здесь важно и почему именно так:

• template_redirect — момент, когда WordPress уже определил, какую страницу показывает, но ещё не начал выводить HTML. Раньше нельзя — не знаем запись; позже нельзя — заголовки уже ушли.
• Проверка is_user_logged_in() нужна, чтобы вы сами в админ-баре не ловили 304 и не думали, что сайт сломался.
• exit после отправки 304 обязателен. Без него PHP продолжит работу и допишет к пустому ответу весь HTML — получится 304 с телом, а это уже нарушение протокола, и робот может отреагировать непредсказуемо.
• Для архивов, рубрик и главной эту логику надо расширять: там дата — это максимум из дат изменения всех выведенных на странице записей. Отдельная выборка, отдельный код.

Перед внедрением обязательно уберите со страниц всё, что меняется само по себе: блоки случайных записей, «сейчас на сайте», подмену телефона по времени суток. Иначе вы будете отдавать 304 на страницу, которая на самом деле каждый раз другая. И проверьте потом весь набор шаблонов, а не одну запись — карточку товара, страницу услуги, рубрику, пагинацию, страницу 404. Кстати, 404 должна отдавать именно 404, без всяких дат: если вместо неё стоит редирект на главную, у вас проблема покрупнее, и она описана в материале редирект на главную вместо 404 плодит soft 404.

Как это связано с попаданием новых страниц в индекс

Лимит обхода — это в первую очередь время, которое робот готов потратить на ваш сервер. Оно не выдаётся раз и навсегда: чем быстрее сервер отвечает и чем меньше ошибок, тем охотнее робот увеличивает нагрузку. И тут 304 работает сразу с двух сторон.

Первое — прямая экономия. Ответ 304 обходится серверу в доли миллисекунды: не поднимается PHP, не идут запросы в базу, не собирается шаблон. Сравните с полной генерацией страницы каталога, которая на средненьком хостинге занимает 300–800 мс. Разница в сотни раз. Второе — косвенный выигрыш: средняя скорость ответа по сайту падает, а от неё напрямую зависит, сколько запросов в секунду робот себе позволит. Про то, откуда вообще берётся секунда до первого байта, я писал в статье хостинг быстрый, а сайт тормозит: куда исчезает секунда до первого байта.

Показатель	Без Last-Modified	С корректным Last-Modified и 304
Ответ на неизменённую страницу	200 + полный HTML (десятки—сотни КБ)	304, несколько сотен байт заголовков
Работа сервера	Полная генерация: PHP, база, шаблон	Сравнение двух чисел, выход до генерации
Куда уходит лимит обхода	На повторное скачивание старых разделов	На новые и обновлённые адреса
Реакция на новую страницу	Может ждать несколько недель в очереди	Очередь короче, до новых URL доходит быстрее
Нагрузка на хостинг от роботов	Заметная, особенно на больших каталогах	Падает пропорционально доле неизменных страниц

Важно понимать границы эффекта. Настройка 304 не поднимает позиции, не улучшает тексты и не заменяет корректный sitemap — она только убирает лишнюю работу и высвобождает лимит. Если новые страницы не индексируются по другой причине — закрыты в robots.txt, склеены каноникалом, не попали в карту сайта, — 304 не поможет ничем. Полный список причин, по которым Яндекс перестаёт брать новое, у меня собран в материале Яндекс перестал индексировать новые страницы: 10 технических причин. Начинать всегда стоит с него, а условные запросы подключать уже как оптимизацию, когда базовые вещи в порядке.

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

Когда возиться не стоит

Сайт-визитка на 40 страниц. Робот обходит его целиком за один заход и приходит снова через день-два. Экономить тут нечего: даже если каждая страница качается заново, это меньше четырёх мегабайт в месяц и никакой очереди. Здесь ваш ресурс лучше потратить на скорость первой отрисовки и на контент.

Сайт на конструкторе. На Тильде, Wix и подобных платформах вы не управляете заголовками ответа — их формирует платформа, и точка. Единственное, что можно сделать, — проверить curl, что там отдаётся, и учитывать это как данность. Проверить, конечно, стоит — вдруг платформа всё делает правильно, — но повлиять на результат вы не сможете.

Сайт, где содержимое меняется постоянно и по делу: новостная лента, биржевые котировки, страницы с наличием и ценами, обновляемыми из 1С каждые полчаса. Такая страница честно меняется, и любой ответ 304 будет враньём. Здесь механизм просто нечего применять — и это нормально.

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

И последнее: не начинайте с 304, если у вас в Вебмастере висят ошибки 5xx или сервер регулярно отваливается. Сначала стабильность, потом оптимизация: на сервере, который через раз отдаёт 502, вопрос лишних скачиваний вообще не первый по важности. Если непонятно, в каком состоянии техническая часть вашего сайта прямо сейчас, начните с бесплатного аудита сайта — по заголовкам ответа сразу видно, есть ли смысл этим заниматься.

Финальный чеклист

№	Что делаем	Норма
1	curl -sI по типовой странице записи	Есть строка Last-Modified с датой в GMT
2	Пять одинаковых запросов подряд	Дата во всех пяти ответах одна и та же
3	Условный запрос с этой же датой	Код 304 Not Modified
4	Условный запрос с датой годичной давности	Код 200 и полное тело страницы
5	Размер тела при ответе 304	Ноль байт
6	Правим текст записи и повторяем шаг 3	Дата обновилась, снова приходит 200
7	Проверяем все типы шаблонов	Запись, страница, рубрика, пагинация, товар — везде корректно
8	Проверяем страницу 404	Код 404, никаких 304 и никаких дат
9	Вебмастер → Инструменты → Проверка ответа сервера	Робот видит то же, что и curl
10	Заходим на сайт залогиненным	Видим свежую страницу, а не 304
11	Сбрасываем кэш и проверяем дату заново	Дата не изменилась — она берётся из базы, а не из кэша
12	Через две недели смотрим логи сервера	Доля ответов 304 роботу по старым разделам заметно выросла

Работы тут на один вечер, а эффект накопительный и не требует поддержки: настроили один раз — и каждый последующий обход сайта обходится роботу и вашему серверу в разы дешевле. Если сомневаетесь, стоит ли трогать functions.php руками, или после правок что-то поехало, это разбирается на SEO-консультации — вместе смотрим заголовки ответа и решаем, где именно ломается цепочка.