Здравствуйте, гость ( Вход | Регистрация )




 
Ответить в эту темуОткрыть новую тему
> Перевод сайта на HTTPS, Полезная информация
aprika
сообщение 21.11.2016, 10:11
Сообщение #1


Админша
*******

Группа: Администратор
Сообщений: 14 026
Регистрация: 20.9.2006
Пользователь №: 1
Спасибо сказали: 321 раз(а)
Фуу сказали: 7 раз(а)




Репутация:   21  


Какой SSL сертификат выбрать для своего сайта

При переходе на HTTPS сперва необходимо выбрать и купить подходящий SSL-сертификат. Хостинг-провайдеры предлагают большое множество сертификатов, начиная примерно от $10 до $1000 в год. И с первого раза неясно, чем они отличаются и какой из этих SSL-сертификатов подойдет именно для вашего сайта и нужно ли на разные сайты и поддомены покупать отдельные сертификаты? Ниже вы найдете неколько советов, как выбрать подходящий SSL-сертификат.

Прикрепленное изображение

Особенности сайта

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

1. Кириллический домен (доменная зона) или обычный на латинице?

Не все сертификаты поддерживают кириллические домены. Здесь вам нужны те, которые имеют пометку “Поддержка IDN” (Internationalized Domain Names). Обычно это сертификаты от GlobalSign, Comodo и Symantec. IDN SSL сертификаты дороже обычных.

2. Куча поддоменов

Сейчас при покупке SSL-сертификата на основной домен большинство центров сертификации также выписывает их на поддомен www. Однако, это стоит уточнить перед покупкой, чтобы потом не покупать отдельно для www-поддомена. Если у сайта имеется множество других поддоменов, то нужно брать Wildcard-сертификат. Бесплатные версии сертификатов не поддерживают wildcard. А если вместе с поддоменами у вас еще кириллический домен, то подойдут только сертификаты от Comodo.

3. Много сайтов или зеркал

Некоторые проекты разделены на несколько сайтов, например, каждый для своей страны или для своего бренда. Либо вы просто хотите для всех своих проектов купить один сертификат. В таком случае необходимо искать мультидоменные версии, они помечаются как SAN сертификаты (Subject Alternative Names) или Multi-Domain. Перед покупкой SSL-сертификата уточните у продавца, поддерживает ли он мульти-доменные проекты.

4. Обычный сайт с одним доменом с латинским названием

Здесь подойдет любой сертификат. В том числе бесплатные версии. Однако, обратите также внимание на возможности сертификатов, перечисленные ниже.

Возможности SSL-сертификатов

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

1. Проверка домена

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

2. Проверка организации

Такой тип сертификата (OV – organization validation) уже содержит название организации и частное лицо его получить не может. Срок выдачи варьируется от 3 до 10 дней. Здесь центр сертификации проверяет, реально ли существует такая организация и принадлежит ли ей домен.

3. Расширенная проверка организации

EV – сертификаты (extended validation) одни из дорогих, и их сложно получить, так как происходит многоуровневая проверка. Помимо того, что домен принадлежит организации здесь еще тщательно проверяется сама организация (правовая, физическая и операционная деятельность субъекта, имеются официальные документы, компания имеет исключительное право на использование домена). Зеленая полоска с в браузере с названием организации как раз свидетельствует, что организация прошла расширенную проверку.

Обращайте внимание на срок действия SSL-сертификатов. Обычно они выпускаются минимум на год, но например LetsEncrypt только на 90 дней.

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

Заключительные советы

Если у вас самый простой сайт, вы можете себе приобрести бесплатные сертификаты, например, StartSSL или LetsEncrypt (последний подойдет если у вас свой сервер). При необходимости в будущем сменить сертификат, вы сможете это сделать в любое время. В остальных случаях ищите подходящие для себя версии. Не важно, у кого именно вы приобретете сам сертификат, хостер вам его установит, единственное что может потребоваться это выделенный IP адрес. Часто сами хостеры предлагают купить у них (как у реселлеров центров сертификации) разные нормальные версии сертификатов, вы можете смело с ними консультироваться.

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

