Переезд на https

Перед тем как приступить к разбору темы – маленькое отступление: в январе 2017 года 1PS.RU перешел на безопасный протокол https (и вам советует). Также предлагаем и вам помощь в переезде на безопасный протокол. Зачем? Как это сделать? И какой период лучше всего выбрать? Вот об этом сейчас и расскажем.

В статье пойдет речь о переезде сайтов на безопасный протокол HyperText Transfer Protocol Secure (https). Тема на сегодняшний день считается «заезженной» и рассмотрена на многих ресурсах, но от этого она не становится менее актуальной. Читатели нашего блога и постоянные клиенты часто интересуются – как переехать на https? Зачем мне переходить на https? Нужен ли https для моего сайта? Чтобы ответить на все вопросы разом и помочь тем, кто все еще не разобрался в вопросе, мы и написали эту статью.

Для начала давайте разберемся, что такое https? HyperText Transfer Protocol Secure – это безопасный расширенный протокол http с ключом шифрования для передачи данных или гипертекста (термин «гипертекст» был введен в 1965 американский социологом, философом и первооткрывателем в области информационных технологий Нельсоном, Теодором Холмом), примером гипертекста являются веб-страницы – документы HTML.

HTTPS не является отдельным протоколом. Это обычный HTTP, работающий через шифрованные механизмы SSL и TLS.


Что такое SSL и TLS

SSL – (secure sockets layer – уровень защищённых сокетов) – набор правил с более безопасной связью, регламентирующих применение шифровальных (криптографических) преобразований и алгоритмов в информационных процессах.

TLS – (Transport Layer Security – безопасность транспортного уровня) – протокол, основанный на спецификации протокола SSL версии 3.0. Хотя имена SSL и TLS взаимозаменяемы, они всё-таки отличаются, так как каждое описывает другую версию протокола.

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

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

SSL сертификат – уникальная цифровая подпись вашего сайта, основанная на двух типах криптографических ключей – приват и паблик.

Публичный ключ не является секретным и он присутствует в запросе.


Приватный ключ располагается на вашем сервере и должен быть известен только вам.

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

В частности, время действия сертификата очень важно. Браузеры не будут считать ключ валидным, если время действия ключа еще не наступило или (что случается чаще) уже закончилось.

Более подробную информацию об уже установленном на сайте сертификате вы можете посмотреть с помощью специальных сервисов, таких как:

https://www.ssllabs.com/ssltest/index.html – он передоставит расширенную техническую информацию о сертификате.

https://cryptoreport.websecurity.symantec.com/checker/views/certCheck.jsp – проверит, насколько верно установлен сертификат.

Типы SSL сертификатов по валидации

Что такое SSL сертификат и зачем он нужен вроде разобрались ).

