Блог свободен от NOFOLLOW!

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

Дата: 15-01-2017 | Автор: Yaroslav.CH | Рубрика: Безопасность сайта
Метки: ,

78

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

В последнее время Google все активнее подталкивает владельцев сайтов к переходу на защищенный протокол (HTTPS). И инициатива это абсолютно правильная.

Зачем вообще нужен именно этот протокол? Не вдаваясь в глубинные подробности, можно пояснить это так — в случае использования HTTPS-протокола, любой обмен данными между сайтом и браузером пользователя будет проходить в защищенном шифрованном канале. К примеру, вы авторизуетесь на сайте: если используется не шифрованный HTTP, ваш логин-пароль передается в открытом канале и может быть перехвачен и использован злоумышленниками. При использовании HTTPS, подобная возможность резко снижается, т.к. эти данные будут зашифрованы. Естественно, тоже самое касается и любых других персональных данных, данных платежных карт и т.д. Соответственно, вопрос «переходить или нет» в сущности, даже не стоит.

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

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

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

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

Шаг 1. Получаем и подключаем SSL-сертификат

До появления бесплатных сертификатов, именно в этом же первом шаге крылась основная проблема. SSL-сертификаты всегда были платными — стоимость начиналась от $30 в год и выше. Естественно, что для небольшого сайта или личного блога эту сумма была не то, чтобы неподъемной, но тратить ее, откровенно говоря, желания было мало. Однако с появлением Let's Encrypt ситуация изменилась - сертификат начального уровня (а его нам и достаточно) стало возможно получить не только бесплатно, но также и практически мгновенно, в автоматизированном режиме.

Я пользуюсь хостингом «Украина», в нем процесс получения сертификата от Let's Encrypt полностью автоматизирован и не требует от пользователя каких-либо специфических знаний. Для получения сертификата нам необходимо:

  1. зайти в «Панель управления»;
  2. выбрать раздел «Настройка SSL»
    Настройка SSL
  3. Выбираем закладку «Let's Encrypt сертификат» и нажимаем кнопку «Установить».
    Let's Encrypt сертификат
  4. Через несколько минут (иногда дольше — если очередь большая), мы получим наш сертификат, который автоматически будет установлен.

Все, больше никаких действий по поводу сертификата от нас не требуется. Сам сертификат выписывается на 3 месяца и будет автоматически продлеваться до тех пор, пока вы будете использовать хостинг или Let's Encrypt не изменит правила.

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

Шаг 2. Исправляем «смешанное содержимое»

Шаг 2.1. исправляем в теме блога

ВНИМАНИЕ! Перед любыми действиями с файлами, обязательно сделайте резервную копию темы!

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

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

