Шаблон приймання переходу на HTTPS: чекліст

Аркуш приймання переходу на HTTPS (для заповнення)

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

Аркуш приймання переходу на HTTPS

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

Один рядок на одну перевірку. Рядок пройдено, лише коли в колонці «Доказ» є посилання, яке може відкрити будь-хто інший.

Відкриті проблеми

• Проблема: [що не пройшло] Дія: [виправлення] Відповідальний: [ім'я] Термін: [дата]

Фінальна перевірка

• Кожен рядок, крім HSTS, має статус «Пройдено» і доданий доказ.
• Кожна відкрита проблема має відповідального й термін або закрита.
• Повторні перевірки заплановано на [запуск + 7 днів] і [запуск + 30 днів].
• Підписали [відповідальний за SEO] і [розробник], дата: [дата].

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

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

Коли використовувати: Переконайтеся, що сертифікат дійсний, покриває всі хости й продовжується автоматично, бо терміни дії скорочуються.

Переконайтеся, що сертифікат дійсний, довірений і продовжується

Через проблемний сертифікат браузер показує попередження на всю сторінку. Користувачі йдуть, а Google не може коректно оцінити HTTPS URL.

• Довіра: сертифікат видав визнаний центр сертифікації (CA), а для [Домен] встановлено повний ланцюжок проміжних сертифікатів.
• Хости: покриває всі імена, які ви обслуговуєте: [з 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 URL на його HTTPS-відповідник за один перехід і оновіть canonical, посилання та sitemap.

Ведіть кожен URL на одну захищену адресу

Для Google http і https, з www і без www - це різні URL. Оберіть одну канонічну адресу сайту, наприклад [https://www.example.com], і перенаправляйте все на неї.

1. Зіставте кожен HTTP URL з його точним HTTPS-відповідником. Ніколи не перенаправляйте все гуртом на головну.
2. Використовуйте серверні постійні редиректи (301 або 308) одразу на кінцевий URL, за один перехід.
3. Зберігайте повний шлях і рядок запиту (query string).
4. Тримайте редиректи щонайменше рік. Google радить якомога довше.

Оновіть усе, де згадано URL

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

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

Згенеруйте sitemap заново зі списку HTTPS URL за допомогою XML Sitemap Generator. Йому потрібні абсолютні URL, які збігаються з вашими canonical.

Виправлення змішаного вмісту

Коли використовувати: Знайдіть і виправте HTTP-ресурси на HTTPS-сторінках, поки браузери їх не заблокували.

Завантажуйте всі ресурси по HTTPS

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

• Автоматично оновлюються: звичайні img src, audio та video. Браузер пробує завантажити їхню HTTPS-версію. Якщо вона недоступна, ресурс не завантажується.
• Блокуються: скрипти, таблиці стилів, iframe, шрифти, запити fetch і зображення з srcset або picture. Браузер їх блокує.

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

1. Відкрийте DevTools на кожному шаблоні ([Список шаблонів]) і перегляньте в консолі повідомлення про змішаний вміст.
2. Проскануйте сайт і відфільтруйте URL ресурсів, що починаються з 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 URL і переконайтеся, що кожен віддає один постійний редирект.
4. Приберіть тимчасові noindex чи блокування в robots.txt, які використовували під час переїзду.

Перевірки в Search Console

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

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

Перевірка на злам і шкідливе ПЗ

Коли використовувати: Виявіть впроваджений спам, шкідливе ПЗ чи редиректи, від яких сам HTTPS не захищає.

Виявіть злам раніше за Google

HTTPS захищає дані під час передавання. Але він не завадить зламаному сайту показувати спам, шкідливе ПЗ чи приховані редиректи.

• Звіт «Проблеми безпеки» (Security issues): перевірте його в Search Console для [Ресурс]. Тут Google показує зламаний вміст, шкідливе ПЗ та оманливі сторінки.
• Пошук по сайту: пошукайте свій домен у Google за спамними ключовими словами або сторінками, яких ви ніколи не публікували.
• Файли та база даних: шукайте впроваджені скрипти, невідомих адміністраторів і змінені файли ядра.

1. Якщо сайт позначено, видаліть шкідливий вміст і закрийте шлях проникнення, наприклад застарілий плагін чи слабкий пароль.
2. Оновіть програмне забезпечення і змініть облікові дані для [Облікові записи].
3. Коли сайт очищено, надішліть запит на перевірку у звіті «Проблеми безпеки» (Security issues).

Порада: переконайтеся, що сповіщення Search Console на пошту отримує людина, яка на них реагуватиме.

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

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

Підтримуйте HTTPS у робочому стані після підписання

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

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

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

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

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

Заповнений приклад: Ridgeline Supply переходить на HTTPS

Лише приклад. Компанію, людей, URL і цифри вигадано, щоб показати, як виглядає придатна до роботи заповнена версія.

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

Чому це спрацювало

• Перевірка кожного рядка в день запуску виявила три збої ще до того, як Google повторно просканував більшу частину сайту.
• Sitemap перевіряли окремим рядком, тож його виправили того ж дня, а не віддавали HTTP URL тижнями.
• HSTS почали з короткого терміну, тож невдалий редирект ще можна було відкотити, не прив'язуючи браузери до HTTPS надовго.

Наступний крок

Запустіть безкоштовний аудит сайту для HTTPS-версії головної сторінки. Він перевіряє, що сайт відкривається по HTTPS і що http:// перенаправляє на нього, а також переглядає редиректи, robots.txt і sitemap.