Переход на https

Всем большой привет! Браузер Google Chrome не намерен отступать от своих намерений и движется вперёд по намеченному пути, внедряя предупреждения безопасности для HTTP сайтов. Mozilla Firefox также активно пропагандирует протокол HTTPS, подталкивая вебмастеров устанавливать SSL сертификаты на свои сайты. Но как избежать проблем, связанных с потерей трафика и дохода?

HTTPS протокол

Свои сайты я начал переводить на HTTPS постепенно, а не все сразу, для того чтобы отработать процедуру на мелких незначительных и затем применить накопленный опыт на более значимых проектах. И сегодня я готов поделиться с вами инструкцией, состоящей из десяти простых шагов.

10 последовательных шагов по переезду сайта на HTTPS

Всего мною было переведено 6 сайтов. Первый шаг был сделан 18 сентября 2016 года, тогда я стал записывать в блокноте все свои действия. Сегодня эти записи помогут мне сформировать цельную инструкцию по переезду сайта на работу по HTTPS протоколу без потери трафика из поисковых систем.


1. Получение SSL сертификата

Первое, что необходимо сделать – приобрести SSL сертификат (платный или бесплатный) и подключить его к домену. Это можно сделать самостоятельно в панели управления хостингом (ISPmanager, CPanel, VestaCP) или обратиться за помощью в техподдержку. Некоторые хостеры предлагают подключить бесплатный SSL с автоматическим продлением в один клик.

Let’s Encrypt

Но сегодня я не стану затрагивать вопросы, связанные с выбором и установкой SSL сертификата – это отдельная тема. Сейчас у меня подключены сертификаты Let’s Encrypt. До этого использовал StartSSL, но после шумихи с бесплатными SSL-сертификатами StartCom и WoSign последовала закономерная блокировка этих удостоверяющих центров в популярных браузерах.

2. Внесение изменений в robots.txt

Давайте перейдём к файлу robots.txt и изменим директиву Host, указывающую на главное зеркало:

Если директива Host не использовалась раньше, тогда добавьте ее в любом месте, т.к. она является межсекционной. Согласно справке Яндекса, если сайт работает по защищённому каналу связи, то обязательно указывать протокол.

3. Переезд сайта в сервисе Яндекс Вебмастер

Теперь необходимо зайти в Яндекс Вебмастер и в разделе Индексирование перейти на страницу Переезд сайта. Отметьте флажком Добавить HTTPS и сохраните изменения.


Переезд сайта

Появится информационное сообщение о том, что Яндекс не гарантирует сохранение количества страниц сайта в поиске, его позиций или посещаемости в случае изменения главного зеркала:

Также стоит добавить новый сайт с HTTPS протоколом, после склейки они будут объединены в группу зеркал.

Именно поэтому при переезде сайта особое внимание нужно уделить этой поисковой системе, в то время как Google достаточно простого редиректа для склейки. В принципе, склейку зеркал я уже делал при исключении www из URL, в этом нет ничего сложного.

4. Добавление нового сайта в Google Search Console

В Google нет инструмента переезда, поэтому просто добавьте в Search Console новый сайт с HTTPS. Старый можно не удалять, он может понадобиться в дальнейшем для анализа процедуры перехода.

Да, в консоли есть инструмент Изменение адреса, но знайте, что в данном случае он не поможет, т.к. в справочной системе есть примечание:

5. Работа с картой сайта sitemap.xml

Переходим к карте сайта sitemap.xml. На всех сайтах у меня сформирован минимальный набор необходимых плагинов, в частности за карту сайта отвечает одноимённый модуль в составе плагина All in One SEO Pack. Если вы используете этот же плагин, то в настройках модуля включите опцию Динамическая карта сайта. Таким образом поисковый робот при доступе к сайту по защищённому протоколу будет получать карту, содержащую список URL с HTTPS, что ускорит индексирование по новому адресу.


Sitemap

Ещё в сентябре 2016 года в основных настройках плагина была возможность переключения протокола для канонических ссылок и я это прекрасно помню по сайтам-первопроходцам. Начиная с версии 2.3.11 в Canonical URL были внесены изменения, связанные с автоматической установкой протокола, поэтому на следующих сайтах такой опции я уже не обнаружил. Очень жаль, эта функция позволяла получать роботу карту сайта с URL по HTTPS даже при посещении HTTP версии сайта.

Для решения описанной проблемы вы можете временно установить более раннюю версию плагина или воспользоваться следующим решением. Для этого достаточно в файл functions.php добавить код, опубликованный ниже:

Я не настаиваю на выполнении этого шага, вы можете его пропустить, просто склейка займёт чуть больше времени. В этом случае рекомендую в настройках плагина включить динамическую карту сайта, при этом возможно потребуется удалить конфликтный файл sitemap.xml физически расположенный на сервере. Динамическая карта не создает файлов, она выполняет виртуальное построение при обращении к ней.


Теперь вернёмся к нашему файлу robots.txt и внесём изменения в пути до карты сайта или добавим нужную строку, если ранее её не использовали:

А в Яндекс Вебмастере и Google Search Console нужно добавить обновлённую карту сайта с новым протоколом.

6. Замена внутренних ссылок на HTTPS, решение проблемы Mixed Content

Дальнейшее действие подразумевает замену всех абсолютных путей к стилям, скриптам, изображениям, а также замену всех внутренних ссылок по протоколу HTTP на относительные или простую замену протокола Я предпочёл сменить протокол путей и ссылок на HTTPS и ниже поделюсь с Вами как это можно быстро сделать с помощью SQL-запросов к базе данных.

При сохранении записи в таблицу wp_posts в поле guid записывается глобальный уникальный идентификатор (Globally Unique Identifier). Давайте изменим это поле для смены протокола, выполнив следующий запрос к БД через phpMyAdmin:

Произведём замену протокола всех ссылок в контенте, то есть выполним запрос к полю post_content в таблице wp_posts нашей базы данных:

В комментариях, отвечая на вопросы пользователей, я зачастую ссылаюсь на свои прочие записи, поэтому необходимо провести замену протокола ссылок и в комментариях. Для этого внесём изменения в поле comment_content таблицы wp_comments следующим образом:

На что следует обратить внимание при выполнении этих SQL-запросов:

  • обязательно замените адрес сайта на свой,
  • измените префикс таблиц, если он отличается от стандартного wp_.

SQL-запросами мы внесли львиную долю изменений, но есть места, где всё же придётся поработать вручную — это могут быть файлы темы и виджеты, где используются внутренние ссылки с HTTP протоколом. Также стоит обратить внимание на загрузку внешних стилей, скриптов, фреймов и картинок — все они должны загружаться по HTTPS, иначе они не будут загружены, а в консоли появятся ошибки смешанного содержимого (Mixed Content).