К примеру, мы загружаем страницу www.proofsite.com.ua в HTTPS (https://www.proofsite.com.ua), но внутри темы ссылка на картинку-логотип прописана как абсолютная и с явным указанием протокола HTTP

http://www.proofsite.com.ua/images/logo.png

мы получим ошибку смешанного содержимого. Следовательно, нам нужно открыть файл темы header.php и исправить ссылку на относительную. То есть написать:

/images/logo.png

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

Если по какой-либо причине, вы не можете изменить ссылку на относительную, то можно указать как абсолютную, но без указания протокола:

//www.proofsite.com.ua/images/logo.png

Как видите, в этом формате записи убрано «HTTP» и браузер будет самостоятельно выбирать тот тип протокола, по которому загружается вся страница.

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

Шаг 2.2 исправляем в CSS

Иногда в CSS-стилях возникает проблема смешанного содержимого в конструкции «background-image». Для ее исправления, нужно открыть файл стилей и убрать у ссылки на файл фонового изображения протокол. Получится так:

 background-image: url(//www.ваш-сайт.com/wp-content/themes/[имя-темы]/images/background.png);

Шаг 2.3 исправляем в контенте

Если с темой и CSS все можно сделать вручную более-менее быстро, то с контентом придется повозиться. Дело в том, что WordPress при добавлении изображения через редактор, по-умолчанию прописывает абсолютные ссылки. Соответственно, сейчас все наши ссылки загружаются по HTTP-протоколу, что продолжает вызывать ошибку смешанного содержимого. Если у вас немного статей — можете исправить эти ссылки вручную, но если статей больше десятка — придется воспользоваться заменой в базе данных.

Для этого нам понадобится доступ к phpMyAdmin. В панели управления хостинга «Украина» ссылка на вход в phpMyAdmin находится в разделе «MySQL».

phpMyAdmin

ВНИМАНИЕ! Перед любыми действиями с базой, обязательно сделайте ее резервную копию!

Открываем закладку «SQL» и выполняем следующую команду:

 UPDATE wp_posts SET post_content = replace(post_content, "http://www.proofsite.com.ua", "//www.proofsite.com.ua); 

Таким образом, мы изменим в таблице «post_content», содержащей контент записей, протокол у ссылок и теперь при загрузке страницы браузер сам определит — по какому протоколу вызывать файлы.

Шаг 3. Проверяем работу HTTPS

Теперь, когда проблема смешанного содержимого устранена, нам нужно проверить — действительно ли мы все сделали правильно. Для этого открываем наш сайт по протоколу HTTPS.

https://www.proofsite.com.ua

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

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

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

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

В чем причина ошибки «Подключение к сайту защищено не полностью», мы можем узнать, нажав на ссылку «Подробнее». Перед нами откроется окно с указанием на нашу проблему — «Mixed Content» («Смешанный контент»).

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

Соответственно, нам нужно это исправить. Для этого выбираем закладку «Console» («Консоль») в списке сверху и получаем список наших ошибок, указанных как «Mixed Content» («Смешанный контент»).

Далее индивидуально исправляем все указанные проблемы.

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

Также получить доступ к этой информации можно через «Инструменты разработчика». Для того открываем в Google Chrome «Инструменты разработчика»: «Меню» -> «Дополнительные инструменты» -> «Инструменты разработчика» (или Ctrl + Shift + I на странице)

Шаг 4. Переводим блог на HTTPS

Теперь нам нужно указать для всего блога режим работы в HTTPS. Для этого открываем админ-часть нашего блога и заходим в «Настройки» -> «Общие». Здесь нас интересуют 2 строки:

Адрес WordPress (URL)

Адрес сайта (URL)

Для обеих строк меняем протокол и сохраняем.

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

Шаг 5. Прописываем 301 редирект с HTTP на HTTPS

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

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP:SSL} !=1 [NC]
RewriteRule ^(.*) https://www.proofsite.com.ua/$1 [L,R=301]

Теперь при вызове страниц сайта по HTTP, запрос будет автоматически переадресован на страницы с HTTPS.

Шаг 6. Сообщаем поисковикам о смене протокола

Шаг 6.1. Google

Для того, чтобы сообщить Google о том, что мы сменили протокол, нам нужно добавить HTTPS-версию сайта в Google Webmasters Tools как новый сайт. При этом HTTP-версию можно оставить. Также нужно добавить новую карту сайта и перенести настройки (если были) из HTTP-версии в HTTPS-версию.

Шаг 6.2. Yandex

Для Яндекса нам понадобится выполнить следующие действия:

  1. открыть «Инструменты вебмастера»;
  2. в меню выбрать пункт «Переезд сайта»;
  3. установить флаг «добавить HTTPS»;

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

Далее также как и в ситуации с Google, нам нужно добавить новую карту сайта с HTTPS-страницами. А также прописать главное зеркало в файле robots.txt:

 Host: https://www.proofsite.com.ua 

 

Заключение

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

Комментарии 78 комментариев

перейти к форме для комментирования

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

ОтветитьОтветить

@Roman: вы несколько путаете взлом сайта и перехват данных. Но без использования HTTPS при входе в админку, передаваемые вами в открытом виде логин-пароль администратора — да, могут стать причиной взлома. При этом нужно понимать, что WordPress как таковой тут не причем — точно так же можно перехватить данные на любом движке. Более того, WordPress позволяет включить принудительный HTTPS для админки.

ОтветитьОтветить

Здравствуйте, заметил что вы упомянули 301 редирект через файл htaccess, но забыли что этот способ всем не подходит. Если сайт стоит на сервере nginx (а таких все больше и больше) то эта инструкции не срабатывает. Универсальный способ это в файл функции темы ввести php скрипт.

Ссылка в дропбокс на скрипт www.dropbox.com/s/8ptj7ko...p-https.txt?dl=0

ОтветитьОтветить

@Клим: nginx как таковой здесь не при чем. Подавляющее большинство хостингов использует его в качестве кэширующего прокси-сервера, при этом сам веб-сервер работает на Apache. Собственно, мой хостинг делает тоже самое и указанная в статье конструкция, как вы прямо сейчас видите (раз видите эту страницу) — без проблем работает.

По-факту, универсальным вариантом является редирект, основанный на конфигурационном файле сервера, а не движка. Но если у вас не Apache, то — да, для вас вариант с .htaccess не сработает и придется использовать скрипт.

ОтветитьОтветить

Немало действий нужно сделать. Но моё мнение, что всё-таки рано обычным блогам, где нет регистрации и ввода платёжных данных, переходить на новый протокол. Вот когда и Гугл, и Яндекс будут менее доверительно относиться к сайта на HTTP, тогда и стоит задуматься о переходе. А пока рановато...

ОтветитьОтветить

@Сергей: Google уже сейчас говорит о том, что HTTPS-сайты имеют преимущество в выдаче за счет своей большей безопасности. Соответственно, логично предположить, что если HTTPS-сайты имеют большее преимущество, значит отношение к HTTP-сайтам как раз и есть «менее доверительное».

С отношением Яндекса ситуация менее ясная, но обычно он подтягивается за Google. Не в первый раз.

ОтветитьОтветить

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

ОтветитьОтветить

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

ОтветитьОтветить

@Илья: да, иногда так действительно бывает. Чаще всего нужно выполнить пункт 5 (настроить редрект) и после этого проблема решается.

ОтветитьОтветить

Спасибо админу за полезную статью, все получилось, сайт отлично работает работает.

ОтветитьОтветить

Отличная статья, спасибо за разъяснение. Переезд дело 10 минут, все получилось!

ОтветитьОтветить

Чтобы не мучаться с редиректами через Апач, можно поставить модуль для WordPress. На многих проектах использую WP Force SSL, очень помогает.

ОтветитьОтветить

@Богдан: плагины в данном случае — не лучшее решение. В какой-то момент могут произойти изменения в WP, а плагин автор не обновит. Соответственно, могут быть проблемы. Да и никаких «мучений с редиректами» нет — 4 строчки в .htaceess и всё.

ОтветитьОтветить

@Yaroslav.CH: Да, редирект в .htaccess это вариант для более опытных пользователей и отчасти снижает риски.

ОтветитьОтветить

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

ОтветитьОтветить

Спасибо за статью, но есть одна проблема! sql запрос не много не верный.

'src="http://', 'src="//' вот примерно так. И надо указать где менять

ОтветитьОтветить

@Регина: sql-запрос верный. Не нужно менять протокол у всех ссылок. В этом нет необходимости — на внешние ресурсы можно ссылаться в любом протоколе, а в каком именно сайт будет загружен, будет определено на стороне его сервера.

А в каких таблицах менять — указано в запросе.

ОтветитьОтветить

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

ОтветитьОтветить

Спасибо за подробную инструкцию. Я как раз в раздумьях, думаю перейти на https. Правда вот думаю, не будет ли потом проблем с бесплатным сертификатом?

ОтветитьОтветить

@Андрей: если что-то смущает, то вы всегда можете купить платный у лидеров этого рынка.

ОтветитьОтветить

@Андрей: А я во вторник прикрутил к своему блогу SSL. Практически все сделал, как написал Ярослав, только вот 301 редирект, и настройку сделали на хостинге IHC. А дальше поменял в админке вордпресса все ссылки с http на https. Потом внес изменения в Я&G вебмастер. Сертификат взял платный 600 р/год. Решил не морочится, так как про как мин. два бесплатных было упоминание в гугле о том, что он на них ругается!) Такое может произойти и с другими бесплатными в будущем. А может и нет...

кстати пришлось еще выделенный ip оформить. тоже затраты!!!

ОтветитьОтветить

Я бы тоже платный покупал сертификат. Они сейчас по 10 баксов. Не стоит зажимать я думаю. Это как бесплатный хостинг с рекламой.

ОтветитьОтветить

@Антон Саблев: некорректное сравнение. Бесплатный сертификат ничем, с технической (да и маркетинговой) стороны не отличается от платного. Но выбор, естественно, всегда остается за покупателем.

ОтветитьОтветить

@Yaroslav.CH: С технической да, но на некоторых бесплатных сервисах по предоставлению сертификатов безопасности таки сразу предупредили о том, что гугл с некоторых пор их не любит ... Тут выбирать надо.

ОтветитьОтветить

@Михаил: верно, именно поэтому в статье указан только Let's Encrypt, к которому это не относится. Обратите внимание, кто является их Platinum Sponsors :)

ОтветитьОтветить

Спасибо за пособие. На один сайт (новый) сразу установил сертификат бесплатный прям на хостинге без проблем. На второй переходить как-то боязно. (в смысле накосячить). Сайт на Вордпресс. Наверняка есть плагин для переделки всех ссылок. Что скажите?

ОтветитьОтветить

@Павел: честно говоря, никогда не искал такой плагин — не было необходимости. Возможно, он и существует.

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

ОтветитьОтветить

Плагин называется Better Search Replace. Я с его помощью заменил все ссылки с http на https

ОтветитьОтветить

@Михаил: Спасибо. Буду пробовать. Конечно, Резервную копию надо делать тоже.

ОтветитьОтветить

Как вовремя эта статья! Спасибо огромное!

ОтветитьОтветить

Здравствуйте Yaroslav!

Полезная статься для новичка — гладко и доходчиво излагаете... Но я не об этом.

Увидел у Вас упоминание о хостинге «Украина» (слышал, но не знаком) — интересно бы было послушать поподробнее (наверняка есть пирожки какие).

...ибо как-то мне показалась (условно) дороговата площадка, и 5 загадочных дён теста...

p|s

Кстати, для новичка — Velvet Blues Update URLs — чёткий плагин замены ссылок... и в БД не нужно лезть...

Кто-то вроде спрашивал о запрете входа в админку:

define ('FORCE_SSL_ADMIN', true); // закрыть true false, циклическая переадресация https, чтоб не редиректило.

в — wp-config.php

ОтветитьОтветить

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

ОтветитьОтветить

@Михаил ATs: насчет хостинга — честно говоря, я не слежу за ценами на этом рынке. Для меня важна стабильность работы и удобство админки. У «Украины» своя панель со всем необходимым функционалом, позволяющим практически никогда не обращаться к поддержке. Но если и нужно что-то от них, то отвечают быстро и помогают/исправляют тоже без задержек.

А 5 дней теста — да, реально. Регистрируетесь, пользуетесь, а дальше — принимаете решение.

ОтветитьОтветить

@Павел: чем дольше откладывать, тем сложнее будет потом перейти на https. У меня сайту 2 месяца и на страничке вебмастера яндекса переходи проходит уже второй месяц. Гугл быстрее сообразил и отразил в выдаче страницы с сертификатом. Смотрите сами.

ОтветитьОтветить

@Yaroslav.CH: спасибо!

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

Однако (условно) коли цена хоста чуть выше чем у сотоварищей, вероятно и услуги приличнее...

Однако же... раз «вероятно», то стоит проверить: вот я и...

Меня интересует файловый менеджер... хочу перебросить несколько тестовых сайтов...

ОтветитьОтветить

@Михаил ATs: полноценный файловый менеджер есть, архивация/разорхивация есть, управление БД и дампом есть. Можно даже подключиться к удаленному ФТП, для переноса файлов.

Отдельно мне нравится двухфакторная авторизация на вход в саму панель — очень полезная вещь.

ОтветитьОтветить

@Yaroslav.CH:

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

FTP не люблю: привык в онлайн, так сказать... два-факта прав при авторизации — неплохо! пока это не особливо распространено серёд среднего хостера... хотя удивить этим нынче едва ли...

ОтветитьОтветить

@Михаил ATs: пробуйте — лично мне нравится и все устраивает. Никаких особых сверх-требований к хостингу у меня нет, но их панель мне нравится в разы больше, чем тот же классический Cpanel.

ОтветитьОтветить

@Yaroslav.CH: кстати — да, Cpanel мне тоже не по приколу... «но их панель...» — а вот это пожалуй и есть пирожок)

