Приёмка перехода на HTTPS: шаблон чек-листа

Лист приёмки перехода на HTTPS (для заполнения)

Когда использовать: Примите переход с HTTP на HTTPS, где каждой проверке отведена строка: ожидаемый результат, способ проверки, ответственный, итог и доказательства.

Лист приёмки перехода на HTTPS

Сайт: [канонический HTTPS-адрес, например https://www.example.com]. Дата запуска: [дата]. Кто подписывает: [имя].

Одна проверка - одна строка. Строка считается пройденной, только если в колонке «Доказательства» есть ссылка, которую может открыть кто-то другой.

Открытые проблемы

• Проблема: [что не прошло] Действие: [исправление] Ответственный: [имя] Срок: [дата]

Итоговая проверка

• Все строки, кроме HSTS, отмечены как пройденные, и к ним приложены доказательства.
• У каждой открытой проблемы есть ответственный и срок, или она закрыта.
• Повторные проверки назначены на [запуск + 7 дней] и [запуск + 30 дней].
• Подписано: [SEO-специалист] и [разработчик], дата [дата].

Проверяйте выборку редиректов в Redirect Checker: он показывает каждый переход, код ответа и конечный URL, а также находит циклы.

Проверка SSL/TLS-сертификата

Когда использовать: Убедитесь, что сертификат действителен, покрывает все хосты и продлевается автоматически, ведь сроки его жизни сокращаются.

Сертификат должен быть действительным, доверенным и продлеваться

При проблемах с сертификатом браузер показывает предупреждение на весь экран. Пользователи уходят, а HTTPS-адреса невозможно нормально оценить.

• Доверие: сертификат выпущен признанным центром сертификации, для [Домен] установлена полная цепочка промежуточных сертификатов.
• Хосты: покрыты все адреса, которые вы обслуживаете: [с www и без www], а также поддомены, с которых отдаются страницы или ресурсы.
• Срок действия: запишите дату окончания ([Дата окончания]) и кому придёт оповещение, если продление не сработает.
• Продление: только автоматическое. С более короткими сроками ручное продление не справится.

Сроки жизни сертификатов сокращаются

• Сейчас сертификаты Let's Encrypt по умолчанию выдаются на 90 дней.
• С 10 февраля 2027 года Let's Encrypt сокращает срок по умолчанию до 64 дней.
• С 16 февраля 2028 года Let's Encrypt планирует срок по умолчанию 45 дней.
• По отраслевым правилам с 15 марта 2029 года все публичные сертификаты будут выдаваться максимум на 47 дней.

Что сделать: используйте ACME-клиент с поддержкой ACME Renewal Information (ARI) или продлевайте сертификат примерно на двух третях срока. Поищите в скриптах жёстко прописанные таймеры на 60, 80 или 83 дня.

Переход на HTTPS (редиректы и одна каноническая версия)

Когда использовать: Перенаправьте каждый HTTP-адрес на его HTTPS-аналог за один переход и обновите canonical, ссылки и sitemap.

Все адреса должны вести на одну защищённую версию

Для Google http и https, www и без www - это разные URL. Выберите один канонический адрес сайта, например [https://www.example.com], и перенаправляйте всё на него.

1. Сопоставьте каждый HTTP-адрес с точно таким же HTTPS-адресом. Никогда не перенаправляйте всё скопом на главную.
2. Настройте постоянные редиректы на сервере (301 или 308) сразу на конечный URL, за один переход.
3. Сохраняйте полный путь и параметры запроса.
4. Держите редиректы минимум год. Google советует как можно дольше.

Обновите всё, где указан URL

• Канонические теги на HTTPS-страницах, указывающие на саму страницу.
• Внутренние ссылки, разметку hreflang, URL в структурированных данных.
• Sitemap: только HTTPS-адреса на каноническом хосте.
• robots.txt на HTTPS-хосте, включая строку Sitemap.
• Рекламу, шаблоны писем, профили в соцсетях и другие ссылки, которыми вы управляете.

Search Console: не используйте инструмент «Изменение адреса» (Change of Address). Google пишет, что он не нужен при переходе с HTTP на HTTPS или с www на версию без www в пределах одного домена.

Соберите sitemap заново из списка HTTPS-адресов в XML Sitemap Generator. Ему нужны абсолютные URL, совпадающие с вашими canonical.

Исправление смешанного контента

Когда использовать: Найдите и исправьте HTTP-ресурсы на HTTPS-страницах, пока браузеры их не заблокировали.

Все ресурсы должны загружаться по HTTPS

Смешанный контент - это HTTPS-страница, которая загружает ресурсы по HTTP. Современные браузеры поступают с ним двумя способами (по данным MDN):

• Обновляемый: обычный img src, audio и video. Браузер пробует загрузить HTTPS-версию. Если не получается, ресурс не загружается.
• Блокируемый: скрипты, стили, iframe, шрифты, запросы fetch и изображения через srcset или picture. Браузер их блокирует.

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

1. Откройте DevTools на каждом шаблоне ([Список шаблонов]) и найдите в консоли сообщения о смешанном контенте.
2. Просканируйте сайт и отфильтруйте адреса ресурсов, которые начинаются с http://.
3. Переведите свои ресурсы на HTTPS или относительные URL, и в шаблонах, и в базе данных.
4. Переключите сторонние встраивания на HTTPS-версии, а те, у которых её нет, замените.

Быстро проверить одну страницу можно в Get Source Code of Webpage: инструмент покажет ресурсы, на которые ссылается исходный HTML.

Примечание: директива CSP upgrade-insecure-requests переводит все запросы на HTTPS, но исходные URL всё равно нужно исправить.

HSTS и заголовки безопасности

Когда использовать: Безопасно добавьте HSTS и основные заголовки безопасности и узнайте правила preload, прежде чем на это решиться.

Усильте защиту соединения заголовками

Добавляйте заголовки на сервере или в CDN, когда HTTPS уже работает стабильно. Сначала проверяйте каждый на staging.

• Strict-Transport-Security (HSTS): велит браузерам открывать сайт только по HTTPS. Начните с короткого max-age, потом увеличивайте.
• Content-Security-Policy: ограничивает, откуда загружаются скрипты и стили. frame-ancestors определяет, кто может встраивать ваш сайт во фрейм.
• X-Content-Type-Options: nosniff запрещает браузеру угадывать MIME-тип.
• Referrer-Policy: определяет, какие данные об URL передаются другим сайтам.

Требования для HSTS preload (hstspreload.org)

• Действительный сертификат и редирект с HTTP на HTTPS на том же хосте.
• Все поддомены работают по HTTPS, включая www, если для него есть DNS-запись.
• max-age не меньше 31536000 (1 год), плюс includeSubDomains и preload.

Внимание: отменить preload сложно. Удаление из списка доходит до пользователей Chrome месяцами. Подавайте сайт в preload, только когда лист приёмки полностью пройден.

Проверьте заголовки на [URL страницы] в Get Source Code of Webpage: инструмент показывает заголовки ответа и безопасности.

Контрольное сканирование и Search Console

Когда использовать: Докажите, что HTTPS-сайт сканируется без ошибок, и отслеживайте переход в отчётах Search Console.

Докажите, что Google может сканировать HTTPS-сайт

Того, что редиректы работают в браузере, мало. Просканируйте HTTPS-сайт так, как это сделал бы робот, а потом следите за Search Console.

1. Просканируйте [https://www.example.com] и убедитесь, что индексируемые страницы отдают 200.
2. Отфильтруйте внутренние ссылки, canonical и hreflang, которые всё ещё ведут на http://.
3. Просканируйте список старых HTTP-адресов и убедитесь, что каждый отдаёт один постоянный редирект.
4. Уберите временные noindex и запреты в robots.txt, которые ставили на время переезда.

Проверки в Search Console

• Ресурсы: ресурс на уровне домена или оба ресурса с префиксом URL, для HTTP и для HTTPS. Отчёт «HTTPS» появляется только в ресурсе на уровне домена или в ресурсе с префиксом HTTPS.
• Отчёт «Файлы Sitemap» (Sitemaps): отправьте HTTPS-sitemap, затем отфильтруйте по нему отчёт «Индексирование страниц» (Page indexing) и следите, как растёт число проиндексированных HTTPS-адресов.
• Отчёт «HTTPS»: ищите проблемы «HTTP marked with canonical tag» (canonical указывает на HTTP), «HTTPS has invalid certificate» (недействительный сертификат), «Sitemap points to HTTP» (sitemap ссылается на HTTP), «HTTPS has redirect» (HTTPS-адрес перенаправляет) и «HTTPS URL is roboted» (HTTPS-адрес заблокирован в robots.txt).
• Отчёт «Индексирование страниц» (Page indexing): со временем HTTP-адреса должны перейти в статус «Page with redirect» (страница с переадресацией).

Записывайте результаты в лист с датами: [дата сканирования], [просканировано URL], [найдено проблем].

Проверка на взлом и вредоносный код

Когда использовать: Найдите внедрённый спам, вредоносный код или редиректы, от которых один только HTTPS не защищает.

Заметьте взлом раньше, чем Google

HTTPS защищает данные при передаче. Но он не мешает взломанному сайту показывать спам, вредоносный код или скрытые редиректы.

• Отчёт «Проблемы безопасности» (Security issues): проверьте его в Search Console для [Ресурс]. Здесь Google показывает взломанный контент, вредоносное ПО и обманные страницы.
• Поиск по сайту: поищите в Google по своему домену спамные запросы или страницы, которые вы никогда не публиковали.
• Файлы и база данных: ищите внедрённые скрипты, неизвестных администраторов и изменённые файлы ядра.

1. Если сайт помечен, удалите этот контент и закройте лазейку, например устаревший плагин или слабый пароль.
2. Обновите ПО и смените пароли для [Аккаунты].
3. Когда сайт очищен, запросите проверку в отчёте «Проблемы безопасности».

Совет: убедитесь, что письма-оповещения от Search Console получает человек, который на них отреагирует.

Аудит и мониторинг

Когда использовать: Регулярно перепроверяйте сертификаты, редиректы, смешанный контент и заголовки после приёмки.

Поддерживайте HTTPS в порядке после приёмки

Сертификаты истекают, новые страницы выходят с ресурсами по http://, а после изменений на сервере пропадают заголовки. Перепроверяйте всё по графику.

Записывайте каждую находку с ответственным в [Трекер] и перепроверяйте после исправления.

Бесплатный аудит сайта за один запуск перепроверяет HTTPS, редиректы, robots.txt и sitemap.

Заполненный пример (вымышленный магазин туристического снаряжения)

Когда использовать: Посмотрите на заполненный лист приёмки, включая ошибки, которые он выявил в день запуска.

Заполненный пример: Ridgeline Supply переходит на HTTPS

Только для примера. Компания, люди, адреса и цифры выдуманы, чтобы показать, как выглядит рабочая заполненная версия.

Ridgeline Supply, магазин туристического снаряжения примерно на 1 200 URL, 14 октября перевёл http://ridgeline-supply.example на https://www.ridgeline-supply.example.

Почему это сработало

• Все строки проверили в день запуска, поэтому три ошибки нашли до того, как Google пересканировал большую часть сайта.
• Sitemap проверяли отдельной строкой, поэтому его исправили в тот же день, а не отдавали HTTP-адреса неделями.
• HSTS начали с короткого срока, поэтому неудачный редирект ещё можно было откатить, не привязав браузеры к HTTPS надолго.

Что дальше

Запустите бесплатный аудит сайта для главной страницы на HTTPS. Он проверит, что сайт открывается по HTTPS и что http:// перенаправляет на него, а также посмотрит редиректы, robots.txt и sitemap.