7. Решение проблемы политики CORS

Если на сайте подключены шрифты Font Awesome, тогда они могут не загружаться — это связано с появлением в консоли браузера ошибки примерно такого содержания:

Чтобы избежать появления ошибки достаточно добавить в файл .htaccess строку:

В том случае, если браузер всё равно не загружает шрифты и выдаёт ошибку, вместо символа * укажите прямой адрес своего сайта со старым HTTP протоколом:

CORS (Cross-origin resource sharing) в переводе с английского языка означает совместное использование ресурсов между разными источниками. Современные браузеры используют эту политику безопасности в своих технологиях. До тех пор, пока мы не поставим редирект с HTTP на HTTPS эта политика будет действовать, поэтому используем строку до заключительного этапа.

8. Ожидание склейки зеркал в Яндексе

Ждём письма от Яндекс Вебмастера (или уведомления, если не настроена рассылка) о смене главного зеркала. До тех пор, пока это уведомление не поступит, ни в коем случае нельзя ставить редирект! В противном случае все страницы сайта будут исключены из индекса поисковой системы Яндекс, склейка займет значительно больше времени из-за отсутствия доступа к robots.txt для HTTP версии сайта.


Главное зеркало сайта

Но есть исключение из этого правила. Допустимо использовать редирект только в том случае, если исключить из общего правила файл robots.txt. Этого можно добиться, используя в .htaccess:

Все свои сайты я переводил на безопасный протокол только дождавшись склейки через Host, кроме одного. Это был последний сайт на WordPress c установленным в отдельном каталоге форумом на phpBB.

Расскажу о нем немного подробнее. Переезд был запущен 27 января 2017 года, на протяжении трёх месяцев никаких подвижек не происходило, скорее наоборот, ситуация усугублялась из-за странной индексации: через апдейт одни и те же страницы появлялись в выдаче то с HTTP, то с HTTPS — это происходило до марта.

Тогда 10 марта я решил поставить редирект на все страницы, кроме robots.txt и стал ожидать подвижек. Числа 20 в Яндекс Каталоге наконец-то у домена сменился протокол на HTTPS, но с апдейтами в индекс по-прежнему залетали старые страницы, включая самые нелепые, которых и вовсе никогда не существовало. Возникало ощущение, что поисковый робот Яндекс вышел из ума и хватал все подряд, лишь бы зацепиться.


Точку в этом вопросе поставило моё обращение в службу поддержки Яндекса, в котором я описал ситуацию. Кстати, если ваш сайт не меняет главное зеркало более месяца, несмотря на соблюдение всех условий, рекомендую не тянуть время и обращаться. Достаточно заполнить специальную форму на этой странице, скрытую под формулировкой «Заявка на переезд не принимается»:

Неверный протокол

Ответ техподдержки внушал доверие, но в голове всё равно вертелись мысли, мол наверняка всем так отвечают:

На следующий день был апдейт поисковой выдачи, а также тИЦ. Не знаю, совпадение или нет, но уже на следующий день я наконец-то получил долгожданное уведомление о смене главного зеркала! Думаю, что моё обращение сыграло свою роль 🙂

9. Настройка 301 редиректа с HTTP на HTTPS

Теперь, когда этап склейки зеркал в Яндексе пройден, можно приступать к завершающему этапу. Заходим в консоль WordPress, в разделе Настройки — Общие меняем в полях Адрес WordPress и Адрес сайта протокол нашего сайта на HTTPS.

Редирект на HTTPS

Открываем phpMyAdmin и выполняем следующий SQL-запрос к базе данных, с помощью которого делаем замену полей с опциями home
и siteurl в таблице wp_options:

В файле .htaccess ставим постоянный редирект с HTTP на HTTPS:

10. Настраиваем заголовок HTTP Strict Transport Security

Последний штрих — устанавливаем форсированное защищённое соединение через протокол HTTPS с помощью механизма HSTS (HTTP Strict Transport Security). Браузер будет принудительно загружать сайт по защищённому протоколу, для чего в .htaccess нужно добавить строку:

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

webliberty.ru

Переход на HTTPS — проблемы

Прошу прощения, что начинаю с неприятного. Но надо же вас как-то замотивировать читать инструкцию по переезду на HTTPS 🙂

А возможные проблемы — самый лучший мотиватор делать всё аккуратно и внимательно, как показывает практика. Поэтому обязательно ознакомьтесь с данным блоком информации.

А именно с того, к чему может привести неграмотный переезд сайта на HTTPS.

1. Недоступность сайта

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

При возникновении любый проблем с доступностью после перевода сайта на HTTPS изучайте сообщения в браузере и немедленно сообщайте о них технической поддержке своего хостинг-провайдера. Если там находятся квалифицированные специалисты, то в 80% случаев они вам помогут.


http://cccp-blog.com/wp-includes/images/banners/templatemonster/banner_new_year_2019.png

2. Снижение трафика

В сети полно грустных историй вебмастеров, у которых на сайтах после перехода на HTTPS упали позиции или даже некоторые страницы выпали из поискового индекса.

Причин может быть много:

  • Отсутствие 301 редиректов с HTTP адресов на HTTPS.
  • Часть страниц может быть на HTTP, а часть на HTTPS (смешанное содержимое от англ. mixed content). Ещё одной причиной считать содержимое сайта смешанным является наличие HTTP ссылок на страницах, работающих по HTTPS протоколу.
  • Ссылки в sitemap могут быть с учётом HTTP.
  • После перехода на HTTPS новый адрес сайта не был добавлен в кабинетах вебмастера Google и Яндекс.
  • Версия сайта на HTTPS не была отмечена как основная, а старый сайт не был помечен как зеркало. Из-за этого позиции могут понижаться вследствие дублирования контента и разбавления ссылочной массы между двумя доменами.

3. Неправильная работа сайта

Может проявиться в том, что скрипты будут не грузиться вообще или некоторые картинки будут отсутствовать. Причина заключается в HTTP ссылках на статические ресурсы после полного переезда сайта на HTTPS.

4. Потеря статистики посещаемости

После перехода на HTTPS может возникнуть ситуация, что ваши партнёры, рефералами (referrals, affiliates) которых вы являетесь, перестанут видеть трафик с вашего сайта через популярные сервисы аналитики: Google Analytics, Яндекс. Метрика и другие.

Особенно эта проблема может стать актуальной для людей, зарабатывающих на своих сайтах путём размещения баннеров и ссылок, получая доход за переходы и действия, произведённые пользователями при переходе по ним.

Таким образом, после переезда сайта на HTTPS из-за данной проблемы вы просто можете потерять свои деньги, а ваш рекламодатель увидит следующую картину переходов с вашего сайта:

kak-perevesti-sajt-na-https-i-ne-poteryat-trafik

