В CMS title уже исправлен, но посетитель получает прежний. Повторное сохранение текста может быть бесполезно: старый ответ находится в кеше CDN, приложения или браузера. Диагностика сравнивает тело HTML и признаки кеширования на каждом доступном уровне.
Найдите первое место появления старого значения
Отделите исходные данные CMS, сформированный HTML origin и публичный ответ. Значение в DOM может дополнительно изменить JavaScript. Исправлять нужно слой, где новый текст впервые превращается в старый, а не переписывать поле снова.
HTTP-кеширование использует правила актуальности и проверки сохранённого ответа; no-cache требует повторной валидации. Официальная документация.
Запишите новый title из редактора и фактический старый title публичной страницы. Затем сравните сформированный сервером HTML и ответ через обычный публичный маршрут, используя только разрешённый диагностический доступ. Если origin уже новый, а CDN старый, повторное сохранение записи не решает причину. Если оба старые, смотрите генератор и его источник данных. Если HTML новый, а document.title старый, проверьте клиентский код. Эти четыре наблюдения дают конкретный слой исправления и предотвращают бессмысленную очистку всех возможных кешей по очереди.
Матрица CMS, origin, CDN и браузера
Учебные сценарии в таблице задают ожидаемое поведение; фактические ответы своего сайта заносите отдельно.
| Сценарий | Отличие | Решение | Проверка |
|---|---|---|---|
| Поле CMS | Новый текст сохранён | Проверить генератор | Не только редактор |
| HTML origin | Вычисленная страница | Сравнить с CMS | Новые значения |
| CDN ответ | Публичная копия | Проверить актуальность | Не старый body |
| 304 | Повторное использование | Сопоставить validator | Известно тело клиента |
Добавьте гостевой и авторизованный режим, обычный URL и предусмотренный диагностический запрос. Администратор может обходить кеш, поэтому его успешный просмотр не подтверждает внешний ответ. Query-параметр способен менять cache key; не принимайте свежий ответ с случайным параметром как приёмку обычной страницы. В матрице укажите различия Vary, cookies и заголовков, если они реально участвуют в системе. Для каждого режима сохраняйте тело, а не только отметку HIT или MISS. Одинаковый заголовок кеша не гарантирует одинаковое содержание двух ответов.
Сохраните тело HTML и заголовки валидаторов
Получите GET страницы и сохраните title, description, ETag, Last-Modified, Cache-Control, Age и доступные cache-status заголовки. Сравните гостевой и авторизованный ответ в разрешённых условиях; разные ключи кеша дают разные версии.
Сохраните ETag, Last-Modified, Cache-Control, Age и доступные заголовки инфраструктуры вместе с извлечёнными метатегами. Эти признаки помогают проверке, но их отсутствие не доказывает отсутствие кеша. Посмотрите, какой компонент устанавливает срок актуальности HTML и какой событие изменения CMS вызывает инвалидирование. Для title и description проверяйте исходный документ, а не API-запрос, который возвращает новый текст отдельно. Сравните канонический URL запроса: технический вариант со слешем или хостом может иметь иной сохранённый ответ.
Учебный тест изменения description
Учебная услуга меняет description, а CDN сохраняет старый HTML. Запрос origin уже новый, обычный гостевой URL — старый. Очистка соответствующего ключа должна изменить именно публичный ответ, не только диагностический адрес.
В учебной услуге измените description на тестовой копии, сохранив прежнее значение. Получите origin-ответ и публичный ответ по тому же URL. Если новый текст виден только на origin, инвалидируйте предусмотренный ключ HTML и повторите обычный GET. Затем ещё раз сохраните запись: обновление должно работать штатно, без ручного purge каждый раз. Опыт не доказывает состояние поискового индекса; он проверяет цепочку публикации. Для реального сайта используйте безопасное редакционное изменение или уже выполненную правку, не подменяя публичный текст случайным диагностическим маркером.
Исправьте инвалидирование нужного представления
Исправьте инвалидирование конкретного HTML-ресурса и согласованную политику актуальности. Очистите предусмотренный ключ и проверьте обычный публичный URL без диагностических параметров. Убедитесь, что новая генерация не возвращает старые данные.
Определите, инвалидирует ли CMS страницу, связанный список и варианты языка. Неполный purge может обновлять карточку, но оставлять устаревший title в другой форме URL. Исправьте событие и ключи на подтверждённом слое. Не отключайте весь кеш, если задача касается актуальности одного представления. После правки проверьте холодный и повторный запрос. Политика срока хранения должна учитывать частоту изменения конкретного HTML. Статические bundle и изображения имеют другие требования; не распространяйте на них новое правило автоматически только потому, что они обслуживаются тем же CDN.
Условный запрос и 304 требуют знания старого тела
No-cache требует проверки актуальности перед повторным использованием, а не запрещает хранение. Один ответ 304 без сохранённого тела клиента не показывает, какой title посетитель фактически видит.
При условном запросе клиент может отправить If-None-Match или If-Modified-Since и получить 304. Этот ответ сообщает о повторном использовании сохранённого представления и не содержит обычного нового тела страницы. Для диагностики нужно знать, какое тело клиент сохранил и согласован ли валидатор с текущей версией. No-cache разрешает хранение с последующей проверкой, тогда как no-store имеет другое назначение. Не выбирайте директиву по бытовому смыслу названия. Проверьте обычный полный ответ и предусмотренную валидацию, сохраняя оба наблюдения отдельно.
Приёмка обычного гостевого адреса
Откройте обычный гостевой адрес в свежем сеансе и затем повторно. Сравните исходный HTML, DOM и метатеги с принятым редакционным значением. Проверьте вариант хоста и локали, если они входят в поддерживаемую модель. Штатное сохранение записи должно обновлять нужные представления без ручной правки ответа. Поисковый сниппет добавляйте отдельным датированным наблюдением: он может использовать другой текст и прежний обход. Приёмка здесь подтверждает публикацию свежих метаданных и работу кеширования, а не обещает немедленное изменение выдачи.
Критерии завершения проверки
Обычный гостевой GET и предусмотренное повторное открытие получают новые метатеги. Проверка условного запроса согласована с новым представлением; авторизация и локальный DOM не скрывают старый публичный HTML.
- Поле CMS: Не только редактор. Зафиксируйте фактический результат и адрес проверенного сценария.
- HTML origin: Новые значения. Зафиксируйте фактический результат и адрес проверенного сценария.
- CDN ответ: Не старый body. Зафиксируйте фактический результат и адрес проверенного сценария.
- 304: Известно тело клиента. Зафиксируйте фактический результат и адрес проверенного сценария.
Для смежных вопросов: Стратегии кэширования для веб-приложений: от браузера до CDN и Как контролировать изменения Title, meta robots и canonical. Отдельные проверки сайта собраны на странице технического аудита reChecker.