Переезд на HTTPS выглядит рутиной: поставили сертификат, замочек появился, задача закрыта. Именно из-за этой обманчивой простоты я регулярно вижу сайты, у которых после «безобидного» обновления трафик уходит почти в ноль. Виноват не протокол — виновата процедура, в которой пропустили один-два шага, и сайт для поисковой системы превратился в две несвязанные копии.
Ниже — четыре ошибки, которые дают именно такой результат, признаки каждой, порядок безопасного переезда и список того, что нужно проверить в первые дни после переключения. Материал пригодится и тем, кто только собирается переезжать, и тем, кто уже переехал и пытается понять, почему позиции просели и не возвращаются.
Что на самом деле происходит при переходе на HTTPS
Смена протокола — это смена адреса каждой страницы сайта. Для поисковой системы http://site.ru/uslugi/ и https://site.ru/uslugi/ — два разных документа, а не один в новой обёртке. Всё, что накоплено старым адресом — позиции, история, входящие ссылки, поведенческие данные, — привязано именно к нему и автоматически на новый не переносится.
Отсюда правильная рамка: переезд на защищённый протокол нужно вести как полноценную смену адресов, с теми же процедурами, что при переходе на новый домен. Если относиться к нему как к настройке хостинга, ошибки неизбежны — просто потому, что половина необходимых шагов лежит вне панели управления сервером.
Сам переход при этом обязателен, и спорить тут не о чем. Браузеры помечают незащищённые сайты предупреждением, и человек закрывает вкладку, не дойдя до предложения. Формы с персональными данными на HTTP — это ещё и вопрос к соблюдению закона. Перед стартом полезно разобраться, что такое SSL-сертификат и чем отличаются его типы: часть ошибок совершается уже на этапе выбора.
Ошибка первая: нет постраничных 301-редиректов
Самая частая и самая разрушительная. Сертификат установлен, сайт открывается по HTTPS, владелец считает работу завершённой. Но старые адреса продолжают существовать: они в индексе, на них ведут внешние ссылки, по ним заходят из закладок и из чужих статей. Поисковая система видит два сайта с одинаковым содержимым и вынуждена решать, какой из них показывать.
Результат предсказуем: сигналы делятся между копиями, часть страниц признаётся дублями, позиции проседают по всему ядру сразу. Причём проседают не резко в один день, а размазанно за две-три недели, из-за чего связь с переездом замечают не сразу.
Правильное решение — постраничный 301 с каждого HTTP-адреса на его HTTPS-версию, страница в страницу. Механика передачи веса разобрана в материале о том, как 301-редирект сохраняет SEO и посетителей. Два типовых промаха здесь:
- Редирект всего на главную. Самый быстрый способ обнулить внутренние страницы: их релевантность не передаётся, а посетитель, кликнувший по ссылке на конкретную статью, попадает на главную и уходит.
- Использование 302 вместо 301. Временный редирект сообщает, что старый адрес ещё вернётся, поэтому система продолжает держать его в индексе. Разница подробно разобрана в сравнении 301 и 302 редиректа, и на постоянном переезде 302 использовать нельзя.
- Консоль браузера: как владельцу увидеть ошибки сайта за две минуты
Третий промах, менее очевидный, — цепочки. Часто получается конструкция вида http без www → http с www → https с www → https без www. Каждое звено это лишний запрос и потеря части сигналов. Цепочка должна быть в один шаг: любой старый вариант адреса ведёт сразу на конечный.
Тему разбирал отдельно: «7 SEO-ошибок, из-за которых Яндекс режет ваш трафик в 2026 году».
Проверяется всё за пару минут: возьмите десяток адресов разного типа — главную, категорию, карточку, статью, страницу с параметром — и посмотрите коды ответа по HTTP-версии. Должен быть 301 и сразу нужный конечный адрес.
Ошибка вторая: смешанное содержимое
Сайт переехал, но внутри страниц остались абсолютные ссылки на картинки, скрипты, стили и шрифты по старому протоколу. Браузер загружает защищённую страницу, в которой часть ресурсов приходит по незащищённому каналу, и снимает замочек. Иногда просто снимает, иногда блокирует загрузку элемента — и страница ломается визуально или перестаёт работать.
Опасность в том, что владелец этого не видит. У него страница в кеше браузера, у него отключены предупреждения, он смотрит только главную. А посетитель видит уведомление о небезопасности на том самом сайте, куда собирался ввести телефон.
Типовые источники проблемы:
- Ссылки в базе данных. Все ранее опубликованные материалы содержат абсолютные адреса картинок с http. Лечится массовой заменой по базе с обязательной резервной копией до начала.
- Жёстко прописанные пути в шаблоне. Логотип, фоновые изображения, подключение шрифтов и библиотек в файлах темы.
- Сторонние скрипты. Счётчики, виджеты обратного звонка, карты, чаты, подключённые по старым инструкциям с http.
- Файлы стилей. Внутри CSS часто лежат ссылки на фоновые картинки и шрифты, и о них забывают, потому что в разметке страницы их не видно.
- Консоль браузера: как владельцу увидеть ошибки сайта за две минуты
Проверка простая: откройте консоль браузера на нескольких разных типах страниц и посмотрите предупреждения о смешанном содержимом. Одна забытая картинка снимает замочек со всей страницы, поэтому проходить нужно по всем шаблонам — главная, категория, карточка, статья, страница контактов с картой. Заодно имеет смысл провести общий аудит сайта на ошибки: смешанное содержимое редко живёт в одиночестве.
Ошибка третья: robots.txt, sitemap и внешние сервисы
Технические файлы после переезда обновляют реже всего, потому что они не видны глазом. В карте сайта остаются HTTP-адреса, робот продолжает обходить старую версию, краулинговый бюджет уходит на адреса, которых фактически уже нет. Индексация новых страниц при этом буксует неделями.
Что нужно проверить и переделать:
- Карта сайта. Пересобрать на HTTPS-адресах, убедиться, что в ней нет ни одного адреса, отдающего 301 или 404. Как её правильно собирать — в разборе, что такое sitemap и как её создать.
- Robots.txt. Убедиться, что он отдаётся по новому протоколу с кодом 200, что путь к карте сайта указан в HTTPS-виде и что не осталось директив с этапа разработки. Классические промахи собраны в материале об ошибках robots.txt и sitemap, которые закрывают сайт от Яндекса.
- Канонические адреса. Тег canonical на страницах обязан указывать на HTTPS-версию. Если он остался с http, вы своими руками сообщаете системе, что главной является старая копия.
- Внутренние ссылки. Меню, подвал, ссылки внутри статей, ссылки в карточках товара. Каждая ссылка на http-версию — это лишний редирект при каждом переходе.
- Внешние сервисы. Счётчики аналитики, пиксели, интеграции с CRM, виджеты. Если они настроены на старый адрес, данные собираются неполно или дублируются, а часть функций отваливается без явной ошибки.
Последний пункт даёт самые неприятные последствия: сайт работает, но заявки перестают доходить до системы учёта, и обнаруживается это через недели. После переезда стоит отдельно пройтись по списку всех подключённых сервисов и проверить каждый вручную — отправить тестовую заявку и убедиться, что она пришла и туда, и туда.
Ошибка четвёртая: новый адрес не подтверждён в вебмастере
Для панелей вебмастера HTTPS-версия — это отдельный сайт, который нужно добавить и подтвердить права на него. Пока этого не сделано, вы смотрите статистику старой версии и делаете выводы по данным, которые уже ничего не значат.
Смежный материал по теме — «Один тег обрушил трафик на 70%: как canonical годами убивает сайты на автопилоте».
Порядок действий такой:
- Добавить HTTPS-версию как новый сайт и подтвердить права.
- Указать её как основное зеркало и дождаться склейки. Процесс не мгновенный, обычно занимает от нескольких дней до пары недель.
- Загрузить новую карту сайта уже в новом ресурсе.
- Отправить на переобход ключевые страницы — главную, основные разделы, страницы услуг.
- Не удалять старую версию из панели: по ней видно, как идёт склейка и не осталось ли проблем.
- Консоль браузера: как владельцу увидеть ошибки сайта за две минуты
Пока склейка не завершилась, часть страниц может показываться в выдаче по старым адресам — это нормально и лечится временем при условии, что редиректы стоят правильно. Общая логика того, как страницы попадают в поиск, разобрана в материале про индексацию сайта в поисковых системах. Отдельно стоит прочитать разбор ситуаций, когда 301-редирект не любит Яндекс, — там описано, почему склейка иногда затягивается.
Пошаговый план безопасного переезда
Порядок имеет значение: часть шагов делается до переключения, часть сразу после, часть в течение месяца.
| Этап | Что сделать | Признак, что шаг выполнен |
|---|---|---|
| До переезда | Полная резервная копия файлов и базы | Копия скачана и проверена на восстановление |
| До переезда | Выгрузить список всех адресов сайта краулером | Есть файл со списком для последующей сверки |
| Переключение | Установить сертификат, включить HTTPS | Сайт открывается по новому протоколу |
| Сразу после | Настроить постраничный 301 в один шаг | Любой старый адрес ведёт сразу на конечный |
| Сразу после | Заменить адреса в базе и в шаблоне | В консоли нет предупреждений о смешанном содержимом |
| Сразу после | Обновить canonical, robots.txt, карту сайта | В карте только HTTPS-адреса, все отдают 200 |
| Первые дни | Добавить и подтвердить новый сайт в вебмастере | Права подтверждены, карта загружена |
| Первые дни | Проверить счётчики, формы, интеграции | Тестовая заявка дошла до почты и до CRM |
| Первый месяц | Обновить адрес в внешних профилях и справочниках | Карты, каталоги, соцсети ведут на HTTPS |
| Первый месяц | Следить за индексацией и склейкой зеркал | Число страниц в поиске вернулось к прежнему |
Про второй пункт скажу отдельно: список адресов до переезда — это то, чем вы будете сверяться потом. Без него невозможно понять, все ли страницы получили редирект и не потерялось ли что-то в процессе. Собирается он любым краулером за полчаса, а экономит недели разбирательств.
Что проверять в первые две недели
Переезд не заканчивается в момент переключения. Первые две недели — это период, когда всплывают пропущенные детали, и чем раньше они найдены, тем дешевле обходятся.
- Коды ответов по списку адресов. Прогоните собранный до переезда список: каждый старый адрес обязан отдавать 301 на соответствующий новый.
- Число страниц в индексе. Смотрите динамику: новая версия должна набирать страницы, старая — терять. Если новая не растёт, проблема в robots.txt, canonical или карте сайта.
- Раздел исключённых страниц. Там прямым текстом написана причина по каждому адресу — дубль, редирект, ошибка сервера. Это самый быстрый способ найти пропущенное.
- Отчёт по источникам трафика. Переходы по ссылкам с других сайтов не должны обнулиться. Если обнулились, редиректы работают не для всех адресов.
- Работа форм. Отправить заявку с каждой формы вручную и убедиться, что письмо пришло. После смены протокола обработчики форм ломаются регулярно.
- Скорость ответа. Шифрование добавляет накладные расходы. Если сервер настроен без поддержки современных протоколов, время ответа может заметно вырасти.
- Срок действия сертификата и автопродление. Просроченный сертификат закрывает сайт для посетителей полностью, а происходит это молча.
- Консоль браузера: как владельцу увидеть ошибки сайта за две минуты
Просадка после переезда: где норма, а где авария
Отличать одно от другого важно, потому что паника приводит к откатам, которые делают только хуже.
Норма. Небольшое колебание позиций в течение двух-четырёх недель, временное расхождение числа страниц между старой и новой версией, скачки в статистике на несколько дней. Система переиндексирует сайт постепенно, и это занимает время.
Если нужны детали, смотрите «Zero-click убивает трафик: люди получают ответ, не заходя на сайт. Что делать бизнесу в 2026».
Авария. Трафик падает в несколько раз за неделю и не восстанавливается, число страниц в поиске стремится к нулю, в исключённых массово появляются пометки о дублях или недоступности. Это означает пропущенный шаг, и искать его нужно сразу, а не ждать.
Проверять при аварии нужно в таком порядке: сначала robots.txt на предмет запрета обхода, потом коды ответов и редиректы, потом canonical, потом настройку зеркала в вебмастере. В девяти случаях из десяти причина находится в первых двух пунктах.
Откатываться назад на HTTP — почти всегда худшее решение: вы получаете второй переезд поверх незавершённого первого и удваиваете беспорядок. Правильнее довести переезд до конца, устранив пропущенное.
Частые вопросы
Сколько времени занимает восстановление после переезда?
При корректно выполненной процедуре позиции возвращаются за две-четыре недели, полная склейка зеркал может занять до полутора месяцев на крупном сайте. Если через два месяца показатели не вернулись, дело не в сроках — надо искать пропущенный шаг.
Какой сертификат выбрать?
Для информационного сайта и большинства сайтов услуг достаточно бесплатного с автоматическим продлением. Расширенные варианты с проверкой организации имеют смысл там, где на сайте идут платежи и важно юридическое подтверждение владельца. На ранжирование тип сертификата не влияет — влияет только его наличие и корректность.
Нужно ли менять внешние ссылки на сайт?
Те, что вы контролируете, — да: профили в справочниках, карты, соцсети, подписи в рассылках. Чужие ссылки менять не нужно, их закроет редирект. Но помните, что каждый переход через редирект чуть медленнее, поэтому свои ссылки стоит обновить.
Можно ли переезжать частями, раздел за разделом?
Не стоит. Частичный переезд создаёт смешанную структуру, где часть страниц на одном протоколе, часть на другом, а внутренние ссылки ведут в обе стороны. Разбираться с этим сложнее, чем сделать переключение целиком за один раз.
Что делать, если переезд был давно и сделан плохо?
Порядок тот же, что при новом переезде, только вместо переключения идёт исправление: проверить редиректы по списку адресов, убрать смешанное содержимое, привести canonical и карту сайта к HTTPS, настроить зеркало в панели. Позиции после исправления возвращаются, хотя и медленнее, чем если бы всё было сделано сразу.
Влияет ли HTTPS на скорость сайта?
Шифрование добавляет этап установки соединения, но современные протоколы это компенсируют с запасом. На практике корректно настроенный HTTPS работает быстрее старого HTTP за счёт возможности использовать более новые версии протокола передачи данных. Если после переезда сайт замедлился, дело в настройке сервера, а не в шифровании.
Коротко
- HTTPS-переезд — это смена адресов всех страниц, и вести его нужно как переход на новый домен, а не как настройку хостинга.
- Главная ошибка — отсутствие постраничных 301: без них в индексе живут две копии сайта, и сигналы делятся между ними.
- Смешанное содержимое снимает замочек и ломает страницы; источники обычно в базе, в шаблоне, в файлах стилей и в сторонних скриптах.
- После переключения обязательно пересобрать карту сайта, поправить canonical, robots.txt, внутренние ссылки и проверить все внешние сервисы.
- HTTPS-версию нужно добавить в вебмастер отдельно, назначить основным зеркалом и отправить ключевые страницы на переобход.
- Колебание позиций две-четыре недели — норма; падение в разы, которое не восстанавливается, означает пропущенный шаг, и откатываться назад нельзя.
- Консоль браузера: как владельцу увидеть ошибки сайта за две минуты
Если переезд уже состоялся и трафик не вернулся, а причина не находится — это SEO-консультация: проверяю редиректы по полному списку адресов, смотрю индексацию и склейку зеркал и показываю, какой именно шаг был пропущен. Как это выглядит на реальных проектах, видно по кейсам продвижения сайтов.
Увеличьте позиции и продажи вашего сайта
Профессиональное SEO-продвижение с гарантией результата. Выберите подходящую услугу:
Остались вопросы по продвижению?
Меня зовут Анатолий Кузнецов, я SEO-оптимизатор с 20-летним стажем. Разберу ваш сайт, отвечу на вопросы и подскажу, что улучшить для роста позиций в Яндексе и Google.
Связаться со мной →Комментарии
Максим Огородов
Переехали месяц назад, трафик упал в четыре раза и не растёт. Редиректы вроде стоят, проверял главную — уходит на https. Куда смотреть дальше?
Анатолий Кузнецов автор
Проверка главной ничего не доказывает — она почти всегда настроена правильно, ломаются внутренние. Соберите краулером список адресов и прогоните их по HTTP-версии: смотрите не только наличие редиректа, но и куда он ведёт. Частая картина — все внутренние страницы уходят на главную, тогда падение будет ровно таким, как вы описываете. Второе место, куда стоит заглянуть, — раздел исключённых страниц в вебмастере: там по каждому адресу написана причина, и если массово стоит пометка про дубли, значит, старая версия ещё не склеена. Третье — canonical: откройте исходный код внутренней страницы и посмотрите, какой адрес там указан. Если http, вы сами сообщаете системе, что главной является старая копия, и никакие редиректы это не перебьют.
Вероника Приданникова
У нас магазин на 6000 карточек. Настроить постраничные редиректы для каждой — это же нереально вручную. Как такие объёмы делают?
Анатолий Кузнецов автор
Вручную никто и не делает. Постраничный редирект при смене протокола настраивается одним правилом на сервере: берётся любой запрос по HTTP и перенаправляется на тот же путь по HTTPS с сохранением адреса. Одна строка в конфигурации закрывает все шесть тысяч карточек. Ручная работа появляется только там, где адреса меняются не только протоколом, — например, если заодно решили поправить структуру каталога. Вот этого при переезде на HTTPS делать не надо: два изменения одновременно превращают разбор последствий в гадание. Сначала протокол, дождались склейки, потом при необходимости структура. И обязательно проверьте после настройки десяток карточек из разных категорий: правило иногда конфликтует с уже существующими редиректами.
Леонид Пацуков
Разработчик говорит, что смешанное содержимое неважно, потому что современные браузеры сами подтягивают ресурсы по https. Так ли это?
Анатолий Кузнецов автор
Отчасти так: браузеры действительно пытаются повысить протокол для части ресурсов, и во многих случаях это срабатывает. Но полагаться на это нельзя по двум причинам. Первая — повышение работает не всегда: если ресурс по HTTPS недоступен, он либо блокируется, либо загружается как есть, и результат зависит от браузера и его версии. Вторая причина важнее: ссылки остаются в вашей базе и в шаблоне, и рано или поздно они всплывут — при переносе сайта, при смене темы, при генерации карты сайта или при выдаче содержимого в сторонние сервисы. Правильно чинить источник, а не рассчитывать на поведение браузера. Работы там на час: замена по базе и проход по файлам темы.
Кристина Оксенчук
Подскажите, обязательно ли добавлять https-версию в вебмастер отдельно, если старая уже подтверждена и там всё настроено?
Анатолий Кузнецов автор
Обязательно. Для панели это разные ресурсы, и данные они собирают раздельно. Пока новая версия не добавлена, вы видите статистику по адресам, которых фактически больше нет: число страниц падает, ошибки растут, и картина выглядит катастрофой, хотя реальный сайт может чувствовать себя нормально. Порядок такой: добавить HTTPS-версию, подтвердить права любым удобным способом, назначить её основным зеркалом, загрузить туда актуальную карту сайта и отправить главные страницы на переобход. Старую версию удалять не нужно — по ней удобно следить за тем, как идёт склейка: число страниц там должно постепенно уменьшаться, а в новой расти. Если этого не происходит месяц, значит, что-то мешает роботу перейти на новые адреса.
Данила Постовалов
После переезда заявки перестали доходить в CRM, обнаружили через три недели. Формы работали, сообщение об отправке показывалось. Это тот самый случай с внешними сервисами?
Анатолий Кузнецов автор
Именно он, и это самый дорогой из всех промахов при переезде, потому что теряются живые обращения. Интеграция обычно настроена на конкретный адрес приёма данных, и при смене протокола запрос либо уходит по старому адресу, либо блокируется как небезопасный. Форма при этом отрабатывает свою часть и честно показывает «спасибо», потому что она не знает, дошло ли сообщение до получателя. Правило, которое стоит завести после любых работ с сайтом: отправить тестовую заявку с каждой формы и проверить, что она пришла во все места назначения — на почту, в CRM, в мессенджер. Занимает десять минут. И поставьте цель на отправку формы в счётчике: тогда расхождение между числом отправок и числом заявок в системе учёта станет видно сразу, а не через три недели.
Ирина Плюхина
Спасибо за таблицу с этапами. Особенно за пункт про выгрузку списка адресов до переезда — мы в прошлый раз не сделали и потом полгода находили страницы, которые никуда не ведут.
Сергей Олексин
А если сертификат бесплатный и продлевается автоматически, но однажды продление не сработало — сайт просто ляжет? Есть способ узнать заранее?
Наталья Полосухина
У нас цепочка из трёх редиректов, как вы описали. Хостер говорит, что это нормально и на скорость не влияет. Стоит ли настаивать на переделке?
Антон Озорнин
Не соглашусь насчёт «не переезжать частями». Мы переводили большой портал по разделам за три месяца, всё прошло гладко. Хотя признаю, следили за этим плотно.
Полина Пикалова
Вопрос про canonical: если на странице стоит canonical на саму себя, но с http, а редирект настроен правильно — что победит в итоге?
Виктор Пронькин
Проверил консоль на карточках товара — там пятнадцать предупреждений о смешанном содержимом, все из-за фоновых картинок в стилях. На главной ноль. Никогда бы не подумал заглянуть в CSS.
Эльвира Опритова
Скажите, а справочники и карты действительно важно обновлять вручную? Думала, редирект всё решит.
Старт 
Стандарт 
Премиум 
Спасибо, теперь переезд на защищенный протокол уже не кажется страшным, есть по чему свериться.
Согласен, добавлю: не забывайте поменять адрес в счетчиках и подтвердить новое зеркало главным, иначе статистика поедет.
Полезно, но хотелось бы подробнее, как быстро обычно восстанавливается трафик после грамотного переезда без ошибок.
Долго искал, почему после переезда просели именно внутренние страницы, а это были неправильные относительные ссылки внутри сайта.
Главная ошибка переезда это поленившись поставить постраничные редиректы и склеить все на морду, так теряется весь вес.
У нас после переезда часть страниц отдавала лишний редирект через двести один, вычистили цепочку, и все встало на место.
Отличный материал, отправила разработчику, который собирался переносить нас на защищенный протокол на следующей неделе.
Скажите пожалуйста, а как правильно поступить со старой картой сайта после переезда, оставлять оба адреса в Вебмастере или полностью переносить все на новый протокол сразу?
Пров, карту сайта переводите полностью на новый протокол и отдаете в Вебмастере только ее, старую не дублируйте, чтобы не путать поисковик двумя версиями адресов. Оба зеркала держите подтвержденными в панели на время склейки, но главным назначайте новый протокол. Старые адреса живут только через редиректы, а не через отдельную карту. Одна актуальная карта на новом адресе это то, что нужно.
Не соглашусь, что переезд обязательно роняет трафик. Сделали все аккуратно с редиректами, и просадки почти не было.
Склеили зеркала со старого адреса на новый постранично, и позиции вернулись, метод рабочий.
По опыту: чаще всего трафик валится не из за самого протокола, а из за кривых цепочек редиректов в несколько шагов.
А нужно ли отдельно уведомлять Яндекс о переезде на защищенный протокол через Вебмастер, или поисковик сам все поймет по редиректам со временем?
Лаврентий, да, обязательно. Добавьте новое зеркало в Вебмастер и укажите его главным в настройках переезда, не надейтесь, что поисковик разберется сам. Ручное указание главного зеркала плюс корректные постраничные редиректы ускоряют склейку в разы. Заодно обновите карту сайта на новый протокол, чтобы Яндекс быстрее переобошел актуальные адреса. Пассивное ожидание растягивает переезд на недели лишнего простоя.
Спасибо, чек-лист по переезду просто спасение. А то каждый раз собираю его по крупицам из десятка статей.
У нас беда была в смешанном контенте, часть картинок грузилась по старому протоколу, и Яндекс ругался, пока не вычистили.
Подскажите, а какой тип редиректа обязательно ставить при переезде со старого протокола на новый, чтобы не растерять накопленный вес страниц и не обнулить позиции?
Серафима, только постоянный редирект с кодом триста один и обязательно постранично, страница в страницу, а не все на главную. Именно триста первый передает накопленный вес и говорит Яндексу, что адрес сменился навсегда. Временный редирект вес не склеивает и позиции не переносит. И следите, чтобы цепочка была в один шаг: старый адрес сразу на финальный новый, без промежуточных перескоков.
Прошли через это. Переехали на защищенный протокол без нормальных редиректов и просели в ноль, статья бы нам год назад очень пригодилась.