Переход WordPress на HTTPS: смешанный контент, редиректы и что проверить в Вебмастере

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

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

Что именно меняется при переходе на HTTPS

С точки зрения поисковых систем http://site.ru и https://site.ru — два разных сайта. Не две версии одного, а именно два: с раздельными индексами, раздельными позициями и раздельно накопленными сигналами. Задача переезда — не просто включить шифрование, а корректно склеить эти два сайта в один и передать всё накопленное новой версии.

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

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

Третье — служебные файлы. Карта сайта, robots.txt, канонические ссылки, разметка, счётчики, ссылки в письмах — везде остаётся старый протокол, и каждое такое место работает против склейки. Общий обзор задачи я давал в материале «Переход с HTTP на HTTPS», здесь же — конкретный порядок для WordPress.

Адреса сайта в настройках: с чего начать

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

Сначала убедитесь, что сертификат установлен и работает: откройте сайт по адресу с https вручную. Если страница открывается, пусть даже без замка, — сертификат на месте. Если браузер ругается на несоответствие имени или на просроченный сертификат, дальше идти нельзя: сначала чините сертификат. Какие бывают типы и чем они отличаются, разбирал в заметке «Что такое сертификат SSL».

Затем меняются два поля в разделе общих настроек: «Адрес WordPress» и «Адрес сайта». Оба переводятся на https. После сохранения вас выкинет из админки — это нормально, войдите заново уже по защищённому адресу.

Если поля недоступны для правки (так бывает, когда адреса заданы константами), меняйте их в wp-config.php:

define( 'WP_HOME', 'https://site.ru' );
define( 'WP_SITEURL', 'https://site.ru' );

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

Смешанный контент: где он прячется

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

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

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

Ловушка, о которой узнают позже всех: настройки тем и конструкторов страниц хранятся не обычным текстом, а в сериализованном виде. Об этом — следующий раздел.

Замена адресов в базе: сериализованные данные

Соблазн велик: выполнить простой SQL-запрос вида замены подстроки по таблице записей и закрыть вопрос. Для содержимого статей это действительно работает. Для настроек — ломает сайт.

Причина в устройстве сериализации. PHP сохраняет массивы строкой, в которой перед каждым значением записана его длина в символах. Строка http://site.ru длиннее строки https://site.ru на один символ. Слепая замена меняет содержимое, но не трогает записанную длину — и PHP при чтении такого массива получает мусор. Внешне это выглядит как слетевшие настройки темы, пропавшие виджеты, пустой конструктор страниц.

Способ замены	Где безопасен	Где ломает	Комментарий
SQL-запрос REPLACE по таблице записей	Поле содержимого записей и страниц	Таблица настроек, метаполя, настройки конструкторов	Быстро, но применимо только к обычному тексту
Плагин поиска и замены с поддержкой сериализации	Вся база целиком	Практически нигде, если включён режим сухого прогона	Оптимальный вариант для большинства сайтов
Консольная утилита WP-CLI, команда search-replace	Вся база, с корректной пересборкой сериализованных значений	Нигде	Требует доступа к командной строке; лучший вариант при его наличии
Ручная правка в phpMyAdmin	Единичные значения, которые вы видите глазами	Массовые операции — велик риск опечатки	Годится для точечной доводки после основной замены
Фильтр в теме, подменяющий протокол на лету	Как временный костыль на день переезда	Как постоянное решение: база остаётся грязной	Не заменяет реальную замену адресов

Практическая рекомендация: делайте замену инструментом, который умеет корректно пересобирать сериализованные значения, и обязательно сначала в режиме предварительного просмотра, где показывается количество совпадений без внесения изменений. Замену выполняйте с полным адресом — http://site.ru на https://site.ru, а не просто http на https: иначе вы переделаете ещё и внешние ссылки на чужие сайты, часть из которых по защищённому протоколу не работает.

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

Редирект на уровне сервера

Даже после замены адресов старые страницы остаются доступны по незащищённому протоколу. Для поисковика это полный набор дублей: каждая страница существует дважды. Лечится единственным правильным способом — постоянным редиректом со старого протокола на новый.

Ставить его надо на уровне сервера, а не плагином. Плагин поднимает всё ядро WordPress ради одного заголовка перенаправления: это лишние запросы к базе и лишние миллисекунды на каждом обращении. Серверное правило отрабатывает до запуска PHP.

На Apache правило добавляется в .htaccess выше блока WordPress:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://site.ru/$1 [R=301,L]

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

Дальше — три проверки. Первая: редирект должен быть один прыжок, а не цепочка. Частая ошибка — сначала перенаправление на версию с www, потом на защищённый протокол, потом на адрес со слешем. Каждый лишний прыжок замедляет ответ и размывает передачу сигналов. Вторая: код ответа должен быть 301, а не 302. Временное перенаправление оставляет старый адрес в индексе. Третья: не должно быть петли — когда сервер бесконечно перебрасывает страницу на саму себя. Типовая причина петли на панельном хостинге — балансировщик, который передаёт запрос уже расшифрованным, из-за чего условие проверки протокола никогда не срабатывает; в этом случае условие пишется по заголовку, который передаёт балансировщик.

