SiteGuard4 ноября 202617 мин чтения

Как перевести сайт на HTTPS и проверить, что всё работает

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

Для бизнеса важен весь путь: человек переходит из рекламы, открывает товар, входит в кабинет и отправляет заявку. Поэтому проверять нужно не только главную страницу. Ниже — порядок миграции для владельца сайта и вебмастера, пример редиректа в Nginx и критерии приёмки. Имена example.com и www.example.com в примерах замените своими.

С чего начать перевод сайта на HTTPS

Сначала определите конечный адрес. Например, основным станет https://example.com, а варианты с HTTP и www будут вести на соответствующие страницы этого адреса. Выбор должен совпадать в настройках приложения, правилах сервера, ссылках и данных для поисковых систем. Если одновременно меняется структура каталога или доменное имя, потребуется отдельная карта соответствия URL.

Составьте список того, что зависит от адреса сайта

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

Что включить в список	Что проверить при переходе
Основной домен, www и используемые поддомены	DNS, сертификат, нужный сайт и конечный адрес
Категории, товары, статьи и файлы	Соответствие старой и новой страницы, сохранение пути и параметров
Вход, кабинет, корзина и формы	Сессии, отправка данных, результат операции и уведомления
CRM, API, платёжные уведомления и webhooks	Адреса обработчиков, методы запросов и требования внешних систем
Аналитика, реклама, письма и виджеты	Прямые HTTPS-ссылки, загрузка скриптов и фиксация нужных событий
CDN, балансировщик и сервер приложения	Где завершается TLS и кто формирует перенаправление

Назначьте ответственных за сервер, CMS и интеграции и заранее соберите необходимые доступы.

Подготовьте восстановление и контрольные результаты

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

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

Сначала убедитесь, что HTTPS работает без общего редиректа

До перенаправления посетителей откройте защищённую версию напрямую. Сертификат должен быть установлен в точке, которая принимает TLS-соединение: на веб-сервере, балансировщике или CDN. Проверьте соответствие имён, срок действия и доверие в используемых клиентах. Подробный выпуск и продление сертификата — отдельные задачи; здесь нужен подтверждённый результат.

По HTTPS открывается именно нужный сайт, а не стандартная страница сервера или другой проект.
Работают адреса, которые посетители могут открыть напрямую, включая вариант с www.
Доступны используемые IPv4- и IPv6-маршруты; нет узла со старой конфигурацией.
Основные страницы, изображения и файлы загружаются по защищённым адресам.
Понятно, как будет обслуживаться сертификат после изменения правил HTTP.

Если https://www.example.com должен перенаправлять на домен без www, исходному HTTPS-имени всё равно нужен подходящий сертификат. Сначала устанавливается TLS-соединение, затем клиент получает HTTP-ответ с перенаправлением. Поэтому редирект не исправляет предупреждение сертификата на исходном адресе.

Если перед сайтом находится CDN

Разделите соединение посетителя с CDN и соединение CDN с исходным сервером. Внешний сертификат не подтверждает состояние второго участка. Уточните режим шифрования и проверку сертификата origin в документации провайдера; не меняйте эти параметры одновременно с редиректом без понимания текущей схемы.

Приложение должно правильно определять исходный протокол посетителя. Если внешний запрос приходит по HTTPS, а сервер видит внутреннее HTTP-соединение, наивное правило «HTTP всегда перенаправлять» способно создать цикл. Заголовкам вроде X-Forwarded-Proto доверяют только в настроенной схеме с доверенным прокси, который контролирует их значения. Произвольный заголовок от внешнего клиента не является доказательством защищённого подключения.

Обновите адреса сайта, ресурсов и внешних интеграций

Редирект помогает обработать старую ссылку, но приложение должно само создавать актуальные URL. Проверьте базовый адрес сайта, шаблоны, меню, контент, CSS, JavaScript, выгрузки, письма и настройки расширений. После изменений обновите соответствующие кеши, иначе посетитель может получить старую разметку даже при исправной конфигурации сервера.

Внутренние ссылки и смешанный контент

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

Найдите ресурсы, которые HTTPS-страница запрашивает по HTTP: скрипты, стили, изображения, шрифты, iframe и обращения к API. Это смешанный контент, или Mixed Content. Браузер может блокировать такие запросы либо обрабатывать некоторые из них по специальным правилам. Исправляйте источник URL и проверяйте работу ресурса по HTTPS; механическая замена протокола у чужого сервиса не гарантирует, что он поддерживает защищённое соединение.

Откройте несколько типов страниц с инструментами разработчика. Старый адрес может формироваться только в карточке товара, после входа или при отправке формы. Один поиск по HTML главной страницы не обнаружит все такие зависимости. Детали блокировки описаны в документации браузеров о Mixed Content.

