Нужен ли Last-Modified для SEO и что он даёт кроме экономии краулингового бюджета?

Question

Accepted Answer

Last-Modified стоит настраивать, если сервер может отдавать реальную дату изменения и корректно отвечать 304 Not Modified; обязательным SEO-требованием этот заголовок не является. Без него страницы продолжают сканироваться и индексироваться. Основная польза — не рост позиций, а уменьшение передачи данных и серверной нагрузки при повторных запросах.

Как работает Last-Modified

Last-Modified — HTTP-заголовок ответа с датой изменения конкретного представления ресурса. При следующем обращении клиент может отправить эту дату в запросе If-Modified-Since. Если содержимое не изменилось, сервер возвращает 304 Not Modified без тела ответа; если изменилось — 200 OK, новую версию документа и обновлённый валидатор.

Это не отменяет обращение поискового робота к URL: запрос всё равно происходит. Поэтому формулировка «экономит краулинговый бюджет» не вполне точна. Механизм прежде всего сокращает объём передаваемых данных, вычисления на сервере и время обработки. Для Google это может косвенно повысить эффективность обхода, когда ограничением является производительность или пропускная способность сервера, но 304 не гарантирует, что освободившийся ресурс будет автоматически перенаправлен на другие URL.

Google поддерживает условные запросы через пары Last-Modified / If-Modified-Since и ETag / If-None-Match, но отправляет такие заголовки не при каждом обходе. Если доступны оба валидатора, ETag точнее: он позволяет идентифицировать версию содержимого без зависимости от корректности часов и секундной точности даты. Google рекомендует предпочитать ETag, а при возможности отдавать оба заголовка. По HTTP-стандарту при одновременном получении If-None-Match и If-Modified-Since приоритет имеет If-None-Match.

Что Last-Modified даёт кроме обхода

Корректная HTTP-валидация даёт несколько технических преимуществ:

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

Это преимущества веб-производительности и инфраструктуры, а не самостоятельный сигнал ранжирования. В официальной документации Google Last-Modified описывается как механизм кэширования и повышения эффективности обхода. Надёжного подтверждения прямого влияния заголовка на позиции нет.

Для Яндекса заголовок имеет более явно заявленное поисковое назначение. Яндекс указывает, что сайт будет индексироваться и без него, но робот хуже определяет, обновилась ли страница; изменённые документы могут переиндексироваться реже. В текущей справке также заявлено, что отсутствие Last-Modified влияет на показ даты рядом со страницей в результатах поиска. Это не подтверждает влияние заголовка на ранжирование.

Когда настройка оправдана

Настройка приоритетна для:

крупных интернет-магазинов и классифайдов;
сайтов с десятками или сотнями тысяч URL;
архивов и баз документов;
изображений, PDF, CSS, JavaScript и других редко изменяемых ресурсов;
проектов, где Googlebot или другие клиенты создают заметную серверную нагрузку;
сайтов, для которых важна скорость обнаружения обновлений Яндексом.

Для небольшого сайта с быстрым сервером эффект может быть практически незаметен. Исправление Last-Modified обычно уступает по приоритету ошибкам индексации, некорректным HTTP-статусам, дублям URL, бесконечным пространствам URL и проблемам внутренней архитектуры. Это следует из механизма: условные ответы оптимизируют уже совершённые запросы, но не исправляют причины неэффективного распределения обхода.

Заголовок лучше не отдавать, чем генерировать ложную дату. Типичные ошибки:

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

HTTP-стандарт рекомендует отправлять Last-Modified только тогда, когда дату можно определять разумно и последовательно. Она не должна быть позднее серверного времени формирования ответа. Для динамических страниц, где надёжную дату определить сложно, безопаснее использовать корректный ETag либо временно не включать валидатор.

Не путайте Last-Modified, sitemap lastmod и dateModified

HTTP-заголовок Last-Modified, элемент в XML Sitemap и свойство dateModified в структурированных данных решают разные задачи.

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

Один механизм не заменяет два других. Например, наличие правильного в sitemap не позволит серверу вернуть 304, а HTTP-заголовок не заменяет дату обновления в структурированных данных статьи.

Как проверить реализацию

Сначала получите фактические заголовки страницы:

curl -sS -D - -o /dev/null https://example.com/page/

В ответе должен присутствовать корректный валидатор:

HTTP/1.1 200 OK
Last-Modified: Wed, 29 Jul 2026 10:15:00 GMT
ETag: "page-42-v17"

Затем повторите запрос с полученной датой:

curl -sS -D - -o /dev/null \
  -H 'If-Modified-Since: Wed, 29 Jul 2026 10:15:00 GMT' \
  https://example.com/page/

Для неизменённого ресурса ожидается:

HTTP/1.1 304 Not Modified

После реального изменения страницы тот же запрос должен получить 200 OK, тело новой версии и обновлённую дату. Такая логика соответствует семантике If-Modified-Since, установленной HTTP-стандартом.

Если сервер отдаёт ETag, проверьте его отдельно:

curl -sS -D - -o /dev/null \
  -H 'If-None-Match: "page-42-v17"' \
  https://example.com/page/

Нельзя проверять только наличие строки Last-Modified. Критерий исправной реализации — согласованная цепочка:

первый запрос
→ 200 OK + тело + валидатор

повторный запрос без изменения
→ 304 Not Modified без тела

запрос после изменения
→ 200 OK + новое тело + новый валидатор

Практический приоритет следующий: на крупном или нагруженном сайте настройте ETag и/или точный Last-Modified, корректную обработку 304 и подходящий Cache-Control. На небольшом сайте не стоит дорабатывать заголовок ради предполагаемого роста позиций. Если хостинг формирует дату неправильно и исправление требует непропорционально сложной доработки, отключите ошибочный Last-Modified и используйте ETag либо обычные ответы 200 OK.