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

У липні 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, який створює зашифровану непроникну зв`язок між вікном браузера і веб-сервером. Доступні різні види сертифікатів, які відрізняються за вартістю. Важливим моментом є те, що в основному всі вони працюють за одним принципом, тому користувач не отримує «більшої безпеки» лише тому, що платить більше.

Існують різні набори функцій:

1. Доменні SSL початкового рівня. Вони видаються миттєво і, перед тим як перейти на HTTPS, вимагають тільки підтвердження по електронній пошті, пропонують перегляд HTTPS з замком, немає глибокого процесу аналізу, тільки перевірка володіння доменом. Ідеально підходять для НЕВЕЛИКИХ компаній з обмеженим бюджетом, які не приймають онлайн-платежів.
2. Організаційні SSL-сертифікати, вимагають більш високого ступеня перевірки володіння компанією. При такому типі сертифіката назва компанії і доменне ім`я з`являються в панелі браузера.
3. SSL з розширеною перевіркою, дозволяють використовувати " зелену панель браузера». Вони дорожчі, ніж попередні сертифікати, і включають юридичну, операційну та фізичну перевірку.
4. Після того як придбаний сертифікат SSL, його потрібно буде схвалити. Існують різні рівні перевірки до видачі сертифіката, наприклад, для доменного SSL він може бути виданий негайно, як тільки власник домену підтвердить свою адресу електронної пошти. Якщо власник сайту використовує віртуальний хостинг, то перед тим як перейти на HTTPS, звертаються до провайдера за допомогою в адмініструванні сервера, маючи затверджений сертифікат.

Алгоритм переходу на HTTPS:

1. Виконують повну резервну копію сайту. Якщо хостинг управляється cPanel, можна скористатися вбудованою функцією резервного копіювання cpanel. В іншому випадку звертаються в хостингову компанію, щоб дізнатися, чи пропонує вона послугу керованого резервного копіювання.
2. Змінюють на сайті посилання HTTP на HTTPS. Процедура залежить від розміру сайту, який встановлює, як працює HTTPS. Якщо на сайті є тільки кілька сторінок, то можна використовувати ручний процес. Якщо є сотні або навіть тисячі сторінок-застосовують інструменти, які автоматизують процес, особливо якщо він розміщений на движку WordPress.
3. Перед тим як перейти на HTTPS, перевіряють бібліотеки кодів. Це необов`язковий крок і застосовується до більш складних сайтів, які використовують додаткове програмне забезпечення, таке як JavaScript та Ajax.
4. Оновіть усі зовнішні посилання, що вказують на сайт, із облікових записів соціальних мереж та списків у авторитетних каталогах.
5. Створюють редирект на HTTPS 301. Це звучить складно, коли насправді це не так. 301 являє собою метод перенаправлення трафіку з однієї веб-сторінки на іншу URL. Це важливо момент, тому що, якщо на сайті є десятки, сотні або навіть тисячі зворотних посилань, що вказують на нього з інших сайтів, вони будуть вказувати на сторінки HTTP, а рейтинг в пошукових системах залежить від кількості і якості зворотних посилань. Налаштування перенаправлення 301 залежить від типу веб-сервера, який використовується. Найпопулярнішими типами веб-серверів є Apache, NGinx та LiteSpeed та Windows. Перед тим як перейти на HTTPS з Apache і LiteSpeed необхідно оновити файл htaccess, з NGinx - файл конфігурації NGinx, а в Windows - файл web.config.
6. Якщо використовується мережа доставки контенту (CDN), така, як CloudFlare, також необхідно синхронізувати SSL з цією системою. CDN-це глобально розподілена мережа серверів, яка зберігає копії веб-сторінок на своїх серверах. Це дає переваги не тільки з точки зору швидкості, але і безпеки, оскільки може розпізнавати різні шаблони шкідливих програм і запобігати злом сайту.
7. Оновлюйте будь - які інші інструменти та транзакційні електронні листи, такі як маркетинг електронною поштою, Автоматизація та генератори цільових сторінок. Потрібно підготувати список цих програм і пошукати згадки про веб-сторінках, які посилаються на HTTP, потім оновити їх до HTTPS.
8. І останнє, що не менш важливо, щоб виконати інструкцію по переходу на 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:

