Ssl wordpress


Когда вы запускаете ваш собственный веб-сайт, ваши пользователи скорее всего должны будут оставлять там личную информацию. Это означает, что вам необходимо обеспечить соблюдение надежных стандартов безопасности, для обеспечения которой важную роль играют как Secure Sockets Layer (SSL или TLS), так и Hypertext Transfer Protocol Secure (HTTPS). К счастью, настройка на платформе WordPress SSL сертификата и установка HTTPS  довольно проста и может быть выполнена всего за несколько шагов.

В этой статье мы поговорим о следующем:

  1. Какой сертификат SSL и когда нужно использовать.
  2. Что такое HTTPS и как он работает вместе с SSL.
  3. Как использовать WordPress SSL и настроить HTTPS с помощью двух разных методов.
  4. Две распространенные ошибки, с которыми вы можете столкнуться при использовании на WordPress SSL, и способы их устранения.

Нам предстоит узнать многое и будет ещё над чем поработать, так что, давайте уже приступим!

Что такое SSL (и когда его нужно использовать)


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

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

Так выглядит WordPress SSL

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

Что касается вашего собственного сайта, установка SSL сертификата является обязательной. Для этого есть ряд причин:

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

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


Кроме того, Google объявил о том, что с момента появления в июле 2018 года Chrome показывает предупреждение «небезопасно». Поэтому самое время обеспечить безопасность вашего сайта с помощью установки SSL сертификата, если вы ещё этого не сделали.

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

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

Что такое HTTPS (и как это работает вместе с SSL)

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

Так выглядит WordPress SSL

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

Если вы попытаетесь получить доступ к сайту без SSL с помощью HTTPS, вы увидите ошибку, подобную этой:


Так будет выглядеть незащищенное подключение

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

Таким образом, ваш первый шаг должен состоять в том, чтобы получить сертификат SSL и настроить его для работы с вашим сайтом. После этого вам нужно указать в WordPress, что нужно использовать HTTPS вместо HTTP. Давайте посмотрим, как работает этот процесс.

Как настроить на WordPress SSL и HTTPS (2 метода)

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

  1. Используйте панель инструментов WordPress и переадресацию 301

После установки WordPress SSL вам необходимо настроить свой сайт для использования HTTPS. Этот процесс прост, если вы запускаете новый веб-сайт. Однако, если вы добавляете SSL сертификат на сайт, который уже использовался какое-то время, это будет немного сложнее.


В любом случае, ваш первый шаг должен состоять в том, чтобы зайти в панель управления и открыть вкладку Настройки> Общие. Внутри вы найдете два поля, которые называются WordPress Address (URL) и Site Address (URL). Адрес вашего сайта должен быть идентичным в обоих полях, и должен использовать HTTP.

Что вам нужно сделать, это заменить префикс HTTP на HTTPS в обоих полях и сохранить изменения в ваших настройках:

Таким образом можно настроить HTTPS

Это всё, что нужно, чтобы настроить WordPress на использование HTTPS. Однако, некоторые пользователи могли сохранить старый URL вашего веб-сайта, и он может оставаться в сети. Вы должны убедиться, что эти пользователи используют HTTPS-версию вашего сайта. Для этого вы можете настроить переадресацию URL.

Существует много типов переадресаций, которые вы можете использовать. Тем не менее, как правило, лучше всего использовать редирект 301, который сообщает поисковым системам, что ваш сайт переместился с одного адреса на другой. Чтобы реализовать это перенаправление, вам нужно отредактировать файл с именем .htaccess, который контролирует взаимодействие вашего сервера с WordPress, а также структуру URL-адреса.


Это потребует от вас прямого доступа к файлам вашего сайта, используя инструмент File Transfer Protocol (FTP), такой как FileZilla. Если вы впервые делаете это, вы можете найти все подробности в нашем руководстве по FTP.

Как только вы подключитесь к своему сайту через FTP, перейдите в папку public_html и найдите файл .htaccess внутри:

Так выглядит файл htaccess

Выберите этот файл и щёлкните на него правой кнопкой мыши, затем выберите параметр Просмотр / редактирование. Это откроет файл с локальным текстовым редактором, позволяющим внести в него изменения. Не изменяйте какой-либо код внутри .htaccess, если вы не знаете, что делаете. Просто перейдите в нижнюю часть файла и вставьте следующий фрагмент:

<IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{SERVER_PORT} 80 RewriteRule ^(.*)$ https://www.yoursite.com/$1 [R,L] </IfModule>

Для этого вам нужно будет заменить URL-адрес в этом коде на полный HTTPS-адрес вашего сайта. Это перенаправит любое соединение, которое приходит через port 80, на новый безопасный URL. Как вы знаете, port 80 является стандартным для HTTP-соединений, поэтому он “перехватит” практически всех, кто пытается получить доступ к вашему веб-сайту через старый адрес.


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

  1. Установите плагин для WordPress SSL

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

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

Мы рекомендуем Really Simple SSL (англ), так как его очень легко настроить. Всё, что вам нужно — это сертификат для WordPress SSL, готовый к работе:

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


После установки и включения плагина он сканирует ваш сайт на наличие сертификата WordPress SSL. Если найдет, он поможет вам включить HTTPS на всем сайте всего за один клик. Для этого просто зайдите во вкладку Настройки> SSL на панели управления и нажмите кнопку Перезагрузить в HTTPS. Да, всё настолько просто!

