HTTPS и SEO: как безопасно перевести сайт и не потерять трафик

Короткий ответ: одного TLS-сертификата недостаточно. Для корректного переноса нужно выбрать единственную HTTPS-версию сайта, настроить постоянные редиректы с каждого HTTP-адреса на его точный аналог, заменить внутренние ссылки и ресурсы, обновить canonical и sitemap.xml, а после запуска проверить коды ответа, смешанный контент, индексацию и заявки. Замок в браузере подтверждает защищённое соединение, но не правильность всего переезда.

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

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

Для браузера http://example.ru/page/ и https://example.ru/page/ — разные адреса. Если оба отвечают кодом 200, доступны две версии документа. Ссылки, canonical и XML-карта могут указывать на разные варианты, а поисковой системе приходится разбираться в противоречиях.

После правильного переноса любой HTTP-запрос сразу попадает на соответствующий HTTPS-URL. Не на главную, не на похожий раздел и не через цепочку переходов, а на прямой аналог исходной страницы. Все ссылки и технические сигналы внутри сайта тоже используют HTTPS.

Проверяйте три уровня:

• сертификат: подходит ли он домену и корректно ли отдаётся сервером;
• маршрутизация: ведёт ли каждый старый URL на нужную HTTPS-страницу;
• содержимое: нет ли внутри страницы HTTP-ссылок, ресурсов, canonical или обработчиков форм.

Подготовка до включения редиректов

Соберите контрольный список URL

Возьмите не только главную, но и страницы каждого типа: услугу, статью, категорию, карточку, фильтр, пагинацию, контакты и форму. Добавьте адреса, на которые идут поиск, реклама, внешние ссылки и заявки. Отдельно отметьте изображения, CSS, JavaScript, шрифты и API.

Для каждого старого URL запишите ожидаемый HTTPS-аналог. Такая карта выявляет слишком общие правила: например, когда все карточки ведут в один раздел или завершающий слеш создаёт лишний переход.

Проверьте сертификат и сам сайт

Сертификат должен охватывать основной домен, вариант с www и используемые поддомены. Проверьте срок действия и цепочку сертификата. Автоматическое продление полезно, но не отменяет мониторинг.

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

Найдите старые адреса

Ищите http:// в шаблонах, базе данных, меню, canonical, hreflang, Open Graph, JSON-LD, CSS, письмах, фидах, sitemap.xml и настройках формы. Отдельно проверьте сторонние скрипты, видео и виджеты. Исправляйте URL в источнике, а не временной подменой строк.

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

Пошаговый перенос на HTTPS

Шаг 1. Выберите основную форму домена

Определите один вариант: https://example.ru/ или https://www.example.ru/. Все остальные сочетания протокола и www должны приводиться к нему. Этот выбор одинаково отражают в редиректах, canonical, sitemap.xml и внутренних ссылках.

По возможности не меняйте одновременно протокол, домен и структуру каталогов. Если большой переезд неизбежен, составьте карту «старый URL → новый URL». Подробности есть в материале о редиректах при переезде сайта.

Шаг 2. Настройте прямые постоянные редиректы

Каждый HTTP-адрес должен вести на свой HTTPS-аналог с сохранением пути и нужных параметров. Не отправляйте все страницы на главную. Избегайте цепочек вроде «HTTP без www → HTTP с www → HTTPS с www» и обязательно проверьте циклы.

Для постоянного переноса на точный аналог нужен постоянный редирект, а для удалённой страницы без замены — честный статус удаления. Выбрать вариант поможет практический разбор HTTP-кодов.

Шаг 3. Обновите внутренние сигналы

Редирект — страховка для старых входов, а не способ навигации. Меню, карточки, пагинация, ссылки и кнопки должны сразу вести на HTTPS. Проверьте, что:

• canonical указывает на итоговый HTTPS-URL;
• Open Graph, JSON-LD и hreflang используют HTTPS;
• формы отправляют данные на защищённый обработчик;
• изображения, стили, скрипты, шрифты и iframe загружаются по HTTPS;
• sitemap.xml содержит только канонические страницы с ответом 200.

Шаг 4. Обновите внешние настройки

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

Шаг 5. Повторите обход

Запросите контрольные URL по HTTP и HTTPS, с www и без него. Запишите конечный адрес, число переходов и итоговый код. Просканируйте сайт и найдите внутренние HTTP-ссылки, ошибки 4xx/5xx, цепочки и смешанные ресурсы.

В инструментах разработчика проверьте сеть и консоль: скрипт или запрос к API может появиться только после выполнения JavaScript.

Смешанный контент: незаметная поломка

Смешанный контент возникает, когда HTTPS-страница запрашивает ресурс по HTTP. Браузер может заблокировать скрипт, форму или API. В итоге ломается меню, карта, шрифт, аналитика или отправка заявки, хотя сама страница открылась.

