Переход на HTTPS без потери трафика из Яндекс и Google

Всем большой привет! Браузер Google Chrome не намерен отступать от своих намерений и движется вперёд по намеченному пути, внедряя предупреждения безопасности для HTTP сайтов. Mozilla Firefox также активно пропагандирует протокол HTTPS, подталкивая вебмастеров устанавливать SSL сертификаты на свои сайты. Но как избежать проблем, связанных с потерей трафика и дохода?

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

10 последовательных шагов по переезду сайта на HTTPS

Всего мною было переведено 6 сайтов. Первый шаг был сделан 18 сентября 2016 года, тогда я стал записывать в блокноте все свои действия. Сегодня эти записи помогут мне сформировать цельную инструкцию по переезду сайта на работу по HTTPS протоколу без потери трафика из поисковых систем.

1. Получение SSL сертификата

Первое, что необходимо сделать – приобрести SSL сертификат (платный или бесплатный) и подключить его к домену. Это можно сделать самостоятельно в панели управления хостингом (ISPmanager, CPanel, VestaCP) или обратиться за помощью в техподдержку. Некоторые хостеры предлагают подключить бесплатный SSL с автоматическим продлением в один клик.

Но сегодня я не стану затрагивать вопросы, связанные с выбором и установкой SSL сертификата – это отдельная тема. Сейчас у меня подключены сертификаты Let’s Encrypt. До этого использовал StartSSL, но после шумихи с бесплатными SSL-сертификатами StartCom и WoSign последовала закономерная блокировка этих удостоверяющих центров в популярных браузерах.

2. Внесение изменений в robots.txt

Давайте перейдём к файлу robots.txt и изменим директиву Host, указывающую на главное зеркало:

Host: https://webliberty.ru

Если директива Host не использовалась раньше, тогда добавьте ее в любом месте, т.к. она является межсекционной. Согласно справке Яндекса, если сайт работает по защищённому каналу связи, то обязательно указывать протокол.

3. Переезд сайта в сервисе Яндекс Вебмастер

Теперь необходимо зайти в Яндекс Вебмастер и в разделе Индексирование перейти на страницу Переезд сайта. Отметьте флажком Добавить HTTPS и сохраните изменения.

Появится информационное сообщение о том, что Яндекс не гарантирует сохранение количества страниц сайта в поиске, его позиций или посещаемости в случае изменения главного зеркала:

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

Именно поэтому при переезде сайта особое внимание нужно уделить этой поисковой системе, в то время как Google достаточно простого редиректа для склейки. В принципе, склейку зеркал я уже делал при исключении www из URL, в этом нет ничего сложного.

4. Добавление нового сайта в Google Search Console

В Google нет инструмента переезда, поэтому просто добавьте в Search Console новый сайт с HTTPS. Старый можно не удалять, он может понадобиться в дальнейшем для анализа процедуры перехода.

Да, в консоли есть инструмент Изменение адреса, но знайте, что в данном случае он не поможет, т.к. в справочной системе есть примечание:

5. Работа с картой сайта sitemap.xml

Переходим к карте сайта sitemap.xml. На всех сайтах у меня сформирован минимальный набор необходимых плагинов, в частности за карту сайта отвечает одноимённый модуль в составе плагина All in One SEO Pack. Если вы используете этот же плагин, то в настройках модуля включите опцию Динамическая карта сайта. Таким образом поисковый робот при доступе к сайту по защищённому протоколу будет получать карту, содержащую список URL с HTTPS, что ускорит индексирование по новому адресу.

Ещё в сентябре 2016 года в основных настройках плагина была возможность переключения протокола для канонических ссылок и я это прекрасно помню по сайтам-первопроходцам. Начиная с версии 2.3.11 в Canonical URL были внесены изменения, связанные с автоматической установкой протокола, поэтому на следующих сайтах такой опции я уже не обнаружил. Очень жаль, эта функция позволяла получать роботу карту сайта с URL по HTTPS даже при посещении HTTP версии сайта.

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

