Як перейти на HTTPS : покрокова інструкція. Як працює HTTPS

Опубликованно 05.06.2019 03:00

У липні 2014 року Google оголосив про перевагу в рейтингу сайтів з правильно встановленими сертифікатами SSL. Перетворені і захищені SSL-сайти стали відображатися як HTTPS (hypertext transfer protocol secure) на відміну від раннього стандарту HTTP. Таким чином, з'явився додатковий рівень безпеки, який запобігає небажаний доступ до збережених даних.

Сьогодні Google, Safari, Firefox і більшість інших популярних браузерів вимагають цей протокол для кращого ранжирування, геолокаціі, введення даних кредитних карт і багато іншого. Протокол безпеки HTTPS також захищає сайт від небажаних рекламних оголошень, які докучають відвідувачам нав'язливою, некрасивою інформацією, часом містить шкідливе ПО. З жовтня 2018 року Google почав показувати попередження про небезпеку червоного кольору, коли користувачі вводять дані на HTTP-сторінках або замочок в адресному рядку зеленого кольору, коли безпека в нормі на HTTPS. Стисле визначення

HTTPS і SSL видно на URL сайту, що відображено у панелі браузера. Поруч також можна помітити символ замку. Так сучасні браузери показують, що користувач знаходиться на сайті, який використовує шифрування SSL. У деяких випадках URL включає назву компанії. Ці ознаки свідчать про те, що відвідувач знаходиться на сайті, який серйозно ставиться до конфіденційності. Він означає гіпертекстовий транспортний протокол HTTPS Secure. Його «брат» HTTP означає те ж саме без «секретності» в кінці і є протоколом зв'язку, зазвичай використовуваних для полегшення веб-трафіку.

Безпечна версія застосовує сертифікат SSL (Secure Socket Layer) для встановлення з'єднання між браузером і сервером. Тому стає зрозумілим, як працює HTTPS - будь-яка інформація, якою обмінюються, стає зашифрованою. Шифрування — це процес заміни простої текстової інформації, наприклад імен користувачів і паролів, випадковими числами і буквами. Таким чином, вона більше не може бути прочитана людьми, і її складніше зрозуміти під час перехоплення.

Невелике уточнення: технічно SSL взагалі-то не є правильним терміном, в кінці 90-х він змінився на TLS (безпека транспортного рівня). Тим не менш, він як і раніше часто використовується при описі процесів HTTPS.

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

Існують різні набори функцій: Доменні SSL початкового рівня. Вони видаються миттєво і, перед тим як перейти на HTTPS, вимагають лише підтвердження по електронній пошті, пропонують перегляд HTTPS з замком, немає глибокого процесу аналізу, тільки перевірка володіння доменом. Ідеально підходять для невеликих компаній з обмеженим бюджетом, які не беруть онлайн-платежів. Організаційні SSL-сертифікати, вимагають більш високого ступеня перевірки володіння компанією. При такому типі сертифіката назва компанії і доменне ім'я з'являються на панелі браузера. SSL з розширеною перевіркою, дозволяють використовувати «зелену панель браузера». Вони дорожче, ніж попередні сертифікати, і включають в себе юридичну, операційну і фізичну перевірку. Після того як придбаний сертифікат SSL, його потрібно схвалити. Існують різні рівні перевірки до видачі сертифіката, Наприклад, для доменного SSL він може бути виданий негайно, як тільки власник домену підтвердить свою адресу електронної пошти. Якщо власник сайту використовує віртуальний хостинг, то перед тим як перейти на HTTPS, звертаються до провайдера за допомогою в адмініструванні сервера, маючи затверджений сертифікат.