Если Really Simple SSL plugin не кажется вам настолько простым, есть альтернативные инструменты, которые вы можете использовать для достижения тех же результатов. Есть и другие отличные параметры плагина для WordPress SSL, которые включают WordPress HTTPS (SSL) (англ) и Force HTTPS (англ).

Две распространённые ошибки в WordPress SSL (и как их исправить)

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

  1. Некоторые файлы не загружаются через HTTPS

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

Если у вас возникла проблема с изображениями вашего сайта, CSS или JavaScript, самый простой способ решить её – сделать несколько дополнений к вашему файлу .htaccess. Однако этот подход применяется только в том случае, если вы использовали ручной метод из предыдущего раздела. Мы поговорим о том, что делать, если вы используете плагин вместо этого чуть позже.


Перейдите на свой веб-сайт через FTP ещё раз и найдите файл .htaccess в каталоге public_html. Откройте его и найдите ранее добавленный код, чтобы установить переадресацию 301. Это должно выглядеть следующим образом:

<IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{SERVER_PORT} 80 RewriteRule ^(.*)$ https://www.yoursite.com/$1 [R,L] </IfModule>}

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

<IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{SERVER_PORT} !^443$ RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L] RewriteBase / RewriteRule ^index.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] </IfModule>

Этот код перенаправит весь трафик через HTTPS. Он также включает в себя правила для ваших файлов в WordPress, поэтому такой код позаботится обо всех файлах, которые работали некорректно. После его добавления сохраните изменения в файле .htaccess и загрузите их обратно на сервер.


Если вы настроили свой сайт для использования HTTPS через плагин, вам не нужно вручную настраивать файл .htaccess. Вместо этого большинство плагинов предложит альтернативное решение. Например, Really Simple SSL может находить на вашем сайте файлы, которые не загружаются через HTTPS, и помогать вам их исправить. Чтобы использовать эту функцию, перейдите во вкладку «Настройки»> «SSL», а затем перейдите на страницу настроек плагина:

Исправить ошибку смешанных файлов

В верхней части экрана есть параметр Автозамена смешанного содержимого. Убедитесь, что он включён, а затем сохраните изменения в конфигурации плагина. Этот параметр гарантирует, что WordPress загрузит все объекты через HTTPS, а не только ваши посты и страницы.

  1. Ваш плагин для кэширования WordPress вызывает проблемы

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


Как будет происходить процесс кэширования зависит от того, какой плагин  вы используете. Тем не менее, это не займет у вас больше нескольких минут. Для получения более подробной информации вы можете ознакомиться с нашим руководством по очистке кеша в WordPress в WP Super Cache (англ), W3 Total Cache (англ) и WP Fastest Cache (англ). Если вы используете другой плагин для кеширования, вам может потребоваться заглянуть в справку для получения инструкций о том, как действовать.

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

Вывод

Раньше WordPress SSL сертификаты были зарезервированы только для деловых веб-сайтов, которые сталкивались с большим количеством конфиденциальной информации. В наши дни сертификаты SSL и HTTPS стали обычным явлением. Фактически, сами поисковые системы, такие как Google, рекомендуют их использовать. К счастью, как вы видите, установка SSL сертификата и использование HTTPS для вашего сайта в WordPress – довольно простая задача.

У вас есть вопросы о том, как использовать WordPress SSL и настроить HTTPS? Давайте поговорим о них в разделе комментариев ниже!

www.hostinger.ru

Зачем вообще нужны SSL сертификаты?

Вы согласны, что чем безопаснее Интернет в целом и Ваш сайт для Ваших посетителей, тем живется спокойнее и зарабатывается больше?

Каждый день мы оставляем на разных сайтах свою персональную информацию

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

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

Передача личных данных в Интернет сейчас настолько обыденная вещь, что мы обычно долго не думаем, нажимая кнопку “Отправить” в очередной заполненной форме.

А ведь любые данные, передаваемые на незащищенных SSL сертификатом и безопасным HTTPS-протоколом сайтах, запросто могут быть похищены (и, будьте уверены, похищаются).

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

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

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

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

Что об SSL и HTTPS говорит Google

Google всегда был весьма щепетилен в вопросах информационной безопасности – сначала, в 2010 году, переведя на HTTPS свой почтовый сервис GMail, а затем сделав то же самое и с Google Drive.

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

SSL сертификат на сайте влияет на позицию в поиске Google

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

С 17-го декабря 2015 года Google начал по умолчанию индексировать страницы с протоколом HTTPS, если таковой доступен одновременно с HTTP и не заблокирован каким-либо образом.

Индексирование страниц, использующих HTTPS

Летом 2016 года представитель Google на одной из встреч с веб-мастерами заявил, что в компании всерьез рассматривают возможность увеличения веса SSL сертификата как фактора ранжирования в поисковой системе.

И вот еще одна статья из первоисточника, гугловского блога по безопасности, которая так прямо и называется: “HTTPS as a ranking signal” (HTTPS как сигнал к ранжированию).

Т.е. в том, что сейчас происходит, нет никакой неожиданности – сани готовились давно.

Почему SSL сертификат нужен Вашему сайту СЕЙЧАС

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

Такая себе “черная метка”.

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

Но, вот сейчас начало января 2017-го, и мы видим, что для сайтов без HTTPS все выглядит достаточно терпимо – всего лишь невзрачный кружок с буквой “i” (надо полагать, “информация”).

Правда, если человек на него нажмет, то должное впечатление от этого сообщения наверняка им будет получено.

Незащищенное соединение

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

Если Вы сейчас читаете это из “хрома” – можете наблюдать сие чудо в адресной строке браузера, или на картинке, помещенной мной в начало данного поста.

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