remove_action ('wp_head', 'rel_canonical');
add_action ('wp_head', function() {
	if (!is_singular()) {
		return;
	}
	$id = get_queried_object_id();
	if (!$id) {
		return;
	}
	$cpage = get_query_var('cpage');
	if ($cpage) {
		$url = get_comments_pagenum_link($cpage);
	} else {
		$url = get_permalink($id);
		$page = get_query_var('page');
		if ($page > 1) {
			if (get_option('permalink_structure') == '') {
				$url = add_query_arg('page', $page, $url);
			} else {
				$url = trailingslashit($url) . user_trailingslashit($page, 'single_paged');
			}
		}
	}
	$url = str_replace('http://', 'https://', $url);
	echo " 	 	<link href="\"{$url}\"" rel="\"canonical\"">\n";
});

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

Теперь вернёмся к нашему файлу robots.txt и внесём изменения в пути до карты сайта или добавим нужную строку, если ранее её не использовали:

Sitemap: https://webliberty.ru/sitemap.xml

А в Яндекс Вебмастере и Google Search Console нужно добавить обновлённую карту сайта с новым протоколом.

6. Замена внутренних ссылок на HTTPS, решение проблемы Mixed Content

Дальнейшее действие подразумевает замену всех абсолютных путей к стилям, скриптам, изображениям, а также замену всех внутренних ссылок по протоколу HTTP на относительные или простую замену протокола Я предпочёл сменить протокол путей и ссылок на HTTPS и ниже поделюсь с Вами как это можно быстро сделать с помощью SQL-запросов к базе данных.

При сохранении записи в таблицу wp_posts в поле guid записывается глобальный уникальный идентификатор (Globally Unique Identifier). Давайте изменим это поле для смены протокола, выполнив следующий запрос к БД через phpMyAdmin:

UPDATE wp_posts SET guid = REPLACE(guid, 'http://webliberty.ru','https://webliberty.ru');

Произведём замену протокола всех ссылок в контенте, то есть выполним запрос к полю post_content в таблице wp_posts нашей базы данных:

UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://webliberty.ru', 'https://webliberty.ru');

В комментариях, отвечая на вопросы пользователей, я зачастую ссылаюсь на свои прочие записи, поэтому необходимо провести замену протокола ссылок и в комментариях. Для этого внесём изменения в поле comment_content таблицы wp_comments следующим образом:

UPDATE wp_comments SET comment_content = REPLACE(comment_content, 'http://webliberty.ru', 'https://webliberty.ru');

На что следует обратить внимание при выполнении этих SQL-запросов:

• обязательно замените адрес сайта на свой,
• измените префикс таблиц, если он отличается от стандартного wp_.

SQL-запросами мы внесли львиную долю изменений, но есть места, где всё же придётся поработать вручную — это могут быть файлы темы и виджеты, где используются внутренние ссылки с HTTP протоколом. Также стоит обратить внимание на загрузку внешних стилей, скриптов, фреймов и картинок — все они должны загружаться по HTTPS, иначе они не будут загружены, а в консоли появятся ошибки смешанного содержимого (Mixed Content).

7. Решение проблемы политики CORS

Если на сайте подключены шрифты Font Awesome, тогда они могут не загружаться — это связано с появлением в консоли браузера ошибки примерно такого содержания:

Чтобы избежать появления ошибки достаточно добавить в файл .htaccess строку:

Header set Access-Control-Allow-Origin *

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

Header set Access-Control-Allow-Origin http://webliberty.ru

CORS (Cross-origin resource sharing) в переводе с английского языка означает совместное использование ресурсов между разными источниками. Современные браузеры используют эту политику безопасности в своих технологиях. До тех пор, пока мы не поставим редирект с HTTP на HTTPS эта политика будет действовать, поэтому используем строку до заключительного этапа.