Алгоритм переходу на HTTPS: Виконують повну резервну копію сайту. Якщо хостинг управляється cPanel, можна скористатися вбудованою функцією резервного копіювання cpanel. В іншому випадку звертаються в хостингову компанію, щоб дізнатися, чи пропонує вона послугу керованого резервного копіювання. Змінюють на сайті посилання HTTP HTTPS. Процедура залежить від розміру сайту, який встановлює, як працює HTTPS. Якщо на сайті є лише кілька сторінок, то можна використовувати ручний процес. Якщо є сотні або навіть тисячі сторінок — застосовують інструменти, які автоматизують процес, особливо якщо він розміщений на движку WordPress. Перед тим як перейти на HTTPS, перевіряють бібліотеки кодів. Це необов'язковий крок і застосуємо до більш складних сайтів, що використовують додаткове програмне забезпечення, таке як JavaScript і Ajax. Оновлюють всі зовнішні посилання, що вказують на сайт, з облікових записів соціальних мереж і списків в авторитетних каталогах. Створюють редирект на HTTPS 301. Це звучить складно, хоча насправді це не так. 301 являє собою метод перенаправлення трафіку з однієї веб-сторінки на іншу URL. Це важливий момент, тому що, якщо на сайті є десятки, сотні або навіть тисячі зворотних посилань, що вказують на нього з інших сайтів, вони будуть вказувати на сторінки HTTP, а рейтинг в пошукових системах залежить від кількості і якості зворотних посилань. Налаштування перенаправлення 301 залежить від типу веб-сервера, який використовується. Найбільш популярними типами веб-серверів є Apache, NGinx і LiteSpeed і Windows. Перед тим як перейти на HTTPS З Apache і LiteSpeed необхідно оновити файл htaccess, з NGinx - файл конфігурації NGinx, а В Windows - файл web.config. Якщо використовується мережа доставки контенту (CDN), така, як CloudFlare, також необхідно синхронізувати SSL з цією системою. CDN - це глобально розподілена мережа серверів, яка зберігає копії веб-сторінок на своїх серверах. Це дає переваги не тільки з точки зору швидкості, але і безпеки, оскільки може розпізнавати різні шаблони шкідливих програм і запобігати злом сайту. Оновлюють будь-які інші інструменти та транзакційні електронні листи, наприклад, електронний маркетинг, автоматизація та генератори цільових сторінок. Потрібно підготувати список цих програм і пошукати згадки про веб-сторінки, що посилаються на HTTP, потім обновити їх до HTTPS. І останнє, що не менш важливо, щоб виконати інструкцію по переходу на HTTPS - потрібно оновити облікові записи Google Analytics і Search Console. В Analytics потрібно змінити URL-адресу за замовчуванням на HTTPS. В консолі пошуку необхідно додати новий сайт з HTTPS. Запобігання пасток SEO

Chrome попереджає користувачів про те, що сайт не захищений, коли вони заповнюють форму, наприклад, вікно пошуку реєстрацію або по електронній пошті. Це новітнє оповіщення в поєднанні з перевагами Google SEO прискорило перехід на новий стандарт багатьох сайтів.

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

З допомогою Keylime Toolbox Query Analytics можна об'єднувати дані HTTP запитів та HTTP Secure з Google Search Console і відстежувати тенденції за кількістю кліків, ранжування, показів по часу і в сукупності, на рівні окремих запитів і для категорій. Keylime Toolbox Crawl Analytics надає щоденний аналіз журналів, щоб допомогти відстежувати сканування Googlebot, оцінювати, скільки часу займе повне сканування і переіндексація, і виявляти будь-які проблеми. Якщо сайт великий і звичайне сканування неефективно, розглядають можливість впровадження спеціальних елементів ефективності сканування перед початком міграції. Налаштування функцій переходу

При переході на Redirects налаштовують наступні параметри. Керівництво по переходу з HTTP HTTPS: 301 перенаправляють HTTP-адреси на HTTPS URL. У максимально можливій мірі включають усі існуючі правила. Google буде сканувати тільки до 5 перенаправлень в ланцюжку. Оновлюють всі внутрішні посилання на URL-адресу HTTPS. Оновлюють метадані та структуровану розмітку. Переконуються, що всі ресурси переміщені в HTTPS, а посилання оновлені у вихідному коді сторінки. Перевіряють властивість HTTPS в консолі пошуку Google. Створюють набір властивостей, який об'єднує HTTP та HTTPS для цілей моніторингу. Налаштовують обробку параметрів для HTTPS-версії домену Google Search Console у відповідності з налаштуваннями установки HTTPS. Встановлюють міжнародний таргетинг. Встановлюють швидкість сканування. Переконуються, що файл HTTPS robots.txt має той же зміст, що було раніше зазначено для HTTP та не забороняє всі. Переконуються, що сторінки HTTPS не мають атрибутів «meta noindex». Переконуються, що теги веб-аналітики та інших сторонніх виробників встановлені. Відправляють XML Sitemap для URL-адрес, HTTPS і не блокують URL-адреси за допомогою HTTP robots.txt. Відстежують звичайний пошуковий трафік веб-аналітиці, щоб переконатися, що він стабільний. Відстежують рейтинг та інші SEO-орієнтовані дані в Google Search Console. Вручну перевіряють відображення результатів пошуку, щоб переконатися, що все виглядає правильно, так як URL-адреси HTTPS індексуються. Сканування роботом Google

