«Я боялась, что миграция на HTTPS сломает сайт, и откладывала это 3 месяца: рассказываю, как перевела сайт на HTTPS на Timeweb и не потеряла трафик»

У меня был блог про интерьерные решения — на WordPress, с трафиком 1,5–2 тысячи визитов в месяц. Клиент сказал: «Надо переходить на HTTPS: сейчас это стандарт, плюс позиции в поиске лучше». Я кивнула, а внутри всё сжалось: в голове крутились страшные сценарии. «Все картинки перестанут грузиться», «формы начнут выдавать ошибки», «поисковик решит, что это новый сайт, и обнулит позиции».

Я откладывала задачу три месяца. Каждый раз, когда собиралась начать, вспоминала: «А вдруг я сделаю редирект неправильно, и сайт будет циклично перекидывать пользователя туда‑сюда? Или в базе останутся жёсткие ссылки с http, и половина стилей не подгрузится?»

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

Чего я боялась больше всего

Перед стартом я честно выписала свои главные страхи:

Битые картинки и стили. Что в CSS и базе данных останутся ссылки вида http://site.ru/wp-content/..., и сайт станет «голым» — без картинок и стилей.
Циклические редиректы. Что .htaccess будет бесконечно перекидывать с http на https и обратно.
Потеря трафика и позиций. Что поисковики воспримут HTTPS‑версию как новый сайт и начнут индексировать заново.
Ошибки форм и корзины. Что скрипты форм и платёжных модулей перестанут работать из‑за смешанного контента.
Не успеть откатиться, если что‑то пойдёт не так. Что я не смогу быстро вернуть всё назад, если сайт «ляжет».

С этим списком я пошла в панель Timeweb и составила план из понятных шагов.

Шаг 1: бэкап и тестовая версия

Сначала я сделала ручной бэкап в панели Timeweb — на случай, если придётся откатиться. Потом создала тестовый поддомен https-test.site.ru и развернула туда копию сайта (как в прошлой истории: отдельная папка, отдельная база с префиксом).

На тестовой версии я планировала проверить все правки, прежде чем трогать основной сайт. Это сразу сняло половину паники: если что‑то сломается, основной трафик не пострадает.

Шаг 2: включить SSL на хостинге

В панели Timeweb в разделе «Сайты» я открыла карточку своего сайта и нажала «Выпустить SSL». Через пару минут сертификат был готов, и панель показала статус «Активен».

Я открыла https://test.site.ru — сайт открылся, но в адресной строке был серый замок (или предупреждение). В консоли браузера (F12 → Console) я увидела ошибки «Mixed Content»: сайт грузил часть ресурсов по http. Это нормально на этом этапе: нужно исправить ссылки.

Шаг 3: настроить редирект с HTTP на HTTPS

Я хотела сделать 301‑редирект, чтобы поисковые системы поняли: это тот же сайт, просто теперь он на HTTPS.

Сначала попробовала плагин для редиректов — но решила не полагаться только на него и добавила правило в .htaccess:

Это правило говорит: если HTTPS выключен, перекидывай на https:// с кодом 301.

Важно: я сначала протестировала это на тестовом поддомене. Открыла http‑версию — и она корректно перекидывала на https. В консоли не было циклических редиректов. Только после этого я перенесла правило на основной сайт.

Шаг 4: исправить смешанный контент и ссылки

Самая частая причина «сломанного» сайта после перехода — жёстко прописанные http:// в базе данных, CSS, JS и настройках плагинов.

Я действовала так:

Проверила консоль браузера. Там были ошибки Mixed Content — я выписывала URL проблемных ресурсов.
Заменила ссылки в базе. Для этого использовала безопасный плагин миграции URL (он делает SQL‑замены, но с проверками). Заменяла http://site.ru на https://site.ru, но не трогала внутренние ссылки вида /wp-content/uploads/... — они работают и так.
Проверила настройки CMS и плагинов. В WordPress поменяла адрес сайта на HTTPS в настройках. В плагинах форм, корзин и аналитики тоже проставила HTTPS‑адреса.
Проверила CSS и JS. Если в CSS были абсолютные ссылки на картинки, их тоже нужно было поправить (или сделать относительными).

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