Причиной данной проблемы является то, что переход с вашего защищённого HTTPS сайта на обычную HTTP страницу, которая может быть у вашего партнёра, воспринимается сервисами аналитики как прямой переход на сайт партнёра.

Поэтому ваш сайт может просто выпасть из данной цепочки.

Как вы могли заметить, при описании каждого пункта приведённого списка проблем, которые могут возникнуть при переходе сайта на HTTPS, я указал только их вероятные причины.

А решения?… Что делать, шеф? 🙂

Именно с этой целью я и составил следующую пошаговую инструкцию как перенести сайт на HTTPS, при выполнении которой вы убережёте себя и свой ресурс от описанных траблов, а также от негативной реакции на них ваших пользователей и поисковиков.

Библиотека курсов

Как перевести сайт на HTTPS — инструкция

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

1. Установка SSL сертификата на сервер

Переезд сайта на HTTPS начинается с покупки и установки SSL сертификата.

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

О том, зачем нужен SSL сертификат, какие виды SSL сертификатов существуют на сегодняшний день, чем они отличаются и сколько стоят, подробно написано в статье о том, что такое HTTPS, ссылку на которую я привёл в самом начале статьи.

2. Настройка движка сайта

После установки SSL сертификата, для корректной работы по новому протоколу в коде самого сайта и его настройках нужно будет произвести ещё кое-какие изменения.

Первым делом, нужно будет указать, что URL сайта отныне содержит не HTTP, а HTTPS протокол. Такие настройки требуются в большинстве CMS для создания правильных внутренних ссылок, которые являются относительными.

Также важно будет проверить, чтобы существующие страницы сайта корректно открывались по URL с учётом HTTPS протокола.

3. Сообщить поисковикам об изменениях

После этого нужно сообщить поисковикам о том, что сайт перешёл на HTTPS протокол. Для индексации новых URL страниц c учётом HTTPS протокола, необходимо сообщить об их наличии поисковым роботам с помощью так называемых «аддурилок»:

  • Яндекс: https://webmaster.yandex.ru/addurl.xml
  • Google: https://www.google.com/webmasters/tools/submit-url
  • Bing: https://www.bing.com/toolbox/submit-site-url

4. Изменение главного зеркала

У Яндекса и других поисковых систем есть такое понятие, как «зеркало». Зеркалами считаются копии сайтов, среди которых есть главное зеркало – сайт, страницы которого как раз присутствуют в поисковой выдаче.

Процесс переноса ссылочного веса с зеркал на главное называется склейкой зеркал и занимает до нескольких месяцев. На скорость, к сожалению, повлиять никак нельзя, остаётся только ждать.

Главное зеркало сайта устанавливается вручную в кабинетах вебмастеров Google, Яндекс и Bing. При переносе сайта на HTTPS главным зеркалом сайта должна быть именно HTTPS версия. Также указать главное зеркало можно с помощью robots.txt, прописав в нём (или изменил) директиву Host, которая должна выглядеть так:

 Host: https://site.com 

А также главное зеркало сайта можно указать с помощью 301 редиректа, которые всё равно будут необходимы для переноса веса с HTTP URL страниц на HTTPS.

5. Изменение внутренних ссылок

Параллельно с добавлением HTTPS адресов страниц в аддурилки и настройкой главного зеркала необходимо проверить внутренние ссылки на сайте. Причём, это должны быть не только перекрёстные ссылки внутри статей, но и URL статических файлов (картинок, JS и CSS файлов).

Если ссылки прописаны в абсолютном виде, то нужно будет заменить в них протокол HTTP на HTTPS.

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

Могут быть как относительно протокола в следующем виде:

 //site.ru/page.html 

Так и относительно корня сайта:

 /page.html 

Лучше делать изменение внутренних ссылок при помощи специальных скриптов, которые помогут найти и заменить ссылки как в коде сайта, так и в БД, автоматически.

Если же их использование покажется вам слишком сложным, то можете изменить все ссылки вручную. Главное, при этом не забыть про контент, который может находиться в базах данных, внутри JavaScript скриптов, файлах CSS стилей и правилах редиректа.

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

Если вы не знакомы с тонкостями установки и настройки пакетов через Composer, то лучше воспользоваться вторым вариантом, т.к. он не требует от пользователя наличия специальных данных.

Стоит также учесть, что при использовании сторонних библиотек по CDN или иным другим способом, когда в коде сайта располагается ссылка на них, нужно также заменить их с учётом HTTPS протокола. Либо заменить абсолютные HTTP адреса относительными.

Если сделать это будет невозможно, то от таких ресурсов лучше отказаться совсем или скачать их и вызывать с собственного сервера уже по HTTPS протоколу, естественно, что будет предпочтительно даже с технической точки зрения, т.к. скорость их подключения будет выше, и вы не будете зависеть от наличия Интернет соединения.

6. Установка 301 редиректов с HTTP на HTTPS адреса страниц

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

Сделать это можно при помощи специальных плагинов и пакетов (для того же WordPress HTTPS плагинов существует уйма). Либо даже с помощью средств языков программирования.

Но самым быстрым и простым вариантом является организация 301 редиректа на уровне веб сервера с помощью специальных директив в их конфигурационных файлах.

Если ваш сайт работает на Apache сервере, то добавьте в файл .htaccess, который должен располагаться в корне сайта (или создайте его) следующий код:

 <IfModule mod_rewrite.c>  RewriteEngine On  RewriteCond %{HTTPS} off  RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]  RewriteCond %{HTTP_HOST} ^www.(.+)$ [NC]  RewriteRule ^ https://%1%{REQUEST_URI} [R=301,L] </IfModule> 