Разбор частых ошибок именно этого этапа собран в материале «HTTPS, который убивает SEO: 4 ошибки переезда, после которых трафик падает в ноль».

Канонические адреса, карта сайта и robots.txt

Редирект решает вопрос для тех, кто пришёл по старому адресу. Но поисковику надо ещё явно сказать, какая версия основная. Это делается тремя способами одновременно.

Элемент	Что проверить	Типовая ошибка
Канонический адрес в исходном коде	Ссылка указывает на защищённый адрес той же страницы	Канонический адрес остался на старом протоколе — тогда вы редиректом ведёте на новую версию, а кодом страницы говорите, что главная старая
Карта сайта	Все адреса внутри с защищённым протоколом, дата изменения свежая	Карта сгенерирована до переезда и лежит в кэше плагина
Файл robots.txt	Строка со ссылкой на карту сайта указывает на защищённый адрес	Осталась старая строка; робот идёт по редиректу и часть систем это игнорирует
Внутренние ссылки в шаблонах	Меню, логотип, кнопки, футер ведут на защищённые адреса	Жёстко прописанные адреса в файлах темы, которые замена по базе не задела
Разметка и метатеги для соцсетей	Адреса изображений и страницы указаны с новым протоколом	Метатег с адресом картинки собирается из старого значения в настройках
Счётчики и внешние сервисы	В настройках счётчика указан адрес с защищённым протоколом	Статистика начинает считаться как для нового сайта

Отдельно про канонические адреса: это самая частая причина того, что переезд «сделан», а поиск продолжает показывать старые адреса. Проверяется за минуту — откройте исходный код любой страницы и найдите строку с указанием канонической ссылки. Подробно логика канонических адресов и их взаимодействие с редиректами разобрана в материале «Полный гайд по канониклам, редиректам и дублям: разбираем раз и навсегда», а про устройство самой карты сайта — в статье «Карта сайта Sitemap».

Переклейка зеркал в Вебмастере

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

Дальше в разделе переезда сайта указывается, что основным зеркалом становится версия с защищённым протоколом. Панель проверит, что редирект настроен корректно и что обе версии доступны для проверки, и поставит задачу на переклейку. Занимает она обычно от нескольких дней до двух-трёх недель.

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

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

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

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

Чего ждать от позиций и когда переезд не нужен

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

Просадка на пару недель — нормальное явление даже при идеально сделанном переезде. Ненормально — просадка, которая длится второй месяц и не восстанавливается. Это всегда означает недоделанную склейку: где-то остались доступные страницы на старом протоколе, канонические адреса указывают не туда или редирект отдаёт временный код.

Отдельно — три ситуации, когда переезд лучше отложить. Первая: сайт находится в процессе других крупных изменений — смены структуры адресов, переноса на новый движок, редизайна. Смешивать два переезда нельзя, потому что при просадке вы не поймёте, что именно её вызвало. Вторая: сертификат бесплатный и продлевается вручную. Просроченный сертификат отдаёт браузеру ошибку и обнуляет трафик за сутки; переезжать имеет смысл только на автоматическое продление. Третья: на сайте много старого содержимого с жёстко прописанными адресами внешних ресурсов, работающих только по незащищённому протоколу — например, встроенные виджеты давно заброшенных сервисов. Их надо сначала убрать, иначе замок пропадёт сразу после переезда.

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

Частые вопросы

Обязателен ли платный сертификат? Для обычного сайта нет. Бесплатные сертификаты с автоматическим продлением шифруют соединение так же и распознаются браузерами одинаково. Платные нужны там, где требуется расширенная проверка организации или покрытие нестандартного набора поддоменов.

Можно ли обойтись плагином принудительного перевода на HTTPS? Как временная мера на день переезда — можно. Как постоянное решение — нет: база остаётся с адресами на старом протоколе, а перенаправление выполняется средствами PHP на каждом запросе. При отключении плагина сайт мгновенно вернётся в исходное состояние.

Надо ли менять адреса в счётчиках и рекламных кампаниях? Да. В настройках счётчика указывается адрес сайта, в объявлениях — ссылки на страницы. Если оставить старый протокол, каждый переход будет проходить через редирект, а часть систем аналитики начнёт считать переходы как с внешнего источника.

Сколько держать редирект со старого протокола? Постоянно. Внешние ссылки на старые адреса живут годами, и снятое правило превратит их в недоступные страницы.

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

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

Коротко

• Для поисковика версии сайта на разных протоколах — два разных ресурса; задача переезда не в сертификате, а в полной склейке.
• Порядок такой: сертификат, адреса в настройках, замена адресов в базе, серверный редирект, канонические адреса и карта сайта, переклейка в Вебмастере.
• Массовая замена по базе обязана корректно пересобирать сериализованные значения, иначе слетят настройки темы и конструктора страниц.
• Редирект ставится на уровне сервера одним прыжком с постоянным кодом; цепочки и петли — самые частые причины неудачного переезда.
• Канонический адрес, оставшийся на старом протоколе, отменяет весь эффект редиректа: поиск продолжит держать в индексе старые адреса.
• Просадка на две-три недели нормальна; просадка второго месяца означает недоделанную склейку, а не «алгоритм так решил».

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