Изменения сайта не видны: как найти старый HTML или CSS

1. Выберите узнаваемое изменение

Допустим, вы изменили время начала мастер-класса с 10:00 на 11:00, а публичная страница всё ещё показывает 10:00. Используйте этот текст как признак версии. Для изменения оформления выберите конкретное правило или имя файла. Нужна разница в полученном файле, а не только сообщение «публикация завершена».

Скопируйте конечный публичный адрес из браузера после перенаправлений. Проверьте язык, домен и путь: предпросмотр, сеанс редактора или другой перевод могут показывать иную версию. По возможности сравните ту же публичную страницу без входа в аккаунт. Для закрытых страниц сохраняйте тот же аккаунт и вариант ответа.

• Ожидаемый признак: 11:00. Полученный: 10:00. Запишите точный конечный URL.
• Есть ли признак в собранной или выбранной для публикации версии? Если нет, сначала проверьте сохранение, сборку и выбор публикации.
• Если устарели только результат Google или превью в социальной сети, сравните их с живой страницей. Эти сервисы могут хранить отдельные копии; обновление браузера не меняет сохранённый результат.

2. Проверьте документ, затем его файлы

В настольном Chrome откройте DevTools → Network до перезагрузки. Выберите запрос документа (Doc), проверьте конечный адрес и найдите признак версии во вкладке Response. Сначала прочитайте сам ответ: в Elements страница уже может быть изменена JavaScript. Если приложение получает текст позже, проверьте и соответствующий ответ Fetch/XHR.

Теперь включите Disable cache, оставьте DevTools открытыми и перезагрузите страницу. Так проверяется HTTP-кеш браузера. Эта настройка не очищает CDN или хранилище service worker приложения. Запишите, изменился ли признак версии в ответе. Перед итоговой проверкой обычного визита выключите настройку.

• Старый ответ документа → проверьте этот HTML-адрес и публикацию, которая его обслуживает.
• Новый HTML, но старое оформление → проверьте конкретный CSS, JavaScript или рисунок, на который ссылается HTML. Копия файла по прежнему адресу может сохраняться дольше документа.
• Новые ответы документа и файлов, но прежний вид страницы → проверьте содержимое, которое рисует скрипт, переопределения CSS и состояние приложения. Очистка HTTP-кеша может не помочь.
• Отсутствие запроса документа после кнопки «Назад» ещё не доказывает неисправность кеша. Откройте точный URL или перезагрузите страницу с включённой записью запросов.

3. Сравните с запросом вне браузера

Для публичной страницы замените пример адреса ниже на записанный конечный URL. Выполните команду в терминале; в Windows используйте curl.exe, если curl — псевдоним PowerShell. Этот GET выводит заголовки и тело ответа. При перенаправлениях проверяйте последний блок ответа.

Сначала выполните первую команду, затем вторую для сравнения. Эти запросы не используют сохранённый ответ браузера и не запускают его service worker. Но они проходят через публичный домен и его инфраструктуру доставки, включая CDN. Вторая команда просит кеши проверить ответ перед повторным использованием; она не гарантирует прямого соединения с исходным сервером и ничего не очищает.

Сравните признак версии и статус в обоих результатах с браузером. curl не выполняет JavaScript и не использует ваш сеанс входа. Cookies, язык и другие варианты ответа могут объяснять разницу, поэтому одно расхождение ещё не устанавливает виновный кеш.

• curl -sS -L --max-redirs 5 --max-time 20 -i "https://example.com/page/"
• curl -sS -L --max-redirs 5 --max-time 20 -i -H "Cache-Control: no-cache" "https://example.com/page/"

4. Прочитайте заголовки без догадок