8. Ожидание склейки зеркал в Яндексе

Ждём письма от Яндекс Вебмастера (или уведомления, если не настроена рассылка) о смене главного зеркала. До тех пор, пока это уведомление не поступит, ни в коем случае нельзя ставить редирект! В противном случае все страницы сайта будут исключены из индекса поисковой системы Яндекс, склейка займет значительно больше времени из-за отсутствия доступа к robots.txt для HTTP версии сайта.

Но есть исключение из этого правила. Допустимо использовать редирект только в том случае, если исключить из общего правила файл robots.txt. Этого можно добиться, используя в .htaccess:

RewriteCond %{SERVER_PORT} !^443$
RewriteCond %{REQUEST_URI} !^/robots.txt
RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]

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

Расскажу о нем немного подробнее. Переезд был запущен 27 января 2017 года, на протяжении трёх месяцев никаких подвижек не происходило, скорее наоборот, ситуация усугублялась из-за странной индексации: через апдейт одни и те же страницы появлялись в выдаче то с HTTP, то с HTTPS — это происходило до марта.

Тогда 10 марта я решил поставить редирект на все страницы, кроме robots.txt и стал ожидать подвижек. Числа 20 в Яндекс Каталоге наконец-то у домена сменился протокол на HTTPS, но с апдейтами в индекс по-прежнему залетали старые страницы, включая самые нелепые, которых и вовсе никогда не существовало. Возникало ощущение, что поисковый робот Яндекс вышел из ума и хватал все подряд, лишь бы зацепиться.

Точку в этом вопросе поставило моё обращение в службу поддержки Яндекса, в котором я описал ситуацию. Кстати, если ваш сайт не меняет главное зеркало более месяца, несмотря на соблюдение всех условий, рекомендую не тянуть время и обращаться. Достаточно заполнить специальную форму на этой странице, скрытую под формулировкой «Заявка на переезд не принимается»:

Ответ техподдержки внушал доверие, но в голове всё равно вертелись мысли, мол наверняка всем так отвечают:

На следующий день был апдейт поисковой выдачи, а также тИЦ. Не знаю, совпадение или нет, но уже на следующий день я наконец-то получил долгожданное уведомление о смене главного зеркала! Думаю, что моё обращение сыграло свою роль 🙂

9. Настройка 301 редиректа с HTTP на HTTPS

Теперь, когда этап склейки зеркал в Яндексе пройден, можно приступать к завершающему этапу. Заходим в консоль WordPress, в разделе Настройки — Общие меняем в полях Адрес WordPress и Адрес сайта протокол нашего сайта на HTTPS.

Открываем phpMyAdmin и выполняем следующий SQL-запрос к базе данных, с помощью которого делаем замену полей с опциями home и siteurl в таблице wp_options:

UPDATE wp_options SET option_value = REPLACE(option_value, 'http://webliberty.ru', 'https://webliberty.ru') WHERE option_name = 'home' OR option_name = 'siteurl';

В файле .htaccess ставим постоянный редирект с HTTP на HTTPS:

RewriteCond %{SERVER_PORT} !^443$
RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]

10. Настраиваем заголовок HTTP Strict Transport Security

Последний штрих — устанавливаем форсированное защищённое соединение через протокол HTTPS с помощью механизма HSTS (HTTP Strict Transport Security). Браузер будет принудительно загружать сайт по защищённому протоколу, для чего в .htaccess нужно добавить строку:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

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

Подведение итогов

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

Стоит отметить, что в последнее время Яндекс стал чаще выкатывать апдейты поисковой выдачи (практически через день), поэтому переезд не растянется на продолжительный период. А Google активно начинает индексировать сайт по новому протоколу после настройки редиректа, с ним проблем быть не должно.

Графики посещаемости я не стал публиковать, но могу гарантировать — снижения трафика не наблюдалось, даже более того, по некоторым проектам зафиксирован незначительный рост 😎 Желаю всем удачи!