Переход с HTTP на HTTPS

Переход с HTTP на HTTPS выглядит как установка сертификата, а по сути это смена адреса у каждой страницы сайта. Поисковая система видит не «тот же сайт стал защищённым», а тысячу новых адресов вместо тысячи старых и заново решает, что из этого показывать. Поэтому риск переезда лежит не в сертификате — он ставится за десять минут, — а в том, насколько аккуратно старые адреса связаны с новыми.

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

Что происходит с сайтом в момент переключения

Адрес страницы для поисковой системы состоит из протокола, домена и пути. Меняется любая из трёх частей — получается другой адрес, даже если содержимое осталось прежним. Именно это и происходит при переключении: http://site.ru/uslugi/ и https://site.ru/uslugi/ — два разных документа с точки зрения индекса.

Дальше возможны три сценария, и они зависят только от настроек.

• Обе версии отвечают кодом 200. Худший вариант: у сайта появляется полная копия. Сигналы делятся между двумя адресами, поисковая система сама выбирает, какой показывать, и выбор может не совпасть с тем, на который ведут внешние ссылки.
• Старый адрес отдаёт 301 на главную. Внутренние страницы пропадают как класс. Накопленный вес каждой из них не переходит никуда: система видит, что документ исчез, а на его месте появился совсем другой.
• Старый адрес отдаёт 301 на свой аналог по https. Правильный вариант. Система связывает документы попарно, переносит на новый адрес накопленные сигналы и постепенно заменяет старые адреса в индексе новыми.

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

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

Сертификат: какой нужен и за что берут деньги

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

Тип	Что проверяется	Кому подходит	Что важно знать
Проверка домена (DV)	Только право управлять доменом	Сайты услуг, блоги, большинство магазинов	Выдаётся автоматически, бесплатный Let’s Encrypt относится сюда же
Проверка организации (OV)	Домен и существование юридического лица	Банки, страховые, крупные порталы	Данные компании видны в свойствах сертификата, но не в адресной строке
Расширенная проверка (EV)	Домен, юрлицо, полномочия заявителя	Финансовые сервисы по требованию регулятора	Зелёной строки с названием компании браузеры давно не показывают
Wildcard	Домен и все поддомены одного уровня	Сайты с поддоменами по городам или разделам	Не покрывает второй уровень вложенности поддоменов
Мультидоменный	Несколько разных доменов в одном файле	Группы связанных проектов на одном сервере	Продление затрагивает сразу все домены из списка

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

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

Порядок перехода по шагам

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

1. Сделать полную резервную копию — файлы и база данных. Откат должен быть возможен в любой момент первых суток.
2. Установить сертификат и убедиться, что защищённая версия открывается без предупреждений на компьютере и на телефоне.
3. Заменить адреса в базе данных — ссылки между страницами, пути к картинкам, скриптам и стилям.
4. Проверить шаблон и настройки: жёстко прописанные адреса в теме, в виджетах, в настройках плагинов и в файлах конфигурации.
5. Обновить canonical — он обязан указывать на защищённую версию, иначе система получит противоречивый сигнал.
6. Включить постраничный редирект 301 с http на https и проверить его не только на главной.
7. Поправить карту сайта и robots.txt: адреса внутри карты и строку Sitemap в robots.
8. Добавить защищённую версию в Вебмастер и указать её главным зеркалом; в Search Console добавить новый ресурс.
9. Проверить счётчики и цели: Метрика, системы коллтрекинга, виджеты форм и чатов.
10. Пройти чеклист проверок из раздела ниже и запланировать повторную проверку через неделю и через месяц.

Постраничный редирект — место, где обваливается трафик

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

Проверяется он не на главной. Главная почти всегда настроена верно — берите внутреннюю страницу третьего уровня вложенности, желательно с параметрами в адресе, и смотрите, куда попали.

Что открываем по http	Правильный результат	Признак поломки
Главная страница	301 на главную по https	302 или цепочка через www
Внутренняя страница раздела	301 на ту же страницу по https	301 на главную — критично
Карточка товара с параметрами	301 с сохранением всех параметров	Параметры обрезаны, попадаем в общий каталог
Адрес с кириллицей в пути	301 на такой же адрес по https	404 или неверная перекодировка
Картинка или PDF-файл	301 на файл по https	Файл остаётся доступен по http с кодом 200
Несуществующий адрес по http	301 на https, затем 404	Сразу 404 без редиректа — терпимо, но хуже

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

