Еще осенью писал статью о том, стоит ли переезжать на SSL блогерам, и кому это просто необходимо сделать. За прошедшее время с момента написания той статьи я уже перенес несколько сайтов на SSL и поделюсь собственными наработками.
Покажу наиболее простой способ переноса сайта на защищенный протокол HTTPS, который сам применяю. Кстати, на этом блоге тоже был совершен переезд на SSL именно таким образом.
Предупреждаю сразу, что статья длинная, со множеством картинок, так как в свое время, читая подобные мануалы, у меня у самого возникало множество вопросов.
Про новичков вообще молчу.
Поэтому, я постарался написать все максимально подробно, чтобы даже опытный seo-шник сразу все понял =)
Ладно, если без шуток, то особенность этого метода в том, что скорее всего, у вас вообще не будет проблем со смешанным содержимым (mixed content), заветный зеленый значок появится сразу, и самое главное, не будет проблем с загадочными сериализованными данными.
1. Подготовительная работа к переезду на HTTPS
Во-первых, я порекомендую сразу проверить сайт на … предмет заражения вирусами. Не, я не шучу, так как когда начал переводить один из заброшенных сайтов в тренировочных целях на SSL, то обнаружил, что он насквозь дырявый =)
То есть, не должно получиться так, что вы проделали много работы, а потом выяснится, что вы ковырялись уже с зараженным сайтом. И все придется начинать сначала, так как в страницы сайта (или блога) внедрен вредоносный код, который никак не дает появиться заветному “зеленому замочку”.
Да, я именно так и обнаружил сторонний код, так как никак не мог добиться того, чтобы появился зеленый значок, из-за которого все и затевалось. Я даже разбираться с тем ГС-сайтом не стал, а просто снес к чертовой матери, вместе с бесплатным SSL-сертификатом.
Чем проверять сайт?
Более чем достаточно проверить при помощи:
- Замечательного плагина безопасности WordFence Security
- Или при помощи сервиса VirusDie. Этот сервис платный, но 1 сутки дают на тест. Сам пользуюсь, всем рекомендую.
2. Временно выключаем плагины кеширования и безопасности
Непосредственно на момент переезда рекомендую выключить плагины безопасности. Например, рекомендую отключить Ithemes Security, WordFence Securiry если используете их, так как могут возникнуть проблемы со входом в админку.
Плагин кеширования тоже лучше на время отключить, чтобы он не отдавал старые, закешированные страницы посетителям и поисковым системам.
Настоятельно рекомендую отключить в плагинах безопасности файрвол, который может помешать поисковым роботам нормально пересканировать сайт. Сам с такой проблемой столкнулся, кстати.
3. Обязательно делаем резервную копию сайта. А лучше две =)
Думаю, что не нужно объяснять, насколько важно это сделать. Все люди взрослые собрались в автономном блоггинге, как говорится. Да и честно говоря, что-то мало видно молодых блоггеров в автономной блогосфере в последнее время.
Остались одни seo-шники, да настоящие энтузиасты, которым не нужно объяснять такие элементарные вещи.
4. Приобретаем SSL-сертификат
Лично я предпочел использовать платный сертификат Comodo Positive SSL, который обошелся мне на два года за 800 рублей. Ну куда уж дешевле-то?
Из бесплатных сертификатов могу порекомендовать только Lets Encrypt, который единственный из всех бесплатных вариантов SSL-сертификатов вызвал у меня доверие.
Остальные бесплатные варианты SSL-сертификатов вызывают большие сомнения на фоне последних скандалов, когда FireFox отказался их поддерживать. И многие экономные админы стали срочно использовать другие бесплатные SSL-сертификаты. (оцените тошноту текста, да =)
Я рассматривал сначала использование сертификата Lets Encrypt, тем более, что в ISPmanager есть возможность его быстро (и бесплатно) подключить. Но почитав официальный форум, понял, что некоторые вебмастера, которые используют ISPmanager, испытывают проблемы с его продлением, которое происходит каждые три месяца.
Лично мне не понравилась идея каждые три месяца напрягаться по такому пустяку. Лучше отдать 800 рублей за два года и не забивать свое время всякой ерундой каждые три месяца.
5. Устанавливаем SSL-сертификат
Тут все просто, на самом деле. Если не знаете как это делается, то лучше попросите сделать это поддержку хостера, чтобы дров не наломать на пустом месте.
Так как я в основном использую VPS, то пришлось немного повозиться с настройками аккаунта в ISPmanager.
Но опять-же, установка сертификата в ISP занимает несколько минут. Достаточно лишь прописать данные, которые получите от центра сертификации
А затем активировать его в настройках для WWW-домена.
Кстати, если не знаете как работать с ISPmanager, то можете почитать вот здесь: https://ideafox.ru/pro-blog/nastrojka-vps-servera-za-47-minut-na-ispmanager-5-lite.html
Ничего трудного в этом нет.
Но если используете виртуальный хостинг, то там все иначе, конечно. И, повторюсь, самый простой вариант – это попросить установить SSL-сертификат поддержку хостера.
Но делать это нужно только тогда, когда полностью будете готовы к переезду на HTTPS, чтобы процесс переезда не растянулся на несколько недель. Дело в том, что сайт начиная с этого момента будет доступен для поисковых роботов одновременно по двум протоколам. По HTTPS и по HTTP.
И может получиться так, что они подхватят сайт уже по защищенному протоколу, который посчитают приоритетным. Про подобные случаи читал на SEO-форумах.
6. Самый главный шаг, на котором многие спотыкаются
Если почитать подобные инструкции от других вебмастеров, то мы добрались до самого муторного шага. А именно – нам нужно поменять все ссылки на сайте с вида
http://site.ru/bla-bla-bla.html
на
httpS://site.ru/bla-bla-bla.html
Или, как вариант, убрать из ссылок прямое указание на действующий протокол, сделав их относительными.
И вот тут-то и начинаются проблемы, так как на некоторых сайтах плагины, которые предназначены для таких целей отказываются работать. Например, у меня не получилось сделать эту операцию при помощи всем известного плагина Velvet Blues Update Urls.
Так как у меня сайт технически довольно сложный, то он категорически отказался корректно обработать страницы, созданные при помощи плагина Optimize Press.
7. Что точно не нужно делать при переезде на HTTPS?
По сети гуляют рекомендации, что достаточно скачать базу данных сайта, открыть ее в текстовом редакторе, и при помощи поиска с заменой поменять протокол.
Делается это примерно вот так в текстовом редакторе Notepad ++
То есть, вебмастер просто скачивает свою базу данных сайтов, открывает ее в Notepad ++ и меняет ручками все ссылки, которые относятся к его сайту.
Но загвоздка в том, что в базе данных сайта для WordPress часто данные хранятся в так называемом сериализованном виде. Не буду говорить, что я являюсь спецом в сериализованных данных : ) Но точно знаю, что так делать точно не нужно, так как это может повлечь проблемы.
Сайт может просто отказаться работать, или начать глючить в будущем, при обновлении движка, плагинов или тем.
Да и в рекомендациях от самих разработчиков WordPress говорится вот что:
If you do a search and replace on your entire database to change the URLs, you can cause issues with data serialization, due to the fact that some themes and widgets store values with the length of your URL marked. When this changes, things break. To avoid that serialization issue, you have four options
- Use the Velvet Blues Update URLs plugin if you can access your WP Admin Dashboard.
- Use the Better Search Replace plugin if you can access your WP Admin Dashboard.
- Use WP-CLI’s search-replace if your hosting provider (or you) have installed WP-CLI.
- Use the Search and Replace for WordPress Databases Script to safely change all instances on your old domain or path to your new one. (** only use this option if you are comfortable with database administration ** )
https://codex.wordpress.org/Moving_WordPress
Перевод:
Если вы делаете поиск и замену по всей базе данных, чтобы изменить URL-адреса, вы можете вызвать проблемы с сериализации данных, в связи с тем, что некоторые темы и виджеты хранят данные с учетом длины вашего URL. Когда это изменится, то возможен сбой. Чтобы избежать этой проблемы сериализации, у вас есть четыре варианта…
Вы, конечно, можете попробовать четыре варианта, которые представлены выше, но сразу скажу, что ни один из них не является панацеей.
В любом случае придется повозиться с картинками, со смешанным контентом. Обязательно что-то вылезет, что не даст загореться заветному зеленому значку в поисковой строке сразу.
Я подумал, что проклятые буржуины =) ценят свое время, и наверняка есть БОЛЕЕ простой способ замены протокола на WordPress. Ну не может быть такого, чтобы все вебмастера мира так долго и нудно возятся с переездом на HTTPS.
Наверняка есть более простое решение, решил я.
8. И почти сразу нашел более простой способ миграции на SSL при помощи плагина Duplicator
Этот способ хорош тем, что проблем с вероятностью в 99% вообще не возникнет. Также этот способ НЕ вызывает проблем с сериализованными данными.
Есть очень популярный плагин, который называется Duplicator. Опять-же, по неведомой причине, он малоизвестен в России. Между тем, он на данный момент имеет почти миллион активных установок.
9. Устанавливаем плагин Duplicator
Думаю, что не нужно объяснять как это делается. Если вы собрались подключать SSL-сертификат, но не знаете, как установить плагин WordPress, то лучше подождать пару дней, пока не научитесь работать с движком WordPress =)
Правда, я не шучу, так как научиться работать с ВордПресс можно за пару дней:
10. Делаем резервную копию сайта при помощи Duplicator
Заходим вот сюда: “Duplicator” – “Пакеты”
Нажимаем на кнопку “Создать новый”
Жмем на кнопку “Далее”
Сайт будет просканирован на возможные ошибки
В моем случае выскочило предупреждение, что нужно оптимизировать базу данных сайта. На этот момент можно не обращать внимание, так как это сообщение всегда появляется.
Жмем на кнопку “Создание”, после чего начнется создание резервной копии сайта:
Чем больше сайт, тем больше придется ждать. Но сразу скажу, что для очень больших сайтов, размером более, чем 500 мегабайт, процесс создания пакета может завершиться с ошибкой.
В платной версии Duplicator таких проблем нет, так там можно задать более тонкие настройки для больших сайтов (но не более, чем 8 гигабайт).
Так как мой блог довольно тяжелый и дряхлый, то мне пришлось купить платную версию этого плагина. Но на небольших сайтах и блогах размером примерно до 300 мегабайт таких проблем быть не должно и достаточно бесплатной версии плагина Duplicator.
После завершения создания резервной копии сайта ОБЯЗАТЕЛЬНО скачиваем два файла:
- Файл установщика installer.php
- Zip-Архив сайта, который всегда имеет длинное название из цифр и букв.
Фактически, мы получили полную резервную копию сайта. Сам плагин в дальнейшем пригодится как раз для быстрого создания резервных копий сайта. Так как у меня теперь платная версия, то я настроил резервное копирование своих сайтов в облачное хранилище.
Очень удобно. Пожалуй, даже лучше, чем штатное резервное копирование, которые используется в ISPmanager.
11. Удаляем сайт, чистим базу данных
Дальше пойдут только отчаянные вебмастера =), так как придется удалить сайт. Полностью.
И еще раз убедитесь, что у вас есть резервная копия сайта, которую сделали до всех этих манипуляций с сайтом, чтобы всегда можно было откатиться назад.
Что нужно сделать для восстановления сайта из резервной копии, которую создали при помощи Duplicator?
- Для этого необходимо полностью очистить корневой каталог сайта (но не все служебные каталоги и файлы на хостинге, разумеется =)
- Найти/вспомнить имя и пароль и имя пользователя к базе данных сайта. Убедится, что они рабочие. На крайний случай, пароль к базе данных можно поменять в панели управления хостингом.
Для новичков напомню, что корневой катало сайта, который работает на WordPress, это тот каталог, где находятся файлы и каталоги движка wp-admin, wp-content, и так далее:
Все удаляем из корневого каталога и уже в пустой каталог заливаем два файла, которые скачали ранее.
В моем случае получилось вот так:
Очищаем базу данных сайта через PHPmyAdmin:
Обратите внимание, что нужно обязательно очистить старую базу данных сайта. Как вариант, можно создать новую базу данных, куда и зальются новые таблицы.
Далее переходим по следующей ссылке в браузере: site.ru/installer.php, где вместо site.ru подставите имя вашего домена.
Вы увидите следующее окно, где нужно указать логин и пароль к базе данных.
Еще раз подчеркну, что указывать нужно только для чистой базы данных. То есть, нужно либо очистить старую БД, либо создать новую БД.
12. Самый главный шаг!
Обратите внимание на этот скриншот. В настройках New Settings я просто добавил букву “s” в протокол сайта. Да, еще важно. Когда я делаю реальный переезд сайта, то удаляю слэш “/”на конце нового адреса сайта.
Непонятно, зачем плагин подставляет этот слэш по-молчанию, но я его также автоматически удаляю.
После завершения операции восстановления сайта вот что увидите:
Можете понажимать на эти кнопки, но скорее всего, у вас ничего не получится, так как вас будет перенаправлять по старому адресу админки ВордПресс, без учета того, что теперь используется протокол HTTPS.
Поэтому, сразу переходим в админку сайта. Только не забудьте, что входим уже не по ссылке вида:
http://site.ru/wp-admin,
а используем ссылку вида
httpS://site.ru/wp-admin
Первое, что мы увидим в админке, так это предупреждение о том, что нужно почистить зарезервированные файлы установки Дупликатора:
Переходим по ссылке, как на рисунке:
И по очереди нажимаем на три кнопки
Обязательно проверьте что в корне сайта НЕ остался zip-архив вашего сайта, который мы заливали ранее, вместе с файлом installer.php. Просто удалите его, в целях безопасности.
Переходим в настройки WordPress и и убеждаемся, что протокол автоматически сменился на HTTPS
Заодно и другие настройки движка проверьте.
Но я еще ни разу не сталкивался ни с какими-либо проблемами при использовании этого метода. Сайт полностью, в автоматическом режиме переносится на HTTPS.
Нет проблем со смешанным контентом, сразу загорается зеленый значок, что сайт работает по защищенному протоколу.
Еще осталось сделать несколько важнейших шагов.
13. Обязательно прописываем в robots.txt:
Host: https://site.ru Sitemap: https://site.ru/sitemap.xml
Эти директивы в robots.txt подскажут ботам Яндекса, что сайт переезжает на новый протокол. Понятно, что вместо site.ru пишем имя своего домена.
14. Включаем 301 редирект в файле .htaccess
Для большинства хостингов достаточно будет прописать в htaccess две строчки, которые включают 301 редирект:
RewriteCond %{SERVER_PORT} !^443$ RewriteRule ^(.*)$ https://site.ru/$1 [R=301,L]
Если этот код у вас не сработает, то обратитесь к своему хостеру, он подскажет свое решение. Понятно, что вместо site.ru указываем имя своего домена.
Важно убедиться в Яндекс.Вебмастере, что если кто-то пытается зайти по старому, незащищенному протоколу HTTP на ваш сайт, то он будет переадресован 301-м редиректом на ту-же страницу, но уже по HTTPS.
Советую проверить подобным образом как отвечает главная страница сайта, страницы, записи, рубрики сайта и т.д. Побродите по сайту, убедитесь, что на проблем нет и на каждой странице сайта горит зеленый замок в адресной строке браузера.
Разумеется, все должно быть в рамках приличия, и не нужно обходить каждую страницу сайта, который имеет на борту 100500 статей. Но желательно это сделать =)
Затем убеждаемся, что сайт работает нормально, включаем обратно плагины безопасности, плагин кеширования. Обязательно проверьте настройки плагинов безопасности (если используете их), так как при этом способе переезда на SSL создается новый файл .htaccess. И, по-сути, придется заново настраивать тот-же Ithemes Security.
15. Оповещаем Яндекс о переезде
После проверки корректности работы 301-редиректа и работы сайта в целом, собираем волю в кулак и делаем последний шаг зеленому значку в адресной строке браузера =)
Выпиваем “Успокоительное Средство Вебмастера”, а затем идем в Яндекс.Вебмастер и в пункте меню “Индексирование”- “Переезд сайта” ставим галочку, что переехали на HTTPS.
Как нажмете на кнопку “Сохранить”, то увидите вот такое сообщение:
Примерно через 7-10 дней Яндекс полностью переклеит сайт и увидите в вебмастере еще один сайт, на который тоже нужно будет подтвердить права. То есть, залить HTML-файл валидации в корень сайта.
Как только новый сайт появится в Яндекс.Вебмастере, то сразу укажите для него новый sitemap, уже с учетом HTTPS.
16. Оповещаем поисковую систему Google
Здесь все по-другому. Придется добавить еще один сайт, который содержит в адресе HTTPS. Старый сайт из Google Searche Console удалять НЕ нужно.
Для него тоже необходимо сразу указать обновленный sitemap, для более быстрой индексации.
Какие проблемы могут возникнуть при переезде на SSL?
Единственная техническая проблема, которая может возникнуть, если сайт слишком много весит. Бесплатная версия плагина Duplicator просто захлебнется на этапе создания резервной копии сайта. Но и в этом случае не обязательно покупать платную версию плагина Duplicator, так как есть небольшая хитрость, которая поможет сэкономить 40 долларов на покупку Дупликатора. Но об этой фишке я расскажу в другой раз, а то статья получилась слишком большой.
Если сделаете все правильно, то просадка по трафику будет минимальной.
Вот, собственно, и все
К моему удивлению, инструкция получилась просто огромной, хотя если это все делать в реальном времени, то переезд на SSL займет примерно 30-60 минут. Не более.
А далее следует запастись терпением и сходить в магазин за успокоительным =)
P.S. И еще раз настойчиво рекомендую на 3-4 недели отключать любые файрволы на сайте, так как они могут запросто забанить поисковых ботов. Я сам попался в ловушку собственной паранойи=), и до сих пор у меня штормит трафик из Google на этом блоге.
С Яндексом, как ни странно, проблем вообще не возникло.