Что проверить после настройки HTTPS

Проверьте обычный запрос

Примеры используют зарезервированный домен example.com. Подставьте свой адрес. Не добавляйте -k: этот параметр отключает проверку сертификата и скрывает именно те ошибки, которые вы ищете.

# Заголовки ответа на GET, без тела
curl --silent --show-error --dump-header - \
  --output /dev/null https://example.com/

# Вся цепочка перенаправлений
curl --silent --show-error --location --dump-header - \
  --output /dev/null http://example.com/

Убедитесь, что сертификат подходит имени хоста, цепочка доверия полная, а перенаправления не образуют цикл. Проверьте продление сертификата и уведомление об ошибке обновления.

Заголовки должны совпадать с содержимым

Для HTML нужен корректный Content-Type с кодировкой. Язык страницы задаётся в html lang; Content-Language описывает предполагаемую языковую аудиторию ответа. Проверьте также canonical и метаданные для предпросмотра ссылок.

X-Content-Type-Options: nosniff ограничивает угадывание MIME-типа браузером. HSTS настраивайте осознанно: браузер запомнит требование HTTPS на указанный срок.

Кэш — часть корректной выдачи

Last-Modified должен отражать изменение представления, а не придуманную дату публикации. Дату статьи храните отдельно в тексте и структурированных данных. Для изменившейся страницы должен измениться валидатор кэша.

Для статических ресурсов удобно использовать версионированные имена и длительный кэш. Для HTML выбирайте политику, которая позволяет своевременно получать обновления.

Проверьте ошибки как отдельный сценарий

curl --silent --output /dev/null \
  --write-out '%{http_code}\n' \
  https://example.com/this-page-does-not-exist

Красиво оформленная страница ошибки должна возвращать HTTP 404. Ответ 200 для любого несуществующего адреса создаёт soft 404 и мешает клиентам различать успех и ошибку.