HTTPS і SSL: перехід без втрати позицій у пошуку

HTTPS — не просто «замочок у браузері». Google офіційно підтвердив HTTPS як фактор ранжування у 2014-му, а з 2018-го Chrome позначає HTTP-сайти як «небезпечні». Нижче — покрокова інструкція переходу без втрати трафіку і позицій.

Що таке SSL/TLS і HTTPS: як працює шифрування

HTTPS (HyperText Transfer Protocol Secure) — це HTTP з шифруванням через протокол TLS (Transport Layer Security). Назва «SSL» збереглася в побуті, але технічно SSL як протокол застарів ще у 2015 році — всі сучасні сайти використовують TLS 1.2 або TLS 1.3.

Коли браузер відкриває HTTPS-сторінку, відбувається так зване TLS-handshake:

1. Браузер запитує сертифікат у сервера.
2. Сервер надсилає сертифікат, підписаний Центром сертифікації (CA).
3. Браузер перевіряє підпис і встановлює зашифрований канал.
4. Весь подальший обмін даними шифрується — зловмисник не може прочитати або підмінити дані в дорозі.

Різниця між SSL і TLS — лише в версії протоколу. Для SEO і безпеки важливо, щоб сервер підтримував TLS 1.3 (найшвидший і найбезпечніший) і вимикав застарілі SSLv3 та TLS 1.0/1.1.

Вплив HTTPS на ранжування в Google

У серпні 2014 року Google офіційно оголосив HTTPS фактором ранжування. Спочатку вплив був мінімальним — «меншим за 1%» від усіх сигналів. До 2025 року ситуація інша.

За даними досліджень Semrush і Ahrefs, серед топ-10 Google за комерційними запитами в Україні 99,2% сайтів працюють на HTTPS. HTTP-сайт у топі — рідкісний виняток для дуже вузьких низькоконкурентних ніш. Це не означає, що HTTPS автоматично піднімає позиції — але його відсутність є сигналом недовіри, який Google враховує в сукупності інших факторів.

Важливіший практичний ефект: Chrome версії 68+ показує попередження «Небезпечний» для всіх HTTP-сторінок. Якщо відвідувач бачить це попередження, він іде — а зростання відмов Google читає як сигнал низької якості сторінки.

Переконайтесь, що після переходу не погіршились показники Core Web Vitals — LCP, INP і CLS впливають на ранжування разом із наявністю HTTPS.

HTTPS і довіра користувачів

Замок у рядку браузера — перше, на що звертають увагу користувачі перед тим, як залишити особисті дані або оплатити замовлення. Дослідження GlobalSign 2023 року показало: 84% покупців відмовляються від покупки, побачивши, що сайт не захищений.

З практики: у нас був клієнт — інтернет-магазин сантехніки. До переходу на HTTPS конверсія кошика у замовлення складала 1,4%. Через тиждень після встановлення SSL — 2,1%. Без жодних змін у юзабіліті чи ціноутворенні. Люди просто перестали лякатися попередження браузера.

Додатково HTTPS захищає від атак «людина посередині» (MITM), коли провайдер або зловмисник у публічній Wi-Fi мережі підмінює контент сторінки — наприклад, вставляє рекламу або збирає паролі форм.

Типи SSL-сертифікатів: DV, OV, EV

Вибір сертифіката залежить від типу сайту і бюджету. Для SEO тип не має значення — важлива наявність HTTPS. Для бізнес-репутації і довіри — важливий рівень верифікації.

Let's Encrypt — безкоштовний CA (Certificate Authority), підтримується всіма браузерами. Сертифікати видаються автоматично і поновлюються кожні 90 днів. Більшість хостингів (cPanel, Plesk, DirectAdmin) інтегрують Let's Encrypt у один клік. Для 90% сайтів малого і середнього бізнесу — оптимальний вибір.

Чеклист переходу з HTTP на HTTPS: 8 кроків

Перехід на HTTPS — технічна операція. Зробіть її неправильно — і сайт може втратити 20–60% трафіку на 1–3 місяці. Ось порядок дій, який ми відпрацювали на десятках проєктів.