Что учесть в WordPress

Проверьте адрес WordPress и адрес сайта, сохранив предусмотренные пути: они не всегда совпадают, например при размещении файлов WordPress в отдельном каталоге. Если используются WP_HOME и WP_SITEURL, учитывайте, что они переопределяют соответствующие значения настроек; назначение констант описано в руководстве по wp-config.php.

При замене сохранённых URL используйте инструмент, который корректно обрабатывает структуру данных. Обычная текстовая замена в SQL-дампе может повредить сериализованные значения. Официальный WP-CLI search-replace поддерживает такие данные и предварительный запуск --dry-run. Область замены, таблицы и исключения выбирают для конкретной установки после резервного копирования, особенно в Multisite.

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

Формы, API и платёжные уведомления

Обновите action форм, адреса API, callback и webhook у отправителей запросов. Проверьте разрешённые адреса возврата у поставщиков авторизации и оплаты: серверный редирект не обновляет настройки интеграции.

В тестовом режиме проверьте доставку запроса и обработку результата. Для оплаты важно не только возвращение покупателя на страницу «Спасибо», но и серверное подтверждение, по которому меняется статус заказа. Не используйте реальные списания как первый способ проверки миграции.

Как настроить редирект с HTTP на HTTPS

Для постоянного переезда страниц используйте серверное перенаправление на соответствующий конечный HTTPS-адрес. Например, http://www.example.com/catalog/item/ должен вести на https://example.com/catalog/item/, если основным выбран домен без www. Главная, категории и товары должны сохранять назначение; отправлять весь каталог на главную не следует.

Сохраните путь и нужные параметры

Исходный URL	Ожидаемый адрес
`http://example.com/`	`https://example.com/`
`http://www.example.com/catalog/`	`https://example.com/catalog/`
`http://example.com/search/?q=panel`	`https://example.com/search/?q=panel`
`http://example.com/product/?utm_source=mail`	`https://example.com/product/?utm_source=mail`

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

Чем отличаются 301 и 308

Google рассматривает 301 и 308 как постоянные перенаправления для миграции. Для обычных страниц с GET-запросами часто используют 301. Однако RFC 9110 допускает, что клиент после 301 изменит POST на GET. При 308 метод сохраняется; это имеет значение для запросов с телом.

Даже 308 не делает любой webhook совместимым с переездом: отправитель может не следовать перенаправлениям, проверять подпись для исходного адреса или запрещать смену назначения. Поэтому обновляйте URL у отправителя и тестируйте конкретную интеграцию. Данные, уже отправленные на HTTP-адрес, редирект не превращает задним числом в защищённую передачу.

Минимальный пример для Nginx

Пример рассчитан на обычный публичный сайт, где Nginx принимает HTTP напрямую, основной адрес — https://example.com, а защищённая версия уже проверена. В HTTP-блоке нет API и служебных маршрутов, которым требуется отдельная обработка. Это фрагмент для перенаправления, а не полная конфигурация приложения:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

Целевой домен задан явно. Переменная $request_uri сохраняет исходный URI вместе с параметрами; её значение приведено в справочнике Nginx. Директива return описана в документации модуля rewrite. При использовании IPv6 проверьте соответствующий слушающий адрес и правило в действующей конфигурации.

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

Для https://www.example.com потребуется отдельно настроенный HTTPS-виртуальный сервер с подходящим сертификатом и перенаправлением на основной HTTPS-домен. Приведённый блок слушает только порт 80 и этот случай не обрабатывает. Порядок выделения отдельного сервера для перенаправления показан в руководстве Nginx.

Перед применением сохраните конфигурацию и проверьте её:

sudo nginx -t

Если тест успешен и команда обращается к нужному экземпляру Nginx, примените изменения штатным способом, например:

sudo nginx -s reload

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

Панель хостинга, Apache и обратный прокси

На управляемом хостинге используйте предусмотренную настройку принудительного HTTPS и выясните, какие имена и пути она охватывает. Для Apache правила размещают в разрешённом контексте конфигурации; возможность использовать .htaccess зависит от настроек сервера. Код для Nginx в этот файл не переносится.

За CDN выберите согласованный уровень перенаправления и правильное определение исходного протокола. Если панель, CDN и CMS независимо меняют www и HTTPS, правила могут направлять посетителя друг к другу. Проверяйте весь маршрут, включая старые правила нормализации адресов, а не только последнее добавленное условие.

Обновите SEO-настройки под новый основной адрес

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

Canonical и языковые версии