Yandex.ru — SAN Wildcard OV SSL сертификат от GlobalSign
Google.com — собственные OV сертификаты
Wildberries.ru — SGC (максимальной защищенности) OV SSL Wildcard сертификат от Comodo
Ostrovok.ru — PositiveSSL Wildcard сертификат от Comodo
Tinkoff.ru — Thawte EV SSL сертификат
Privatbank.ua — обычный RapidSSL от GeoTrust на один домен
Moz.com — CloudSSL SAN сертификат от GlobalSign
Twitter.com — EV-сертификат от DigiCert
Devaka.ru — самый простой AlphaSSL от GlobalSign


Devaka.ru - блог Сергея Кокшарова


--------------------
Пользователь в офлайнеКарточка пользователяОтправить личное сообщение
Вернуться в начало страницы
+Цитировать в форуму быстрого ответаОтветить с цитированием данного сообщения
aprika
сообщение 22.11.2016, 7:58
Сообщение #2


Админша
*******

Группа: Администратор
Сообщений: 14 026
Регистрация: 20.9.2006
Пользователь №: 1
Спасибо сказали: 321 раз(а)
Фуу сказали: 7 раз(а)




Репутация:   21  


Какие SSL-сертификаты используют сайты из ТОП-500 Alexa

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

Как проводились наблюдения:

1. Взяты сайты из ТОП-500 Alexa.

Это 500 наиболее трафиковых сайтов мира по данным тулбаров Alexa.

2. Для каждого сайта произведена проверка сертификата
Настроен ли для сайта SSL-сертификат и если да, то самоподписанный или же от какого-то известного центра сертификации.

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

Статистика по популярным сайтам

Из 500 популярных сайтов около 70% имеют настроенные сертификаты (при этом, не обязательно используют HTTPS, но большинство использует по данным ручной проверки, здесь требуется отдельная проверка). В ТОП10 только live.com не использует HTTPS (если обращаться к нему напрямую), однако его поддомены все на защищенном протоколе.

Прикрепленное изображение

Те, кто использует сертификаты из нашего списка, преимущественно платные. Бесплатный от Let’s Encrypt только у домена wp.com, хотя сам WordPress везде у себя использует сертификаты GoDaddy.

Прикрепленное изображение

Среди популярных центров сертификации — Comodo, Symantec, DigiCert, GlobalSign. Распределение получилось следующим:

Прикрепленное изображение

Что интересно, Comodo используют просто популярные проекты, чаще частные, и среди них много порнушных (может из-за того, что PositiveSSL одни из самых дешевых сертификатов).

Прикрепленное изображение

Более серьезные компании, типа средних поисковиков, маркетплейсов, и разных мировых брендов используют сертификаты от Symantec.

Прикрепленное изображение

Различные социальные сети и сервисы чаще используют сертификаты от DigiCert.

Прикрепленное изображение

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

Прикрепленное изображение

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

Devaka.ru - Блог Сергея Кокшарова


--------------------
Пользователь в офлайнеКарточка пользователяОтправить личное сообщение
Вернуться в начало страницы
+Цитировать в форуму быстрого ответаОтветить с цитированием данного сообщения
aprika
сообщение 23.11.2016, 7:06
Сообщение #3


Админша
*******

Группа: Администратор
Сообщений: 14 026
Регистрация: 20.9.2006
Пользователь №: 1
Спасибо сказали: 321 раз(а)
Фуу сказали: 7 раз(а)




Репутация:   21  


Как перенести сайт на HTTPs. Пошаговая инструкция

Многие серьезные проекты использовали HTTPS ещё в 2000х, часть перешли на защищенный протокол в 2010-2011, когда был большой бум из-за утилит иранского хаккера Марлинспайка Firesheep и SSLStrip, позволяющих воровать персональные данные с незащищенных сайтов. Совсем недавно правительство США поручило всем федеральным сайтам перейти в срочном порядке на HTTPS до конца 2016 года. И уже совсем скоро Mozilla Firefox перестанет поддерживать небезопасные HTTP-соединения в браузере. В связи с этим, предвидится новый бум и массовый переход на HTTPS. Рано или поздно вам тоже придется с этим столкнуться.

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

Как же перенести свой сайт на HTTPs? Ниже представлена пошаговая инструкция.

1. Подготовка сайта

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

— Смена ссылок внутренней перелинковки с абсолютных на относительные.

Относительные ссылки бывают двух типов:

1. Относительные вне зависимости от домена
Код
https://devaka.ru/about/ — абсолютная.
/about/ — относительная.


2. Относительные вне зависимости от протокола.
Код
https://devaka.ru/about/ — абсолютная
//devaka.ru/about/ — относительная


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

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

