Разница между http и https её влияние на seo продвижение

HTTP/1.1 – 1999

Прошло 3 года со времён HTTP/1.0, и в 1999 вышла новая версия протокола — HTTP/1.1, включающая множество улучшений:

• Новые HTTP-методы — PUT, PATCH, HEAD, OPTIONS, DELETE.
• Идентификация хостов. В HTTP/1.0 заголовок Host не был обязательным, а HTTP/1.1 сделал его таковым.
• Постоянные соединения. Как говорилось выше, в HTTP/1.0 одно соединение обрабатывало лишь один запрос и после этого сразу закрывалось, что вызывало серьёзные проблемы с производительностью и проблемы с задержками. В HTTP/1.1 появились постоянные соединения, т.е. соединения, которые по умолчанию не закрывались, оставаясь открытыми для нескольких последовательных запросов. Чтобы закрыть соединение, нужно было при запросе добавить заголовок Connection: close. Клиенты обычно посылали этот заголовок в последнем запросе к серверу, чтобы безопасно закрыть соединение.
• Потоковая передача данных, при которой клиент может в рамках соединения посылать множественные запросы к серверу, не ожидая ответов, а сервер посылает ответы в той же последовательности, в которой получены запросы. Но, вы можете спросить, как же клиент узнает, когда закончится один ответ и начнётся другой? Для разрешения этой задачи устанавливается заголовок Content-Length, с помощью которого клиент определяет, где заканчивается один ответ и можно ожидать следующий.

Замечу, что для того, чтобы ощутить пользу постоянных соединений или потоковой передачи данных, заголовок Content-Length должен быть доступен в ответе. Это позволит клиенту понять, когда завершится передача и можно будет отправить следующий запрос (в случае обычных последовательных запросов) или начинать ожидание следующего ответа (в случае потоковой передачи).
Но в таком подходе по-прежнему оставались проблемы. Что, если данные динамичны, и сервер не может перед отправкой узнать длину контента? Получается, в этом случае мы не можем пользоваться постоянными соединениями? Чтобы разрешить эту задачу, HTTP/1.1 ввёл сhunked encoding — механизм разбиения информации на небольшие части (chunks) и их передачу.

• Chunked Transfers если контент строится динамически и сервер в начале передачи не может определить Content-Length, он начинает отсылать контент частями, друг за другом, и добавлять Content-Length к каждой передаваемой части. Когда все части отправлены, посылается пустой пакет с заголовком Content-Length, установленным в 0, сигнализируя клиенту, что передача завершена. Чтобы сказать клиенту, что передача будет вестись по частям, сервер добавляет заголовок Transfer-Encoding: chunked.
• В отличие от базовой аутентификации в HTTP/1.0, в HTTP/1.1 добавились дайджест-аутентификация и прокси-аутентификация.
• Кэширование.
• Диапазоны байт (byte ranges).
• Кодировки
• Согласование содержимого (content negotiation).
• Клиентские куки.
• Улучшенная поддержка сжатия.
• И другие…

Особенности HTTP/1.1 — отдельная тема для разговора, и в этой статье я не буду задерживаться на ней надолго. Вы можете найти огромное количество материалов по этой теме. Рекомендую к прочтению Key differences between HTTP/1.0 and HTTP/1.1 и, для супергероев, ссылку на RFC.

HTTP/1.1 появился в 1999 и пробыл стандартом долгие годы. И, хотя он и был намного лучше своего предшественника, со временем начал устаревать. Веб постоянно растёт и меняется, и с каждым днём загрузка веб-страниц требует всё больших ресурсов. Сегодня стандартной веб-странице приходится открывать более 30 соединений. Вы скажете: «Но… ведь… в HTTP/1.1 существуют постоянные соединения…». Однако, дело в том, что HTTP/1.1 поддерживает лишь одно внешнее соединение в любой момент времени. HTTP/1.1 пытался исправить это потоковой передачей данных, однако это не решало задачу полностью. Возникала проблема блокировки начала очереди (head-of-line blocking) — когда медленный или большой запрос блокировал все последующие (ведь они выполнялись в порядке очереди). Чтобы преодолеть эти недостатки HTTP/1.1, разработчики изобретали обходные пути. Примером тому служат спрайты, закодированные в CSS изображения, конкатенация CSS и JS файлов, доменное шардирование и другие.

Виды SSL сертификатов

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

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