Теперь давайте разберем их типы по валидации:

  1. Самоподписанный сертификат. Оговорюсь сразу, данный вид сертификата НЕ подойдет 99% пользователям. Плюс у данного сертификата один – цена (он совершенно бесплатен). Самый весомый минус – при переходе на ваш сайт из поисковой системы или по любому другому заходу пользователю будут показаны вот такие сообщения:

    • В Chrome:

      предупреждение при бесплатном сертификате в Chrome


    • В Яндекс браузере:

      предупреждение при бесплатном сертификате в Яндекс браузере

    • В Opera:

      предупреждение при бесплатном сертификате в Opera

    • В Mozilla Firefox:

      предупреждение при бесплатном сертификате в Mozilla Firefox

    • Вид в адресной строке:

      Переезд на https

    Цена: 0 руб.

  2. Валидация по домену (Domain Validated) – SSL-сертификат, при оформлении которого производится только проверка доменного имени. Также данные сертификаты называют сертификатами начального уровня доверия. Подойдут практически 90% владельцев сайтов. Являются самыми распространенными. Подходят как физическим, так и юридическим лицам. Выдача данного сертификата, как правило, производится в течение суток.

    Вид в адресной строке:

    Переезд на https

    Цена: может колебаться от 800 руб./год до 3000 руб./год (хотя эта цифра не предел).


  3. Валидация организации (Organization Validation) – сертификат с повышенной надежностью. При выдаче сертификата производится проверка компании, проверяется не только право владения доменом и принадлежность веб-сайта организации, но и существование компании как таковой. Доступен только юридическим лицам. При выдаче данного сертификата могут быть запрошены следующие документы: свидетельство ИНН/КПП, свидетельство ОГРН, свидетельство о регистрации доменного имени, и.т.д.

    Вид в адресной строке:

    Переезд на https

    Цена: может колебаться от 2000 руб./год до 35000 руб./год.

  4. Расширенная валидация (Extended Validation) – сертификат с самым высоким уровнем аутентификации между всеми типами SSL сертификатов. Не подойдет 99% «смертных» из-за своей цены и способа проверки. Предназначен для крупных корпораций. Доступен только юридическим лицам. Зеленая адресная строка браузера отображает название компании и обеспечивает визуальное подтверждение безопасности вашего сайта.

    Вид в адресной строке:

    Переезд на https

    Цена: может колебаться от 12000 руб./год до 150000 руб./год.

  5. Еще существует отдельный вид сертификатов, о котором нельзя не сказать – это сертификаты Wildcard. Данный вид сертификата стоит выбрать, если у вас структура сайта представлена в виде поддоменов. Или требуется защита передаваемой информации на субдоменах. На некоторых хостингах данный вид представлен в виде опции.


    Цена: может колебаться от 1500 руб./год до 35000 руб./год.

    Также для реализации https соединения на некоторых хостингах требуется оплата выделенного IP, цена которого может быть равна
    1200 руб./год.

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

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

Для чего нужно переходить на https?

Причин несколько и все весомые:

  • Протокол https обеспечивает безопасность передаваемой информации.
  • С 2014 года наличие https соединения на сайте для поисковой системы Google является фактором ранжирования со знаком плюс. 
  • C начала 2017 года браузер Google Chrome версии 56 начнет помечать все HTTP-сайты, которые передают личные данные пользователей, как «небезопасные».

    браузер Google Chrome версии 56

  • Если вы владелец сайта, содержащего видео контент, то следующая информация для вас:

    Изменения в сервисе яндекс видео


Подходим к завершающей части и ответу на вопрос – как корректно переехать на https с минимальными потерями.

Инструкция по переезду на https

  1. Выбираем сезон, в котором посещение вашего сайта минимально (если ваш сайт не связан с тематикой «всё для праздника», то, возможно, лучшее время для вас – новогодние праздники, когда покупательская активность в Сети снижается). Проверить сезонность можно с помощью систем аналитики Google Analytics или Яндекс.Метрика.
  2. Выбираем подходящий нам SSL сертификат.
  3. Устанавливаем сертификат на хостинг, используя панель управления, доступ ssh или помощь администратора хостинга, при этом никаких редиректов с http не настраиваем.
  4. Открываем файл robots.txt и прописываем директиву host с протоколом https

    User-agent: Yandex

    Host: https://site.ru

  5. Далее переходим в Яндекс.Вебмастер с подтвержденными правами на сайт. Если такого нет, то подтверждаем права (следуя инструкции сервиса).
  6. Далее переходим в раздел Настройка индексирования – Переезд сайта. И выставляем чекбокс (галочку) напротив «Добавить HTTPS», после этого нажимаем «Сохранить».

    переезд сайта яндекс вебмастер


  7. После этого ждем пока изменения вступят в силу. Как правило, этот срок составляет 2 недели.
  8. Настраиваем 301 редирект со страниц http на https, при этом избегайте цепочек переадресации.
  9. Меняем все ссылки, имеющиеся в коде сайта, на https или делаем их относительными.
  10. Смотрим, чтобы в карте сайта .xml присутствовал только протокол https.
  11. Добавляем карту в Вебмастер.Яндекса.
  12. Добавляем все версии сайта в Google Search Console.
  13. Переходим в настройки сайта и выбираем Основной домен (если этого не было сделано раньше).

    настройки сайта в google webmaster

    выбор домена в google webmaster

  14. Переносим все настройки (если такие имелись) с версии сайта http на https.
  15. Инструмент изменения адресов не используем.

    Инструмент изменения адресов google webmaste

  16. Сразу после переноса сайта попробуйте обновить все входящие ссылки, в том числе: Внешние ссылки, Ссылки на профили, например в Google+, Facebook, Twitter, Vk и т.д.

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

