В CMS появился новый title, разработчик убрал noindex, но внешняя проверка получает прежние значения. Повторное сохранение страницы может ничего не изменить: запрос до опубликованной версии ещё не дошёл. Между редактором и посетителем находятся кэш приложения, reverse proxy, CDN и браузер.
Задача проверки — определить, на каком участке сохраняется старый ответ. Сначала зафиксируйте ожидаемые значения и фактические ответы. Очистка всех кэшей одновременно иногда убирает симптом, однако оставляет неизвестной причину его следующего появления.
Зафиксируйте точный URL и ожидаемую правку
Запишите полный адрес с протоколом, хостом, путём и параметрами. Укажите время публикации, прежний title, новый title и ожидаемую директиву robots. Фраза «убрали запрет индексации» недостаточна: запрет мог находиться в HTML, HTTP-заголовке или нескольких местах сразу.
В условном примере у страницы /catalog/desks/ изменили title и удалили HTML-тег noindex. Проверка должна получить новый заголовок страницы и отсутствие запрещающей директивы во всех действующих источниках. Значение index,follow в одном теге не доказывает, что другой источник перестал запрещать индексацию.
Проверяйте опубликованную страницу как посетитель без административной сессии. Авторизованный редактор может обходить кэш приложения и видеть свежую версию, пока обычные пользователи получают сохранённую. Сравнение двух режимов помогает объяснить расхождение, но не заменяет проверку публичного ответа.
Сохраните HTML вместе с HTTP-заголовками
Получите ответ методом GET. HEAD может обрабатываться другой веткой инфраструктуры, поэтому для подтверждения содержимого нужен сам документ. Сохраните тело и заголовки одного запроса, чтобы не сопоставить случайно две разные версии.
curl -sS -D /tmp/page-headers.txt \
-o /tmp/page-body.html \
'https://example.com/catalog/desks/'Проверьте статус, конечный URL, title, все meta robots и каждый X-Robots-Tag. При редиректе отдельно снимите ответ конечной страницы. В документации Google о robots указано, что при конфликте применяется более ограничивающее правило. Поэтому удаление noindex из HTML при сохранённом noindex в заголовке не решает задачу.
Различия механизмов описаны в материале о robots.txt, meta robots и X-Robots-Tag. Здесь важно найти конкретный источник старого значения: отсутствие изменений в поисковой выдаче пока не служит таким доказательством.
Разделите четыре возможных места хранения
HTML и заголовки могут устаревать вместе, однако формируются разными участниками. Приложение создаёт документ, веб-сервер добавляет свои заголовки, CDN сохраняет ответ, браузер повторно использует полученную копию. Одинаковый симптом требует разных исправлений.
| Наблюдение | Рабочая гипотеза | Следующая проверка |
|---|---|---|
| Старое значение только в привычном браузере | Локальный кэш или service worker | Новая сессия и сетевой журнал |
| Публичный GET старый, исходный сервер свежий | Кэш промежуточного слоя | Ключ объекта и правила CDN |
| Исходный сервер тоже отдаёт старый HTML | Кэш приложения или старая сборка | Версия публикации и генерация страницы |
| HTML свежий, X-Robots-Tag прежний | Отдельное правило заголовка | Конфигурация сервера и CDN |
Это диагностическая матрица, а не установленная причина. Например, различие между двумя сетями может объясняться разными серверами за балансировщиком. Подтвердите слой ответом или настройкой, прежде чем назначать исполнителя.
Прочитайте возраст ответа и правила обновления
Запишите Cache-Control, Age, ETag, Last-Modified, Vary и служебный заголовок статуса кэша, если инфраструктура его добавляет. Заголовки HIT/MISS и их названия зависят от используемого CDN. Отсутствие Age само по себе не доказывает, что кэширования нет.
В руководстве MDN по HTTP-кэшированию разделены частные и общие кэши, свежесть ответа и повторная валидация. no-cache разрешает хранение, но требует проверки перед повторным использованием; no-store запрещает хранение. Подмена одного другим без понимания задачи может увеличить нагрузку и не очистить уже сохранённые объекты.
Проверьте валидаторы условным запросом со старым ETag. Если документ изменился, сервер не должен подтверждать прежнюю версию ответом 304. Значение ETag и возвращаемое тело должны относиться к одной актуальной версии. Общие настройки разобраны в статье о заголовках кэширования.
Сравните CDN, исходный сервер и браузер
Для проверки исходного сервера используйте согласованный с эксплуатацией маршрут, который сохраняет нужные Host и TLS-имя. Запрос к голому IP может попасть в другой виртуальный хост и дать ложное сравнение. Сохраните, к какому серверу и какой версии приложения обращались.
В браузере откройте инструменты разработчика, отключите локальный кэш и сделайте новую навигацию на проверяемый адрес. Изучите документ в Network и итоговый DOM. Отключение браузерного кэша не очищает CDN; если service worker обслуживает навигацию, его участие также нужно проверить отдельно.
Повторите обычный публичный GET из независимой сети. Не считайте добавление случайного query-параметра окончательной проверкой: такой URL может иметь другой ключ кэша или другой ответ приложения. Требуется свежая версия по тому адресу, который действительно открывают посетители и поисковые роботы.
Исправьте подтверждённый слой и проверьте повторение
Если устарел объект CDN, очистите нужный ключ и связанные варианты, которые действительно обслуживают эту страницу. Если старый HTML генерирует приложение, исправьте инвалидирование при публикации. Для прежнего X-Robots-Tag измените правило его формирования: обновление текста в CMS не управляет этим заголовком автоматически.
После исправления запросите страницу дважды. Первый запрос может сформировать свежий объект, второй — показать, что в кэш сохранилось правильное содержимое. Затем проверьте адрес после времени жизни объекта или очередной публикации. Цель — воспроизводимое обновление, а не удачный единственный запрос после ручной очистки.
В задаче разработчику приложите URL, время, ожидаемые значения, пары HTML/заголовки и подтверждённый слой. Для самостоятельной диагностики достаточно этих данных; HAR-файл перед передачей очистите от cookies и других данных сессии. Отдельно укажите, зависел ли результат от авторизации.
Примите правку по публичному ответу
Критерии приёмки задают до закрытия задачи:
- обычный GET конечного URL возвращает ожидаемый title;
- HTML и HTTP-заголовки не содержат нежелательного noindex;
- повторный запрос к сохранённому объекту даёт ту же актуальную версию;
- новая браузерная навигация показывает согласованный результат;
- следующая публикация обновляет страницу предусмотренным механизмом.
Для сверки текущих технических признаков используйте техническую проверку reChecker, сохранив конкретный URL и дату отчёта. Её результат сопоставляйте с полученными ответами; браузерное выполнение и внутренний маршрут до исходного сервера требуют отдельной проверки.
Если сайт уже отдаёт правильные директивы, а поисковый отчёт хранит прежние сведения, сравните дату последнего обхода с датой исправления. Это следующий этап расследования. Обновление кэша не гарантирует немедленную индексацию, новый сниппет или рост позиций: оно подтверждает, что публичный сайт перестал передавать прежний технический сигнал.