Чаще всего старый адрес прячется в фоновой картинке CSS, общем шаблоне, давней статье, iframe, клиентском JavaScript, виджете обратного звонка или на поддомене без подходящего сертификата.

Исправляйте URL в источнике, затем очищайте кэш сайта и CDN и повторяйте проверку в новом сеансе. Сторонний виджет обновляйте по документации поставщика. Если защищённой версии нет, компонент лучше отключить до решения проблемы.

Сценарий: сайт услуг после переноса

После перехода сайта услуг на HTTPS заявки перестали попадать в CRM, хотя главная открывается нормально. Полная проверка находит три дефекта: меню ведёт на HTTP, картинки в старых статьях загружаются по HTTP, а форма отправляет запрос на незащищённый адрес API, который блокирует браузер.

Сначала заменяют адрес API и подтверждают получение тестовой заявки. Затем обновляют ссылки шаблона и изображения, сверяют canonical, JSON-LD и sitemap.xml. После этого формы проверяют с телефона и компьютера, а ошибки и цели наблюдают в динамике. Сертификат работал с самого начала, но ключевой бизнес-процесс был сломан — поэтому одного замка для приёмки недостаточно.

Частые ошибки

Все страницы ведут на главную

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

HTTP и HTTPS отвечают 200

Это две доступные версии сайта. Выберите основной вариант и приведите к нему редиректы, ссылки, canonical и карту сайта.

Canonical остался на HTTP

HTTPS-страница сообщает поисковику другой основной адрес. Без отдельной обоснованной схемы canonical должен вести на выбранный HTTPS-URL.

Редиректы образуют цепочку

Настройте прямой переход на финальный адрес. После общего правила отдельно проверьте старые индивидуальные перенаправления.

В sitemap.xml смешаны протоколы

В карте должны быть только канонические индексируемые HTTPS-страницы с ответом 200. Сверить sitemap.xml, robots.txt и canonical поможет материал о базовой технической гигиене сайта.

Перенос совместили с редизайном

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

Никто не следит за сертификатом

Автопродление не отменяет мониторинг. Заранее определите, кто получает уведомление и как восстанавливает HTTPS.

Контроль после запуска

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

Следите за четырьмя группами сигналов:

• обход: роботы получают итоговые страницы без циклов и массовых ошибок;
• индексация: основными становятся HTTPS-URL, а HTTP-версии не возвращаются как отдельные документы;
• работа сайта: формы, вход, оплата, поиск и виджеты не блокируются;
• бизнес-результат: цели и заявки фиксируются так же корректно, как до переноса.

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

Практический чек-лист

До запуска

• выбран основной HTTPS-домен, а сертификат охватывает публичные имена;
• составлена карта важных URL;
• HTTPS-страницы отдают нужное содержимое и коды;
• найдены HTTP-ссылки и ресурсы;
• сохранены данные по входам, целям и ошибкам;
• подготовлены прямые редиректы и план отката.

После запуска

• каждый HTTP-адрес ведёт на соответствующую HTTPS-страницу;
• нет циклов и лишних цепочек;
• canonical, hreflang, Open Graph, JSON-LD и sitemap.xml используют HTTPS;
• внутренние ссылки не проходят через редирект;
• браузер не блокирует смешанный контент;
• формы, авторизация, аналитика и интеграции проверены реальным сценарием;
• контролируются ошибки 4xx/5xx, срок сертификата, страницы входа, цели и заявки;
• новые материалы и шаблоны сразу создаются с HTTPS-ссылками.

FAQ

Достаточно ли установить сертификат?

Нет. Нужны редиректы, HTTPS-ссылки, корректные canonical и sitemap.xml, безопасные ресурсы, рабочие формы и обновлённые интеграции.

Какой редирект использовать?

Для постоянного переноса нужен постоянный редирект на точный HTTPS-аналог — без цепочек, циклов и отправки всех страниц на главную.

Нужно ли менять внутренние ссылки?

Да. Они должны сразу вести на итоговые адреса. Редирект нужен для старых входов, а не для обычной навигации.

Можно ли сразу включить HSTS?

Сначала убедитесь, что HTTPS стабильно работает на всех нужных доменах и поддоменах. Ошибка в HSTS может сделать сайт недоступным на период действия политики.

Почему сломалась форма?

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

Как долго хранить редиректы?

Пока старые URL используются во внешних ссылках, документах или закладках и пока соответствие страниц остаётся актуальным.

Что делать дальше

Если сайт работает по HTTP или перенос выполнен частично, начните с карты URL и проверки форм — так быстрее обнаружатся риски для заявок. Затем приведите к одной HTTPS-версии редиректы, ссылки, canonical, карту сайта и внешние интеграции.

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