Дані відстеження процесу, як робот Google сканує HTTP і HTTPS, які URL скануються і які коди відповідей він отримує, доступні тільки у тому випадку, якщо використовується Crawl Analytics, який завантажує файли журналу сервера для обробки. Для цього завантажують повний список наданих Google помилок сканування, як для HTTP, так і для HTTPS, а також дані джерела посилання для кожної помилки.

Виконується відстеження агрегованого ранжирування і трафіку HTTP і HTTPS з плином часу для брендованих і не брендових запитів, а також інших даних SEO, таких, як індивідуальні та зведені рейтинги кліків і їх загальна кількість, за якими сайт з'являється

Якщо сайт великий і сканування неефективно, Google може знадобитися деякий час для повторного сканування всіх URL-адрес HTTP і заміни їх в індексі версіями HTTPS, щоб прискорити цей процес. Файли журналу є відмінним ресурсом для виявлення проблем ефективності. Хоча Google стверджує, що він обробляє потік PageRank однаково для 301-го і 302-го, але все одно ці перенаправлення обробляються по-різному. Оскільки 302 є технічно «тимчасовим», Google продовжує індексувати цільової URL 302. При перенаправленні 301 Google видаляє URL-адресу перенаправлення з індексу і індексує тільки цільової URL 301. Консолідація правил перенаправлення

Робот Googlebot виконує тільки до 5 переадресацій, і, так як URL-адреси з часом змінюються і додаються правила канонізації, ланцюжки перенаправлення стають звичайним явищем. Однак вони уповільнюють завантаження сторінок на мобільних пристроях.

У багатьох випадках перенаправлення HTTP, HTTPS і www/non-www виконуються на рівні сервера, а всі інші на рівні програми. У цьому випадку ідеальним сценарієм є використання одного 301 на рівні сервера для обліку, як HTTP/HTTPS.

Цей останній редирект на HTTPS буде включати в себе такі правила: Від старих шаблонів URL до поточних переконують, що всі старі правила оновлено з поточними кінцевими цілями. Нормалізація регістру, наприклад, від example.com/Page1 до example.com/page1 і завершальний слеш, наприклад, від example.com/page1 до example.com/page1/. У цьому прикладі example.com/Page1 буде перенаправляти 301 безпосередньо на example.com/page1/ одним циклом HTTPS і www. При розгляді всіх старих правил, їх поновлення та консолідації переконуються, що всі мають значення 301, а не 302. URL-адреси, які перенаправляють 302, можуть залишатися проиндексированными, що призводить до непередбачуваних елементів відображення результатів пошуку. У них може з'явиться не тільки неправильний URL-адресу, але й інше небажану поведінку. Наприклад, якщо метадані, такі як посилання сайту, пов'язані з поточним URL-адресою, а старий відображається в результатах пошуку, то посилання не будуть відображатися. Оновлюють всі внутрішні посилання на канонічні URL, що корисно виконувати, так як перенаправлення збільшують час завантаження сторінки, особливо на мобільних пристроях. В ідеалі внутрішні посилання повинні бути абсолютними, а не відносними і повинні оновлюватися до URL-адрес, HTTPS. Використовують відносні, а не абсолютні посилання, що усуне необхідність оновлення внутрішніх. Це нормально, але не ідеально і пов'язано з тим, що внутрішні посилання є сильним канонічним сигналом для пошукових систем, тому якщо які-небудь URL-адреси неправильно налаштовані, щоб не переписувати, то сайт випадково дублюється на піддомені або видаляється. Всі посилання на цих сторінках на неканонічних версіях.

У більшості випадків не потрібно великої роботи по оновленню внутрішніх посилань. Часто вони можуть бути оновлені за допомогою параметрів конфігурації, програмно або все відразу через сценарій. Оновлення метаданих і структурованої розмітки