Спасибо, Ярослав!

ОтветитьОтветить

@Михаил ATs: ну вот потому у них и есть 5 дней на тест.

Всегда пожалуйста :)

ОтветитьОтветить

Вот вроде бы и норм, и инструкция и т.д. У браузеры обязывают по немногу нас заниматься этим, но проблема то у многих одна и та же — за время переезда траф проседает очень сильно. У самого пару магазинов, и пытаюсь как можно дольше не переводить, но понимаю, что скоро это будет необходимо... И потом жди 2-3 месяца. Радует одно — у гугла https — это фактор. Яндекс пока говорит — что для них это все равно... ну посмотрим)

ОтветитьОтветить

@Vadio: да, траффик действительно проседает. До 30% в среднем. Но потом (4-8 недель) восстанавливается. Если, конечно, не произойдет чего-то непредвиденного.

ОтветитьОтветить

@Yaroslav.CH: а что... неплохой такой хостинг — «Украина»!

Понравились кое-какие рычаги) но сегодня не о них.

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

Так что два плаца уже там... Поглядим-посмотрим.

ОтветитьОтветить

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

ОтветитьОтветить

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

ОтветитьОтветить

@Аня: оба варианта есть. И платный и бесплатный. В обоих случаях есть плюсы и минусы. На мой взгляд лучше платный.

