Животные меняются при загрузке страницы
Пошаговый чеклист миграции сайта на HTTPS: как сохранить позиции и избежать падения трафи…
Карточки, чек-листы, таблицы и примеры помогают быстро найти нужный ответ.
Переход сайта на HTTPS – это не просто смена протокола. Это комплексный процесс, требующий тщательной подготовки, точной настройки сервера и постоянного контроля результатов. В этом чеклисте собраны конкретные действия, которые помогут сохранить позиции в поиске и избежать резкого падения трафика.
Сохранять позиции при миграции на HTTPS можно, если выполнить следующие ключевые шаги: провести аудит готовности, получить и настроить сертификат, обновить все внутренние ссылки и канонические теги, настроить 301‑редиректы, проверить индексацию в поисковых консолях, оценить влияние на Core Web Vitals, а затем внимательно мониторить результаты и при необходимости вносить коррективы.
Аудит до миграции
Проверьте сертификат: действителен ли, срок, цепочка, совместимость с TLS 1.2/1.3. Используйте инструменты вроде SSL Labs. Сканируйте сайт на http‑ссылки: внутренние (внутренний контент, меню, карты) и внешние (партнеры, ссылки на сторонние ресурсы). Сохраняйте список. Включите в поисковые консолы отчёты о покрытии, ошибки 404, редиректы, canonical. Оцените, какие страницы не индексированы, и устраните проблемы. Сравните текущий индекс с прошлым, чтобы знать baseline. Сохраняйте метрики: CTR, позиции, трафик. Запишите текущие настройки файрвола, CDN, HSTS. Убедитесь, что сервер поддерживает HTTP/2, HSTS preload. Сохраните конфигурацию .htaccess, Nginx, Apache. Проверьте, что robots.txt не блокирует http‑страницы. Сохраняйте шаблоны sitemap, убедитесь, что они используют https. Сделайте полную резервную копию сайта и базы данных. Сохраните текущий файл .htaccess, конфиги nginx, Apache, файлы .env. Проверьте, что все подключаемые модули (PHP‑версии, расширения) совместимы с HTTPS. Убедитесь, что все внешние API и скрипты используют HTTPS. Проверьте, что все изображения, CSS, JS подключаются по https, иначе они будут блокироваться браузером. Составьте список всех 301‑редиректов, которые уже настроены, и проверьте их корректность. Включите в отчёт о покрытии поисковых консолей статус каждой страницы, наличие canonical, hreflang. Проверьте, что sitemap.xml содержит только https‑ссылки и находится в корне. Убедитесь, что в файле .htaccess включена директива RewriteEngine On и правила перенаправления http на https. Проверьте, что сервер поддерживает HTTP/2 и SPDY, что ускорит загрузку. Сохраните метрики Core Web Vitals, LCP, FID, CLS в Google PageSpeed Insights. Сравните их с текущими значениями, чтобы иметь baseline. Запишите текущую частоту обновления кэша CDN, чтобы не потерять кэшированные ресурсы после перехода. Проверьте, что HSTS заголовок установлен с preload, чтобы браузеры сразу переходили на https. Сохраните список всех внешних ссылок, которые могут быть потеряны после перенаправления, и обновите их вручную.
Получение сертификата и настройка сервера
- Определить тип сертификата: wildcard для поддоменов, SAN‑сертификат для нескольких доменов. Выбрать CA, например Let’s Encrypt для бесплатного ACME, или коммерческое, если нужен расширенный контроль.
- Сгенерировать CSR (или использовать ACME‑плагин). Для Let’s Encrypt запустить
certbot certonly --standalone -d example.com -d www.example.comи получитьfullchain.pemиprivkey.pem. - Разместить файлы в
/etc/ssl/certsи/etc/ssl/private, установить праваchmod 600для ключа. - В конфигурации сервера прописать TLS‑протоколы:
ssl_protocols TLSv1.2 TLSv1.3;, включить сильные шифры, сессии и stapling. Ниже пример для nginx. - Перезапустить nginx/apache и убедиться, что порт 443 открыт, а 80 перенаправляет на https.
- Проверить работу:
openssl s_client -connect example.com:443 -tls1_2,-tls1_3; убедиться, что выбран cipherECDHE‑RSA‑AES256‑GCM‑SHA384и сертификат валиден. - Сканировать порт с помощью
nmap -p 80,443 example.com– 443 должно быть открыто, 80 – закрыто или редирект. - Проверить в SSL Labs:
https://www.ssllabs.com/ssltest/analyze.html?d=example.com– оценка должна быть A, протоколы 1.2/1.3, отсутствие уязвимостей. - В браузере открыть
https://example.com, убедиться, что замок зелёный, нет смешанного контента.
# nginx пример конфигурации
server {
listen 443 ssl http2;
server_name example.com www.example.com;
ssl_certificate /etc/ssl/certs/fullchain.pem;
ssl_certificate_key /etc/ssl/private/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_stapling on;
ssl_stapling_verify on;
# остальные директивы
}
Канонизация и внутренние ссылки
-
Canonical‑теги остались на http – поисковики видят два одинаковых URL, один http, один https.
Потеря ранжирования: дублирование контента приводит к размыванию ссылочного веса и падению позиций.
Как избежать: обновите все canonical‑теги в шаблонах и CMS, используя переменную протокола, и проверьте в Search Console, что canonical‑URL совпадает с https‑версией. -
Динамические ссылки в шаблонах не перешли на https – ссылки в каруселях, списках новостей, пагинации продолжают указывать http.
Потеря ссылочного веса: внутренние ссылки с http не передают authority к https‑страницам, а поисковики могут считать их «плохими» ссылками.
Как избежать: везде, где генерируется URL, замените hard‑coded http на протокол‑независимый вызов, например, {{ request.scheme }}://{{ request.host }} или просто //{{ request.host }}. -
hreflang‑теги используют http вместо https – при миграции они остаются прежними, что нарушает международную индексацию.
Потеря локального ранжирования: Google может игнорировать hreflang‑теги, если протокол не совпадает с фактическим, и показывать неверные языковые варианты.
Как избежать: обновите все hreflang‑теги, заменяя http на https, и проверьте в инструментах для вебмастеров, что все языковые ссылки корректны.
301‑редиректы и карта URL
Сохраняем ссылочный вес при переходе на HTTPS. Нужно составить карту URL, настроить 301‑редиректы и проверить их корректность. После миграции убедитесь, что 404‑страницы не появляются.
- Составьте файл со списком старых URL и их новых эквивалентов (пример: /old-page → https://example.com/new-page).
- Добавьте правила 301 в .htaccess или серверную конфигурацию для каждого старого пути.
- Проверьте 301‑ответ в браузере: откройте старый URL, убедитесь, что адрес изменился и статус 301.
- Проверьте 301‑ответ через curl:
curl -I http://example.com/old-page→HTTP/1.1 301 Moved Permanently. - После запуска проверьте, что на всех перенаправленных страницах нет 404‑ответов:
curl -I https://example.com/new-page→HTTP/1.1 200 OK. - Сканируйте все старые URL через Screaming Frog или Sitebulb, убедитесь, что они все перенаправлены.
- В Google Search Console проверьте раздел «Переадресации» – ошибок не должно быть.
Проверка в поисковых консолях
- Войдите в Google Search Console и Яндекс.Вебмастер, добавьте новый HTTPS‑домен и подтвердите владение.
- Запустите проверку ключевых страниц через «URL‑инспектор» в GSC и «Проверка URL» в Яндекс.Вебмастере.
- Откройте вкладку «Coverage» (Google) и «Отчёт о покрытии» (Яндекс) – убедитесь, что ошибок 404 и 500 нет.
- Проверьте раздел «Security Issues» в GSC и «Безопасность» в Яндекс: SSL‑сертификат должен быть валиден, ошибок не должно.
- Скачайте карту сайта, загрузите её в обе консоли и проверьте статус индексации в «Sitemaps».
- Запустите сканирование сайта в Screaming Frog с HTTPS‑режимом, сравните найденные 404 и SSL‑ошибки с данными консолей.
- Проверьте Core Web Vitals и Lighthouse в Chrome DevTools – они должны показывать улучшения по скорости и доступности.
- Отсутствие ошибок 404 и 500 в отчётах покрытия.
- Нулевые SSL‑ошибки в разделе безопасности.
- Карта сайта принята и полностью проиндексирована.
- Ключевые страницы находятся в индексе и показывают «Indexed» в инспекторе URL.
- Core Web Vitals находятся в пределах допустимых значений (LCP
| Инструмент | Что проверяем |
|---|---|
| Google Search Console | Coverage, Security Issues, Sitemaps, URL Inspection |
| Яндекс.Вебмастер | Покрытие, Безопасность, Карта сайта, Проверка URL |
| Screaming Frog SEO Spider | 404, SSL‑ошибки, internal links |
| Chrome DevTools (Lighthouse) | Core Web Vitals, доступность |
| SSL Labs | Проверка сертификата и цепочки |
Влияние на Core Web Vitals
| Параметр | Риск | Снижение риска |
|---|---|---|
| Core Web Vitals | LCP 2.3 s → 1.8 s, CLS 0.04 → 0.02, FID 120 ms → 80 ms | Оптимизация критического CSS, lazy‑load, HTTP/2, preload |
| Изображения & ресурсы | Большой размер, не‑компрессированные, отсутствие WebP | Сжатие, WebP/AVIF, HTTP/2, cache‑control, gzip |
| HTTP/2 | Неправильная настройка, отключённый multiplexing | Включить HTTP/2, проверить ALPN, приоритеты |
| HSTS & кэширование | Неверный max‑age, отсутствие preload, некорректный кеш | HSTS max‑age ≥ 31536000, preload, cache‑control, immutable |
| Переадресации 301/302 | Слишком много, медленные цепочки | Минимизировать, использовать 301, проверить цепочку |
| Криптография TLS | Старые протоколы, слабые cipher‑suites | TLS 1.3, ECDHE, SHA‑256, disable SSLv3 |
| Сервера и CDN | Низкая пропускная способность, latency | Оптимизировать гео‑распределение, edge caching |
| Мобильные устройства | Неподдерживаемые скрипты, медленный рендер | AMP, PWA, оптимизация JS, async/defer |
| SEO‑индексация | Потеря ссылок, дублирование контента | 301‑переадресации, canonical, robots.txt |
| Мониторинг после миграции | Необнаруженные ошибки, падение трафика | Google Search Console, Lighthouse, GTmetrix |
Мониторинг после релиза
После перехода на HTTPS важно быстро увидеть, как меняется трафик и позиции. Первый пункт – сравнение показателей в Google Analytics и Яндекс Метрике. В GA вы видите чистый трафик по протоколу, в Метрике – общую статистику, включая «HTTPS» и «HTTP». Сравните объёмы за один и тот же период до и после миграции, чтобы убедиться, что падения не связаны с техническими проблемами, а не с сезонностью. Если в Метрике снижается трафик, но GA остаётся стабильным, вероятно, ошибка в настройке поисковых роботов.
Второй пункт – проверка серверных логов. Ищите коды 500 и 404, которые могут указывать на неработающие ссылки после перенаправления. 301‑ответы – это правильные перенаправления, но их частота должна быть минимальной – только на тех страницах, которые действительно перемещены. Сравните процент 301 с общим количеством запросов: если он превышает 5 %, проверьте правила .htaccess.
Третий пункт – отслеживание CTR и позиций по ключевым запросам. В Яндекс.Вордстате и Google Search Console сравните средний CTR до и после миграции. Если CTR падает, но позиции остаются, проблема в отображении ссылок. Если позиции падают, проверьте наличие ошибок в индексации и наличие «https» в ссылках в Search Console.
Наконец, используйте автоматические отчёты. Настройте еженедельные дашборды в GA и Метрике, чтобы видеть отклонения в реальном времени. Это позволит быстро реагировать на неожиданные изменения.
| Параметр | Что смотреть | Где проверять |
|---|---|---|
| Объём трафика | Сравнение GA и Метрики за одинаковый период | GA → Audience → Overview, Метрика → Метрика → Метрика |
| Коды 500/404 | Частота ошибок в логах сервера | Серверные логи (access.log, error.log) |
| 301‑ответы | Процент перенаправлений по сравнению с общим трафиком | Логи, инструменты типа Screaming Frog |
| CTR по ключам | Сравнение среднего CTR до и после миграции | Яндекс.Вордстат, Google Search Console → Performance |
| Позиции по запросам | Стабильность или падение позиций | Google Search Console, Яндекс.Вордстат |
| Coverage Index | Наличие новых ошибок индексации | Google Search Console → Coverage, Яндекс.Вебмастер → Ошибки индексации |
HSTS и preload
- Неделя 1 – Подготовка:
- Проверьте, что все ресурсы доступны по HTTPS и нет смешанного контента.
- Сгенерируйте сертификат и убедитесь, что он действителен на всех поддоменах.
- Подготовьте конфигурацию сервера: для Apache добавьте
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"; для Nginx –add_header Strict-Transport_Security "max-age=63072000; includeSubDomains; preload" always;.
- Неделя 2 – Тестирование:
- С помощью
curl -I https://example.comубедитесь, что заголовокStrict-Transport-Securityвозвращается с нужными параметрами. - Проверьте совместимость браузеров: Chrome, Firefox, Edge, Safari, Safari on iOS. В Safari 12+ необходимо включить
includeSubDomainsиpreloadдля корректной работы. - Запустите hstspreload.org для проверки, что домен не попал в черный список и готов к preload.
- С помощью
- Неделя 3 – Отправка в preload‑лист:
- Заполните форму на https://hstspreload.org/, выберите «Submit».
- Подтвердите владение доменом через DNS‑запись или файл‑проверку.
- После одобрения домен будет добавлен в список Chrome, Edge и Safari. Время ожидания публикации в списке – от 3 до 30 дней.
- Неделя 4 – Мониторинг и корректировка:
- Проверьте, что все запросы к сайту проходят по HTTPS без ошибок в консоли браузера.
- Проверьте, что в Google Search Console нет ошибок 404, связанных с переходом на HTTPS.
- Обновите карты сайта и robots.txt, чтобы они ссылались только на HTTPS‑версии.
- В течение 1–2 месяцев – Наблюдение:
- Отслеживайте показатели Core Web Vitals и Core Page Experience в Search Console.
- Проверяйте, что индексация новых страниц не падает – используйте «URL Inspection» для критических страниц.
- Поддерживайте HSTS‑заголовок при смене инфраструктуры (например, при переходе на новый CDN).
Вопросы и ответы
Как быстро проверить, что миграция прошла успешно?
В Google Search Console откройте раздел Coverage, проверьте статус каждой страницы. Используйте инструмент URL Inspection для проверки HTTPS‑версии и убедитесь, что все 301‑переадреса работают. Также проверьте, что в Analytics не появились новые 404.
Что делать, если после миграции падает трафик?
Сначала проверьте отчёты по 404 и broken links, убедитесь, что все внутренние ссылки перенаправлены. Обновите sitemap, отправьте его в GSC, проверьте, что в Analytics не появились новые ошибки. Если трафик остаётся низким, сравните позиции с конкурентами и при необходимости скорректируйте контент.
Как убедиться, что все внутренние ссылки перенаправлены на HTTPS?
Запустите сканер сайта, например Screaming Frog, и посмотрите, что все URL содержат https://. Убедитесь, что в коде нет hard‑coded http‑ссылок, а в настройках CMS включена автоматическая переадресация.
Нужно ли обновлять внешние ссылки после миграции?
Обновлять внешние ссылки не обязательно, если вы настроили 301‑переадресацию. Однако, если важные партнёры используют ваши URL, стоит попросить их обновить ссылки, чтобы избежать потери ссылочного веса.
Как быстро проверить, что Google перестал показывать HTTP версии в SERP?
Введите в поиске http://yourdomain.com и посмотрите, появляются ли результаты. Если нет, значит Google перестал индексировать HTTP‑страницы. Также в GSC проверьте, что в разделе Coverage отсутствуют HTTP‑URL.
Как избежать падения позиций в нишах с высокой конкуренцией?
Сохраняйте оригинальный контент, обновляйте только URL‑структуру. Убедитесь, что 301‑переадреса не создают циклов, а canonical‑теги указывают на HTTPS‑версии. После миграции мониторьте позиции в течение 2–4 недель и при необходимости корректируйте мета‑данные.
Как быстро проверить, что SSL сертификат корректно установлен?
Откройте сайт в браузере, кликните на замок и убедитесь, что сертификат действителен и цепочка доверия завершена. Можно также использовать онлайн‑тест SSL Labs, но это займет несколько минут.
Что делать, если после миграции появляются ошибки 500?
Проверьте логи сервера, убедитесь, что правила .htaccess и конфигурация PHP не конфликтуют с HTTPS. Перезапустите веб‑сервер и проверьте, что все скрипты работают без ошибок.
Как быстро проверить, что все страницы доступны через HTTPS?
Запустите сканер, который проверит статус кодов 200 для всех URL. Если какие‑то страницы возвращают 404 или 301, исправьте ссылки и обновите sitemap.
Как быстро проверить, что мета‑теги и canonical не нарушены?
С помощью инструмента Screaming Frog или аналогичного проверьте, что все canonical‑теги указывают на HTTPS‑версии и что meta‑описания не содержат http‑ссылок. Убедитесь, что в GSC нет ошибок canonical.
Важно
Материал носит информационный характер. Перед внедрением рекомендаций учитывайте нишу, регион, конкурентов, текущее состояние сайта и бизнес-цели проекта.
Материал подготовлен и проверен редакцией AX.SEO
Редакция AX.SEO готовит материалы о SEO, разработке, AI, аналитике, маркетинге и росте digital-проектов.
Проверяет практическую применимость рекомендаций, корректность терминов и соответствие материала digital-тематике.