Бесплатные SSL с доверенной подписью

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

Сайты с такими сертификатами часто рассматриваются обозревателями Chrome, Opera Internet Explorer, Mozilla Firefox как подозрительные, не доверенные. В итоге сайты блокируются и не загружаются в самых распространенных браузерах.

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

Например, на сайте letsencrypt.org/ru/ выдаются бесплатно сертификаты, которые все популярные браузеры из «большой пятерки» рассматривают как надежные.

Вот как выглядит адресная строка с сертификатом Let’s Encrypt. Если кликнуть на замочек, выпадает окно с информацией о сертификате.

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

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

Платные SSL

Надежный коммерческий SSL-сертификат вызывает больше доверия, а доверие – это двигатель торговли. Никто не хочет вести дела с организациями, которым нельзя доверять. Ведь речь идет о деньгах, а иногда и о больших деньгах.

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

Платные SSL выдаются авторитетными центрами сертификации.

В их числе:

• Symantec,
• Norton,
• Comodo,
• Trustwave,
• Thawte.

Почему все иностранные? Суть в том, что и все популярные веб-браузеры разрабатываются в зарубежных странах. Поэтому и сертификаты в браузерах применяются свои.

С проверкой домена

Сертификат типа DV (Domain Validation — валидация домена) переназначен для того, чтобы пользователь мог быть уверен, что попадает именно на заявленный сайт, а не на фишинговую копию.

На скриншоте выше сертификат с валидацией домена.

С проверкой компании

Сертификат OV (Organization Validation – валидация организации) подтверждает посещение сайта по правильному домену и что сайт точно принадлежит заявленной компании или организации.

С расширенной проверкой

Сертификат EV (Extendet Validation – расширенная валидация). Такие сертификаты осуществляют проверку как по перечисленным выше параметрам, так и дополнительные тесты, в том числе периодические.

Сертификация EV обозначается в адресной строке замочком, где рядом видно название компании.

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

По какому принципу работает SSL сертификат и почему он безопасный

Цифровой SSL сертификат обеспечивает невозможность перехвата пользовательских данных в момент передачи информации из веб-браузера на удаленный сервер.

Принцип работы криптографического сертификата довольно прост.

• В процессе сеанса (например, когда клиент онлайн-банка производит денежный перевод, оплату услуг или иную транзакцию) веб-браузер отравляет на удаленный сервер (на котором размещен сайт банка) специальный запрос на наличие сертификата безопасности SSL.
• Если на сервере сертификат SSL для данного сайта банка установлен – сервер отправляет в браузер реквизиты сертификата (для подтверждения его действенности и подлинности) и публичный ключ.
• Браузер своими средствами проверяет подлинность и действительность (не истек ли строк действия сертификата) и, если сертификат не вызывает сомнений, генерируется одноразовый ключ текущего сеанса связи, шифруется при помощи публичного ключа, полученного от сервера, после чего информация пересылается на сервер.
• На сервере полученные данные расшифровываются, сервер убеждается в подлинности транзакции и только после этого между пользователем в браузере и сайтом на сервере устанавливается защищенное соединение по протоколу HTTPS.
• После этого клиент банка видит в поисковой адресной строке браузера уведомление о безопасном соединении HTTPS. Если кликнуть по значку замочка, откроется окно с реквизитами действующего сертификата SSL.

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

Все пользователи могли видеть уведомление при попытке зайти на какой-либо сайт – «Сертификат недействителен, установить соединение невозможно».

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

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

Далее разберемся, какие бывают сертификаты и где их взять.

Покупка и установка SSL-сертификата

Для работы SSL-протокола необходим SSL-сертификат, для этого нужно его купить и установить.

Какой SSL-сертификат выбрать

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

Переходим на страницу заказа SSL-сертификатов и выбираем нужный тип:

1.DV-сертификат (Domain Validated) — самый простой, подходит для физических лиц и юридических лиц, выдается на один домен одному владельцу. Сертификат защищает информацию, но не гарантирует, что владельцу можно доверять.

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

Визуально у сайта появится замочек в адресной строке.

Сайт с сертификатом безопасности

2. OV-сертификат (Organization Validation) — сертификат для коммерческих и некоммерческих организаций, юридических лиц. Для выдачи нужна проверка существования юрлица или ИП и проверка принадлежности домена.

Этот сертификат подходит порталам, магазинам, компаниям, предоставляющим услуги..

