Блог про сео




Як (і навіщо) перекласти сайт з HTTP на HTTPS

Запрпонувати іншу тему
Якісні посилання з головних в shared.domains

Інформація оновлена 11 січня 2023 року

HTTPS є покращенням стандартного протоколу, що забезпечує більш високий рівень конфіденційності. Hypertext Transport Protocol Secure, а саме це означає дана абревіатура, шифрує дані користувача, запобігаючи перехопленню посередниками, а також виконує ряд інших важливих технічних функцій, про які краще прочитати окремо*. З точки зору безпеки, HTTPS слід обов'язково використовувати на сайтах, де користувач може вносити особисті та/або платіжні дані. Але ось з точки зору сео-оптимізації Hypertext Transport Protocol Secure слід використовувати на всіх сайтах, що просуваються.

*Є базова стаття у Вікіпедії, на яку посилається сам Google - https://en.wikipedia.org /wiki/HTTPS. Оскільки HTTPS це HTTP, у якому використовується Secure Socket Layer, можна відразу вивчити статтю про SSL.

Чому обов'язково використовувати HTTPS з точки зору сео

  1. 7 серпня 2014 року наявність захищеного протоколу стала офіційно фактором ранжирування в пошуковій системі Google. На момент анонсування оновлення в новини було опубліковано таку інформацію: "… [зараз] це дуже легкий сигнал — він впливає менш ніж на 1% глобальних запитів і має меншу вагу, ніж інші сигнали", але тим не менш, за рівних показників і він може вплинути ваш рейтинг серед конкурентів. Посилання на новину https://developers.google.com/search/blog/.
  2. Сайти без захищеного протоколу отримують у пошуковому рядку браузера значення «Не захищено», що дуже знижує довіру до ресурсу. Це впровадження відбулося у липні 2018 року.
  3. Якщо у вас немає захищеного протоколу, деякі користувачі можуть не переходити на ваш сайт з видачі, вибираючи захищені ресурси. Через це впаде CTR і згодом – позиції.
  4. Ці переходи з HTTPS на HTTP заблоковані в Google Analytics. Це означає, що ви не бачитимете свої сайти-реферали.
  5. Я не знаю, як у вас, але у мене та деякі сайти на HTTP просто перестали відкривати з Google Chrome. При цьому такі сайти відкриваються в інших браузер і відображаються в Кеші, відповідно, інформація про помилку відображається лише на рівні користувача Google Chrome (порівняйте два скріншоти нижче).

Ось так виглядає спроба переходу на домен на HTTP у браузері Chrome:

сайт на http не відкривається в браузері Chrome

У браузері FireFox він відкриється:

сайт на http у FireFox

Відразу зазначу для тих, хто сумнівається: в налаштуваннях роботи сайту все правильно. Враховуючи, що Google Chrome використовує до 70% користувачів Інтернету, це серйозна втрата трафіку.

>

Потенційні проблеми

Головна потенційна проблема для сайту з трафіком – втрата цього самого трафіку у процесі переїзду на тривалий період часу або назавжди. Рідко коли переїзд проходить гладко, оскільки дублі, що виникають у процесі сканування сторінок домену, склеюються один з одним рандомно (301 не відразу допомагає), заважаючи один одному якийсь період часу.

Крім цього, суто технічно можуть виникнути:

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

Схематичний алгоритм переїзду з HTTP на HTTPS

Крок перший: необхідно зробити резервну копію файлової системи та конфігурацій сайту. Виконується для того, щоб у разі будь-яких проблем можна було швидко відкотитись назад. Резервну копію файлів можна зробити у різний спосіб: завантажити на жорсткий диск, зробити віртуальну копію на серваку і так далі.

Бекап на сервері

Крок другий: визначитися з тим, де буде отримано сертифікат. Безкоштовний SSL можна отримати на хостингу, на CDN (наприклад, Cloudflare, там це також безкоштовно), або придбати на реєстраторі (хоча деякі реєстратори можуть безкоштовно видавати сертифікати). На моєму реєстраторі та хостингу від Namecheap можна й інсталювати SSL-сертифікат, і відразу ж зробити редирект із HTTP на HTTPS.

Інсталяція SSL на хостингу

