Що важливо зрозуміти за темою «Аудит HTTPS та безпеки сайту»

HTTPS давно перестав бути просто «замочком» у браузері для заспокоєння відвідувачів. Для Google це прямий ранговий фактор з 2014 року, а для користувачів — базова ознака того, що сайт не красть їхні дані. Проте в рамках технічного SEO аудит HTTPS означає не перевірку наявності сертифіката, а діагностику того, наскільки коректно він впроваджений і чи не створює проблем для індексації.

Перше, що варто чітко розділити: безпека сайту в широкому сенсі та безпека в контексті SEO — це різні речі. Повний security audit включає перевірку на вразливості, XSS, SQL-ін'єкції, налаштування firewall та багато іншого. Аудит HTTPS у межах технічного SEO зосереджується на тому, як шифрування трафіку впливає на сканування, індексацію та ранжування.

Що саме перевіряється

  • Статус сертифіката. Чи дійсний, чи не закінчився термін, чи правильно встановлений ланцюжок довіри.
  • Редиректи з HTTP на HTTPS. Чи працюють вони коректно, чи не створюють ланцюжків, чи передають статус 301.
  • Змішаний контент (mixed content). Ситуації, коли сторінка завантажується по HTTPS, але ресурси всередині — зображення, скрипти, стилі — тягнуться по HTTP.
  • Внутрішні посилання. Чи всі лінки на сайті ведуть на HTTPS-версії, а не на голий HTTP.
  • HSTS заголовок. Чи вказує сервер браузеру завжди використовувати HTTPS.
  • Протоколи та шифри. Чи не використовує сайт застарілі алгоритми, які вразливі або не підтримуються сучасними браузерами.

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

Практичні особливості та варіанти застосування

Аудит HTTPS зазвичай проводиться на етапі підготовки до міграції з HTTP, після неї або під час регулярного технічного аудиту. Кожен сценарій має свої нюанси.

Перевірка сертифіката та протоколів

Починають з базового: чи валідний сертифікат, чи збігається домен, чи не закінчився термін. Але цього мало. Потрібно перевірити ланцюжок сертифікатів — часто трапляється, що кореневий або проміжний сертифікат не встановлений на сервері, через що деякі клієнти (включно з ботами) отримують помилку довіри.

Для перевірки якості шифрування використовують інструменти на кшталт SSL Labs. Вони показують, чи підтримує сервер TLS 1.2 та 1.3, чи відключені застарілі протоколи SSLv3 та TLS 1.0/1.1, чи не використовуються слабкі шифри. З погляду SEO це опосередкований фактор: якщо бот не може встановити безпечне з'єднання, він не просканує сторінку.

Діагностика змішаного контенту

Це одна з найпоширеніших проблем після міграції на HTTPS. Браузер показує сторінку як «небезпечну», хоча сертифікат в порядку. Причина — ресурси, що завантажуються по незахищеному протоколу.

Змішаний контент буває двох типів:

  • Активний (blocking mixed content). Скрипти, стилі, iframes через HTTP. Браузер їх блокує, сторінка ламається візуально чи функціонально. Для SEO це критично: бот бачить неповну сторінку, користувач бачить зламану.
  • Пасивний (optional mixed content). Зображення, відео, аудіо через HTTP. Браузер їх завантажує, але показує попередження. Менш критично, але сигнал довіри падає.

Для пошуку змішаного контенту зручні Screaming Frog або Sitebulb — вони показують кожен ресурс з HTTP на HTTPS-сторінці. У Chrome DevTools на вкладці Console теж видно відповідні попередження.

Перевірка редиректів та внутрішніх лінків

Після міграції кожна HTTP-сторінка має віддавати 301-редирект на відповідну HTTPS-версію. Перевіряють кілька моментів: чи немає редиректів на інший домен, чи не створюється ланцюжок (HTTP → www.HTTPS → HTTPS), чи не редиректить головна на внутрішню сторінку.

Внутрішні посилання перевіряють на наявність http:// всередині коду. Ідеально, коли всі лінки одразу ведуть на HTTPS — це зменшує кількість редиректів і прискорює сканування.

HSTS та канонізація

Заголовок Strict-Transport-Security каже браузеру: «завжди використовуй HTTPS для цього домену». Це усуває ризик атак downgrade, коли зловмисник примусово переводить з'єднання на HTTP. Але для SEO важливо розуміти: HSTS не замінює редиректи, він працює лише в браузері. Пошуковий бот може ігнорувати цей заголовок, тому 301-редирект має залишатися.

Також перевіряють, чи збігаються канонічні URL з фактичною HTTPS-версією сторінки. Якщо канонічний лінк вказує на HTTP — це пряма проблема для індексації.

Помилки, обмеження та що враховувати на практиці

«Замочок є — значить, все добре»

Найпоширена помилка — вважати наявність сертифіката достатньою умовою. На практиці сайт може мати дійсний сертифікат, але при цьому грузити всі зображення по HTTP, не мати редиректів з HTTP-версій і вказувати канонічні URL на незахищені сторінки. Результат — втрата позицій, попередження в Search Console та зниження довіри користувачів.

Неправильний вибір сертифіката

Існують три основні рівні валідації: DV (Domain Validation), OV (Organization Validation) та EV (Extended Validation). Для більшості сайтів достатньо DV — він підтверджує лише право на домен. Але якщо сайт приймає платежі або працює з чутливими даними, варто розглянути OV або EV. З погляду SEO різниця мінімальна, але для конверсії та довіри — суттєва.

Безкоштовні сертифікати Let's Encrypt цілком підходять для SEO-завдань. Головне — стежити за автоматичним поновленням, бо термін їхньої дії — 90 днів.

Проблеми з піддоменами

Сертифікат може покривати лише основний домен, а піддомени залишитися без захисту. Wildcard-сертифікат вирішує цю проблему, але його потрібно планувати заздалегідь. Якщо частина піддоменів на HTTPS, а частина — ні, це створює плутанину для ботів і користувачів.

HSTS як пастка

Якщо встановити HSTS із довгим max-age і при цьому допустити помилку в налаштуванні сертифіката, браузер запам'ятає вимогу HTTPS і не дозволить відвідати сайт навіть після виправлення — поки не мине вказаний термін. Тому HSTS спочатку вмикають з коротким періодом (наприклад, 300 секунд), перевіряють усе, і лише потім збільшують до рекомендованих 6–12 місяців. Для преміум-захисту є HSTS Preload List, але туди потрапити легко, а вилучитися — дуже складно.

Обмеження аудиту HTTPS

Аудит HTTPS у рамках SEO не є повноцінним security audit. Він не перевіряє налаштування WAF, не шукає вразливості в коді, не аналізує права доступу до файлів сервера. Це окрема спеціалізація. SEO-аудит фокусується на тому, щоб безпека не заважала пошуковим ботам коректно сканувати та індексувати сайт.

Ще одне обмеження — зовнішні фактори. Якщо сторонні сервіси (віджети, аналітика, рекламні мережі) завантажують ресурси по HTTP, ви не завжди можете це виправити власноруч. У таких випадках варто шукати альтернативи або використовувати CSP (Content Security Policy) для контролю.

Після міграції — не відразу чекати результатів

Навіть ідеально проведена міграція на HTTPS не дасть миттєвого приросту позицій. Google потрібно час на переобробку URL, оновлення індексу та перерахунок сигналів. Зазвичай це займає від кількох тижнів до кількох місяців. Під час цього періоду важливо моніторити Coverage Report у Search Console та слідкувати за тим, чи немає помилок сканування, пов'язаних із сертифікатом чи редиректами.