Главная → Все проверки → HTTP-кэширование обхода
HTTP-кэширование обхода: что проверяется
Когда робот Google приходит повторно, сервер может коротко ответить «ничего не менялось» вместо пересылки всей страницы. Это экономит ресурсы и помогает роботу заходить чаще — важно, если контент часто обновляется.
Почему это важно
На ранжирование эта проверка не влияет напрямую: Google прямо говорит, что дело в эффективности обхода, а не в позициях. Смысл в другом — если сервер не умеет отвечать «страница не менялась» на повторный визит робота, каждый заход означает скачивание полной страницы заново. На сайте с тысячами страниц это съедает лимит обхода, и часть контента обновляется в индексе с задержкой. Незаметность тут и есть главная беда: сервер объявляет заголовок ETag, но не проверяет его на входящих запросах, либо дата в Last-Modified записана в формате, который робот не может разобрать. Правка обычно на стороне сервера, для типовых CMS это вопрос конфигурации веб-сервера, а не переписывания кода.
Откуда взялись требования
Инфраструктура обхода Google поддерживает ETag/If-None-Match и Last-Modified/If-Modified-Since и рекомендует ETag. Наличие валидаторов читается из заголовков ответа; если они есть, дополнительно выполняется реальный условный запрос. Робот Яндекса этим механизмом не пользуется; на ранжирование напрямую не влияет. Первоисточник ↗
Категория проверки: Техническая база. Вес в оценке: 4/10.
Какие результаты возможны
Google не качает страницу заново, если она не менялась
Сервер отвечает кодом 304 на условный запрос (робот спрашивает «менялась ли страница», сервер отвечает «нет» без пересылки). Google не перекачивает неизменившиеся страницы и тратит меньше времени на обход сайта. Робот Яндекса этим механизмом не пользуется.
Робот скачивает страницу заново при каждом визите
Сервер не отдаёт ни ETag (короткая метка версии страницы), ни Last-Modified (дата последнего изменения), поэтому Google качает страницу целиком при каждом заходе. Где чинить, зависит от того, кто формирует ответ. Файл с диска: nginx проставляет ETag сам, директива etag включена по умолчанию, отключить её мог только явный «etag off;»; в Apache за это отвечает FileETag MTime Size. Страницу собирает движок или PHP: ни та ни другая настройка на неё не действует, заголовок ставится там же, где формируется ответ, или на кэширующем слое перед бэкендом. На позиции это не влияет. Зато сервер отдаёт меньше данных, а робот быстрее замечает обновления.
Страница объявлена нехранимой: экономить обход нечем
Директива no-store запрещает сохранять ответ вообще, поэтому и спросить «менялась ли страница» некому: клиент ничего не хранит и сравнивать ему не с чем. Один ETag тут ничего не изменит, пока стоит no-store. Убирать его вслепую нельзя: на страницах с личным кабинетом, корзиной или сессией он стоит осознанно, и его снятие грозит показом чужих данных из кэша. Решение за тем, кто знает, что на странице: если она одинакова для всех посетителей, no-store лишний и его снимают вместе с добавлением ETag. На позиции ни то, ни другое не влияет.
Кэширование объявлено, но не работает
Либо не настроен сервер или CDN, либо страница успела измениться между двумя нашими запросами: у динамических страниц это в порядке вещей.
Дата обновления страницы в нечитаемом формате
HTTP ждёт вид «Wed, 21 Oct 2015 07:28:00 GMT»: день недели, дата, время, GMT. Надёжнее другой путь. Включите ETag (короткая метка версии страницы): Google рекомендует именно его, с форматом там ошибиться нельзя.
Кто исправляет
Такую задачу обычно адресуют разработчику или хостингу.
Другие проверки категории «Техническая база»
Частые вопросы: HTTP-кэширование обхода
Влияет ли HTTP-кэширование на позиции сайта в поиске?
Напрямую нет — Google описывает этот механизм как способ снизить нагрузку на сервер и сэкономить ресурсы обхода, а не как фактор ранжирования. Косвенный эффект возможен на больших сайтах: если робот тратит лимит обхода на повторную загрузку неизменившихся страниц, до новых или обновлённых страниц он может добираться медленнее.
Почему заголовок ETag есть, а кэширование обхода всё равно не работает?
Значит, сервер отдаёт заголовок ETag в ответе, но не проверяет значение If-None-Match во входящем запросе робота и при повторном визите всё равно присылает полную страницу. Это частая ошибка ручной настройки на nginx или в кастомном backend — заголовок добавили, а логику сравнения не реализовали.
Нужно ли настраивать это кэширование, если сайт обновляется редко?
Эффект будет минимальным. Механизм полезнее для сайтов с частыми обновлениями и большим количеством страниц, где экономия ресурсов обхода заметна. На небольшом сайте с редкими изменениями приоритет стоит отдать более весомым проверкам вроде скорости ответа сервера или доступности страниц для роботов.
Проверить страницу целиком
Эта проверка — одна из 52. Полный анализ показывает оценку от 0 до 100, разбор по категориям и список того, что чинить первым.