1ps.ru

Общие вопросы


Нужно ли переходить на HTTPS?

Да, на HTTPS нужно переходить. И не важно, коммерческий у вас сайт или чисто информационный. И не важно, что говорит Яндекс [1], все свои сервисы они перевели на HTTPS. Причины описаны в следующем пункте.

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

  • Фактор ранжирования в Google
  • Пометка “Надежный” в Google Chrome и поддержка современными браузерами
  • Безопасность при работе с админкой (ваша и ваших редакторов)
  • Лучшие поведенческие факторы на мобильных устройствах при использовании публичных Wi-Fi
  • Использование протокола HTTP2 для ускоренной загрузки страниц
  • Использование “Service Worker” для рассылки Push-уведомлений

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

Когда нужно переходить?

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


Улучшится ли ранжирование?

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

Сколько я потеряю трафика, если будет проседание?

Если у вас будет проседание трафика, то в Google оно обычно длятся не больше 2х недель, в Яндексе склейка зеркал может затянутся на 1-2 месяца. При этом, теряется примерно до 20% трафика. Сложно предусмотреть всё сразу, даже если вы работаете по готовому чеклисту. Именно поэтому, лучше переезд делать не в сезон.

Лучше сайт сразу запускать на HTTPS или сначала на HTTP?

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

Меняю домен, нужно сразу переходить на https?

Смена домена это одна смена зеркал, смена протокола это другая. Поисковикам нужно время, чтобы обработать изменения. Я сторонник того, чтобы все изменения делать одним махом, но при этом зеркальщик будет дольше склеивать сайты. Был пример, когда владелец большого сайта сменил доменную зону, перешел на HTTPS и одновременно сменил CMS (поменялась структура адресов страниц), склейка в Google у него длилась больше 2х месяцев, было проседание по трафику и одновременное присутствие нескольких зеркал в индексе. Но сложно сказать, сколько бы заняла склейка, если бы мы разбили процесс на 2-3 этапа. При больших изменениях вам просто понадобится больше времени.

Решение проблем


Что делать, если сильно просел трафик после переезда?

Проверьте сперва следующие пункты:

  • Статус склейки зеркал в вашей поисковой системе, присутствует ли HTTP версия до сих пор в индексе и на какую версию идет трафик.
  • Доступность сайта по протоколам HTTP/HTTPS. Правильно ли организована доступность (например, до склейки в Яндексе сайт должен быть доступен по обеим протоколам).
  • Не закрыли ли вы сайт для индексации в robots.txt (были такие случаи).

Причин просадки трафика может быть много, и в некоторых случаях они могут быть даже не связаны с HTTPS. Напишите в техподдержку Яндекса (если продвигаете под Рунет), возможно они подскажут вам проблему. Если вы уверены, что все настроено правильно, открыто к индексации и прочее, то просто не паникуйте раньше, чем через 2 недели. В противном случае необходимо привлекать экспертов для анализа проблем.

Тиц обнулился, это нормально?

Это нормально, он вернется в течение месяца.

Почему крупные сайты делают наоборот, редирект с HTTPS на HTTP?

Некоторые крупные сайты приобрели SSL-сертификат, уже настроили его на сервере, но не торопятся переходить на HTTPS из-за возможных рисков или ждут, пока будет “не сезон”. А так как Google по-умолчанию индексирует HTTPS-версию (в случае её наличия и работы), то вебмастера настраивают редирект с HTTPS на HTTP для избежания проблем.

Что нужно учесть при переезде?

Используйте готовые чеклисты по переезду на HTTPS [4], там уже многое расписано. Главный алгоритм:

  • Подготавливаете сайт.
  • Приобретаете и настраиваете сертификат.
  • Настраиваете сайт и делаете всё для склейки зеркал.
  • Ожидаете.
  • Исправляете ошибки и снова ожидаете.

Вопросы по сертификатам

Где лучше купить сертификат?

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

Можно ли использовать бесплатный сертификат?