• Cache-Control: max-age=3600 позволяет считать ответ свежим в течение часа. Старая редакция текста при этом может быть свежей по правилам HTTP.
• Cache-Control: no-cache разрешает хранение, но требует проверки перед повторным использованием. no-store запрещает сохранять этот ответ; переход на него не удаляет копии, уже находящиеся в других кешах.
• ETag — признак версии для проверки актуальности. Ответ 304 на условный запрос означает использование сохранённого тела: это не новая загрузка HTML и не обязательно ошибка. Если содержимое изменилось, а признак нет, проверьте его вычисление и выбранную публикацию.
• Age оценивает секунды с создания ответа или успешной проверки на исходном сервере. Это не время с вашей правки. Отсутствие Age не доказывает, что запрос дошёл до исходного сервера.
• Специальные заголовки CDN могут дать подсказку. Уточните их значение у провайдера, прежде чем считать HIT, MISS или отсутствие заголовка готовым диагнозом.

5. Контрольный пример: свежий HTML, старые стили

21 октября 2026 года Coru провела изолированный опыт с HTTP/1.1 в Chromium 155.0.8059.12 и curl 8.5.0. После изменения HTML и CSS на локальном сервере обычный повторный переход показал новый текст release-2, но сохранил старый красный стиль: нового запроса таблицы стилей на сервер не поступило. Отключение HTTP-кеша браузера загрузило изменённый CSS и сделало стиль синим. В отдельной проверке неизменённый HTML с no-cache и ETag получил сетевой ответ 304; после изменения тела и ETag пришёл 200 с новым текстом. Это контрольные технические результаты, а не измерения поведения читателей.

Чтобы повторить идею на локальном тестовом сайте, задайте HTML заголовок no-cache и ETag, меняющийся вместе с телом, а таблице стилей — max-age=3600. Откройте страницу, затем измените признак в HTML и правило CSS, сохранив адрес CSS. Снова перейдите на страницу обычным способом и сравните ответы документа и CSS. В конце отключите кеш браузера и перезагрузите страницу. Этот локальный опыт с HTTP-кешем не проверяет CDN или service worker.

6. Исправьте найденный уровень

• Публикация: убедитесь, что нужная сборка выбрана для правильного домена и пути. Снова проверьте признак версии в полученном ответе.
• Кеш браузера для изменяемого файла: опубликуйте новое имя с версией, например style.v2.css, и одновременно обновите ссылку в HTML. Проверьте наличие нового файла; сохраните старые для страниц, которые ещё на них ссылаются.
• Общий кеш или CDN: после проверки нужной публикации на исходном сервере сбросьте затронутый URL или выпуск средствами провайдера. Повторно проверьте именно публичный адрес. Случайный параметр в URL — лишь подсказка: правила ключа кеша различаются.
• Service worker: в Chrome откройте Application → Service Workers. Bypass for network — отдельный диагностический переключатель. Если с ним результат меняется, проверьте стратегию кеширования и обновления worker, затем повторите проверку без обхода. Исправление должно доходить до возвращающихся посетителей с включённым worker.
• Политика кеша публичного HTML: если важны своевременные обновления, рассмотрите проверку актуальности перед повторным использованием с корректными валидаторами. Срок свежести файлов выбирайте отдельно; no-store не нужен для каждого публичного файла. Персонализированным страницам нужна отдельная политика с учётом конфиденциальности.

7. Сохраните короткую запись проверки

Запишите: точный конечный URL; ожидаемый и полученный признак; документ или файл; результат в обычном браузере; результат с Disable cache; результат curl; заголовки ответа; исправление; обычная перезагрузка после выключения диагностических настроек. Заголовки запросов и данные аккаунта храните приватно.

Успех — нужные текст и файлы приходят через настоящий публичный адрес при обычном визите, в том числе при повторном визите из браузера, который уже открывал страницу, если это относится к задаче. Одного скриншота после локальной очистки кеша или статуса 200 для этого недостаточно.

Источники и материалы

• MDN: HTTP caching
• Chrome DevTools: Network features reference
• Chrome DevTools: Debug Progressive Web Apps
• IETF RFC 9111: HTTP Caching