Визуально такая форма будет выглядеть как DV-сертификат.

Сайт с сертификатом безопасности

2.EV-сертификат (Extended Validation) — домен с расширенной проверкой, подходит только для юридических лиц. Потребуется проверка принадлежности домена и другие данные о юрлице: свидетельство о гос регистрации, зарегистрированное название и другие данные.

Этот сертификат обычно заказывают банки и крупные организации.

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

Сайт с сертификатом и дополнительной формой

Дополнительно сертификаты могут иметь опции: Wildcard, то есть поддержку поддоменов сайта, SAN — поддерживать несколько доменов на одном сервере, IDN (Internationalized Domain Names) — поддержку кириллических доменов.

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

После покупки нужно установить SSL на хостинг, если вы покупали сертификат у своего хостера, это будет чуть проще.

Сертификат обычно покупается как домен или хостинг: на год-два, а потом продлевается.

Как установить SSL-сертификат

После покупки у вас должен быть файл сертификата, файл ключа и два файла цепочки сертификатов.

1.Войдите в личный кабинет хостинга вашего сайта.

2.Найдите раздел SSL.

3. Загрузите эти файлы в соответствующие поля.

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

Загрузка сертификата на reg.ru

4. Проверьте, доступен ли сайт по по HTTP-протоколу и по HTTPS. Он должен быть доступен по обоим.

5. Проверьте корректность установки сертификата на сайте: страницы сайта корректно открываются по URL с учётом нового протокола, а конфигурация SSL корректно установлена. Проверить правильность конфигурации SSL-сертификата можно на сервисе
PR-CY: вставьте адрес сайта в строку и нажмите проверку. Если установка прошла корректно, появится примерно это:

Результаты проверки SSL

Проверить настройку также можно с помощью
Ssllabs, сервис проведет анализ конфигурации SSL. Вводите адрес сайта и нажимаете проверку, если все в порядке, появится такой результат:

Успешный результат проверки

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

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

SSL-сертификат установлен, но выдыхать рано – нужно провести еще некоторые манипуляции в коде сайта и его настройках.

HTTPS: что это такое и зачем нужно

— «протокол передачи гипертекста». В наше время повсеместно используется для получения информации с веб-сайтов. Все сайты сразу работают на HTTP. Когда пользователь вводит личную информацию на сайте, браузер в открытом виде передает ее на сервер. Этим и пользуются мошенники, перехватывая личные данные.

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

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

Сервер, прежде чем ответить на запрос от браузера, предъявляет ключ шифрования — SSL-сертификат, браузер проверяет его подлинность в Центре сертификации, и если все в порядке, то браузер и сервер «доверяют» друг другу и «договариваются» о разовом шифре для защиты передаваемых данных. Так происходит при каждой сессии.

Безопасность пользователей и регламент GDPR

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

Предупреждение о небезопасном соединении

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

Доверие к сайту

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

В адресной строке браузера, где указан URL сайта есть уведомление «Не защищено». Если на него нажать, то появиться окно с объяснениями, почему так.

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

После такого вряд ли многим захочется что-то у вас купить или на что-то подписаться.

SEO

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

Преимущества перехода на HTTPS с точки зрения SEO

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

1. Повышение позиций в выдаче.

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

2. Реферальные данные.

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

3. Безопасность и конфиденциальность.

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

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

Возможные проблемы при переходе на HTTPS

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

Обязательно сообщите Google о том, что вы перешли с HTTP на протокол HTTPS.

Google предлагает воспользоваться следующими рекомендациями при переходе на HTTPS:

• Выберите подходящий вам тип сертификата безопасности: одиночный, мультидоменный или wildcard-сертификат (сертификат-шаблон для защищенного источника с несколькими динамическими субдоменами).
• Используйте сертификаты с 2048-битными ключами.
• Используйте относительные URL-адреса для ресурсов, находящихся на одном защищенном домене.
• Используйте относительные URL без указания протокола для всех остальных доменов.
• Не закрывайте от индексации HTTPS-страницы в файле robots.txt.
• По возможности разрешайте поисковым роботам индексирование страниц. Старайтесь не использовать noindex в метатеге «robots».
• Google обновил Google Webmaster Tools для более удобной работы с сайтами, использующими протокол HTTPS.
• Внимательно отслеживайте переход сайта с HTTP на HTTPS в программах аналитики и в Google Webmaster Tools.

