HTTP-кеширование позволяет повторно использовать уже полученный ресурс и проверять, изменился ли он на сервере. Для сайта это вопрос передачи данных, нагрузки и актуальности. Для SEO важно, чтобы робот получал новую версию после изменения, а неизменившийся документ не требовал лишней передачи полного тела ответа.
Кеш браузера, промежуточного узла и приложения — разные механизмы. Успешная очистка одного уровня не доказывает, что все посетители уже получают свежий HTML. Разбирать проблему следует на конкретном адресе и конкретном пути запроса.
Что происходит при условном запросе
В технической публикации от 9 декабря 2024 года описана поддержка кеширования поисковыми роботами через пары ETag / If-None-Match и Last-Modified / If-Modified-Since. Клиент передаёт известный ему валидатор, а сервер проверяет актуальность представления. Если оно не изменилось, возможен ответ 304 без повторной передачи тела документа.
304 не означает, что страница пропала, и не является обещанием лучшего ранжирования. Его смысл — использование уже имеющейся версии. Если сервер ошибочно подтверждает старую копию после изменения, кеширование начинает мешать обновлению.
Как проверить ETag на тестовой странице
Выберите публичный материал без персонализации. Выполните обычный GET-запрос и сохраните ETag из ответа. Затем повторите запрос с этим значением в If-None-Match. Ниже — условная последовательность, а не готовая конфигурация сервера:
GET /guide/ HTTP/1.1 Host: example.org HTTP/1.1 200 OK ETag: "page-v1" GET /guide/ HTTP/1.1 Host: example.org If-None-Match: "page-v1" HTTP/1.1 304 Not Modified
Теперь измените значимый фрагмент материала в тестовой среде и повторите запрос со старым валидатором. Ожидается новая версия представления, а не ошибочное подтверждение старой. Значение ETag в примере условное: в рабочем приложении оно должно формироваться последовательно по выбранной стратегии.
Чем no-cache отличается от no-store
Руководство по HTTP-кешированию поясняет: no-cache допускает хранение, но требует проверки перед повторным использованием; no-store запрещает сохранение ответа кешем. Директива private ограничивает использование общими кешами. Это разные условия, а не взаимозаменяемые способы «ускорить сайт».
Поэтому правило для общедоступной инструкции нельзя бездумно переносить на личный кабинет. Отдельно решайте, какой контент можно хранить, где и как долго. Для файлов с версией в имени и для часто меняющегося HTML обычно нужны разные стратегии.
Проверьте цепочку после публикации
- Запишите время обновления материала и контрольную фразу новой версии.
- Получите страницу без сохранённой копии на стороне клиента.
- Проверьте повторный условный запрос с предыдущим валидатором.
- Сравните заголовки и содержимое через публичный адрес и доступный для диагностики серверный путь.
- Повторите проверку после окончания заданного времени хранения.
Если на одном узле виден новый текст, а через публичный адрес — старый, уточните правила промежуточного кеша. Не меняйте адрес статьи при каждом обновлении только для обхода кеширования: это затрагивает внутренние ссылки и историю URL. Исправлять следует механизм актуализации.
Какие ошибки искать в первую очередь
Подозрительны постоянный ETag при изменении представления, неверный Last-Modified и слишком длительное хранение часто обновляемого HTML. Другая крайность — изменение валидатора при каждом запросе без реального изменения содержимого: проверка перестаёт экономить передачу.
Не оценивайте экономию только по журналу приложения. Часть ответов может обслуживаться раньше по цепочке. Сопоставляйте доступные журналы и границы измерения; порядок работы описан в статье про анализ серверных логов.
Что считать результатом
После правки неизменённый ресурс допускает корректное повторное использование, а изменённый становится доступен согласно выбранной политике. Скорость страницы можно дополнительно оценить через аудит сайта, но сами заголовки и условные запросы проверяются сетевыми инструментами. Если устаревшая копия содержит неправильные правила индексации, сверяйтесь с проверкой robots.txt и noindex.