Шаг 5: SEO‑подготовка и проверка индексации

Чтобы не потерять позиции, я сделала следующее:

Обновила адрес сайта в WordPress. В настройках указала https://site.ru.
Сгенерировала новую sitemap.xml (или убедилась, что плагин sitemap обновил ссылки на HTTPS).
Добавила HTTPS‑версию в Яндекс Вебмастер и Google Search Console. И отправила туда новую карту сайта.
Проверила robots.txt. Убедилась, что там нет правил, которые запрещают индексировать HTTPS‑страницы.

Это важно: поисковики должны понять, что это не новый сайт, а тот же самый, только на защищённом протоколе.

Шаг 6: финальная проверка и запуск

Перед тем как включать редирект на основном сайте, я провела полный чек‑лист на тестовой версии:

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

Только после этого я сделала ещё один ручной бэкап основного сайта, перенесла правило редиректа в .htaccess и обновила настройки WordPress.

Где я чуть не ошиблась (и что панель подсказала)

Хотела сначала поменять URL в базе вручную через SQL. Это опасно: можно случайно испортить сериализованные данные. Панель и поддержка подсказали: используйте плагины миграции URL — они учитывают формат данных.
Пыталась включить SSL и сразу проверить основной сайт. Хорошо, что я сначала всё тестировала на тестовом домене: там я увидела смешанный контент и ошибки, которые потом исправила.
Забыла обновить sitemap и добавить HTTPS‑версию в вебмастера. Это могло привести к тому, что поисковик будет держать старую версию в индексе. Поддержка напомнила: «После редиректа обязательно обновите карту сайта и сообщите поисковикам».
Не проверяла консоль браузера. Без консоли я бы не увидела ошибки Mixed Content и думала бы, что «всё работает», а на деле часть стилей и картинок не грузилась.

Что реально помогло на Timeweb

Бэкапы в один клик. Я могла откатиться за минуты, если бы редирект или замены в базе что‑то сломали.
Возможность развернуть тестовую копию. Это дало безопасную площадку для всех правок.
Панель с SSL‑сертификатами. Сертификат выпускается и обновляется автоматически — не нужно заказывать и вручную устанавливать.
Файловый менеджер и доступ к .htaccess. Я быстро редактировала конфиги и проверяла, нет ли синтаксических ошибок.
Поддержка. Когда сомневалась, правильно ли настроила редирект, в чате ответили за пару минут и даже прислали пример безопасного правила.

Практические советы, чтобы переход на HTTPS прошёл без потерь

Если вы тоже планируете миграцию, вот что реально спасает:

Делайте бэкап перед любыми изменениями. На Timeweb это быстро, а откатиться можно за минуты.
Используйте тестовый поддомен. Все правки сначала тестируйте там.
Настраивайте 301‑редирект и проверяйте, чтобы не было циклов. Лучше сначала протестировать правило вручную.
Устраняйте смешанный контент. Проверяйте консоль браузера и исправляйте ссылки на http.
Обновляйте адрес сайта и карту сайта. Это сигнал поисковикам: «Это тот же сайт, только на HTTPS».
Добавьте HTTPS‑версию в Яндекс Вебмастер и Google Search Console. Так быстрее произойдёт переиндексация.
Следите за метриками первые 2–4 недели. Трафик, позиции, ошибки 404 — если что‑то падает, вы успеете быстро среагировать.

Сейчас сайт уже полгода работает на HTTPS, трафик не просел, а даже немного вырос. Я перестала бояться слова «миграция»: поняла, что это управляемый процесс, если делать всё по шагам и использовать инструменты хостинга. А Timeweb даёт всё необходимое: бэкапы, поддомены, автоматическое SSL, понятную панель и поддержку, которая помогает не наломать дров.