На индексируемой канонической HTTPS-странице canonical должен указывать на её выбранный канонический адрес. Если у страницы уже предусмотрена другая каноническая цель, например для дубля, сохраните эту логику и обновите протокол цели. Не заменяйте все canonical ссылкой на главную.

Пример для самостоятельной страницы каталога:

<link rel="canonical" href="https://example.com/catalog/">

Согласуйте canonical, внутренние ссылки и перенаправления. Используйте полный URL: Google описывает способы выбора адреса и типичные противоречия в руководстве по каноникализации. Canonical не заменяет серверный редирект и не гарантирует, что поисковик примет выбранный вариант без учёта других сигналов.

Для многоязычного сайта обновите HTTPS-адреса в hreflang и проверьте взаимные ссылки между версиями. Согласно документации Google, адреса альтернатив должны быть полными, включая протокол. Не меняйте языковые коды или структуру локалей без отдельной задачи.

Sitemap, robots.txt и запреты индексирования

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

В robots.txt проверьте разрешения и полный HTTPS-адрес карты, если там есть директива Sitemap. Область действия файла определяется протоколом, хостом и портом, что описано в спецификации обработки robots.txt у Google. Не закрывайте старые URL от обхода просто ради их исчезновения: робот должен иметь возможность увидеть перенаправление.

Уберите временные запреты noindex и X-Robots-Tag: noindex с тех HTTPS-страниц, которые должны участвовать в поиске. При этом сохраните ограничения для кабинетов, служебных разделов и других страниц, которые не предназначены для индексации. Проверьте, не попали ли настройки тестовой среды в рабочее окружение.

Как сообщить о переходе Google и Яндексу

У поисковых сервисов различаются инструменты переезда. Не переносите инструкцию из одного кабинета в другой: одинаковое изменение протокола оформляется по-разному.

Google Search Console

Убедитесь, что можете просматривать данные нового HTTPS-адреса, отправьте актуальный sitemap и проверьте важные URL инструментом проверки страниц. Если используете отдельные ресурсы с префиксом URL, учтите различие HTTP и HTTPS. Сохраните доступ к данным старого адреса для сравнения.

Change of Address для обычного перехода с HTTP на HTTPS не требуется. Это прямо указано в руководстве Google по миграции URL. Там же рекомендовано сохранять перенаправления как можно дольше, обычно не менее года. Для посетителей, старых закладок и внешних ссылок полезно поддерживать их и дальше.

Переобход и обработка изменений занимают время; обещать завершение к определённому дню нельзя. Наблюдайте за HTTPS-страницами, ошибками обхода и трафиком. Смена протокола сама по себе не гарантирует роста позиций или заявок.

Яндекс Вебмастер

В Яндекс Вебмастер добавьте HTTP- и HTTPS-версии и подтвердите права. После проверки новой версии и редиректов в старом ресурсе откройте «Индексирование → Переезд сайта» и используйте опцию добавления HTTPS по актуальной инструкции Яндекса. Следите за обработкой заявки и страницами в поиске.

Выберите основной вариант с www или без него в соответствии с настройками сайта. Обновите ссылки в рекламе, профилях компании и письмах, чтобы новые переходы сразу начинались с HTTPS.

Как проверить, что после перехода всё работает

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

Проверьте редирект командой curl

Примеры рассчитаны на Linux или macOS с установленным curl. Они выполняют обычный GET-запрос к учебной странице, печатают заголовки и не сохраняют тело ответа. Перед проверкой замените домен и путь на свои; выбирайте публичную страницу без действий, изменяющих данные:

curl -q -sS --connect-timeout 10 --max-time 20 -D - -o /dev/null 'http://www.example.com/catalog/?utm_source=test'

Ожидайте постоянный редирект и правильный Location, например https://example.com/catalog/?utm_source=test. Убедитесь, что не потерялись каталог и параметры. Для просмотра всей цепочки добавьте следование редиректам:

curl -q -sS -L --max-redirs 5 --connect-timeout 10 --max-time 30 -D - -o /dev/null 'http://www.example.com/catalog/?utm_source=test'

-q в начале отключает пользовательский файл настроек curl, -D - выводит заголовки, -L следует перенаправлениям, а --max-redirs ограничивает их число. Параметры описаны в справочнике curl. Не добавляйте -k: проверка сертификата должна оставаться включённой. Нулевой код завершения программы не заменяет оценку полученных HTTP-статусов.

Повторите проверку для домена с www и без него, нескольких внутренних страниц и нужных параметров. Конечный адрес должен быть правильным и возвращать ожидаемый результат. Для существующей публичной страницы обычно ожидается 200; отсутствующая страница должна сохранять корректную ошибку, а не превращаться в главную с ответом 200.

Проверьте действия пользователя