— Исправление вложений медиа-контента

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

Если используемые вами картинки хранятся на вашем сайте, то просто используйте относительные адреса //site.ru/img/mega-image.jpg. Если вы подгружаете картинки с внешних ресурсов (CDN или других сайтов), то они также должны поддерживать HTTPS, иначе стоит отказаться от этих вложений.

Популярные сервисы, которые позволяют внедрять свой контент, типа YouTube, SlideShare, виджеты VK или Facebook, и другие, уже давно поддерживают HTTPS, поэтому с ними проблем не возникнет. Но если вы используете медиа-контент с непопулярных сервисов, то уточните, будет ли этот контент работать/отображаться, если вы смените протокол.

— Исправление подключений внешних скриптов

Во внешних скриптах также нужно использовать относительные URL. Например, для библиотеки jQuery, вместо кода:

Код
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.11.3/jquery.min.js"></script>


Нужно использовать:

Код
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.11.3/jquery.min.js"></script>


Также и с другими скриптами: Яндекс.Метрика, LiveInternet, Google Analytics, Яндекс.Директ, различные javascript библиотеки и др. Здесь принцип тот же: популярные сервисы и библиотеки поддержкивают HTTPS, а вот с непопулярными могут возникнуть проблемы (как например, у ПриватБанка или Корреспондента с сетью MediaTraffic, которые до сих пор её использует по небезопасному соединению).

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

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

После того, как вы сделали все внутренние и внешние ссылки относительными, проверили доступность медиа-контента и скриптов по протоколу HTTPS, можно заняться установкой и настройкой SSL-сертификата.

— Выбор и приобретение подходящего SSL-сертификата


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

1. Обычные сертификаты подходят физическим и юридическим лицам, выдаются на один домен и их выпуск занимает несколько минут. Здесь происходит лишь проверка принадлежности домена тому, кто запрашивает сертификат.

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

3. Wildcard. Сертификаты, которые выдаются на все поддомены одного домена. Если у вас много региональных или других поддоменов, то обязательно нужно брать wildcard-сертификат.

4. С поддержкой IDN. Не все сертификаты поддерживаются для кириллических доменов. Если у вас кириллический домен, то нужно искать сертификаты с поддержкой IDN. Подробнее о видах сертификатов можно ознакомиться в http://habrahabr.ru/company/tuthost/blog/150433/]этой статье[/url].

— Установка сертификата на сервере

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

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

— Проверка доступности сайта через HTTPS-протокол

Установив ssl-сертификат, убедитесь, что теперь сайт доступен по двум адресам, с http:// и https://. Если по какому-то адресу он оказался недоступным, то нужно срочно искать причину и решать эту проблему.

3. Настройка сайта

После успешной настройки сертификата на сервере можно заняться настройкой сайта. Здесь тоже придется попотеть.

— Настройка директивы Host в файле robots.txt

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

Яндекс требует для новой версии сайта указать директиву Host в файле robots.txt, где явно прописать используемый протокол. Например, в моем robots это выглядит так:

Код
Host: https://devaka.ru


Теперь Яндекс будет знать, что среди всех зеркал, указанное вами с протоколом HTTPS – самое главное.

— Установка 301 редиректа с http на https

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

Код
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^(.*)$ https://site.ru/$1 [R=301,L]


Если этот код не сработает, то обратитесь в техподдержку хостинга за консультацией.

— Исправление найденных ошибок

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

4. Сообщение поисковикам о переносе

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

— Добавление https-версии сайта в панель для вебмастеров

И в Google и в Яндексе необходимо добавить и подтвердить новый сайт, указав версию https. Теперь у вас в списке сайтов будет и та и другая версии. Для Google дополнительных настроек больше делать не надо, достаточно присутствия 301 редиректов.

— Изменение адреса в панели для Яндекса

Для Яндекса необходимо у HTTP-сайта указать главное зеркало HTTPS. Делается это в панели для вебмастеров в меню “Настройка индексирования” — “Главное зеркало” — “Установить протокол HTTPS”.

— Перенос дополнительных настроек в панели для вебмастеров со старого хоста на новый

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

– Настройки региона (геотаргетинг)
– Файлы Sitemap.xml
– Список ссылок в Disawov Tool для Google
– Исключенные параметры URL для Google

5. Ожидание переиндексации