Да, можно использовать бесплатный. Но только Let’s Encrypt, с остальными бесплатными SSL-сертификатами у вас могут возникать проблемы. Кстати, некоторые хостинги предлагают бесплатные сертификаты. В этом случае необходимо узнать, они бесплатные навсегда (например, ukraine.com.ua имеет возможность настройки Let’s Encrypt) или же это акция и вам предоставляют платный сертификат бесплатно на первый год.

Нормально ли использовать сертификат от CloudFlare?

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

Какой сертификат подойдет, если у сайта ОЧЕНЬ много поддоменов?

Ознакомьтесь с лимитами Let’s Encrypt, вы можете там выпускать сертификаты до 2000 поддоменов в неделю. Если у вас их ещё больше, возьмите Wildcard-сертификат от Comodo (как вариант). Если у вас поддомены 2-3 уровня, то вам нужно разбивать структуру на блоки и брать wildcard-сертификаты на каждый уровень. Проконсультируйтесь со специалистами в случае особенностей разветвленной поддоменной структуры сайта.

Нужен ли выделенный IP

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

Склейка зеркал

Надо ли добавлять HTTPS сайт в панель для вебмастеров?

Да, нужно добавить сайт с https-версией протокола в панель для вебмастеров Яндекса и Гугла.

Нужно ли удалять неглавное зеркало после склейки?

Лучше не удалять. Например, в Яндексе статистика по старым ссылкам будет отображаться для HTTP-сайта и не будет видна в HTTPS-версии. В Google вы также можете потерять старую статистику.

Нужно ли редирект настраивать сразу?

Да, после настройки HTTPS нужно сразу настраивать постраничный 301 редирект с HTTP-версии.

Редирект настраивать после того, как HTTP версия полностью уйдет из поиска Яндекса?

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

Когда нужно убирать редирект?

Редирект убирать не нужно.

Должен ли robots.txt быть доступен по двум протоколам?

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

RewriteCond %{REQUEST_URI} !^/robots.txt$

Сколько ждать склейки?

Около 2х недель в Google и около месяца в Яндексе, иногда склейка может происходить до 2х месяцев.

Как узнать, что переезд закончился?

В панели Яндекса вы увидите, что сайты образуют одну группу зеркал и главным выбрана ваша https-версия. Также, http-версия сайта уйдет из индекса (и в Яндексе и в Google), и останется только https.

Внешние сервисы и ссылки

Надо ли менять внешние ссылки, они ссылались на HTTP

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

Нужно ли менять внутренние ссылки

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

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

Нужно ли еще что-то менять?

Убедитесь, что вы учли все пункты из чеклиста по переходу на HTTPS [4]. Также настройте мета-тег referer, чтобы на вас не обижались рекламодатели.

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

Полезным будет доступность robots.txt и sitemap.xml по двум протоколам. В sitemap.xml указывайте адреса страниц с тем протоколом, на какой версии сайта лежит эта карта. Тег rel=canonical аналогичен редиректу, его лучше использовать после полной склейки зеркал.

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

Если у вас на сервере/хостинге остались еще какие-то сайты, которые вы не переводили на HTTPS (но при этом один уже перевели), просто лишний раз убедитесь, что будет, если их запросить по https-протоколу.

Нужно ли менять код счетчика?

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

devaka.ru

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

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

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

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

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

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

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

http://cccp-blog.com/wp-includes/images/banners/templatemonster/banner_content.jpg

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

Обмен с 1С

1С (УТ/УПП) использует настройки параметров обмена для соединения с сайтом. В них указывается адрес сайта. Если настройки неверны то можно увидеть похожее сообщение “Не удалось установить соединение с сервером. Авторизация пользователя не выполнена”.

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

1С:Управление торговлей, ред. 11.1.

1С:Управление торговлей, ред. 11.1.

В старых версиях модуля обмена не предусмотрено соединение по https. Совсем. Поэтому либо потребуются доработка на стороне 1С, либо нужно оставить скрипт импорта доступным по HTTP.

Пример такого исключения (для вставки в .htaccess):

RewriteCond %{SERVER_PORT} !^443$ 

RewriteCond %{REQUEST_URI} !^/bitrix/admin/1c_exchange.php