Є окремі постачальники сертифікатів типу GoGetSSL та SSLs.com, на яких можна купити розширені версії SSL (не просто перевірка домену на безпечне з'єднання, а перевірка бізнесу, звірка доменного імені з назвою компанії тощо). Якщо ви оберете для себе установку SSL у спеціальних постачальників, вам ще доведеться пройти процедуру встановлення сертифіката (яку тут не має сенсу описувати, тому що на кожному сервісі вона виглядатиме інакше); на реєстраторі або CDN це робить набагато простіше, буквально перемикання повзунка в потрібному розділі.

Крок третій: Зробіть доступним сайт на HTTPS активувавши сертифікат у вибраний спосіб. За фактом на поточному етапі у вас має бути два ідентичні сайти на захищеному та незахищеному протоколі з відповіддю 200. В окремих випадках можуть бути проблеми з версткою – як це усунути читайте нижче. Далі надішліть ваш домен з HTTPS на перевірку сертифіката за допомогою одного з сервісів перевірки, наприклад https://www.ssllabs.com/.

Проверка ssl

Крок четвертий: виконайте правки в коді - треба виправити ВСІ внутрішні посилання на адресу з HTTPS, а ще краще - на відносні. Мова не тільки про посилання в контенті, але про всі посилання в head: на стилі, js і таке інше. Наприклад: файл стилів знаходився за адресою http://aboutseo.blog/css/main-styles.css, ви його змінюєте на https://aboutseo.blog/css/main-styles.css (абсолютне посилання) або /css/main-styles.css (відносне посилання). Звичайно, це виконується не в ручному форматі, а в автоматизованому.

Крок п'ятий: зробіть заміну посилань у тегах: у канонікалах, тегах hreflang. Також замініть урл у мікророзмітці. Чому я виділила даний пункт окремо, а не приєднала його до попереднього: річ у тому, що якщо на стилі, скрипти та внутрішні посилання ми можемо посилатися за допомогою відносного написання урла, то в тегах link та мікророзмітці обов'язково потрібно вписувати все у вигляді абсолютних адрес. . Відносне написання вважатиметься помилкою.

Крок шостий: виконайте 301. Він виконується або на Cloudflare (там є окремі налаштування - зробити сайт доступним тільки на HTTPS), або на сервері. Кожен хостинг має свій інтерфейс та логіку налаштування, тому якщо ви не зовсім розумієте, як це зробити, зверніться до саппорту. Зазвичай посторінковий редирект самостійно налаштовувати не потрібно: сервери мають простий інструмент редиректу на http. Також ви можете виконати 301 за допомогою конфігурацій на сервері, вписавши наступні команди:

Для конфігурацій у Nginx:

 
        server {
    listen 80;
    server_name domain.com www.domain.com;
    return 301 https://domain.com$request_uri;
               }  
        

Для конфігурацій в Apache:

 
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L] 
        

Крок сьомий: оновіть robots.txt та sitemap.xml. Налаштовувати 301 між картами сайту не обов'язково, ви навіть можете вказати в карті на http адреси на https як канонічні, оскільки у Гугла є опція зчитування канонікала в сайті, читайте тут - https://developers.google.com/.

Крок восьмий: технічна перевірка. По-перше, перевірте сайт з анонімної вкладки браузера на коректність відображення верстки (з поточного вікна немає сенсу відкривати, оскільки браузер може кешувати стилі). Також ви повинні будете побачити у пошуковому рядку напис "Безпечне з'єднання" із замочком, що говоритиме про коректність роботи сертифіката. По-друге, запустіть 2 парсинги сайту за допомогою ScreamingFrog або іншого спайдера: на HTTP і на HTTPS. У першому випадку ви повинні побачити, що всі сторінки сайту віддають відповідь 301, у другому випадку – всі сторінки з відповіддю 200. Якщо десь щось працює не так, потрібно одразу виправити.

Крок дев'ятий: додайте сайти до Search Console і запросіть перехід топових сторінок. Це вже чисто сеошний пункт, необхідний для того, щоб склейка швидше відбулася. Також запитайте сканування карти сайту (але спочатку оновіть її, звичайно ж, як я писала в пункті 7), а також надішліть ще раз файл відхилення посилань для домену з HTTPS.

Крок десятий: оновіть url в Google Analytics. Якщо у вас є активні соцмережі, також змініть адресу там. Знову ж таки, це чисто сеошний пункт, але все ж таки його варто виконати.

Я розумію, що, можливо, інструкція недостатньо деталізована, особливо для тих, хто погано розуміє технічку. Однак річ у тому, що точний алгоритм, як робити переїзд з HTTP на HTTPS, залежить багато в чому від того, які інструменти та сервіси ви використовуєте (CDN, хостинг, реєстратор, CMS тощо). Тут я скоріше навела схематизовану інструкцію, кроки якої є обов'язковими до виконання.

Скільки триває переїзд з HTTP на HTTPS

Останній переїзд, який я виконувала (це був невеликий сайт на кілька десятків сторінок під запит Holenderskie kasyno online) зайняв у мене (якщо брати в облік відновлення позицій у топ-10) місяць. Склейка пройшла такі етапи:

  1. Спочатку незважаючи на 301 редирект Google визначав як канонічні сторінки на HTTP.
  2. Потому сторінки на HTTPS стали потихеньку з'являтися у видачі, але на 30-50-х позиціях
  3. Через 32 дні після налаштування 301 основна сторінка (головна) відновилася за своїми запитами в топ-5 (дивіться скріншнот нижче).
Переїзд з http на https на сайті hetplaneet.nl та відновлення позицій

Чи я за цей місяць втратила конвертуючий трафік? Так, втратила на 98%. Зробила б я також, якби я знала, що так буде? Так, зробила. І вам рекомендую, тому що підвищення безпеки буде пріоритетною метою для Google у майбутньому. І це буде висновком для моєї статті).

Підтримуємо своїх!🇺🇦

Мій колега-сеошник став на захист України і зараз збирає на спорядження побратимові. Кожна гривня важлива!

Підпишись!

Так, тобі дуже сподобався контент на сайті, але... ти ніколи ні на що не підписуєшся, вірно? Будь ласка, зроби виняток для мене. Я сильно єбашу для того, щоб сайт не тільки ріс, але також був максимально якісним. Підтримай не проект - підтримай мене в моєму прагненні писати класно.