1. 301 перенаправляють HTTP-адреси на HTTPS-URL. В максимально можливій мірі включають всі існуючі правила. Google буде сканувати лише до 5 переспрямувань у ланцюжку.
2. Оновлюють усі внутрішні посилання на URL-адреси HTTPS.
3. Оновлюють метадані та структуровану розмітку.
4. Переконуються, що всі ресурси переміщені в HTTPS, а посилання оновлені у вихідному коді сторінки.
5. Перевіряють властивість HTTPS в консолі пошуку Google.
6. Створюють набір властивостей, який об`єднує HTTP і HTTPS для цілей моніторингу.
7. Налаштовують обробку параметрів для HTTPS - версії домену в Google Search Console відповідно до налаштувань установки HTTPS.
8. Встановлюють міжнародний таргетинг.
9. Встановлюють швидкість сканування.
10. Переконуються, що файл HTTPS robots.txt має той самий вміст, який раніше був вказаний для HTTP і не забороняє все.
11. Переконуються, що сторінки HTTPS не мають атрибутів " meta noindex».
12. Переконуються, що теги веб-аналітики та інших сторонніх виробників встановлені.
13. Надсилайте XML Sitemap для URL-адрес на HTTPS і не блокуйте URL-адреси HTTP за допомогою robots.txt.
14. Відстежують звичайний пошуковий трафік у веб-аналітиці, щоб переконатися, що він стабільний.
15. Відстежують рейтинг та інші SEO-орієнтовані дані в Google Search Console.
16. Вручну перевіряють відображення результатів пошуку, щоб переконатися, що все виглядає правильно, оскільки 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 включатиме такі правила:

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

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

Оновлення метаданих та структурованої розмітки

При оновленні значень канонічних атрибутів на URL-адреси HTTPS, якщо перенаправляється 301 з HTTP на HTTPS, але URL-адреси HTTPS мають канонічні атрибути для HTTP, Google побачить нескінченний цикл, внаслідок чого з`являться непередбачувані результати індексації. Для усунення збою потрібно:

1. Для переходу сайту з HTTP на HTTPS оновлюють значення атрибута нумерації сторінок за URL-адресами HTTPS.
2. Оновіть значення атрибута hreflang до URL-адрес HTTPS.
3. Оновлюють rel альтернативні значення, якщо вони використовуються для окремих мобільних URL-адрес на HTTPS-URL.
4. Оновіть структуровану розмітку, таку як відео, каруселі та вікно пошуку посилань сайту, за URL-адресами HTTPS.
5. Переконуються, що всі ресурси переміщені в HTTPS. Усі ресурси, що використовуються сторінками HTTPS, повинні обслуговуватися з HTTPS. Це включає такі елементи, як зображення, файли JavaScript та CSS.
6. Оновлюють соціальні плагіни, рекламні дзвінки і так далі.
7. Використовують інструменти Google для пошуку "змішаного вмісту" на сайті.

Налаштування консолі пошуку

Для того щоб налаштувати консоль пошуку, створюють набір властивостей, який містить як HTTP, так і HTTPS-версії домену для моніторингу. Алгоритм послідовних дій:

1. Налаштовують конфігурацію обробки параметрів для HTTPS-версії домену в Google Search Console.
2. Встановлюють міжнародний таргетинг, якщо це можливо, щоб відповідати тому, що було встановлено для HTTP.
3. Оновлюють частоту сканування, якщо це встановлено для HTTP.
4. Завантажують всі дезавуйовані файли, які завантажені для HTTP.
5. Встановлюють бажаний домен.
6. Встановлюють протокол виключення роботів для HTTP і HTTPS.
7. Переконуються, що файл HTTP robots.txt переспрямовує або 404s.
8. Переконуються, що файл HTTPS robots.txt має той самий вміст, що і попередній HTTP, крім посилання на файли Sitemap.
9. Переконуються, що сторінки HTTPS не мають атрибута meta noindex.
10. Переконуються, що Теги 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 все ще індексуються місяцями пізніше.

Найбільш поширені причини цей:

1. URL-адреси HTTP блокуються за допомогою robots.txt, тому робот Googlebot не може сканувати перенаправлення і частково індексуються.
2. URL-адреси HTTP є «неканонічними " і скануються не дуже часто.
3. URL-адреси HTTP не повертають 301, натомість повертається 302 або помилка.

Поради з усунення неполадок

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

Основний види збоїв при перехід:

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

Інші підводні камені, не ПОВ`ЯЗАНІ з SEO

Є й інші можливі проблеми для сайтів, які переходять на HTTPS:

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

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