Так что, если Вы себе SSL сертификат еще не установили, как говорится, выводы делайте сами.

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

Как работает SSL?

SSL шифрует информацию, которой обмениваются браузер и сервер, на котором находится веб-сайт.

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

Издатель сертификата проверяет предоставленную владельцем сайта информацию, и, если она отвечает действительности, выдает нам подписанный специальным алгоритмом (SHA) сертификат.

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

Ссылка на такой сайт всегда начинается с HTTPS://… и это можно видеть в адресной строке браузера.

Более заумные технические детали из спецификаций и Википедии здесь цитировать не буду – если Вас это интересует и голова не заболит, погуглите.

В каких случаях SSL перестает работать?

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

При заходе на такой сайт по протоколу https мы увидим следующее:

Ошибка SSL сертификата

И сразу никаких вопросов, правда?

Очень важно приобретать сертификат именно авторизованного издателя: Comodo, Symantec, GeoTrust, Thawte, GoGetSSL (GGSSL), RapidSSL, т.к. браузеры ДРУГИМ НЕ ДОВЕРЯЮТ!

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

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

Также будут сложности, если был выбран не подходящий для Вас тип сертификата (о типах SSL сертификатов читайте далее в этой статье).

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

Что делать, когда срок действия сертификата истекает?

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

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

SSL сертификаты, применяемые для веб-сайтов, имеют следующие разновидности:

  • С проверкой домена (Domain Validation SSL)
  • Мультидоменные (Multi-Domain SSL)
  • С поддержкой субдоменов (Wild Card SSL)
  • С проверкой бизнеса (Business Validation SSL)
  • С расширенной проверкой и зеленой строкой (Extended Validation SSL)

Если у Вас всего один сайт и Вы не используете субдомены, выбирайте Domain Validation SSL.

При наличии сайтов на субдоменах будет дешевле (и проще) приобрести сертификат с поддержкой субдоменов (Wild Card SSL), чем по отдельному сертификату на каждый сайт.

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

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

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

К тому же, существуют и БЕСПЛАТНЫЕ сертификаты от авторизованных издателей – они обладают теми же свойствами, что и платные, но без финансовой гарантии.

Также и срок действия бесплатного сертификата может быть менее одного года.

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

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

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

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

Хостинг – это хостинг, регистратор доменов – это регистратор доменов, а поставщик сертификатов – это поставщик сертификатов.

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

Если у Вас мультисайт

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

Как известно, эти сайты могут располагаться:

  1. в поддиректориях основного домена и обращение к ним происходит по адресам вида http(s)://www.mymultisite.com/site_1, http(s)://www.mymultisite.com/site_2…
  2. на субдоменах – http(s)://site_1.mymultisite.com, http(s)://site_2.mymultisite.com…
  3. и на отдельных доменах – http(s)://www.site_1.com, http(s)://www.site_2.com…

Следовательно, в первом случае достаточно одного SSL-сертификата с проверкой домена (Domain Validation SSL), во втором – потребуется один сертификат с поддержкой субдоменов (Wild Card SSL) или мультидоменный (Multi-Domain SSL), а в третьем – мультидоменный.

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

Сразу оговорюсь, здесь нет инструкций для владельцев VPS/VDS – выделенных серверов. Ваши администраторы вполне компетентные люди и знают, как это все делается.

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

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

Промежуточные сертификаты (Ca Bundle или цепочка сертификатов) необходимы для поддержки сертификата определенными браузерами.

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

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

На обновление информации по домену может потребоваться некоторое заметное время, а может и нет – в любом случае, проверить корректность установки Вы можете на этом ресурсе.

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

Как настроить SSL на WordPress

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

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

По моему опыту процесс перехода на HTTPS редко проходит гладко и с первого раза – и это нормально. На каждом сайте свои нюансы конфигурации и особенностей хостинга.

И если даже с работой редиректов (http на https) проблем не возникает (а часто бывают), то не мало головной боли приносит так называемый “смешанный контент”.

Смешанный контент – это когда на странице, открытой через https, имеются подключения ресурсов по обычному http-протоколу (картинки, стили, скрипты).

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

Смешанный контент

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

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

  1. Откройте свой файл wp-config.php и добавьте (выше комментария /* Это всё, дальше не редактируем. Успехов! */) следующую строку:

2. Откройте файл .htaccess или создайте новый, если у Вас этого файла нет (?!) и добавьте туда следующие директивы:

WordPress htaccess

Не забудьте заменить www.mysite.com на домен своего сайта!

3. Очистите историю браузера, весь кэш и куки, и заходите в админку по адресу https://адрес_вашей_админки.

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

Как настроить SSL на WordPress проще

Теперь забудьте пункты 1 и 2 предыдущей инструкции и сделайте доступными для записи свои файлы wp-config.php и .htaccess – для этого установите для них права 777.

На разных серверах значения могут отличаться, поэтому привожу “гарантированно работоспособное” значение – главное, потом верните все обратно.

Установите плагин Really Simple SSL и активируйте его. Здесь Вас, скорее всего, выбросит из админки (так и должно быть), поэтому выполните пункт 3 из предыдущего варианта инструкции и заходите обратно.

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

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

Постскриптум

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

Не забывайте об этом! ?

* В статье использованы материалы из открытых источников Google.com, WPMUdev.org, SSLcom.ua.

www.wpmarketer.io

Журнал изменений