Навигация. Меню, поиск, фильтры и пагинация ведут на актуальные адреса и сохраняют выбранные параметры.
Авторизация. Вход, выход, восстановление пароля и переходы между нужными поддоменами работают с ожидаемой сессией.
Формы. Отправка завершается подтверждением, данные появляются у получателя, ошибки заполнения отображаются корректно.
Магазин. Корзина сохраняется, заказ создаётся, тестовый платёж и серверное уведомление проходят предусмотренный сценарий.
Ресурсы. Нет заблокированных Mixed Content запросов, пропавших шрифтов, скриптов и встроенных блоков.
Аналитика. Нужные события фиксируются, рекламные параметры сохраняются, тестовые заявки можно отличить от реальных.

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

Проверьте внешнее наблюдение

Повторите проверку из другой сети и по известным узлам балансировщика. Обновите URL в проверках доступности, сохранив контроль старых HTTP-входов.

После запуска наблюдайте за ошибками 4xx/5xx, циклами перенаправлений, обращениями к старым адресам и доставкой заявок. Сравнивайте показатели с исходной точкой с учётом обычных колебаний трафика. Если снизились обращения, сначала проверьте работоспособность форм и измерений, затем делайте выводы о поисковом трафике.

Когда включать HSTS после перехода

HSTS сообщает поддерживающему браузеру, что к хосту следует обращаться по HTTPS в течение заданного времени. Заголовок передают через защищённое соединение. Его поведение и область действия описаны в справке Strict-Transport-Security.

Настраивайте эту политику после устойчивой работы HTTPS и проверки обновления сертификатов. Начальный срок и его увеличение выбирают осознанно. Параметр includeSubDomains распространяет требование на поддомены, поэтому сначала проверьте все зависимые сервисы. Участие в preload-списке требует отдельной готовности и не является обязательным первым шагом переезда.

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

Типичные ошибки после перевода сайта на HTTPS

Начинайте с наблюдаемого симптома и проверяйте соответствующий участок. Повторная установка сертификата не исправляет ошибочный canonical, а очистка кеша не устраняет цикл между CDN и приложением.

Симптом	Направление проверки
Браузер предупреждает о сертификате до перенаправления	Сертификат исходного HTTPS-имени, цепочка, точка завершения TLS
Сообщение о слишком большом числе редиректов	Согласованность HTTPS и www в CDN, сервере и CMS; определение протокола за прокси
Категории и товары ведут на главную	Сохранение пути и карта соответствия старых и новых URL
Пропали фильтры или рекламные метки	Передача query-параметров в Location и дальнейшая обработка приложением
Страница открывается, но форма не отправляется	Адрес обработчика, Mixed Content, сессия, метод запроса и журнал приложения
HTTPS-страницы не обнаруживаются или исключаются из поиска	robots.txt, noindex, canonical, sitemap и результат проверки конкретного URL
Ошибка появляется только у части посетителей	Разные узлы, IPv4/IPv6, кеши, старые сессии и фактический маршрут запроса

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

Частые вопросы о переходе на HTTPS

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

Нет. Это создаёт предпосылку для защищённого соединения. Нужно ещё обновить адреса приложения, ссылки и SEO-настройки, обработать старые входы и проверить пользовательские действия. Новый сертификат может быть установлен правильно, а форма — продолжать отправлять запрос на старый HTTP-адрес.

Можно ли оставить HTTP и HTTPS одновременно?

Технически сайт может отвечать по обоим протоколам, но для постоянного перехода публичных страниц обычно выбирают основной HTTPS-адрес и перенаправляют на него старые входы. Исключения для служебных маршрутов определяют отдельно. Не превращайте временный этап подготовки в два несогласованных набора адресов.

Когда удалять редиректы после переезда?

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

Нужно ли менять домен или покупать новый хостинг?

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

Сколько времени занимает переход сайта на HTTPS?

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

Чек-лист: сайт переведён на HTTPS и результат подтверждён

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

Основной HTTPS-адрес выбран и одинаково используется в приложении и SEO-настройках.
Нужные имена открываются с подходящими действующими сертификатами.
HTTP-входы направляют на соответствующие HTTPS-страницы без петель и лишних цепочек.
Пути и необходимые параметры сохраняются, отсутствующие страницы обрабатываются корректно.
Внутренние ссылки, ресурсы, canonical, hreflang и sitemap обновлены.
Индексируемые страницы доступны роботам, временные запреты сняты.
Формы, авторизация, заказы и интеграции проверены по полному сценарию.
В поисковых сервисах выполнены действия, подходящие именно для смены протокола.
Проверки доступности, обслуживание сертификата и уведомления имеют ответственного.

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