Как (и зачем) перевести сайт с HTTP на HTTPS

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 года наличие защищенного протокола стало официально фактором ранжирования в поисковой системе Гугл. На момент анонсирования обновления в новости была опубликована такая информация: "… [сейчас] это очень легкий сигнал — он влияет менее чем на 1% глобальных запросов и имеет меньший вес, чем другие сигналы", но тем ни менее, при прочих равных и он может повлиять на ваш рейтинг среди конкурентов. Ссылка на новость https://developers.google.com/search/blog/.
2. Сайты без защищенного протокола получают в поисковой строке браузера значение «Не защищено», что очень понижает доверие к ресурсу. Это внедрение произошло в июле 2018 года.
3. Если у вас нет защищенного протокола, некоторые юзеры могу не переходить на ваш сайт с выдачи, выбирая для себя защищенные ресурсы. Из-за этого упадет CTR и впоследствии - позиции.
4. Данные переходов с HTTPS на HTTP заблокированы в Google Analytics. Это означает, что вы не будуте видеть свои сайты-рефералы.
5. Я не знаю, как у вас, но у меня и некоторые сайты на HTTP просто перестали открывать с Google Chrome. При этом, такие сайты открываются в других браузер и отображаются в Кеше, соотвественно, информация про ошибку отображается только на уровне пользователя Google Chrome (сравните два скриншота ниже).

Вот так выглядит попытка перехода на домен на HTTP в браузере Chrome:

В браузере FireFox он открывется:

Сразу отмечу для сомневающихся: в настройках работы сайта все правильно, это конкретно нежелание открывать http. Учитывая, что Google Chrome использует до 70% юзеров, это серьезная потеря трафика.

Потенциальные проблемы

Главная потенциальная проблема для сайта с трафиком - потеря этого самого трафика в процессе переезда на длительный период времени или навсегда. Редко когда переезд проходит гладко, поскольку возникающие в процессе сканирования страниц домена дубли склеиваются друг с другом рандомно (301 не сразу помогает), мешая друг другу какой-то период времени.

Кроме этого, чисто технически могут возникнуть:

• 🟥 Цепочки внутренних редиректов вместо прямого перенаправления между страницами.
• 🟥 Битые ссылки.
• 🟥 Неверные sitemap.xml и robots.txt.
• 🟥 Неправильные url в в важных тегах.
• 🟥 Проблема отображения страницы в браузере под названием mixed content, когда часть содержимого не переведена на http.

Ну и конечно же, непрямая ссылка будет снижать влияние ваших внешних доноров на сайт, и это еще одна причина почему вначале сайт будет иметь худшие позиции и снижение трафика. Тем ни менее, выполнять переезд нужно, и чем раньше, тем лучше. Новые сайты запускать сразу с сертификатом.

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

Шаг первый: необходимо сделать резервную копию файловой системы и конфигураций сайта. Выполняется для того, чтобы в случае каких-либо проблем можно было быстро откатиться назад. Резервную копию файлов можно сделать разными способами: скачать на жесткий диск, сделать виртуальную копию на серваке и так далее.

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

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

Шаг третий: сделайте доступным сайт на HTTPS активировав сертификат выбранным способом. По факту на текущем этапе у вас должно быть два идентичных сайта на защищенном и незащищенном протоколе с ответом 200. В отдельных случаях могут быть проблемы с версткой - как это устранить читайте ниже. Далее отправьте ваш домен с HTTPS на проверку сертификата с помощью одного из сервисов проверки, например https://www.ssllabs.com/.

Шаг четвертый: выполните правки в коде - исправьть ВСЕ внутренние ссылки на адрес с HTTPS, а еще лучше - на относительные. Речь не только о ссылках в контенте, но о всех ссылках в head: на стили, js и так далее. Например: файл стилей находился по адресу //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 в ГуглАналитика. Если у вас есть активные соцсети, также смените адрес там.Опять же, это чисто сеошный пункт, но все же его стоит выполнить.

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

Сколько длится переезд с HTTP на HTTPS

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

1. Сначала несмотря на 301 редирект Гугл определял как канонические страницы на HTTP.
2. Потом страницы на HTTPS стали потихоньку появляться в выдаче, но на 30-50-х позициях
3. Спустя 32 дня после настройки 301 основная страница (главная) восстановилась по своим запросам в топ-5 (смотрите скриншнот ниже).

Потеряла ли я за этот месяц конвертирующий трафик? Да, потеряла на 98%. Сделала бы я также, если бы я заранее знала, что так будет? Да, сделала. И вам рекомендую, потому что повышение безопасности будет приоритетной целью для Гугл в будущем. И это будет заключением для моей статьи).