Как перейти на 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 для указания старого http-URL. Тем не менее он говорит, что это работает, только если старый 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 и зачем «городить огород».