ОтветитьОтветить

@Аня: посещаемость восстанавливается, со временем. Let's Encrypt — бесплатный. Понятно, что гарантировать, что так будет всегда никто не может. Но если завтра Let's Encrypt станет платным — можно будет либо купить его, либо поменять на любой другой.

ОтветитьОтветить

@Михаил: честно говоря, в рамках блога я не вижу смысла в платном сертификате — нет никаких особых преимуществ, за которые бы стоило платить.

ОтветитьОтветить

@Yaroslav.CH: гугл внёс в чёрный список некоторые компании предоставляющие бесплатный сертификат. Но конечно же не все, но кто знает какие ещё внесёт и когда. Поэтому я поставил проверенный платный comodo и забыл про все это.

ОтветитьОтветить

@Михаил: ну, с таким же успехом и comodo может попасть в этот список — все зависит от ситуации. А по поводу Let's Encrypt — я уже писал выше, обратите внимание, кто является их Platinum Sponsors.

ОтветитьОтветить

@Yaroslav.CH: Понятно, спасибо за разьяснения.

ОтветитьОтветить

Спасибо за подробный урок. У меня всего пара сайтов на WordPress, но и другие почти все не переведены. Немного неясно, есть ли смысл переводить недавно запущенные сайты, которые только начали появляться в поиске?