Приведем краткий список последовательности шагов, чтобы в общих чертах обрисовать процесс:

1. Создайте запрос на получение сертификата (CSR).
2. Выберите серверное ПО, используемое для генерации запроса CSR.
3. Выберите алгоритм хэширования.
4. Выберите срок действия сертификата.

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

С подробной инструкцией по переходу на HTTPS вы можете ознакомиться в нашей статья «HTTP vs HTTPS. Как перейти на HTTPS без последствий?».

Преимущество http/2 для разработчиков

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

• Доменное
  шардирование. Раньше в http/1.1
  число открытых соединений было ограничено. Но можно было установить большое количество
  соединений за счет загрузки файлов сразу с нескольких поддоменов, чтобы
  ускорить работу. Такой подход был особенно актуальным для сайтов, куда
  загружено множество изображений. Теперь благодаря HTTP/2 нет нужды прибегать к домен-шардингу,
  потому что протокол дает возможность запросить неограниченное количество ресурсов.
  Тем более, что с новым протоколом доменное шардирование не только не повысит производительность,
  но и нагрузит сервер лишними соединениями.
• Объединение
  скриптов Java и CSS. Процедура заключается в том, чтобы из множества
  маленьких файлов создать один большой. Это конечно уменьшает число запросов, но
  пользователь, посетив страницу, загрузит абсолютно все CSS и JS файлы, даже те, которые ему не
  понадобятся. Соответственно объединение файлов съедает память. Еще одна
  трудность – все элементы нуждаются в одновременной чистке из кэша, так как
  недопустимо, чтобы дата окончания срока действия каждого из них разнилась. Если
  поменять даже одну строку в CSS,
  срок действия закончится у всех элементов одновременно. HTTP/2 позволяет не прибегать к объединению
  файлов, потому что он не затрачивает много ресурсов.
• Объединение
  картинок (спрайты). Тоже снижает количество запросов, но так как вес изображения
  увеличится, загружаться он будет дольше. Более того, для показа хотя бы одной
  картинки нужно загрузить весь спрайт. Вывод – применение спрайтов чревато занятием
  больших объемов памяти.
• Доменные
  имена без cookie. Подразумевает загрузку
  изображений, JS и CSS файлов с другого домена, где нет данных cookie.
• Перенос JavaScript, CSS, картинок в HTML-файл. Аналогично уменьшает количество соединений, но
  страница не отобразится до полной загрузки всего файла.

Как подключить http/2

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

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

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

Для подключения HTTP/2 нет необходимости вносить какие-либо изменения непосредственно на ресурсе. URL страниц, ссылки, разметки, данные для Яндекс.Вебмастера и Google Search Console – все остается без изменений.

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

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

Nginx

Протокол поддерживается в версиях сервера от 1.9.5 и новее, так что обязательно обновите устаревший Nginx. Далее запустите файл, расположенный по пути /etc/nginx/nginx.conf. Найдите секцию Сервер со строкой:

Поменяйте ее на

Сохраните изменения и перезапустите сервер при помощи
команды:

Apache

Для подключения протокола http/2 вам понадобится версия сервера от 2.4.17 и новее. Если у вас устаревшая версия Apache, обновите его и подключите mod http2.

Затем откройте файл apache.conf и добавьте в него следующие команды:

Далее остается лишь перезапустить сервер. Все готово.

Если вы хотите проверить, поддерживается ли HTTP/2, скачайте специальное расширение для Chrome или Firefox. Можно воспользоваться и сервисом проверки скорости Айри. Если протокол поддерживается, в результатах проверки отобразится соответствующая зелена надпись.

Распространенные проблемы при использовании HTTPS

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

Период действия сертификата:

1. Невозможность просканировать или проиндексировать сайт. Проверьте, нет ли метатега noindex. Также запрет индексации сайта может быть прописан в файле robots.txt с помощью команды Disallow.
2. Смешанное содержимое. На проекте с HTTPS должны отсутствовать страницы, доступные по стандартному протоколу HTTP, даже простые картинки. Наличие HTTP-контента делает сайт уязвимым.

Некорректное указание названия ресурса в сертификате. При получении сертификата должны учитываться все варианты написания домена, как с префиксом «www», так и без него.

Различное содержание на страницах с безопасным и обычным протоколом. Контент сайта с протоколом HTTPS должен полностью совпадать с содержимым соответствующих HTTP-страниц.

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