На этом все, ваш сайт и ваши пользователи защищены. Google и Яндекс со временем поменяют адрес вашего сайта в поиске.

Сергей Кокшаров (Devaka.ru)


--------------------
Пользователь в офлайнеКарточка пользователяОтправить личное сообщение
Вернуться в начало страницы
+Цитировать в форуму быстрого ответаОтветить с цитированием данного сообщения
aprika
сообщение 29.11.2016, 13:27
Сообщение #4


Админша
*******

Группа: Администратор
Сообщений: 14 026
Регистрация: 20.9.2006
Пользователь №: 1
Спасибо сказали: 321 раз(а)
Фуу сказали: 7 раз(а)




Репутация:   21  


Почему HTTPs портит отношения с рекламодателями и как это решить

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

1. Количество лайков и твитов

Пользователи интернета, те кто активно читает тематические статьи и общается на разных контентных площадках, привыкли измерять ценность материала по количеству лайков/твитов/репостов. Особенно если статья уже старая, по ней должна накопиться какая-то информация (обратная связь от пользователей). И если мы видим, что у этой статьи 0 твитов или 0 лайков, а площадка достаточно популярна, то это минимум вызовет смятение и максимум может негативно сказаться на репутации площадки.

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

Теперь представьте, что после перехода на HTTPs все ваши лайки старых статей обнуляются, так как фактически меняется URL страницы.

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

Например, хорошая статья про “100 уроков, которые я извлек за 10 лет работы в SEO“, опубликованная еще в 2012 году и получившая большой отклик читателей.

Прикрепленное изображение

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

Для порталов без своей статистики расшариваний проблема не решается. По крайней мере до тех пор, пока все социальные сети будут игнорировать протокол при подсчете цифровых значений. Максимум, что здесь можно сделать – предоставить как можно больше данных (обратной связи от читателей).

2. Обнуление тИЦ

При переходе на HTTPs будьте готовы, что тИЦ вашего сайта станет нулевым. Конечно, через время он вернется – как только переклеятся зеркала и произойдет очередной апдейт, но в течение месяца-двух лучше кнопочки убрать со своего сайта, иначе у некоторых вебмастеров будет формироваться неверное мнение о ресурсе. Кто-то из моих читателей подумал, что на блог наложили АГС-фильтр и писали мне в личку. Кто-то не писал, но наверное посмеялся smile.gif Если здесь не уделить внимание корректной склейке зеркал, то нулевой тИЦ у сайта может сохраняться длительное время и отпугивать вебмастеров и некоторых рекламодателей.

3. Отсутствие реферера

Браузеры устроены так, что если пользователи переходят по ссылкам с защищенных https-версий сайтов на незащищенные http, то реферер (информация, откуда именно они перешли) по-умолчанию не передается. Именно поэтому потерялась часть статистики, когда поисковые системы и социальные сети стали использовать HTTPs.

К примеру, статистика реферального трафика (источник devaka.ru) одного из сайтов, на который стоит ссылка с этого блога:

Прикрепленное изображение

На блоге я практикую публикацию пресс-релизов. Обычно они показывают хорошее качество, так как информация соответствует интересам аудитории. Однако, после перехода на HTTPs один из рекламодателей мне написал, что получил целых 0 переходов. Здесь мы вовремя сообразили посмотреть в статистику директ-трафика (прямых заходов) и быстро добавить utm-метки. Прямые заходы, действительно, показывали резкий скачок. То есть, весь реферальный трафик ушел в директ-трафик из-за отсутствия реферера. Если бы мы вовремя не сообразили, то это могло бы испортить репутацию площадки для рекламодателя. Та же самая история была и с баннерами, люди просто не видели переходов.

Если у вас контентный проект и вы планируете перейти на защищенный HTTPs протокол, то рекомендую для всех партнерских ссылок использовать UTM-метки, а также добавить meta-тег referrer, который для большинства браузеров создаст правило работы с реферером.

Прикрепленное изображение

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

Сергей Кокшаров (Devaka.ru)


--------------------
Пользователь в офлайнеКарточка пользователяОтправить личное сообщение
Вернуться в начало страницы
+Цитировать в форуму быстрого ответаОтветить с цитированием данного сообщения
Поделиться с друзьями в соцсетях



Ответить в эту темуОткрыть новую тему
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0

 


 
Текстовая версия Сейчас: 19.6.2019, 15:12