RewriteRule ^ https:// ваш-сайт%{REQUEST_URI} [R=301,L]

Сервисы использующие API

Как правило, сайты (особенно интернет-магазины) интегрированы со множеством сторонних сервисов:

  • платежные системы (Яндекс.Касса, IntellectMoney,  Web Money),

  • службы доставки (СДЭК, ПЭК, DHL),

  • счетчики посещений (Google Analytics, Яндекс.Метрика),

  • соц-сети и пр.

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

Переезд на https

Переезд на https

Переезд на https

Ссылки на сторонние ресурсы

После переезда на https мы ожидаем, что браузер покажет — наш сайт безопасен:

Переезд на https

Однако, вопреки ожиданиям мы можем увидеть это:

Переезд на https

Такое сообщение свидетельствует о подключении на странице ресурсов (изображений, стилей, скриптов, шрифтов и.т.д) не по https, а по http. В чем именно проблема браузер может указать в режиме разработчика в консоли:

pasted image 0 (19).png

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

Переезд на https

Одна из возможных неприятностей, которая может настигнуть — невозможность пользователю оплатить заказ прямо на сайте. Некоторые платежные системы подключаются на страницу с помощью  javascript. Если скрипт подключен неверно (по http) — браузер запретит переходить на страницу оплаты.

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

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

Переезд на https

Доступность сторонних ресурсов по https

Если сторонний ресурс (например CDN) доступен по http, вовсе не обязательно, что он будет доступен и по защищенному протоколу:

Переезд на https

Поэтому прежде чем кинуться бездумно заменять все ссылки на “https” нужно убедиться, что ресурс действительно доступен. Для шрифтов, стилей, изображений, видео проверить это легко — в адресной строке браузера указываем ссылку на ресурс с ‘https’ и если он появился, то проблем нет. В остальных случаях лучше изучить документацию.

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

Ссылки на внутренние ресурсы

Хотя указывать абсолютные пути на внутренние ресурсы — дурной тон, такое все же встречается. Поэтому также как и в предыдущем пункте — находим все ссылки с http:// и заменяем на https://. А вообще, чтобы не было проблем с переходом, нужно сразу ссылки ставить как “//”.

Например: <img src=»//www. intervolga. ru/favicon.ico»>

В таком случае будет использоваться такой же протокол как у текущего url-а.

Приложения использующие API

У вас есть мобильное приложение? Или ваш сайт предоставляет REST API? Не забудьте протестировать это API, обновить документацию и узнать — а могут ли клиенты подключиться по https без проблем? Проверять нужно до переезда, ведь может потребоваться доработка.

Содержимое robots.txt

Сайт на http и https — для поисковых систем два разных сайта. Чтобы сообщить поисковику, что это два зеркала одного сайта раньше можно было использовать директиву Host в файле robots.txt. Она говорит какое зеркало главное и должна со всех зеркал вести на один адрес.

С конца марта 2018 Яндекс не поддерживает директиву Host . Переезд сайта осуществляется с помощью 301 редиректа (как в Google).

Содержимое sitemap.xml

Еще один механизм, который поможет поисковику узнать о переезде — файл sitemap.xml. В нем содержатся ссылки на страницы сайта, которые нужно проиндексировать.

После переезда не забываем пересоздать sitemap.xml cо ссылками на https.

Meta-тег canonical

На хороших SEO-оптимизированных сайтах давно настроен мета-тега rel=’canonical’. Адрес страницы в этом теге всегда задается с указанием протокола. При типовой реализации протокол меняется в настройках соответствующего инфоблока.

После переезда необходимо проверить все инфоблоки и указать канонический адрес с протоколом https.

Кеширование

Ну и как же забыть про извечную проблему «не сбросил кеш». Можно блестяще справиться со всеми проблемами, которые мы перечислили выше, но если забыть очистить кеш сайта, многие усилия окажутся напрасны. Конечно, в Битриксе есть технология «Управляемый кеш», но вы абсолютно уверены что ваши разработчики ей воспользовались, делая какой-нибудь нестандартный отчет или сложную систему лояльности?

Выводы

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

www.intervolga.ru


You May Also Like

About the Author: admind

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

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

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

Adblock
detector