Третий дефект — код 302 вместо 301. Временный редирект говорит системе, что старый адрес скоро вернётся, поэтому она держит его в индексе и не переносит сигналы. Иногда 302 ставят «на всякий случай, пока проверяем» и забывают на год. Проверяется код ответа в консоли браузера на вкладке сети или запросом через curl -I.

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

Смешанное содержимое: почему замок пропадает

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

Опасность в том, что типы ресурсов ведут себя по-разному, и часть проблем не видна глазом.

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

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

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

Замена адресов в базе данных: почему голый SQL ломает сайт

Соблазн понятный: один запрос вида UPDATE ... REPLACE(...) по таблице записей — и все адреса заменены. На сайтах на распространённых системах управления это регулярно заканчивается слетевшими настройками темы и неработающими блоками.

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

Правильный порядок такой:

1. Резервная копия базы до любых действий.
2. Замена инструментом, который умеет разбирать сериализованные данные и пересчитывать длину — это делают специализированные плагины поиска и замены и консольные утилиты систем управления.
3. Первый прогон в режиме предпросмотра: инструмент показывает, сколько строк в каких таблицах будет затронуто, до внесения изменений.
4. Замена в двух формах: полный адрес с доменом и, если он встречается, экранированный вариант со слэшами внутри JSON-полей.
5. Проверка сайта по разделам сразу после замены, до включения редиректа.

Что настроить после переезда

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

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

Search Console. Ресурс с новым протоколом добавляется отдельно, старый не удаляется: по нему ещё какое-то время будет приходить полезная статистика об исчезающих адресах. Удобнее всего добавить ресурс уровня домена — он объединяет обе версии и все поддомены.

Карта сайта. Пересобрать так, чтобы внутри были адреса только по https, и указать её заново в обоих панелях. Строка Sitemap в robots.txt тоже правится — про неё забывают почти всегда.

Robots.txt. Проверить, что файл отдаётся по защищённому адресу с кодом 200 и что в нём нет запретов, оставшихся с этапа тестирования.

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

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

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

Чеклист проверок и нормальные сроки

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

Когда	Что проверяем	Норма
Сразу	Код ответа внутренней страницы по http	301 на ту же страницу по https
Сразу	Консоль браузера на пяти типах страниц	Нет предупреждений о смешанном содержимом
Сразу	Отправка формы и приход письма	Заявка доходит на рабочую почту
Сразу	Canonical в исходном коде	Указывает на https-адрес самой страницы
Первые сутки	Визиты в Метрике и срабатывание целей	Данные идут, цели считаются
Первая неделя	Главное зеркало в Вебмастере	Указана защищённая версия
Первая неделя	Статистика обхода	Робот берёт https-адреса, доля 404 не растёт
Первый месяц	Число страниц в поиске	Вернулось к прежнему уровню
Первый месяц	Позиции по основным запросам	Восстановление до прежних значений
Через квартал	Внешние ссылки на сайт	Основные площадки обновили протокол

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

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

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

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

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

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

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

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

Обязательно ли ставить HSTS?
Не обязательно, и включать его сразу не стоит. Этот заголовок запрещает браузеру обращаться к сайту по незащищённому протоколу вообще, и если сертификат по какой-то причине перестанет работать, сайт станет недоступен, а быстро откатиться не получится. Разумный порядок: сначала месяц стабильной работы, потом небольшой срок действия заголовка, и только затем длинный.

Что делать с поддоменами?
Переводить одновременно с основным сайтом и по тем же правилам. Ситуация, когда основной домен защищён, а поддомены нет, встречается часто и создаёт сразу две проблемы: предупреждения браузера на части страниц и ссылки с защищённого сайта на незащищённый. Для набора поддоменов удобен wildcard-сертификат — он покрывает их одним файлом.

Технические проверки сайта и работу с Вебмастером показываю на живом примере:

8:14

Коротко

• Переход с HTTP на HTTPS — это смена адреса каждой страницы, а не установка сертификата. Риск лежит в связке старых адресов с новыми.
• Редирект обязан быть постраничным и с кодом 301: каждая страница на свой аналог, одним шагом, без цепочек через www.
• Смешанное содержимое ищется в консоли браузера и проверяется на всех типах страниц, а не только на главной.
• Адреса в базе меняют инструментом, который пересчитывает сериализованные данные, — голый SQL ломает настройки темы и плагинов.
• После переезда правятся карта сайта, robots.txt, canonical, главное зеркало в Вебмастере, цели в Метрике и адреса во внешних сервисах.
• Просадка на две-три недели нормальна; если через два месяца трафик не вернулся, ищите ошибку в редиректах или доступную копию по http.

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