3.1.2

  • Доработано: добавлены крутые флажки
  • Доработано: .well-known/acme-challenge/ исключены из .htaccess https:// перенаправлений
  • Доработано: введены временные данные для функций, использующих curl/wp_remote_get()
  • Доработано: улучшены сообщения об обнаружении функции исправления смешанного содержимого
  • Доработано: убрано уведомление о просмотре для мультисайта

3.1.1

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

3.1

  • Исправлено: исправлена ошибка в обнаружении сертификата
  • Доработано: добавлен HTTP_X_PROTO, как поддерживаемый заголовок
  • Доработано: разделение HTTP_X_FORWARDED_SSL на вариант, который может принимать значение ‘1’ или ‘on’
  • Доработано: улучшено обнаружение сертификата благодаря очистке доменов подпапок.
  • Доработано: массовая активация SSL для Мультисайта теперь разделена на 200 блоков сайтов, для предотвращения проблем с превышением времени ожидания в больших мультисайтовых сетях
  • Доработано: напоминание ‘оставьте отзыв’ для новых бесплатных пользователей

3.0.5

  • Исправлено: непереводимые строки стали переводимыми.

3.0.4

  • Исправлено: удалена анонимная функция для поддержания совместимости с PHP 5.2.

3.0.3

  • Доработано: функция исправления смешанного содержимого больше не будет срабатывать для содержимого XML
  • Доработано: сетевое меню на подсайтах теперь всегда видимо для Супер Администраторов
  • Доработано: сброс правил перезаписи во время активации задержан на одну минуту для снижения нагрузки на сервер

3.0.2

  • Исправлено: изображение с заглавными символами, которые приводили к тому, что изображение могло не отображаться на некоторых серверах.
  • Исправлено: ситуация, когда маркер ‘data-rsssl=1’ не вставлялся при пустом тэге.

3.0.1

  • Доработано: Добавлено уведомление о конфиденциальности
  • Доработано: перенаправление javascript установлено в false по-умолчанию
  • Исправлено: скрытие SSL уведомления на мультисайте для всех подсайтов, а показана лишь для пользователей группы «activate_plugins»

3.0

  • Добавлена проверка встроенных сертификатов в файле class-certificate.php, который проверяет что домен присутствует в секции обычных иили альтернативных имен.
  • Перенаправление .htaccess теперь использует $1 вместо {REQUEST_URI}
  • Добавлена функция деактивации плагина пока SSL остается в настройках SSL.
  • Добавлен фильтр для перенаправления Javascript.
  • Добавлена боковая панель с рекомендоваными плагинами.

2.5.26

  • Исправлено: меню мультисайта не показывалось когда основной сайт был не SSL.
  • Исправлено: фильтры admin_url и site_url получали пустой blog_id при проверке URL для текущего блога
  • Доработано: добавлен комментарий в уведомлении об активации, чтобы стимулировать создание резервных копий .
  • Плагин тестирован с помощью Gutenberg.

2.5.25

  • Исправлено: опция «переключатель функции исправления смешанного содержимого» не видна на странице настроек мультисайтов
  • Доработано: несколько опечаток и заглавных символов

2.5.24

  • Исправлено: На мультисайте, admin_url заставлял ссылки текущего блога загружаться через http, даже когда текущий блог был загружен через https. Теперь возможно только установить http для других blog_urls кроме текущего, когда они используют http а не https.

2.5.23

  • Тестировано вплоть до WP 4.9
  • Добавлено уведомление безопасности cookie

2.5.22

  • Изменение в функции исправления смешанного содержимого обратно с wp_print_footer_scripts на shutdown

2.5.21

  • Исправлен двойной слэш в пути к файлам
  • Исправлены опечатки в уведомлении активации
  • Доработано: добавлена опция, регулирующая переполнение правил перезаписи
  • Исправлено: предотвращает принуждение admin_url к использованию http когда установлен FORCE_SSL_ADMIN

2.5.20

  • Доработано: константа RSSSL_DISMISS_ACTIVATE_SSL_NOTICE, позволяющая пользователям скрывать уведомления.
  • Доработано: настройка переключения функции исправления смешанного контента из template_redirect в init
  • Исправлено: пони в мультисайте не скрывалась должным образом

2.5.19

  • Исправление Мультисайта: заново добавлены объединенные фильтры admin_url и site_url
  • Добавлена константа RSSSL_CONTENT_FIXER_ON_INIT, так что пользователи могут продолжать использовать init hook для функции исправления смешанного содержимого.

2.5.18

  • Доработано: Удалено исправление JetPack, так как теперь оно поставляется вместе с JetPack.
  • Доработано: Перемещен hook функции исправления смешанного содержимого в template_redirect
  • Исправлено: Изменен hook регулирования правил перезаписи из admin_init в shutdown, при активации SSL.
  • Исправление Мультисайта: Изменена функция, проверяющая admin_url и site_url ответ на запрос http или https для проверки https в home_url.
  • Доработано: окончательно исключены запросы json и xmlrpc из функции исправления смешанного содержимого

2.5.17

  • Доработано: Добавлена функция, где home_url и site_url на мультисайте проверяют, что должно быть или http, или https когда SSL включен для сайта.
  • Доработано: Добавлено уведомление о том, что не будет никакого сетевого меню, когда Really Simple SSL активирован на сайт.
  • Доработано: Добавлен hook для нового мультисайтового сайта, так что новый сайт будет активирован как SSL, при активации SSL на всю сеть.
  • Доработано: ограничено прослушивание JetPack на порту 80 для обратных прокси серверов.
  • Доработано: создана константа, специально для остальных api переадресаций на случай, если пользователи захотят предотвратить переадресации остальных api в https.
  • Исправлено: убирание активированного SSL уведомления на мультисайте не работало должным образом