Если же вы используете Nginx, то вам потребуется следующая конструкция:

 server {  listen 80 default_server;  listen [::]:80 default_server;  server_name example.com www.example.com;  return 301 https://$server_name$request_uri; } 

Яндекс рекомендует устанавливать 301 редиректы после полной склейки зеркал, т.к. при установке редиректов страницы могут исключаться из поисковой выдачи.

7. Изменение внешних ссылок

Если вас ресурс существует достаточно долго, то, скорее всего, в Интернете можно отыскать ссылки на него с других ресурсов. Будь то обычные посты в социальных сетях или покупные ссылки, которыми вы увеличивали свой ТИЦ за деньги.

Естественно, что все они прописаны с учётом HTTP протокола, который было бы хорошо изменить на HTTPS. Но если у вас нет возможности это сделать, то сильно не огорчайтесь, т.к. при склейке доменов ссылки на любое зеркало сайта учитываются поисковиками для главного зеркала.

Таким образом, старые ссылки будут продолжать работать, передавая веса и ТИЦ.

8. Проверка канонических ссылок

Если вы используете на своём сайте канонические ссылки для исключения дублирования контента (работают для поисковиков как и 301 редирект), то необходимо на них всех поменять url с HTTP на HTTPS:

 <link rel="canonical" href="https://site.com/url"> 

Напомню, что чаще всего такие конструкции располагаются в секции head HTML кода страницы. Однако, могут присутствовать и в других местах, например, на элементах пагинации, которые сами, в свою очередь, могут быть оформлены следующим образом:

 <link rel="prev" href="https://site.com?page=1"> <link rel="next" href="https://site.com?page=2"> 

Если ссылки у них будут указаны также с учётом HTTP протокола, то их также нужно будет перевести с HTTP на HTTPS.

9. Правки на мультиязычных сайтах и в пагинации

Если на вашем сайте имеется мультиязычность, т.е. у страниц есть варианты на нескольких языках с возможностью их переключения в интерфейсе, то, скорее всего, в HTML коде у вас будет присутствовать следующая конструкция:

 <link rel="alternate" hreflang="ru" href="https://site.com/"> 

Если таковая присутствует, то необходимо будет перевести страницу на HTTPS, т.е. изменить её URL с учётом данного протокола.

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

10. Коррективы sitemap.xml

При проверке URL внутренних ссылок не забудьте заглянуть в XML карту сайта или плагины, которые её формируют, и проверить, чтобы она отныне содержала только HTTPS ссылки.

В принципе, если в ней будут URL, указанные через HTTP, то благодаря правильно настроенным 301 редиректам роботы всё равно попадут на итоговую страницу, но это приведёт к наличию у вас на сайте большого числа редиректов, что не останется без внимания поисковиков и снизит скорость загрузки контента.

Также в robots.txt нужно поменять ссылку на саму sitemap.xml с учётом нового протокола HTTPS:

 Sitemap: https://site.com/sitemap.xml 

11. Сохраняем реферальный трафик

Чтобы не стать невидимкой для Google Analytics и прочих сервисов аналитики, используемых вашими партнёрами, о чём я говорил в начале статьи, понадобится ещё одно действие.

Оно заключается в добавлении мета тега referer, с помощью которого задаётся содержимое заголовка Referer HTTP запроса, отправляемого пользователем вашего сайта через браузер. В идеале там должен содержаться URL сайта, на котором находился юзер при отправке запроса.

По умолчанию, при передаче запросов браузеры руководствуются реферальной политикой No Referrer When Downgrade, которая подразумевает передачу реферальных данных (ссылки на ресурс, с которого запрос был инициирован) только с HTTPS на HTTPS ресурс.

При передаче с HTTPS на HTTP заголовок не будет содержать никаких данных и запрос будет считаться прямым, т.е. когда пользователь ввёл URL сайта вашего партнёра прямо в браузере.

Сразу хочу уточнить, что в значении Referer заголовка будет находиться URL без параметров.

Итак, чтобы изменить данное поведение, нужно в HTML коде необходимых страниц (лучше всего, конечно, сделать это для всего сайта) разместить следующую конструкцию в секции head:

 <meta name="referrer" content="значение_параметра">, 

Наиболее часто используемыми на практике являются следующие значения параметров:

  • no-referrer — реферальные данные не будут передаваться;
  • no-referrer-when-downgrade — значение по умолчанию: ссылка источника будет передаваться только сайтам, поддерживающим HTTPS протокол, как и на вашем; сайтам, работающим по HTTP, ничего не будет передаваться;
  • origin — реферальные данные будут передаваться не зависимо от протокола и при переходе как с вашего основного сайта, так и с его поддоменов;
  • origin-when-crossorigin — при внутренних запросах, т.е. когда переход на URL произошёл пользователем с этого же сайта, будет передаваться полный адрес страницы; в случае же запроса с другого сайта заголовок будет пуст;
  • unsafe-url — реферальные данные будут передаваться в любом случае: и при внутренних запросах, и при перекрёстных;

Со списком всех политик безопасности и их описанием (правда, на английском) вы можете познакомиться здесь — https://www.w3.org/TR/referrer-policy/#referrer-policies

В большинстве случаев, для корректной передачи реферальных данных без угроз безопасности ресурса вам пригодится следующий вариант:

 <meta name="referrer" content="origin"> 

После произведения действий, описанных в данной инструкции по правильному переходу на HTTPS сайтов с HTTP, всё, что вам останется — ждать. Ждать полной переиндексации сайта и замещения страниц из поиска с HTTP урлами на HTTPS аналоги.

К сожалению, даже если вы всё сделаете верно, стоит готовиться к кратковременному снижению трафика, т.к. 301 редиректы передают от 85% до 99% ссылочного веса. Трафик может восстанавливаться несколько месяцев.

Также не удивляйтесь тому, что при переходе на HTTPS пропал ТИЦ или данный показатель значительно снизился.

Не волнуйтесь, со временем показатели восстановятся, а трафик может даже и увеличиться благодаря сегодняшней лояльности поисковиков к HTTPS сайтам. Но, как уже говорилось, должно пройти время.

Переезд на HTTPS — снова проблемы…

Аффтар жжот 🙂 Только привёл инструкцию, как избежать проседания трафика и прочих проблем переезда сайта на HTTPS — и снова здрасьте… Какие ещё проблемы?

К сожалению, список трудностей, которые могут возникнуть при переходе с HTTPS на HTTP, не ограничивается перечнем, приведённым в начале.

Я не описал их сразу не потому, что забыл о части и вспомнил только сейчас, а по той причине, что не все они зависят от правильности действий при переводе сайта.

Некоторые из них вызваны особенностями самого защищённого протокола HTTPS, о чём я и захотел поговорить с вами насполедок.

1. Частичная недоступность

Обычно проявляется следующим сообщением об ошибке HTTPS подключения к сайту в браузере:

oshibka-prosrochennogo-sertifikata-pri-perehode-na-https

Причина: В принципе, ничего страшного в данном явлении нет, т.к. сообщение появляется при использовании самоподписанного SSL сертификата или когда истёк срок действия сертификата.

Но пользователи, в большинстве своём, — люди простые 🙂 Просто берут и закрывают сайт в поисках «безопасной» альтернативы.

Естественно, данное поведение не пройдёт незамеченным мимо поисковиков, которые пристально следят за временем нахождения юзеров на страницах сайта, от чего зависят ваши позиции в выдаче.

Решение: Своевременно оплачивайте сертификат или просто переоформляйте его при использовании бесплатного. Многие хостинги, кстати, предоставляют своим клиентам скрипты для автоматического переоформления бесплатных сертификатов от Let’s Encrypt.

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

Кстати! Такая ситуация может возникнуть ещё и тогда, когда недобросовестный регистратор подсунул вам «левый» сертификат. Поэтому при возникновении данных проблем обязательно сообщитетем,  у кого вы купили ваш SSL сертификат.

2. Страницы сайта стали дольше загружаться

В большинстве случаев замедление незначительно, но на больших проектах важны все мелочи. И, не зная данной особенности HTTPS протокола, вы будете очень долго искать причину «тормозов».

Причина: Заключается в наличии операций по шифрованию и дешифровке трафика при передаче по протоколу HTTPS.

Решение: К сожалению, бороться с этим не получится, да и бессмысленно, т.к. это нюансы технологии. Как вариант – заняться переоптимизацией сайта там, где это возможно (организовать серверное кэширование, минимизировать размер картинок и других статических файлов – html/css/js).

3. Потеря статистики социальных сигналов (репосты, лайки и т.д.)

Переезд на HTTPS сулит и ещё одну проблему, которая заключается в обнулении счётчиков лайкнувших и зарепостивших вас пользователей. Мелочь, вроде бы. Но, в некоторых случаях, данный нюанс может создать серьёзные проблемы для бизнеса.

Причина: Это происходит из-за того, что статистика считается для конкретного домена. Поскольку сайт при переходе с HTTP на HTTPS, фактически, изменил свой url, то вся статистика будет утрачена и начнёт считаться заново.

Решение: К сожалению, с этим ничего нельзя сделать, пока разработчики социальных сетей не внесут в свои продукты соответствующие изменения. А пока они этого не сделали, вы можете воспользоваться плагинами. Например, для WordPress существует замечательный плагин от WarfarePlugins, позволяющий сохранить статистику социальных сигналов при переходе сайта на HTTPS.

Но данный функционал, естественно, не является основным. Это, скорее, бонус. Основное предназначение расширения — увеличение социальной активности ваших пользователей, что неминуемо приведёт к увеличению трафика.

Минусов у него всего два: плагин на английском и он платный, но цена не заоблачна и составляет единоразовые 30$. В принципе, вы заплатите эти же деньги или даже больше, если будете обращаться к фрилансерам с подобной просьбой.

Как перейти на HTTPS — рекомендации

К сожалению, реальность такова, что при переезде на HTTPS вы действительно можете потерять часть трафика и столкнуться с неминуемыми проблемами другого рода, некоторые из которых были озвучены выше.

Однако, есть способы минимизировать этот эффект и сделать так, что ваш бизнес понесёт при этом незначительные потери.

Для этого есть несколько рекомендаций.

1. Переход в период снижения посещаемости

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

А если вдруг ресурс будет некоторое время вообще недоступен, то вы потеряете меньше клиентов, чем в период продаж.

Для большинства ресурсов период застоя – с начала мая до донца сентября, т.к. у большинства людей в данное время отпуска.

Однако, всё равно, для каждой тематики и ресурса он свой, поэтому анализируйте свой годовой трафик, чтобы вычислить подходящее время для перевода сайта на https.

2. Использование сервисов для мониторинга ошибок перехода на HTTPS

В самом начале статьи были рассмотрены проблемы, возникающие при переезде сайтов на HTTPS, а также некоторые их причины. Даже если проблему вы и сможете самостоятельно определить, то проработать абсолютно все причины её возникновения вручную будет весьма долго и затруднительно для неопытных пользователей.

Поэтому я советую анализировать сайт с использованием специальных сервисов незамедлительно после установки SSL сертификата на сервер, настройки движка сайта и 301 редиректов. Таким образом, вы сможете узнать о возникших проблемах при переходе с HTTP на HTTPS раньше Яндекса и Google, что позволит вам избежать проседания трафика.

Одним из таких сервисов является Serpstat, который предоставляет следующую аналитику ошибок SSL сертификата и HTTPS соединения в целом:

proverka-ustanovki-ssl-sertifikata-i-oshibok-perevoda-sajta-na-https

Как видите, здесь происходит проверка установки SSL сертификата и наличия типичных ошибок, которые могут возникнуть при переходе на HTTPS, приведённые в самом начале статьи. И хорошо, что на моём тестовом сайте они не были обнаружены.

Единственный недочёт, который отображён на картинке выше, заключался в отсутствии поддержки технологии HSTS на сервере моего хостинга, который решается только сменой такового.

Большой плюс данной аналитики от Serpstat в том, что ошибки подробно описываются, и предлагаются способы их решения. Поэтому очень рекомендую 🙂

3. Настройка HTTPS соединения на копии сайта

Поскольку неправильный перенос сайта на HTTPS чреват многими проблемами, то я, как веб разработчик, хочу дать чисто профессиональный совет 🙂

Он заключается в тестировании изменений, а в данной случае, настройке HTTPS соединения, на локальном веб-сервере или копии сайта на одном тестовом поддомене сайта, а не в «продакшене».

Это немного растянет процесс переезда на HTTPS по времени, но зато у вас будет 100% гарантия того, что после переноса сайта на основной домен поисковые роботы сразу будут индексировать контент правильно.

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

В процессе вас ещё что-то отвлекло… И, в итоге, когда вы доделаете всю работу, у вас есть все шансы обнаружить в кабинетах вебмастеров Google, Яндекс и Bing кучу ошибок, из-за которых позиции вашего сайта в выдаче уже начали падать.

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

Примерно о таких возможных сроках проседания трафика говорят и сами поисковики, видимо, предвидя такую ситуацию. Но, использовав копию сайта для настройки HTTPS, вы всего этого сможете избежать.

Единственное, в случае работы с копией сайта, приведённая ранее инструкция будет слегка отличаться.

Сперва я рекомендовал бы скопировать сайт и подключить к нему SSL сертификат на сервере. Затем я бы откорректировал все внутренние ссылки и сделал бы 301 редиректы. Исправил бы robots.txt и добавил бы канонические тэги.

После этого, когда я бы убедился, что всё в порядке, я добавил бы сертификат на основной сервер и подключил бы его к доменному имени сайта с переносом файлов сайта с тестового домена на основной.

Спрашивается: а что делать, если сертификат был куплен на одно доменное имя? Как его использовать на тестовом поддомене?

Всё просто: купленый сертификат устанавливаем на сервере, где будет размещаться основной сайт, а также подключаем его к основному домену. Для тестового можно использовать бесплатный SSL сертификат от Let’s Encrypt либо самоподписанный.

Ну, а если вы купили Wildcard сертификат или вообще мультидоменный, то проблем с этим нюансом у вас не будет в принципе.

Как видите, проблем может возникнуть масса. Особенно у «матёрых» сайтов с большой посещаемостью и историей, которые сегодня активно переходят на HTTPS.

Но, если вы только собираетесь создавать сайт и лишь «прощупываете почву» по поводу HTTPS и SSL сертификатов, то я бы однозначно рекомендовал бы устанавливать их с самого старта проекта, чтобы избежать трудностей перевода в будущем 🙂

И вот, почему…

Перевод сайта на HTTPS — выводы

Несмотря на кучу проблем, к которой вас может привести неграмотный переход на HTTPS, данное мероприятие всё равно рано или поздно предстоит сделать.

Дело даже не в возросшем уровне киберпреступности, а в том, что компания Google, являющаяся владельцем крупнейшего в мире одноимённого поисковика, постоянно стимулирует вебмастеров делать перевод с HTTP на HTTPS своих ресурсов на данный протокол.

Последним новшеством стала отметка сайтов, работающих по HTTP протоколу, как небезопасных, в Google Chrome, начиная с 29 января 2017 года и 56 версии браузера.

А, учитывая, что сегодня Google Chrome используют более 55% всех пользователей Интернет, то существует большая вероятность, что те из них, кто ничего не знает о данной особенности браузера и HTTPS протоколе в целом, просто уйдут с вашего сайта в поисках «безопасного».

Правда, данные санкции касаются не всех сайтов, а только тех, где имеются формы для ввода информации пользователем.

Блогов, похоже, это не коснётся, т.к. данный сайт отображается в Google Chrome 59 в штатном режиме без всяких предупреждений.

Но если у вас Интернет магазин или другой коммерческий продукт, где пользователи вводят платёжную информацию или другие конфиденциальные данные, то переход на HTTPS для вас неизбежен.

И чем раньше вы его сделаете, тем лучше.

Тем более, что временная потеря трафика на сайте — это не обязательное последствие перевода сайта на HTTPS. Поисковые системы и их алгоритмы — вещи непредсказуемые, о чём неоднократно заявляли их инженеры.

Поэтому вполне возможна ситуация, когда переезд сайта на HTTPS с HTTP  приведёт к росту посещаемости практически с первых дней, как это произошло на этом сайте:

uvelichenie-trafika-posle-pereezda-na-https

Главное следовать изложенной в статье пошаговой инструкции как перевести сайт на HTTPS и руководствоваться рекомендациями в процессе.

Пишите свои отзывы в комментариях, делитесь своим опытом переезда на HTTPS и указывайте мне на мои ошибки. Это тоже нужно 🙂

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

Всем удачи и до новых встреч!

cccp-blog.com

Зачем переходить на HTTPS?

Зачем вообще этот риск потерять трафик из-за смены протокола? Главное преимущество HTTPS: зашифрованное соединение нельзя прехватить с помощью стороннего сервиса и использовать оставленные на сайте данные в мошеннических целях. При переходе на HTTPS «незащищенное соединение» заменится на зеленое «безопасное». Все ради зеленой строки в браузере Критически необходимо переходить на новый протокол всем сайтам, где есть какая-либо информация, которую могут перехватить (платежные данные, например). То есть для интернет-магазинов переход на https — в списке обязательных рекомендаций. Процесс перехода состоит из четырех этапов.

1. Подготовка к переходу на HTTPS

Для того, чтобы начать переход на HTTPS, еще перед сменой протокола рекомендуем вам абсолютные внутренние ссылки на сайте заменить на относительные.

Например, ссылку http://netpeak.net/ru/blog/kak-uvelichit-prodazhi-iz-rsya-rost-tranzaktsiy-na-427-za-mesyats/ заменить в текстах на /kak-uvelichit-prodazhi-iz-rsya-rost-tranzaktsiy-na-427-za-mesyats/.

Существует и второй тип относительных ссылок, когда не используется не доменное имя в адресе ссылки, а только сам протокол.

В нашем случае: //netpeak.net/ru/blog/kak-uvelichit-prodazhi-iz-rsya-rost-tranzaktsiy-na-427-za-mesyats/.

Если на сайте есть коды ремаркетинга, различные скрипты, нужно просто заменить их адреса на относительные с доменным именем, но без протокола HTTP. В случае с медиа-контентом ссылки на картинки и видео также следует заменить на относительные без протокола.

Время на написание техзадания: один час. Работа программиста: 3-4 часа (в зависимости от сайта).

2. Как выбрать SSL-сертификат

Не используйте бесплатные SSL-сертификаты — это небезопасно. Браузеры могут выдать ошибку с предупреждением, что сайт не проверен. Такое предупрждение могут увидеть те, кто сэкономил на SSL Существует несколько видов SSL-сертификатов по степени защиты:

  • Domain Validation. Наиболее распространенный сертификат. Выдается на один домен, и если вы решите сменить доменное имя, придется оплачивать заново. Средняя цена колеблется от $10 до $30 в год. Для получения обратитесь в любой центр сертификации (например, Comodo или Symantec).
  • Organization Validation. Подтверждает домен и организацию. Могут проверить информацию в прессе, наличие компании в Whois, свидетельство о государственной регистрации. Средняя цена колеблется от $40 до $200 в год.
  • Extended Validation. Сертификат с расширенной проверкой — для его получения проверяется наличие компании по адресу, свидетельство о регистрации, операционная деятельность, торговая марка. Все для того, чтобы получить зеленую строку в адресной строке браузера. Стоимость в среднем от $120 до $300 в год.

Существует и классификация сертификатов по функциональности:

  • обычные SSL-сертификаты;
  • Wildcard сертификаты — используйте, если хотите установить HTTPS на поддоменах;
  • SAN сертификаты — используется для нескольких доменов.

В нашем кейсе был выбран обычный SSL-сертификат. Проблем с самим переходом возникнуть не должно, так как здесь помощь, в основном, предоставляют хостеры. Скриншот админки одного из хостеров

Скриншот админки одного из хостеров. У вас наверняка другая картина

Впрочем, при смене протокола порой приходится менять хостинг. К сожалению, не все хостеры поддерживают SSL. Будьте внимательны: при смене хостинга и переходе на HTTPS, сайт будет доступен по старому IP-адресу и необходимо будет настроить редиректы с него на новый адрес. Рекомендуем после установки проверить, правильно ли установлен ваш SSL-сертификат. Существует много онлайн-сервисов, которые оценят настройку защищенного соединения с вашим сервером и даже дадут рекомендации в решении проблем. Например, SSL Server Test. Собственно, поздравляем! Сайт теперь доступен по HTTPS. Но это еще не финал.

Время: от 30 минут (в нашем случае).

Больше советов по развитию сайта — в рассылке блога:

Наши подписчики всегда в выигрыше.

3. Как настроить сайт и сохранить трафик

3.1. Раньше перед настройкой 301 редиректов в панели для Вебмастеров Яндекса в разделе «Настройки индексирования» → «Главное зеркало» нужно было выбрать пункт «Установить протокол https». Эта опция уже не работает: Эта опция уже не работает Сейчас необходимо отправлять заявку на смену протокола в инструменте «Переезд сайта», который доступен в новой версии Яндекс.Вебмастера. Обратите внимание, процесс переклейки зеркал происходит автоматически и может занимать несколько недель. Ускорить его, к сожалению, нельзя. В новом интерфейсе необходимо отправлять заявку на смену протокола в инструменте «Переезд сайта» Именно эти первые несколько недель выдачу может «штормить». По наблюдениям, Google с этим быстро справляется, Яндекс — немного дольше.

3.2. В файле robots.txt замените строку host, прописав в ней не просто доменное имя, а доменное имя вместе с https:

Host: https://site.com

Строку с картой сайта также нужно обновить.

3.3. Далее добавьте сайт HTTPS в Google Search Console. Здесь обновите XML-карту сайта, если нужно — выставьте регион. Если у вас есть отклоненные ссылки в Disavow Tool, не забудьте заново загрузить файл с ними.

3.4. Самое главное — настройка 301 редиректов (постоянных перенаправлений) со старого адреса с HTTP на новый с HTTPS. После настройки проверьте, чтобы изображения были доступны по HTTPS, проверьте все типы страниц. Например, страницы фильтров, страницы карточек-товаров, прайс-листы, категории, служебные страницы и тому подобное. Все они должны быть доступны по HTTPS.

При этом файл robots.txt и XML-карта сайта должны быть доступны и по http, и по https. В htacess при настройке редиректов исключение для файла роботс можно настроить строкой:

RewriteCond %{REQUEST_FILENAME} robots.txt$ [NC]

Время: 30 минут.

4. Правки на сайте

Кажется, осталось просто ждать переиндексации. Но нет. Как бы вы не старались подготовить сайт к переносу, наверняка останутся ссылки на HTTP. В нашем примере остались ссылки в link rel=»canonical», то есть все до единой страницы на сайте ссылались на 301 редирект. Кроме того, абсолютные ссылки на страницах пагинации также вели на 301 редирект. Если у вашего сайта существуют языковые версии, то необходимо будет заменить адреса ссылок с

<link rel="alternate" hreflang="ru" href="http://site.com/" />

на

<link rel="alternate" hreflang="ru" href="https://site.com/" />

Несмотря на то, что все эти пункты выполнены, в адресной строке все равно может быть сообщение о том, что соединение не безопасно. Скорее всего, это связано со скриптами, которые тянутся со страниц. Необходимо заменить адреса ссылок на них на относительные без протокола. После этого проверьте коды ответов сервера на сайте, чтобы существующие страницы возвращали код ответа 200, а несуществующие — 404/410. Также нужно провести проверку сайта на наличие ссылок на редиректы, 404 страницы. Все, теперь действительно осталось только ждать переиндексации.

Время на поиск ошибок и написание ТЗ: 1 час. Работа программиста: 4-5 часов (в зависимости от сайта)

Что в результате?

Используя все перечисленные рекомендации, мы перевели на https один сайт по продаже семян. Переход был осуществлен в первых числах февраля. Как вы можете увидеть на скриншоте, видимость сайта не просела, а выросла: Видимость сайта выросла Органический трафик также удалось спасти: Органический трафик удалось сохранить

Нужно ли все сайты переводить на HTTPS?

Да, всем сайтам рекомендуется переходить на безопасное шифрование. Безопасность пользователей — важнейший аргумент в пользу перехода на HTTPS.

Андрей Липатцев из Google в своем выступлении 12 февраля 2016 года заявил:

Также прочитайте о нюансах перехода на HTTPS в блоге roman.ua.

Учитывая то, что поисковые системы постоянно рекомендуют переходить на HTTPS и создают в сервисах для вебмастеров отдельные мануалы и пункты для перехода, то, вероятнее всего, уже в ближайшем будущем (1-2 года) фактор HTTPS как минимум сравняется по значению со скоростью загрузки сайта.

netpeak.net

Что такое HTTPS?

Любое действие в интернете — это обмен данными, при котором каждый раз ваш компьютер делает запрос к необходимому серверу и получает от него ответ. Стандартно такой обмен данными происходит по протоколу HTTP, основной недостаток которого — незащищенность передаваемых данных, что абсолютно не приемлемо, например, когда речь идет о передаче паролей, данных кредитных карт и другой персональной или конфиденциальной информации.

По сути, HTTPS —это расширение протокола HTTP, поддерживающее шифрование, что обеспечивает безопасность передачи данных.

Переход на https

Плюсы и минусы HTTPS

Так почему же мнения специалистов разделились? Дело в том, что использование протокола HTTPS имеет как свои плюсы, так и минусы.

К отрицательным моментам использования HTTPS можно причислить:

  • ежегодно оплачиваемый сертификат, стоимостью примерно от $20 в год;
  • снижение скорости работы сервера, так как часть его ресурсов будет уходить на шифрование передаваемых данных.

К положительным:

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

Корректный перевод сайта с HTTP на HTTPS

Проблема, с которой вы можете столкнуться при переходе на HTTPS — это временная потеря позиций в поиске и проседание трафика. Поисковые системы считают сайты http : // site . ru / и https : // site . ru / зеркалами (то есть сайтами, которые являются полными или частичными копиями), поэтому важно организовать корректный переезд на новый протокол, придерживаясь следующих рекомендаций:

  1. Оба сайта http : // site . ru / и https : // site . ru / должны быть доступны для поисковых систем.
  2. Для сайта http : // site . ru / в Яндекс.Вебмастере в разделе «Настройка индексирования» в пункте «Главное зеркало» установите главным зеркаломhttps : // site . ru /.
  3. В файлах http : // site . ru / robots.txt и https : // site . ru / robots.txt пропишите директиву «Host» с протоколом HTTPS:Переход на https
  4. Дождитесь смены главного зеркала в Яндексе на https : // site . ru /.
  5. Настройте постраничный 301-ый редирект со страниц с протоколом HTTP на страницы с протоколом HTTPS.
  6. Обновите XML-карту сайта — замените в ссылках протокол HTTP на HTTPS. Обновите ссылку на карту сайта в файле robots.txt, например:Переход на https
  7. При использовании в HTML-коде абсолютных ссылок необходимо указать в них протокол HTTPS вместо HTTP.
  8. При использовании теговили— ссылки в них также необходимо обновить на HTTPS.

Использование HSTS

При использовании защищенного соединения сервер затрачивает больше времени на передачу данных. Поэтому рекомендуем использовать веб-сервер, поддерживающий механизм HSTS (заранее убедитесь, что он включен), что позволит ускорить обработку запросов сервером. В этом случае браузер будет запрашивать страницы через протокол HTTPS, даже если пользователь введет http : // site . ru / в адресной строке.

В файл .htaccess добавляем следующие строки:Переход на https

Основные ошибки

Описание проблемы Действие
Просроченные сертификаты. Вовремя обновляйте сертификаты.
В сертификате неправильно указан основной хост. Проверьте, на какое имя хоста зарегистрирован сертификат. Пример такого
Не поддерживается указание имени сервера (SNI, Server name indication). Ваш веб-сервер должен поддерживать SNI. SNI поддерживают все современные браузеры. Для поддержки устаревших браузеров вам понадобится выделенный IP-адрес.
Старые версии библиотек. Старые версии OpenSSL уязвимы. Используйте последние версии библиотек TLS.
Совмещение защищенных и незащищенных элементов. Размещайте на страницах HTTPS только защищенное содержание.
Разное содержание на страницах HTTP и HTTPS. Содержание на страницах HTTP и HTTPS должно быть идентичным.

В заключение

Вернемся к вопросу: стоит ли переходить на HTTPS, чтобы улучшить свои позиции в поиске? Мы не видим необходимости переходить на HTTPS исключительно в целях улучшения SEO-факторов и продвижения сайта. Но если у вас есть потребность в использовании защищенного соединения, например, при передаче персональных данных ваших пользователей, то использование HTTPS — единственный верный способ защитить их от злоумышленников.

www.cossa.ru

Рекомендации по использованию HTTPS

Используйте надежные сертификаты безопасности

Если вы решили использовать протокол HTTPS на своем сайте, вам нужно получить сертификат безопасности. Его выдает центр сертификации, который проверяет, действительно ли указанный веб-адрес принадлежит вашей организации. Таким образом обеспечивается защита посетителей от атак с перехватом. Чтобы обеспечить высокий уровень защиты, при настройке сертификата выберите 2048-битный ключ. Если вы уже используете сертификат с менее надежным ключом (1024-битным), замените его на 2048-битный. При выборе сертификата следуйте изложенным ниже рекомендациям.

  • Получайте сертификат в надежном центре сертификации, который может предоставить техническую поддержку.
  • Определите, какой тип сертификата предпочтителен для вашего сайта:
    • Одиночный сертификат для одного защищенного источника (например, www.example.com).
    • Многодоменный сертификат для нескольких известных защищенных источников (например, www.example.com, cdn.example.com, example.co.uk).
    • Сертификат-шаблон для защищенного источника с несколькими динамическими субдоменами. (например, a.example.com, b.example.com).

Используйте переадресацию 301 на стороне сервера

Перенаправляйте пользователей и поисковые системы на страницу с поддержкой HTTPS или ресурс с переадресацией 301 на стороне сервера для адресов HTTP.

Убедитесь, что страницы HTTPS можно сканировать и индексировать

  • Не запрещайте посредством файлов robots.txt сканировать и индексировать страницы HTTPS.
  • Не используйте на страницах HTTPS метатеги noindex.
  • Чтобы проверить, может ли робот Googlebot обработать ваш сайт, воспользуйтесь инструментом Просмотреть как Googlebot.

Используйте технологию HSTS

На сайтах, использующих протокол HTTPS, рекомендуется применять технологию HSTS (HTTP Strict Transport Security). В этом случае браузер будет запрашивать страницы HTTPS, даже если пользователь введет http в адресной строке. а Google будет предоставлять в результатах поиска только защищенные URL. Все это снижает вероятность показа пользователям незащищенного содержания.

Чтобы применять HSTS, используйте веб-сервер, поддерживающий эту технологию, и включите в его настройках соответствующую функцию.

Технология HSTS усложняет процесс отката, поэтому ее включение следует выполнять следующим образом:

  1. Выполните переход на HTTPS, не включая HSTS.
  2. Активируйте отправку заголовков HSTS с минимальным значением директивы max-age. Отслеживайте объем трафика пользователей и других клиентов, а также эффективность зависимых объектов, например объявлений.
  3. Постепенно увеличивайте значение max-age в заголовках HSTS.
  4. Если HSTS не затрудняет пользователям и поисковым системам просмотр веб-страниц, то сайт можно добавить в список предварительной загрузки. Большинство популярных браузеров использует этот список, чтобы проверять, защищен ли тот или иной сайт.

Включите предварительную загрузку HSTS

Чтобы повысить скорость загрузки и уровень безопасности страниц HTTPS, можно активировать предварительную загрузку HSTS. Также изучите требования на сайте hstspreload.org.

Распространенные проблемы

Ниже перечислены некоторые проблемы, которые могут возникнуть при использовании защиты TLS, и способы их устранения.

Описание Действие
Просроченные сертификаты. Вовремя обновляйте сертификаты.
В сертификате неправильно указано название сайта. Убедитесь, что вы получили сертификат для всех имен хостов, которые обслуживают ваш сайт. Предположим, в сертификате указан только хост www.example.com. Пользователь, который попытается перейти на example.com (без префикса «www.»), не попадет туда из-за несоответствия сертификата.
Не поддерживается указание имени сервера (SNI, Server name indication). Ваш веб-сервер должен поддерживать SNI. Также рекомендуйте посетителям использовать поддерживаемые браузеры. SNI поддерживают все современные браузеры. Для поддержки устаревших браузеров вам понадобится выделенный IP-адрес.
Проблемы сканирования. Не блокируйте сканирование своего сайта HTTPS с помощью файла robots.txt.
Проблемы индексирования. По возможности разрешите поисковым системам индексировать ваши страницы. Старайтесь не использовать метатег noindex.
Старые версии протоколов. Старые версии протоколов уязвимы. Используйте последние версии библиотек TLS и протоколов.
Совмещение защищенных и незащищенных элементов. В страницы HTTPS можно встраивать только контент, который передается по протоколу HTTPS.
Разное содержание на страницах HTTP и HTTPS. Содержание на страницах HTTP и HTTPS должно быть идентичным.
Ошибки кода статуса HTTP на страницах с HTTPS. Убедитесь, что ваш сайт возвращает правильный код статуса HTTP. Например, для доступных страниц используется код 200, а для несуществующих ‒ 404 или 410.

Дополнительные рекомендации

С другими рекомендациями по использованию страниц HTTPS на сайте можно ознакомиться здесь.

Перенос сайта с протокола HTTP на HTTPS

Смена протокола сайта с HTTP на HTTPS считается переносом сайта с изменением URL. Это действие может временно повлиять на учет трафика. Подробнее…

Добавьте в Search Console ресурс, использующий протокол HTTPS. Помните, что Search Console расценивает страницы HTTP и HTTPS как разные, поэтому их данные не совпадают.

Ознакомьтесь со страницей устранения неполадок при переносе файлов Sitemap.

Дополнительная информация

Статьи о реализации TLS на сайтах:

  • Рекомендации Qualys по использованию SSL и TLS
  • Информация об SSL и TLS на сайте Mozilla

support.google.com


You May Also Like

About the Author: admind

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.

Adblock
detector