1. Бекап сайту. Збережіть файли, базу даних і конфігурацію сервера (nginx.conf або .htaccess). Це обов'язковий перший крок — відкотитися назад без бекапу неможливо.
2. Отримайте і встановіть SSL-сертифікат. Через панель хостингу (cPanel → SSL/TLS → Let's Encrypt) або вручну через Certbot на VPS. Перевірте, що сертифікат встановлено на всіх піддоменах, якщо вони є.
3. Налаштуйте 301-редиректи HTTP → HTTPS. Для Apache — додайте в .htaccess:
   RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
   Для Nginx — у блоці server з port 80: return 301 https://$host$request_uri;
4. Усуньте mixed content. Відкрийте Chrome DevTools → Console: шукайте попередження "Mixed Content". Замініть усі http:// у тегах <img>, <script>, <link> на https:// або відносні шляхи (//). Для CMS (WordPress, OpenCart) — використовуйте плагін Better Search Replace або пряму заміну в БД.
5. Оновіть внутрішні посилання в CMS. У базі даних виконайте масову заміну http://ваш-сайт.ua → https://ваш-сайт.ua. Для WordPress — через WP-CLI: wp search-replace 'http://site.ua' 'https://site.ua'.
6. Оновіть Sitemap і robots.txt. У sitemap.xml усі URL мають бути з https://. В robots.txt — перевірте, чи правильно вказано Sitemap: Sitemap: https://ваш-сайт.ua/sitemap.xml.
7. Додайте HTTPS-версію в Google Search Console. GSC вважає http:// і https:// різними сайтами. Додайте нову властивість (https://), підтвердьте доступ і подайте оновлену Sitemap. Стару HTTP-властивість не видаляйте — вона показуватиме 301-помилки ще кілька місяців.
8. Перевірте сертифікат і редиректи. SSL Labs (ssllabs.com/ssltest) — оцінка A або A+. Redirect Checker — ланцюжок редиректів має бути одноланковим: http:// → https:// (не http → http → https).

Типові помилки при переході і як їх уникнути

Ми проаналізували 40+ переходів на HTTPS за 2023–2025 роки і виявили одні й ті самі помилки, що призводять до падіння трафіку.

Як перевірити правильність HTTPS

Після завершення переходу запустіть такі перевірки — в ідеалі всі три:

• SSL Labs (ssllabs.com/ssltest): перевіряє конфігурацію TLS-сервера — версії протоколів, набори шифрів, ланцюжок сертифікатів. Цільова оцінка — A або A+. Оцінка B або нижче — є застарілі протоколи або слабкі шифри.
• Chrome DevTools → Console: відкрийте будь-яку сторінку, F12 → Console. Помаранчеві або червоні попередження "Mixed Content" означають, що якийсь ресурс досі вантажиться по HTTP.
• Google Search Console → Coverage: через 2–3 тижні перевірте, чи з'явилися HTTPS-URL в індексі, і чи немає помилок з HTTP-версіями.
• httpstatus.io: введіть HTTP-URL і переконайтеся, що редирект одноланковий — одна стрілка HTTP → HTTPS, без проміжних кроків.

Що робити після переходу на HTTPS

Технічний перехід зроблено, але робота ще не закінчена. Ось що потрібно оновити в перші 2 тижні:

• Google Search Console: додайте нову властивість https://, підтвердьте, подайте Sitemap. Встановіть пріоритетну версію як https://.
• Google Analytics / GA4: оновіть URL сайту в налаштуваннях потоку даних (Admin → Data Streams → зміна URL).
• Google Ads і Meta Ads: у кампаніях оновіть кінцеві URL оголошень і розширень — з http:// на https://. Без цього реклама може не пройти модерацію або вести на сторінку з редиректом (знижує Quality Score).
• Email-розсилки: оновіть шаблони листів, де є посилання на сайт.
• Соцмережі і каталоги: відредагуйте URL у профілях Facebook, Instagram, Google Business Profile, галузевих каталогах.
• Зовнішні посилання (backlinks): зверніться до донорів з топ-10 у вашому бекпрофілі — попросіть оновити анкорні URL. 301-редирект передає вагу, але пряме HTTPS-посилання надійніше.

Відстежуйте динаміку трафіку через SEO-аудит і GSC щотижня протягом перших 6 тижнів. Якщо трафік падає більш ніж на 15% і не відновлюється — шукайте mixed content або проблему з редиректами.

Як налаштувати GSC після міграції на HTTPS і відстежити відновлення трафіку — у нашому гайді по Google Search Console.

Кейс: 40% трафіку втрачено і повернуто за 2 тижні

Клієнт — регіональний інтернет-магазин будівельних матеріалів, ~850 сторінок в індексі. Перейшли на HTTPS самостійно: встановили сертифікат, оновили sitemap, додали https-версію в GSC. Але 301-редиректи не налаштували — вирішили, що «Google сам розбереться».

Через 3 тижні органічний трафік впав на 42%. Причина: Google проіндексував обидві версії — http:// і https:// — як окремі сайти. Посилальна вага розподілялась між двома версіями, канонікали вказували на http://, sitemap — на https://. Плюс 180 сторінок отримали статус «Duplicate without canonical» у GSC.

Що ми зробили для відновлення:

1. Налаштували серверний 301 для всіх http:// → https:// (Nginx, 2 рядки в конфізі).
2. Масово оновили canonical-теги: замість http:// — https://.
3. Видалили HTTP-версію sitemap.xml, залишили тільки https-версію; подали в GSC.
4. Запросили переіндексування 50 пріоритетних URL через GSC → URL Inspection.
5. Перевірили всі зовнішні посилання (Ahrefs → Backlinks) — 95% вже йшли через 301, критичних прямих HTTP-посилань не знайшли.

За 11 днів трафік повернувся до 94% від попереднього рівня. Повне відновлення — через 18 днів. Головний урок: 301-редирект — це перший крок, а не опція.

«Ми витратили 20 хвилин на налаштування редиректів і 2 тижні на те, щоб відновитися після того, як не налаштували їх вчасно» — слова клієнта після закриття задачі.

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

На практиці

Клієнт — мікрофінансова організація з Харкова, лендинг онлайн-кредиту на WordPress. Сайт невеликий — 14 сторінок, але трафік цільовий: запити типу «кредит онлайн без відмови». Після встановлення Let's Encrypt і оновлення Sitemap конверсія форми заявки різко впала. GSC не показував помилок, редиректи працювали.

Розібрались через Screaming Frog: сканування виявило 340 запитів до HTTP-ресурсів — JS-бібліотека обробки форми заявки підвантажувалась із HTTP CDN стороннього провайдера. Chrome показував попередження «Небезпечний» прямо в полі введення паспортних даних. За тиждень до виправлення конверсія впала на 19%.

Виправлення зайняло 4 години: Screaming Frog вивантажив повний список HTTP-запитів, розробник замінив CDN на HTTPS-версію і оновив два захардкоджених URL у конфізі плагіна форм. Lighthouse до правки фіксував попередження «page is not fully secure», після — чисто.

Через GSC → URL Inspection запросили переіндексування лендингу. За 3 тижні конверсія повернулась до вихідних значень і зросла ще на +11% — браузерне попередження у формі введення було єдиною причиною відтоку на фінальному кроці.

340 mixed content запитів на 14-сторінковому сайті — не рідкість для лендингів зі сторонніми сервісами. Screaming Frog у режимі «crawl JavaScript» бачить такі запити; DevTools показує їх лише на відкритій вкладці. Для фінансових форм перевіряйте обидва інструменти: один — для охоплення, другий — щоб точно зрозуміти, що саме бачить користувач у момент заповнення.

Часті запитання

Чи обов'язковий HTTPS для малого бізнесу?

Так. Google з 2018 року позначає HTTP-сайти як «небезпечні» в Chrome — це відлякує відвідувачів і знижує конверсію. Для інтернет-магазинів HTTPS є обов'язковим: без нього не працюють платіжні системи. Безкоштовний Let's Encrypt вирішує питання за 10 хвилин через панель хостингу.

Чи впливає тип SSL-сертифіката (DV, OV, EV) на SEO?

Ні. Google не розрізняє DV, OV і EV для ранжування — важлива наявність HTTPS, а не рівень верифікації. OV і EV дають юридичну верифікацію компанії і підвищують довіру користувачів, але алгоритм ранжування це не враховує окремо.

Як швидко Google переіндексує сайт після переходу на HTTPS?

Зазвичай 2–6 тижнів для повного переіндексування великого сайту. Після подачі нової Sitemap через GSC перші сторінки з'являються в індексі за 3–7 днів. Запит переіндексування ключових URL через GSC → URL Inspection прискорює процес.

Чи можна перейти на HTTPS без SEO-спеціаліста?

Технічно так, якщо ваш хостинг підтримує Let's Encrypt і є доступ до панелі керування. Але без перевірки редиректів, mixed content і налаштувань GSC ризик втрати трафіку на 2–6 місяців дуже високий. Мінімум — перевірте через SSL Labs після переходу.