2.5.16

  • Возврат wp_safe_redirect к wp_redirect, поскольку wp_safe_redirect приводил к переадресации на wp-login.php даже если основной адрес был domain.com и адрес запроса www.domain.com

2.5.15

  • Без функциональных изменений, версия изменена только потому, что WordPress не обрабатывал обновление версии

2.5.14

  • Исправлено: проблема в функции исправления смешанного содержимого, где на оптимизированной html совпадение будет совпадать между элементами.
  • wp_redirect заменен на wp_safe_redirect
  • Добавлен принудительный SSL на wp_rest_api

2.5.13

  • Доработано: настраивается больше функций

2.5.12

  • Добавлена страница настроек мультисайта
  • Добавлен фильтр к выводу кода .htaccess
  • Увеличена возможность пользователей к «activate_plugins»
  • Добавлено SSL_FORWARDED_PROTO = 1 в дополнение к SSL_FORWARDED_PROTO = on, как поддерживаемую SSL распознаванием переменную.

2.5.11

  • Удалено curl в пользу wp_remote_get

2.5.10

  • Исправление совместимости быстрого кэша

2.5.9

  • Доработки мультисайта

2.5.8

  • Убрана автоматическая вставка переадресаций .htaccess. Переадресации .htaccess работают замечательно у большинства людей, но могут вызывать проблемы в крайних случаях.
  • Добавлена опция для явной вставки переадресации .htaccess
  • Добавлена постоянная безопасного режима RSSSL_SAFE_MODE для включения активации кратчайшим путем
  • Исправлено: постоянная RLRSSSL_DO_NOT_EDIT_HTACCESS не обходила правильно настройки когда последние использовались и ранее.
  • Сброшена очистка кэша при активации, так как не всегда работает должным образом

2.5.7

  • Доработано: изменено testurl на функцию test_url()

2.5.6

  • Исправление номера версии

2.5.5

  • Откат некоторых изменений в 2.4.3, так как они вызывали проблемы у некоторых пользователей.

2.5.4

Исправлено: Настроен выбор порядка правил .htaccess, предотвращающий петли переадресации

2.5.3

  • Изменены переадресации .htaccess для использования лишь одного состояния

2.5.2

  • Убрана функция file_get_contents из class_url.php, Так как в некоторых случаях она создавала проблемы.

2.5.1

  • Добавлены всплывающие подсказки
  • Исправлено: опечатки в объяснениях
  • Обнаруженный сервер добавляется к логу отладки
  • Добавлена тестовая папка для CloudFlare
  • Добавлена переадресация htaccess для использования всех доступных серверных переменных для проверки SSL.

2.5.0

  • Доработано: Улучшена поддержка cloudflare
  • Доработано: Добавлена поддержка Cloudfront, благодаря Sharif Alexandre
  • Исправлено: Предотвращена запись пустых переадресаций .htaccess
  • Доработано: Добавлена опция для внутренней переадресации 301 WordPress
  • Доработано: Улучшена поддержка NGINX
  • Доработано: Добавлена поддержка для случаев, когда присутствует только $_ENV[HTTPS] переменная
  • Исправлено: Исправление смешанного содержимого сбежавших ссылок

2.4.3

  • Удален баннер в admin

2.4.2

  • Доработка: Добавлена ссылка для перезагрузки страницы через https, когда SSL не был обнаружен.
  • Исправлено: После перезагрузки страницы, когда сообщение .htaccess отображается, .htaccess теперь перезаписывается.
  • Доработано: Удалены уведомления Yoast
  • Тестировано для WP 4.7
  • Исправлено: баг, при котором сетевые настройки не удалялись правильно при деактивации
  • Доработано: Изменен маркер смешанного содержимого на разнообразие без квот, для предотвращения проблем со скриптами.

2.4.1

  • Доработано: улучшена проверка HSTS

2.4.0

  • Исправлено: добавлена проверка версии в wp_get_sites / get_sites чтобы избавиться от возражающих уведомлений функции и сохранить обратную совместимость.
  • Исправлено: Баг в мультисайте, когда plugin_url возвращал обезображенную ссылку в случае, когда основной сайт содержал конечную косую черту, а подсайт — нет. Благодарим @gahapati за сообщение об этом баге.
  • Доработка: Добавлена кнопка на странице настроек для включения SSL, для случаев когда другой плагин блокировал уведомления администратора.
  • Доработка: Переработана функция исправления смешанного содержимого для большей совместимости
  • Доработка: Улучшен маркер для смешанного содержимого во front-end, так что оно теперь менее заметное и не будет удалено при уменьшении кода.

2.3.14

  • Исправлено: Очистка кэша WP Rocket после активации SSL вызывала ошибку
  • Исправлено: Очистка W3TC после активации SSL не работала корректно

2.3.13

  • Заново добавлено исправление для Jetpack

2.3.12

  • Требует возврата минимум к версии 4.2, так как функция для которой это предназначено еще не сделана в текущем выпуске.

2.3.11

  • Улучшен метод запросов в url классе
  • Добавлена проверка наличия .htaccess в htaccess_contains_redirect_rules()
  • Сообщение активации сделано более понятным.