При оновленні значень канонічних атрибутів на URL-адресу HTTPS, якщо перенаправляється 301 з HTTP, HTTPS, але URL-адреси HTTPS мають канонічні атрибути для HTTP, Google побачить нескінченний цикл, внаслідок чого з'являться непередбачувані результати індексації. Для усунення збою потрібно: Для переходу з сайту HTTP HTTPS оновлюють значення атрибута нумерації сторінок з URL-адресами HTTPS. Оновлюють значення атрибута hreflang до URL-адрес, HTTPS. Оновлюють rel альтернативні значення, якщо вони використовуються для окремих мобільних URL-адрес, HTTPS-URL. Оновлюють структуровану розмітку, таку як відео, каруселі та вікно пошуку посилань сайту, URL-адрес, HTTPS. Переконуються, що всі ресурси переміщені в HTTPS. Всі ресурси, використовувані сторінками HTTPS, повинні обслуговуватися з HTTPS. Це включає в себе такі елементи, як зображення, JavaScript і CSS. Оновлюють соціальні плагіни, рекламні дзвінки і так далі. Використовують інструменти Google для пошуку «змішаного вмісту на сайті. Налаштування консолі пошуку

Для того щоб налаштувати консоль пошуку, створюють набір властивостей, який містить як HTTP, так і HTTPS-версії домену для моніторингу. Алгоритм послідовних дій: Налаштовують конфігурацію обробки параметрів для HTTPS-версії домену Google Search Console. Встановлюють міжнародний таргетинг, якщо це застосовно, щоб відповідати тому, що було встановлено для HTTP. Оновлюють частоту сканування, якщо це встановлено для HTTP. Завантажують всі дезавуированные файли, які завантажені для HTTP. Встановлюють бажаний домен. Встановлюють протокол вилучення роботів для HTTP та HTTPS. Переконуються, що файл HTTP robots.txt перенаправляє або 404s. Переконуються, що файл HTTPS robots.txt має той же вміст, що і попередній HTTP, крім посилання на файли Sitemap. Переконуються, що сторінки HTTPS не мають атрибута meta noindex. Переконуються, що теги Web Analytics (та інші) як і раніше на місці

У багатьох випадках сайт буде продовжувати використовувати ті ж теги веб-аналітики, наприклад, ідентифікатор властивості Google Analytics. Але якщо це змінено, переконуються, що сторінки сайту оновлені. Крім того, переконуються, що вихідний код, що містить теги, не видаляється зі сторінок у процесі міграції. Можна використовувати сторонній інструмент, який перевіряє наявність тегів, або налаштувати сканер, такий як Screaming Frog, для його перевірки.

Якщо XML Sitemaps додано в Google Search Console, можна використовувати звіти для відстеження зниження індексації. Починають сканування Google-ботів URL-адрес, HTTPS, коли вони знаходяться у файлах XML Sitemap. Можна відстежувати підвищення індексації за допомогою звітів індексації XML-файлів. Завжди створюють XML Sitemaps, які є всеосяжними і канонічними не тільки для цілей переходу з HTTP HTTPS. Монітор Search Console

Необхідно відправляти XML Sitemap для URL-адрес, HTTPS і залишити існуючий XML Sitemap для HTTP. Це дозволить відстежувати зменшення індексації властивості HTTP і збільшення індексації властивості HTTPS.

Всі URL в карті сайту HTTP повинні мати код стану 301, а індексування з часом повинно зменшуватися. Всі URL-адреси в карті сайту HTTPS повинні мати код стану 200, а індексування з часом має зростати. Цей процес може зайняти деякий час, і можна виявити, що деякі URL-адреси HTTP все ще індексуються через місяці.

Найбільш поширені причини цього: URL-адреси HTTP блокуються за допомогою robots.txt, тому робот Googlebot не може сканувати перенаправлення і частково індексуються. URL-адреси HTTP є «неканонічними» і скануються не дуже часто. URL-адреси HTTP не повертають 301, замість цього повертається 302 або помилка. Поради з усунення неполадок

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