ОтветитьОтветить

@СибирскаЯзва: оптимальнее всего было изначально запускать их на https.

ОтветитьОтветить

@СибирскаЯзва: да, имеет смысл. Думаю в последствии это скажется на ранжирование поисковиками. Посещаемость практически не изменится в последствии. А сразу после установки может просесть, но для молодых сайтов это не страшно

ОтветитьОтветить

@Михаил: спасибо

@Yaroslav.CH: Ну что же делать, уже ступила...

Я читала, что может сказаться на быстродействии, а у меня сайте скрипты на php, сео-сервис. Если будет тормозить -вообще толку не будет. Насколько для этого сайта имеет смысл переход? Личных данных, БД пользователей, расчетов -ничего такого нет.

ОтветитьОтветить

@СибирскаЯзва: я не проводил специальных измерений, но в целом я не заметил ни малейших изменений в скорости работы после перехода на https — ни информационных сайтов, ни сервисов, ни интернет-магазинов.

ОтветитьОтветить

Я вообще пока плохо понимаю о чем тут написано,но думаю что скоро придется рабираться,голова кругом,для новичка...(((

ОтветитьОтветить

Спасибо за статью. Нашел у себя пару проблем. У меня пишет что «подключение к сайту защищено не полностью» и через Console нашел ошибки: пару счетчиков. НО они не поддерживают https. Как можно тогда решить проблему не удаляя счетчики?

ОтветитьОтветить

@Стас: измените их вызов, убрав протокол.

Было: www.proofsite.com.ua

Стало: //www.proofsite.com.ua

ОтветитьОтветить

@Yaroslav.CH: Спасибо за оперативный ответ! Сделал как говорите и счетчик перестал работать. Первоначально у счетчиков были ссылки site.ru После сделал как посоветовали и ссылки обрели вид site.ru и перестали работать.

ОтветитьОтветить

@Стас: в чем именно выражается «перестали работать»? И что за счетчики?

Возможна ситуация, когда https не поддерживается на стороне сервера счетчика и с этим, насколько мне известно, с пользовательской стороны сделать ничего нельзя. Такая проблема может быть исправлена только на стороне владельца счетчика — включением поддержки https. К примеру, у GA, Метрики и Рамблера таких проблем нет, они работают корректно по двум протоколам.

ОтветитьОтветить

@Yaroslav.CH: скорее всего что в этом и есть проблема — они не работают по https. Когда я явно прописал https то картинка, которая показывает счетчик (посещение) перестает показываться. Счетчики эти малоизвестные и они с каталогов по узкой тематике. Тогда лучшим решением будет их убрать, чтобы мой сайт полностью стал работать по https?

ОтветитьОтветить

@Стас: думаю, сначала стоит написать в поддержку сервисов — владельцев счетчиков и спросить, что делать со сложившейся ситуацией. Возможно, у них есть альтернативный код под https.

ОтветитьОтветить

Спасибо за действительно полезный контент. А то намучалась...

ОтветитьОтветить

Google только сказал что-то, и все рванули на SSL, а так ли это нужно было? На мой взгляд нужно переходить в первую очередь сайтам с коммерческой тематикой, а не брать бесплатный Let's Encrypt, у которого проблемы с Windows XP. И если многие думают что все такие продвинутые, все устанавливают последнюю версию Windows, то, к сожалению, старшее поколение, особенно в офисах, держат компьютеры на XP.

У меня сайт хоть и посвящен сайтостроению, но все же 3-5% заходят с ОС Windows XP. Не хочется отрезать хоть и небольшой, но все же трафик.

ОтветитьОтветить

@Юрий: а еще есть люди, которые до сих пор сидят на IE6 :) Предлагаете продолжать поддерживать верстку?

ОтветитьОтветить

@Yaroslav.CH: этих людей гораздо меньше, чем тех, кто на XP )

ОтветитьОтветить

@Юрий: меньше их или больше, но по Вашей логике они ведь тоже — трафик, верно? :)