2.3.10

  • Тестировано для 4.6
  • Доработано: изменена проверка переадресации для htaccess от проверки RSSSL комментариев к проверке собственно правила переадресации
  • Исправлено: сообщение о блокировке записи htaccess больше не показывалось, когда SSL еще не включен
  • Доработано: расширена функция исправления смешанного содержимого для выполнения действий в формах, так как они так же должны быть http в случае внешних ссылок.
  • Доработано: добавлен список безопасных доменов для обнаруженных доменов, но не являющихся угрозой.
  • Доработано: добавлен фильтр для get_admin_url в многосайтовых ситуациях, где WP всегда возвращает https ссылку не смотря на то, что сайт может не быть на SSL
  • Доработано: файлы htaccess и wpconfig перезаписываются при загрузке страницы настроек

2.3.9

  • Исправлено: убрана внутренняя переадресация WordPress, так как она вызывала ошибки для некоторых пользователей.
  • Доработано: улучшен метод запросов ссылок

2.3.8

  • Доработано: Возвратная переадресация изменена на внутреннюю переадресацию wp, которая быстрее
  • Доработано: Когда не обнаружены правила .htaccess, опция переадресации включается автоматически
  • Доработано: запрос ссылки возвращается обратно к file_get_contents, когда curl не давал результата

2.3.7

  • Обновлены скриншоты

2.3.6

  • Исправлено: Отсутствующий приоритет в template_include hook вызывал отсутствие активации функции исправления смешанного содержимого в некоторых темах

2.3.5

  • Исправлено: внедрение передресации javascript

2.3.4

  • Доработано: загрузка таблицы стилей css на странице настроек и перед включением ssl
  • Доработано: функция исправления смешанного содержимого управляется is_ssl(), что предотвращает исправление содержимого на http.
  • Старт обнаружения и настройка только для пользователей с возможностью «manage_options»

2.3.3

  • Исправлен баг в скрипте force-deactivate

2.3.2

  • Изменено обнаружение SSL, так что тестовая страница нужна лишь пока его нет.
  • Некоторые мелкие исправления

2.3.1

  • Убрана опция «activate ssl», когда ssl не обнаружен.
  • Оптимизирована очистка кэша
  • Исправлены некоторые баги при деактивации и активации мультисайта

2.3.0

  • Дан больший контроль над процессом активации ясно запрашивая включить SSL.
  • Добавлено уведомление когда .htaccess недоступен для записи

2.2.20

Исправлена ошибка в обнаружении SSL

2.2.19

Изменен followlocation в curl на альтернативный метод, так как он дает ошибки при включенном safemode или open_basedir
Добавлено убираемое сообщение, когда переадресации не могут быть добавлены в .htaccess

2.2.18

Исправлен баг в создании лог-файла обнаружения curl

2.2.17

Исправления безопасности в ssl-test-page.php

2.2.16

Исправление ошибок в функции исправления небезопасного содержимого.

2.2.13

Добавлена проверка работоспособности функции исправления смешанного содержимого во front end
Исправлена ошибка, когда переменная мультисайта per_site_activation не записывалась на всю сеть
Добавлена очистка кэша wp_rocket, благодарность Greg за предложение
Добавлен фильтр, так что вы можете удалить комментарий really simple ssl
Исправлена ошибка в использовании выходного буфера, что решает несколько проблем
Добавлен код, чтобы JetPack работал слаженнее на SSL, благодарность Konstantin за предложение

2.2.12

  • Для предотвращения блокировок, более невозможно активировать плагин когда wp-config.php недоступен для записи. В случае распределителей нагрузки, активация SSL без добавления соответствующего исправления в wp-config вызовет петлю переадресации, которая заблокирует вас вне администратора.
  • Переадресация сдвинута выше правил перезаписи WordPress в файле htaccess.
  • Добавлена возможность отключения возвратной переадресации javascript к https.

2.2.11

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

2.2.10

  • Откат функции исправления смешанного содержимого.

2.2.9

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

2.2.8

Редактирована проверка определений wpconfig для предотвращения предупреждений когда они не требуются.

2.2.7

  • Расширено обнаружение постоянных homeurl и siteurl в wp-config.php с регулярными выражениями, чтобы разрешить пробелы в коде.
  • Изменен текстовый домен, чтобы сделать этот плагин подготовленным к языковым пакетам.
  • Добавлено обнаружение 404 в функцию обнаружения SSL, так что поддомены могут быть проверены должным образом при установке поддоменного мультисайта

2.2.6

Добавлен слэш в правиле переадресации
мелкие исправления

2.2.3

обновление документации

2.2.2

  • Добавлена поддержка мультисайта для отсутствующих переменных https сервера
  • Улучшен скрипт curl подключения
  • Добавлен Французский язык, благодаря Cedric

2.2.1

  • Небольшие исправления ошибок

2.2.0

  • Добавлена посайтовая активация для мультисайта, но исключена эта опция для установок подпапки…
  • Добавлен скрипт для простой деактивации плагина, когда вы заблокированы вне WordPress администратора.
  • Добавлена поддержка для ситуации, когда не давались серверные переменные, которые могли отображать SSL, что приводило к генерации ошибок WordPress и петель переадресации
  • Убраны предупреждения во время проверки WooCommerce force SSL after checkout, так как только не принудительный SSL вызывал проблемы
  • Добавлен Русский язык, благодаря xsascha
  • Улучшены правила переадресации в .htaccess
  • Добавлено отключение возможности плагина редактировать .htaccess в настройках
  • Исправлена ошибка, при которой мультисайт не деактивировался должным образом
  • Исправлена ошибка, при которой сканирование небезопасного содержимого не сканирует пользовательские варианты постов

2.1.18

  • Предупреждение WooCommerce сделано скрываемым, так как оно, похоже, не вызывает проблем
  • Исправлена ошибка, вызванная родным WP plugin_dir_url(), возвращающим относительный путь, приводивший к отсутствию сообщений SSL.

