Краткое руководство по получению бесплатного сертификата SSL и переводу wordpress-сайта на HTTPS. Несколько простых шагов к заветному зелёному замочку.
Цель этого короткого материала: показать, как собственными руками быстро и без ошибок настроить сайт на работу по протоколу HTTPS. Речь идёт не о создании сайта с нуля, а о перестройке имеющегося. Вебмастеру предстоит сделать всего несколько шагов, и пугаться их не следует. Кстати, результат во многом зависит от хостинг-провайдера, его дружелюбия и стремления к сотрудничеству. Ниже я расписываю все шаги по переводу сайта на протокол HTTPS на примере своего сайта «Счастье слова», который обслуживается у «Хостинглэнда» (Apache + Nginx, PHP 5.6).
Получить SSL сертификат бесплатно
Это делается, например, здесь: www.sslforfree.com. В единственное поле вводится доменное имя сайта, нажимается кнопка «Create Free SSL Certificate».
Выдаются сертификаты Let’s Encrypt. Они совершенно бесплатны, надёжны и одобряются всеми браузерами. Срок действия — 90 дней.
Далее сертификат подтверждается одним из трёх способов. Вручную — способ самый лёгкий. Создаются две папки на сервере — например, через ISPManager, cPanel или через другую панель управления хостингом. Во вторую, внутреннюю папку кладутся два файла, которые выдаст sslforfree.com.
Примечание: папки, имеющие имена с точками, должны быть разрешены на сервере. Иначе при проверке sslforfree.com выдаст ошибку 404, и сертификат SSL получить не удастся. В случае проблем надо писать в техподдержку хостинга.
Если всё в порядке, файлы машиной найдены, сервис выдаст просителю ключи сертификата. Архивный файл с ключами надо переслать хостинг-провайдеру, он сам установит сертификат SSL (вместо «самоподписанный» появится «подписан цепочкой»).
Кстати, регистрация на sslforfree.com может оказаться полезной: сервис пришлёт письмо за неделю до истечения срока действия сертификата Let’s Encrypt. Напомню, он действует только три месяца.
Мой провайдер пока не поддерживает автоматическое продление таких сертификатов, зато обязуется продлевать SSL для моего сайта вручную. Мне надо будет только скачивать новые ключи. Ну что ж, тоже неплохо. Обновление серверного ПО и автоматизация ожидаются в следующем году. Надеюсь на это.
Необходимо проверить установленный сертификат: www.sslshopper.com/ssl-checker.html.
Вот так выглядит итог проверки для моего сайта:
Кому показать рассказ или роман? Писателю! Проверьте свой литературный талант. Закажите детальный разбор рукописи или её фрагмента.
Добавить код туда и сюда
Не пугайтесь, его немного. И имейте в виду: я описываю свой случай. Характерный для моего хостинга и моей wordpress-темы.
В панели управления хостингом нужно добавить в файл wp-config.php следующий код:
if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') $_SERVER['HTTPS']='on';
Строка вставляется выше того места, где в файле сообщается на чистом русском языке: мол, дальше не правим.
Проблема связана с тем, что браузеры не могут загрузить таблицу стилей при первом обращении через протокол HTPPS. Без этой строчки весьма вероятна циклическая переадресация. Администратор не попадёт в админку сайта.
На крайний случай, когда не получается ничего, есть простой способ моментально восстановить доступ в админпанель WordPress. Это пригодится, ежели администратор видит на экране такое:
Неверное перенаправление на странице.
При соединении с мой_сайт.ru произошла ошибка.
Эта проблема может возникать при отключении или запрещении принятия кук.
Вернуть работоспособность админке по старому протоколу HTTP можно путём добавления пары строк в файл functions.php темы (в самый низ):
update_option('siteurl', 'http://мой_сайт.ru');
update_option('home', 'http://мой_сайт.ru');
Вместо http://мой_сайт.ru, понятное дело, вводится действующий адрес сайта. Ура, админка открывается! Её главную страницу в браузере лучше перезагрузить (например, нажав клавишу F5). Теперь строки «update_option» из файла functions.php темы можно удалять. Не забываем, что сайт вернулся к HTTP.
Исправить в админпанели WordPress http на https
Это делается на вкладке «Настройки» — «Общие», там, где прописаны адреса сайта. Вместо http://мой_сайт.ru набрать https://мой_сайт.ru. Затем заново войти в админку.
(Не получается войти в админку WordPress? См. несколько абзацев выше. Этот способ вернёт http адресу сайта в админке.)
Добавить директиву в файл .htaccess в панели хостинга
Код, который добавляется в начало файла .htaccess (в самое начало; если поставить в конце, будут доступны обе версии сайта: с http и https, а это приведёт к ошибкам смешанного содержимого при статическом кэшировании!):
RewriteEngine On
Всего один урок. С вашим текстом. Вы и писатель. Больше никого. За 120 минут вы научитесь избавляться от типичных ошибок в сюжете, композиции и стиле. Закрепив полученные навыки, вы сможете обходиться без редактора.
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteCond %{REQUEST_URI} !^/robots.txt$
Или вместо последней строки:
<FilesMatch "robots.txt$">
RewriteEngine off
</FilesMatch>
Подобные директивы не являются единственными и исчерпывающими. Примеров других правил редиректа в сети масса. Редирект 301 нужен, кстати, для «Яндекса». Раньше был важен указатель «Host» в файле robots.txt, нынче важен редирект 301, а «Host» игнорируется. Я свой редирект уже проверил в «Яндекс.Вебмастере», всё прекрасно. И вообще, никаких ошибок у моего «Счастья слова» нет, см. картинку ниже. На то оно и счастье.
Переадресацию для сайта делают и кнопками, особенно это легко в ISPManager 4 и ISPManager 5 через секцию «Редиректы» с выбором варианта «301 — перенесён на новый адрес». Не вижу смысла это пояснять, в сети полно картинок и мануалов. Однако код, приведённый выше, отлично работает для связки Apache + Nginx, а редирект через кнопку вызывает циклическую переадресацию.
Устранить смешанное содержимое
Необходимо избавить сайт от всех ссылок с префиксом http. Такие ссылки браузеры блокируют. И вместо зелёного замочка у адресной строки браузера владелец сайта увидит жёлтенький замочек с предупреждающим восклицательным знаком. Мол, не всё содержимое страниц является защищённым.
Я заменил вручную все устарелые ссылки в виджетах и в футере темы.
Далее применил пару плагинов WordPress. Таких, которые потом удалил за ненадобностью. Следовательно, никакой нагрузки на сервер они не создают.
При помощи плагина Velvet Blues Update URLs я поменял массу ссылок в записях и на страницах, а также в путях к картинкам. Выполняется вот такой запрос-замена:
http://мой_сайт.ru/
https://мой_сайт.ru/
Вместо мой_сайт у меня, конечно, было olegchuvakin.ru.
Ввод «/» в конце запроса позволит заменить все внутренние ссылки.
Плагин Velvet Blues Update URLs исправил далеко не всё. Например, не исправил массу внешних ссылок (ведущих на другие сайты). Исправлять каждую вручную долго, проще исправить в таблицах базы данных, в каждой отдельным запросом. Это я сделал через другой плагин: Better Search Replace (бесплатную его версию).
Better Search Replace моментально меняет в базе данных http:// на https://, достаточно ввести в соседние поля одно и другое. Сначала плагин предлагает поглядеть на результат. Собственно, в бесплатной версии можно увидеть лишь число предполагаемых замен. Платную не пробовал.
Таким-то вот образом я отредактировал сотни и сотни ссылок. Сайт у меня небольшой. Кому-то и десятки тысяч ссылок предстоит заменить.
Плагины эти больше мне не нужны, я их удалил.
Далее я проверил сайт по внутреннему поисковому запросу «http://». Картинка с ответом машины ниже.
К сожалению, решения, изложенные выше, не абсолютные, годные для всех, а относительные. В моём случае они подходят вполне. В других случаях… Скажу несколько слов и о них.
Ошибки смешанного содержимого помогает (предположительно) решить плагин SSL Insecure Content Fixer. Я его протестировал. Правда, эффекта не увидел. Кстати, после установки этот плагин сразу обнаружил директиву в файле .htaccess (см. выше) HTTP:X-Forwarded-Proto. Потому и настраивать там почти ничего не пришлось.
SSL Insecure Content Fixer предлагает несколько методов борьбы со смешанным содержимым. Я попробовал «простой», «режим захвата» и самый последний, который одолевает ну решительно всё. Плагин этот, разумеется, должен функционировать на сайте постоянно. И даже может кое-что «поломать», о чём деликатно предупреждают разработчики. На моём сайте он ничего не сломал. Но и толку от него я не заметил. Редирект на «Счастье слова» работает корректно, все ссылки заменены на https — зачем мне лишний плагин?
Есть и другие плагины для борьбы со смешанным содержимым. Каждый найдёт их через поиск плагинов в админпанели (запрос «SSL»).
Завершив сии манипуляции и очистив кэши, я проверил сайт на сервисе www.jitbit.com/sslcheck.
Done, сообщила машина спустя минутку. И указала число страниц, которые обошли её паучки. No issues found. См. скриншот.
Проблем со смешанным содержимым на сайте, стало быть, нет.
Словом, готово. Сайт получил шифрование и отныне считается надёжным. Благодаря сделанной переадресации он доступен теперь по протоколу HTTPS (хотя параллельно существует версия HTTP, и без редиректа WordPress выдал бы по старым ссылкам как раз её). И по всем давним ссылкам в Интернете, к примеру, в «Фейсбуке» или других соцсетях, будет открываться странички с префиксом https. В адресной строке зазеленеет замочек.
Чтобы админка WordPress была доступна только по HTTPS, в файл wp-config.php я добавил строчку:
define(‘FORCE_SSL_ADMIN’, true);
Напоминаю! Все рекомендации и способы, описанные выше, подходят для сервера провайдера Hostingland (Apache + Nginx, PHP 5.6) и для сайтов на движке «Вордпресс». Проверялось на WordPress 5.
Рассказать поисковым машинам о переезде и смене адреса
HTTPS — это вам не HTTP! Это новый адрес сайта.
Завершающим этапом работы является сообщение «Яндексу» о переезде. Это делается в личном кабинете сервиса «Яндекс.Вебмастер». Там имеется соответствующий раздел с интуитивно понятным названием: «Переезд» («Индексирование» — «Переезд сайта»). Также потребуется в DNS домена заново внести TXT-запись. «Яндекс» сам её предложит. Тем, кто сильно спешит, можно попробовать пройти в раздел «Настройки» — «Права доступа».
Файл robots.txt исключается из редиректа вставкой в .htaccess дополнительной строки, она уже приводилась выше в общем коде:
RewriteCond %{REQUEST_URI} !^/robots.txt$
Без этой строки поисковик потеряет robots.txt. «Яндекс» напишет в кабинете вебмастера красной пастой: «Сервер отвечает редиректом на запрос /robots.txt».
Подойдёт и этот вариант:
<FilesMatch "robots.txt$">
RewriteEngine off
</FilesMatch>
Затем остаётся добавить сайт с HTTPS в Google Search Console. Там будет два сайта: с HTTP и с HTTPS. Поисковик сам поймёт, что это один и тот же сайт. Можно заодно и карту сайта (sitemap) с HTTPS тамошним роботам подкинуть.
И да будут с нами зелёный замочек и голубая мечта!
© Олег Чувакин, 16 декабря 2018
Один отзыв
Сайт «Счастье слова» успешно перешёл на HTTPS. Ни одной странички с ошибками смешанного содержимого. Переиндексация в «Яндексе» и «Гугле» движется быстро. Даже очень быстро для такого маленького сайта. Страницы, признанные неглавным зеркалом, выпадают из поиска, на их место тут же ставятся страницы главного зеркала (HTTPS). Кстати, в «Яндекс.Вебмастере» имеется раздел для мониторинга важных страниц: очень удобный инструмент.
Также отмечу, что при переходе сайта на HTTPS никакого спада посещаемости и тем паче «провала», которым до сих пор стращают в сети, не случилось.