На мой взгляд, поддерживать менее безопасный http в угоду 3% пользователей — это путь в никуда. К тому же, учитывайте, что эти же 3% могут ходить и с мобильных устройств, у которых нет такой проблемы. Соответственно, эти 3% можно разделить минимум на 2.

Впрочем, если Вас тревожат пользователи XP — вы можете взять платный сертификат с ее поддержкой, такие варианты, насколько я помню, на рынке есть :)

ОтветитьОтветить

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

ОтветитьОтветить

Спасибо за подробную инструкцию, вроде все понятно.

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

ОтветитьОтветить

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

ОтветитьОтветить

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

ОтветитьОтветить

Добрый день! Спасибо вам за инструкцию. Подскажите пожалуйста, как быть с вебмастером Google и Яндекс и их аналитикой и метрикой?

Значек на страницах зеленый, изменил внутренние ссылки, сделал редирект с http на https, в robots.txt в строке host и строке sitemap.xml изменил url сайта на https.

В вебмастере Яндекс в разделе Переезд отправил запрос на https для сайта.

В Google analytics в настройках сайта выбрал Url по умолчанию версию с https.

Добавил еще одну версию сайта в Google webmaster уже с версией url с https (также отправил sitemap с https в url).

Теперь в Google webmaster две версии одного сайта (с http и https).

Нужно ли в Google webmaster убрать версию с http?

В Яндекс метрике нужно что-то менять?

ОтветитьОтветить

@Илья: больше ничего делать не нужно. Убирать версию с http в GA не стоит — лишитесь прошлой статистики, равно как и не нужно удалять http-версию в GSC.

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

ОтветитьОтветить

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

ОтветитьОтветить

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

ОтветитьОтветить

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

ОтветитьОтветить

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

ОтветитьОтветить

А Вы оставили комментарий? Ваше мнение очень важно!

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