2.1.17

  • Исправлена ошибка, при которой образец правил перезаписи .htaccess не создавался должным образом
  • Добавлен WooCommerce в обработчик конфликтов плагина, так как некоторые настройки конфликтуют с этим плагином и в любом случае излишни когда вы принудительно переводите ваш сайт на SSL.
  • Исключены временные данные из результатов сканирования смешанного содержимого

2.1.16

  • Исправлена ошибка, при которой скрипт мог не сработать из-за того, что функция curl не была установлена.
  • Добавлены сообщения отладки
  • Доработан FAQ, исправлены опечатки
  • Заменены скриншоты

2.1.15

  • Улучшен пользовательский интерфейс с таблицами
  • Изменена функция тестирования тестовой страницы SSL из file_get_contents на curl, улучшив время отклика, что может предотвратить сообщения «нет SSL»
  • Расширена функция исправления смешанного содержимого для замены src=»http:// ссылок, так как они всегда должны быть https на SSL сайте.
  • Добавлено сообщение об ошибке в случае использования принудительной перезаписи заголовков в плагине Yoast SEO, так как оно мешало плагину исправлять смешанное содержимое

2.1.14

  • Добавлена поддержка для распределителя нагрузки и возврата is_ssl() состояния false: в этом случае необходимо исправление wp-config
  • Улучшена производительность
  • Добавлена опция отслеживания ошибок, чтобы можно было просмотреть лог трассировки
  • Исправлена ошибка, при которой фильтр rlrsssl_replace_url_args не применялся должным образом.

2.1.13

  • Исправлена проблема, при которой в некоторых конфигурациях не срабатывал фильтр заменяемых ссылок.

2.1.12

  • Добавлена опция принудительного SSL для случаев, когда SSL не может быть обнаружен по какой-либо причине.
  • Добавлен тест для проверки работоспособности предложенных правил .htaccess в текущем окружении.
  • Заново добавлен HSTS в правила htaccess, но теперь в виде опции. Это добавление должно делаться только если вы уверены, что не желаете вернуться назад к http.

2.1.11

  • Улучшены инструкции относительно деинсталляции, когда заблокированы вне back-end

2.1.10

  • Убраны заголовки HSTS, поскольку сложно делать откат

2.1.9

  • Добавлена возможность предотвратить редактирование htaccess в случае петли переадресации.

2.1.7

  • Доработано обнаружение SSL
  • Исправление ошибок во время деактивации плагина

2.1.6

  • Исправлена проблема обнаружения SSL, которая приводила к петле переадресации

2.1.4

  • Улучшены правила переадресации для .htaccess

2.1.3

  • Теперь плагин только изменяет .htaccess, когда один из трех предварительно запрограммированных типов ssl был обнаружен.
  • Упрощено использование фильтра, чтобы добавлять ваши собственные ссылки под замену, смотрите f.a.q.
  • Стандартная переадресация javascript, если переадресация .htaccess не удалась

2.1.2

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

2.1.1

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

2.1.0

  • Добавлен контроль версии в правила .htaccess, чтобы .htaccess также обновлялся.
  • Добавлено обнаружение распределителя нагрузки и cdn, чтобы правила .htaccess могли правильно применяться. Исправляет некоторые проблемы с петлями переадресации
  • Добавлена возможность отключения автозамены небезопасных ссылок
  • Добавлено сканирование вебсайта на небезопасные ссылки
  • Добавлено обнаружение siteurl и homeurl, определенных в wp-config.php, что могло предотвратить успешное изменение ссылки.
  • Сброшены настройки принудительного ssl (используется когда ssl не обнаружен)
  • Благодарность Peter Tak, PTA security за упоминание, что безопасность owasp — лучший вариант https://www.owasp.org/index.php/HTTP_Strict_Transport_Security в .htaccess,

2.0.7

  • Добавлена переадресация 301 в .htaccess для нужд seo

2.0.3

  • Исправлены опечатки в readme
  • Добавлены скриншоты
  • Исправлена ошибка, при которой во время деактивации https не убирался из siteurl и homeurl