Основні види збоїв при переході: Найпоширеніші проблеми, що виникають після переходу сайту HTTPS - це попередження про змішаному утриманні. Це відбувається, коли браузер знаходить небезпечні посилання на захищеній сторінці. Зазвичай це питання оновлення посилань на бібліотеки jquery, настроювані шрифти або аналогічні їх HTTPS-версії. Користувач повинен подбати про це при скануванні свого сайту перед публікацією і якщо з'являються подібні попередження, обов'язково перевіряють джерела, які їх викликають. Перехід з HTTP HTTPS може негативно вплинути на рейтинг, хоча зазвичай це тільки тимчасово. Якщо налаштувати 301 переадресацію, вона обробляє тільки 90-99 % посилальної маси. Ось чому рейтинг може на початку знизитися. Однак вони з часом повинні зрости і принести користь у довгостроковій перспективі. Якщо буде виявлено, що деякі URL-адреси все ще індексуються через місяці, але у звітах Google Search Console Search Analytics не відображаються якісь певні властивості HTTP, можливо, цю проблему не варто вивчати. URL не ранжуються за запитами і не викликають проблем. Однак, якщо з'являються певні властивості HTTP, тоді URL-адреси ранжуються за запитами. Найпростіший спосіб почати розслідування переглянути журнали сервера, щоб точно дізнатися, що отримує робот Google при скануванні. В Excel файли журналу докладно Keylime Toolbox Crawl Analytics включають в себе вкладку, в якому перераховані всі URL - адреси з кодом відповіді 200, всі URL - адреси з кодом відповіді 302 і так далі. Можна сканувати сайт за допомогою інструменту, такого як Screaming Frog, щоб отримати список URL-адрес, які повертають 200, заблокованих robots.txt. Також можна подивитися на Консоль пошуку Google> Сканування> robots.txt Tester для властивості HTTP, щоб побачити, чи бачить Google файл robots.txt і, якщо так, блокує він які-небудь URL-адреси. Інші підводні камені, не пов'язані з SEO

Є й інші можливі проблеми для сайтів, які перемикаються на HTTPS: Потенційне скорочення доходів AdSense. У минулому зниження доходів Adsense відбувалося з-за великої кількості оголошень, несумісних з HTTPS. Важливо відзначити, що якщо користувач перемикається з HTTP, HTTPS, йому необхідно оновити код AdSense, інакше він отримає проблеми з вмістом, описані вище. Нерідкі випадки, коли сайт втрачає всі свої частки в соціальних мережах при переході на HTTPS. Навіть фантастична стаття, яка зібрала десятки тисяч лайків у Facebook, може обнулитися після переходу. Документація Facebook пояснює обхідний шлях для цього, який включає установку мета-тегів og: url для вказівки старого http-URL. Тим не менш він каже, що це працює, тільки якщо старий URL повертає відповідь 200. Якщо перенаправити http-сторінки на https-сторінки, тоді «старі» сторінки будуть повертати 301, а не 200. Перехід на HTTPS може призвести до того, що Google переоцінить сайт з точки зору якості. Це найбільша проблема при переході може означати, що всі сторінки сайту отримують нову оцінку якості. Цілком можливо, що ті прийоми і лазівки, які використовувалися раніше, більше не будуть працювати так само після HTTPS -зміщення, внаслідок чого впаде трафік після переходу на HTTPS. Файли Sitemap повинні бути оновлені. Перед тим як переключиться, переконуються, що також створена нова карта сайту. Disavow файл повинен бути завантажений у HTTPS. Google як і раніше розглядає HTTPS і HTTP-версії сайту як різні сайти, і якщо використовується консоль пошуку Google, потрібно буде створити нову властивість для версії HTTPS. Якщо у користувача є файл відключення, то потрібно завантажити його у версію HTTPS. Переконуються, що сертифікат не минув. Якщо сайт працює по протоколу HTTPS і термін дії сертифіката безпеки закінчується тоді, коли Google спробує відправити відвідувачів на сайт, вони отримають велике повноекранне попередження, що безумовно відштовхне людей.

Забезпечення безпеки трафіку є однією з найважливіших проблем для будь-якого власника сайту. Крім передачі довіри, процес дає вигоду від збільшення швидкості і поліпшення SEO. Це відмінна інвестиція в майбутнє, оскільки в цьому напрямку рухається мережу. Як вже згадувалося, Google вважає використання SSL позитивним фактором ранжирування, тому, якщо користувач перемістіть свій сайт HTTPS, він фактично зробить його більш привабливим. Думається, що після настільки вагомих аргументів у вас більше не виникне питання про перехід на HTTPS навіщо городити город».

Іван Фролов

Категория: Техника