2.0.0

  • Добавлено обнаружение SSL при открытии страницы в директории плагина через https
  • Добавлена переадресация https в .htaccess, когда возможно
  • Добавлены предупреждения и сообщения для улучшения удобства пользования
  • Добавлена автоматическое изменение siteurl и homeurl на https для защиты backend с помощью ssl.
  • Добавлена поддержка сброса кэша для WP fastest cache, Zen Cache и W3TC
  • Исправлена ошибка, при которой siteurl был использован как ссылка для исправления вместо homeurl
  • Исправлена проблема, при которой ссылка не заменялась во front end, когда используемая в содержимом ссылка отличалась от домашней (например http://www.domain.com как homeurl и http://domain.com в содержимом)
  • Добавлен фильтр, чтобы вы могли добавлять cdn ссылки в заменяемый скрипт
  • Добавлен googleapis.com/ajax cdn в скрипт замены стандартов, так как он часто используется без https/

1.0.3

  • Улучшены инструкции по установке

ru.wordpress.org

Подготовка

Сначала нам необходимо получить сам SSL сертификат, можно его купить, можно использовать и бесплатный. В этой статье мы будем рассматривать самый простой случай, когда сертификат установит сам хостер. Вариант еще проще — получить в 2 клика бесплатный сертификат у Beget.

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

  • Если сайт открылся — все хорошо, переходим к следующему пункту.
  • Если не отрылся — подождите 10-15 минут и проверьте снова. Если нет — нужно разбираться, правильно ли установлен сертификат.
  • Если произошел редирект на http версию — нужно искать в плагинах, functions.php или в htaccess правила для редиректа и удалить их

Меняем адрес сайта в настройках

Заходим в Настройки – Общие и вбиваем новый адрес с https, сохраняем

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

Заходим на сайт и проверяем, например, меню или ссылки на Ваши статьи. Они должны идти уже по новому протоколу.

Если сайт перестал открываться?

Нам нужно вернуть протокол обратно и искать проблему в плагинах или functions.php самой темы.

Идем в wp-config.php и добавляем туда следующий код:

define('WP_HOME','http://yoursite.ru');  define('WP_SITEURL','http://yoursite.ru');

Где yoursite.ru заменяем на Ваш сайт с протоколом http. Таким образом мы жестко в коде прописываем старый адрес адрес сайта.

Теперь нужно найти причину поломки или редиректа. Методично отключайте плагины, убирайте код из wp-config.php и проверяйте — не заработал ли сайт. Потом смените тему на стандартную и попробуйте тоже самое. Откройте .htaccess, который лежит в корне сайта, возможно причина там.

Меняем адрес сайта в статьях

Теперь нам нужно изменить адрес ссылок в самих статьях. Делать это вручную — занятие долгое и неэффективное. Тут нам на помощь прийдет любимый search-replace.

Вбиваем слева адрес сайта с http, справа адрес с https. Жмем Dry Run. Проверяем внизу в результатах все ли впорядке, все ли правильно меняется. Жмем Live Run. И проверяем ссылки в наших статьях.

смена протокола http на https через search-replace

Теперь все ссылки должны идти по новому протоколу.

Если что-то пошло не так?

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

Повторите шаг, но в этот раз все еще раз перепроверьте, правильно ли выполняется замена при Dry Run. Если проблему устранить не получается — обратитесь за консультацией к специалисту.

Меняем протокол в Вашей теме

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

Сюда же входит различное подключение стилей и скриптов с внешних ресурсов. Виджеты обратных звонков, чаты, счетчики, попапы и пр.

Выкачиваете свою тему на компьютер. Делаем поиск фрагмента «http://» в файлах Вашей темы. Например, с помощью Sublime это можно сделать сразу во всех файлах темы. Меняем пути на правильные, а еще лучше переписываем через функции (необходимы минимальные знания в разработке).

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

http://site.ru/ на //site.ru

Правильный редирект с http на https

Ставить редирект не спешите. Яндекс рекомендует подождать, пока домены склеятся. Для Google можно сразу настраивать редирект. Лучше всего сначала дождаться склейки, потом ставить редирект. Подробнее про поисковые системы напишем ниже.

В файле .htaccess пропишите в начало:

RewriteEngine On  RewriteCond %{THE_REQUEST} ^[A-Z]{3,9} /(.*) HTTP/ [NC]  RewriteCond %{HTTPS} off [NC]  RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI}%{QUERY_STRING} [R=301,QSA,L]  

Если не сработало, попробуйте

RewriteEngine On  RewriteCond %{HTTPS} =off   RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [QSA,L]  

Здесь мы устанавливаем редирект на серверном уровне. Обратите внимание на то, что мы явно указываем на 301 редирект.

Второй вариант, используя php:

add_action('init', 'redirect_http_to_https');  function redirect_http_to_https(){   if( is_ssl() ) return;     if ( 0 === strpos($_SERVER['REQUEST_URI'], 'http') )   wp_redirect( set_url_scheme( $_SERVER['REQUEST_URI'], 'https' ), 301 );   else   wp_redirect( 'https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'], 301 );   exit;  }

Данный код лучше разместить в своем плагине или в папке mu-plugins, в крайнем случае в functions.php Вашей темы. Чтобы при смене темы Вы не потеряли все редиректы.

Можно использовать оба варианта, но первый предпочтительнее, чтобы запросы обрабатывал сервер, а не PHP.

Как смена протокола влияет на SEO

Не забудьте сменить адрес сайта в robots.txt, указать новое главное зеркало в панели вебмастера поисковых систем.

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

В данный момент Google обещает отдавать предпочтение сайтам с https, как оно будет на практике покажет время.

Рекомендации Яндекса

UPD: Яндекс отказался от директивы Host, сейчас для Яндекса инструкция простая. Добавили домен, сразу настроили редирект.

Яндекс дал свои рекомендации по переезду, подробнее тут. Обязательно рекомендую изучить. Если коротко:

  1. Добавить новый сайт в панель вебмастера
  2. Настроить в robots директиву Host, важно, чтобы robots.txt был одинаковый у обоих сайтов. Не актуально.
  3. После признания обоих сайтов зеркалами, зайти и сменить протокол в вебмастере «Настройки индексирования — Главное зеркало». Подождать несколько недель, пока не определиться главное зеркало.
  4. Настроить редирект со старого протокола на новый.

Рекомендации Google

Про перенос сайта для Google можно прочитать тут и тут.

  1. Добавить новый сайт в Search Console
  2. Убедиться, что со старого сайта с каждой страницы идет 301 редирект на новый

Как правильно переехать без потери позиций

  1. Убеждаемся, что все страницы правильно работают с https
  2. Прописываем в robots дерективу Host с https. Не актуально.
  3. Добавляем новый сайт (с https) в Вебмастер Яндекса
  4. Ставим редиректы 301 с http на https
  5. Добавляем новый сайт в Вебмастер Гугла

wpschool.ru


You May Also Like

About the Author: admind

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

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

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