Перенос сайта на новый домен без потери SEO: 301 редиректы, HSTS и SSL

Перенос сайта на новый домен — стрессовая операция для любой команды. В идеале для пользователя должна поменяться только строка в адресной строке, а поисковые системы должны безошибочно понять: это тот же сайт, переехавший на новый адрес. На практике ошибки с 301 редиректами, HTTPS/SSL, HSTS, canonical, sitemap и robots.txt приводят к потере позиций и хаосу в индексации. Ниже — выверенная последовательность действий и готовые решения на уровне веб-сервера, чтобы миграция прошла без потерь.

Почему смена домена — риск для SEO

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

• распаду ссылочного веса из-за неправильных редиректов (302 вместо 301, цепочки и петли);
• дублированию контента (отсутствие canonical и смешанные адреса http/https, www/без www, старый/новый домен);
• выпадению из индекса из-за блокирующего robots.txt или неактуальной sitemap.xml;
• проблемам безопасности (нет SSL на старом домене, mixed content, слишком агрессивный HSTS);
• потере данных аналитики и неправильной атрибуции трафика.

Хорошая новость: почти все риски контролируемы, если следовать плану и запускать миграцию по чек-листу.

План миграции: кратко по шагам

1. Провести инвентаризацию URL и данных: краулинг, карта редиректов, топ-страницы, внешние ссылки.
2. Подготовить новый домен: SSL/HTTPS, структура URL идентична старой, исправить внутренние ссылки.
3. Настроить 301 редиректы на уровне веб-сервера так, чтобы любой старый URL попадал в соответствующий новый за один хоп.
4. Обновить canonical, hreflang, sitemap.xml, robots.txt, микроразметку.
5. Включить аккуратный HSTS и исключить mixed content.
6. Обновить настройки в Google Search Console и Яндекс.Вебмастер, загрузить карты сайта.
7. Мониторить логи, статусы, цепочки редиректов, индекс и позиции, оперативно исправлять 404/410.

Подготовка: инвентаризация и стратегия URL

Соберите полную карту адресов

Перед миграцией выгрузите список всех индексируемых URL: краулер (Screaming Frog/Netpeak/отчёты логов), CMS-экспорт, база ссылок. Отдельно отметьте:

• трафикообразующие страницы (топ по SEO/конверсии);
• страницы с сильными внешними ссылками;
• динамические и параметризованные URL (фильтры, сортировки);
• статические ресурсы (изображения, CSS, JS), страницы пагинации и поиск по сайту.

Если структура URL не меняется, вы в выигрыше: редирект будет 1:1 с сохранением пути и параметров. Если меняется — составьте явную таблицу соответствий (mapping), особенно для важнейших страниц, и закройте брошенные URL кодом 410.

Нормализация URL до запуска

Упростите алгоритм сопоставления за счёт нормализации адресов ещё на старом домене. Определите и зафиксируйте единственный канонический вариант для:

• слеша на конце (/catalog vs /catalog/),
• регистра символов в пути (чувствительность к регистру на уровне приложения/файловой системы),
• страниц по умолчанию (/index.html → /),
• параметров сортировки/фильтров (неиндексируемые значения закрывайте noindex или через robots.txt),
• дублирующих параметров и пустых значений (?utm=, хвост из лишних &).

Чёткая нормализация на старом сайте сокращает вероятность неожиданных дублей на новом.

Сохраняйте структуру и контент

Чем меньшие изменения вы делаете одновременно с переездом, тем проще роботу сопоставить старое и новое. По возможности:

• не меняйте URL и шаблоны страниц в день миграции;
• не резайте контент и не меняйте массово заголовки/Title/Description;
• перенастройте внутренние ссылки на новый домен заранее (стадия предпросмотра) и проверьте, что они абсолютные/относительные последовательно.

Стейджинг и запрет индексации до запуска

Разворачивайте новый домен в тестовом окружении или на временном поддомене, но не допускайте преждевременной индексации. На этапе подготовки добавьте X-Robots-Tag: noindex, nofollow к ответам, закройте доступ базовой авторизацией и продублируйте запрет в robots.txt (Disallow: /). Перед запуском обязательно уберите эти ограничения, иначе роботы не начнут обход.

Если выпускаете сертификат через ACME-клиент, убедитесь, что защита не мешает валидации на путях /.well-known/. Для end-to-end проверок удобно использовать подмену hosts у ограниченного круга тестировщиков, чтобы не «светить» новый домен в поиске до часу X.

DNS и тайминг

За сутки-двое уменьшите TTL для A/AAAA/CNAME записей до 300 секунд — так переключение пройдёт быстрее. Перенос планируйте на малонагруженное окно (ночь/выходной), но с доступностью ключевых специалистов. Держите старый домен с рабочим SSL и редиректами минимум 3–6 месяцев после переезда. Если домен ещё не куплен или требуется перенос — оформите заранее через регистрацию доменов и проверьте NS/зону до старта.

Регистрация доменов от 99 руб.

Каждый проект заслуживает идеального доменного имени, выберите один из сотни, чтобы начать работу!

Зарегистрировать домен

HTTPS/SSL и HSTS: как не выстрелить себе в ногу

SSL должен быть на обоих доменах

Старый домен продолжает принимать трафик, чтобы отдать 301 редирект. Это значит: на старом домене должен стоять валидный SSL-сертификат (включая все нужные поддомены) в период пост-миграции. Иначе браузер/робот увидит ошибку TLS и до редиректа не дойдёт. Заранее выпустите и проверьте SSL-сертификаты для старого и нового домена (SAN или wildcard — по потребности), продлите их срок действия на период миграции.

Избегайте mixed content

После включения HTTPS на новом домене проверьте, что нет загрузок по http:// к изображениям/скриптам/шрифтам. Иначе получите поломку интерфейса и предупреждения безопасности. Ищите и правьте протокол-зависимые ссылки в шаблонах и CMS, используйте протокольно-независимые URL (//) или явный HTTPS.

HSTS: аккуратно и без спешки

HSTS сообщает браузеру: «к этому домену обращайся только по HTTPS». Это усиливает безопасность, но при миграции важно не зацементировать ошибки. Рекомендации:

• включайте HSTS сначала с умеренным max-age (например, 1–4 недели), без preload, проверьте поведение;
• не добавляйте includeSubDomains, если не уверены в сертификатах для всех поддоменов;
• на старом домене HSTS допустим, но preload там обычно не нужен — вы всё равно перенаправляете на новый домен;
• добавляйте preload для нового домена только после стабилизации миграции и покрытия сертификатами всех нужных хостов.

TLS-настройки и производительность

Чтобы редирект с HTTPS отдавался быстро и без предупреждений, проверьте базовые параметры TLS на обоих доменах: включите HTTP/2 (http2) и ALPN, OCSP Stapling, корректные цепочки сертификатов. Если у вас высоконагруженный проект, имеет смысл держать и RSA, и ECDSA сертификаты для максимальной совместимости клиентов. Следите, чтобы наборы шифров и минимальная версия TLS не отличались радикально между старым и новым доменом — это избавит от нетипичных 525/526 у части посетителей.

301 редиректы: принципы и реализация

Требования к редиректам

• Код 301 (перманентно), не 302/307, если это постоянный переезд.
• Один хоп: любой старый URL сразу ведёт на эквивалентный новый, без цепочек http→https→www→новый.
• Сохраняйте путь и строку запроса ($request_uri): /catalog/item?id=10 → /catalog/item?id=10.
• Не перенаправляйте всё на главную: каждый URL должен иметь свой целевой эквивалент, иначе теряется релевантность.
• Для удалённых страниц отдавайте 410, а не гоняйте по цепочкам.

Подводные камни при настройке

• Nginx: используйте return 301 вместо связки rewrite+break — так короче и без побочных эффектов.
• Не теряйте query-string: в Nginx добавляйте $is_args$args, если строите URL вручную; в Apache используйте флаг [QSA] при необходимости.
• Сохраняйте кодировку пути: не допускайте двойного декодирования/кодирования, иначе %2F может превратиться в слэш.
• Следите за www/без www. Фиксируйте канон заранее и убирайте промежуточные редиректы: сразу на целевой хост нового домена.
• Не смешивайте правила на CDN и на бэкенде, если не уверены — легко получить незаметную «лесенку» из 2–3 хопов.

Пример Nginx: старый домен → новый домен в один хоп

# http на старом домене сразу редиректим на https нового домена
server {
    listen 80;
    server_name old.example.com www.old.example.com;
    return 301 https://new.example.com$request_uri;
}

# https на старом домене (нужен валидный сертификат)
server {
    listen 443 ssl http2;
    server_name old.example.com www.old.example.com;

    ssl_certificate     /etc/ssl/certs/old.fullchain.pem;
    ssl_certificate_key /etc/ssl/private/old.key;

    # аккуратный HSTS (без preload на старом домене)
    add_header Strict-Transport-Security "max-age=2592000" always; # 30 дней

    return 301 https://new.example.com$request_uri;
}

Если структура URL меняется, добавьте слой соответствий. Для небольших наборов — сразу правила, для больших — используйте map или внешние файлы. Полный контроль за конфигами удобнее держать на VDS, где легко управлять маппингами и тестовыми экземплярами.

# Пример map: только для особых случаев, остальное — 1:1
map $request_uri $mapped_uri {
    default                      $request_uri;
    /old-path/best-item          /new-path/top-item;
    /blog/2020/old-article       /blog/guide/domain-migration;
}

server {
    listen 443 ssl http2;
    server_name old.example.com;
    # ... SSL ...
    return 301 https://new.example.com$mapped_uri$is_args$args;
}

Пример Apache (.htaccess): старый домен → новый домен

RewriteEngine On

# Сразу на новый домен в https, один хоп
RewriteCond %{ HTTP_HOST} ^(www\.)?old\.example\.com$ [NC]
RewriteRule ^(.*)$ https://new.example.com/$1 [R=301,L]

Важно: не делайте дополнительных правил типа «сначала http→https на старом, а затем домен→домен». Обеспечьте один хоп в сторону нового домена. На виртуальном хостинге без доступа к Nginx — используйте .htaccess.

Редиректы на уровне CDN/балансировщика

Если у вас есть CDN или обратный прокси, предпочтительнее настраивать редирект как можно ближе к краю (Edge), чтобы экономить RPS на бэкенде и ускорить ответ. При этом следите, чтобы не возникали дубли правил на нескольких уровнях (CDN + веб-сервер), создающих цепочки.

Тестирование редиректов

Проверьте выборку из всех типов страниц (каталог, карточка, пагинация, поиск, блоги, медиа) и убедитесь в коде 301 и одной переадресации:

curl -I http://old.example.com/catalog/item?id=10
curl -I https://old.example.com/catalog/item?id=10
curl -I http://www.old.example.com/

Автоматизируйте проверки на сотнях URL с помощью краулера и убедитесь в отсутствии цепочек и 302. Дополнительно проверьте заголовки кеширования и куки: домен куки должен соответствовать новому хосту, а каноникал и og:url не должны указывать на старый адрес. Исключите редиректы, завязанные на рефереры — они усложняют диагностику и ломают перенос веса.

Лайфхак: возьмите выборку URL из access-логов за последние 60–90 дней (только 200/301 и с трафиком), проверьте покрытие маппинга именно по ним. Это позволит закрыть «длинный хвост» реально популярных адресов и не упустить важные посадочные.

Canonical, hreflang, sitemap и robots.txt

Canonical

На новом домене все страницы должны указывать canonical на свою новую каноническую версию:

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

Не оставляйте каноникал, указывающий на старый домен, после запуска редиректов — это создаёт противоречие сигналов. На старом домене каноникал уже не играет роли, так как там только редиректы.

Hreflang

Если есть мультирегиональность/мультиязычность, обновите hreflang, чтобы каждая языковая версия ссылалась на корректный новый домен. Сохраните взаимность между парами hreflang.

Sitemap.xml

Сгенерируйте новые sitemap.xml для нового домена со всеми каноническими URL и отдавайте их быстро и без аутентификации. Для крупных сайтов используйте индекс карт (sitemap_index.xml) и разбивку по 50 000 URL/50 МБ на файл. Проставляйте актуальные lastmod, чтобы ускорить переобход важных страниц. Старые карты сайта можно временно оставить доступными (к роботам всё равно прилетит 301 на уровне URL), но не забудьте прогнать повторную индексацию новых карт в инструментах для веб-мастеров.

robots.txt

На новом домене не должно быть исторических ограничений, случайно запрещающих индексацию. Обновите директивы Host (для Яндекса) и Sitemap, укажите новые карты сайта. На старом домене robots.txt может оставаться, но ключевую роль теперь играют 301 редиректы.

Search Console и Яндекс.Вебмастер

Подтвердите права на оба домена (старый и новый) одинаковым способом. В день миграции:

• добавьте и подтвердите новые свойства (для поддомена и корня, если требуется);
• загрузите новые карты сайта;
• используйте инструмент смены адреса (там, где доступно), чтобы уведомить Google о переносе;
• проверьте отчёты об ошибках сканирования и индексирования, почините 404/410 и некорректные редиректы;
• сверяйте клики/показы по старому/новому домену, следите за динамикой.

В Яндекс.Вебмастере аналогично: подтвердите права, укажите новый сайт в настройках, перезалейте sitemap.xml, следите за индексом, очистите накопившиеся ошибки. Если меняете также канонический хост (www↔без www), убедитесь, что это отражено в настройках и не конфликтует с правилами редиректа.

Дополнительно: что проверить в админках

• Ограничения по сканированию в GSC (crawl rate) — временно не занижайте.
• Проверка файла robots.txt через инструменты, чтобы исключить кеш старой версии.
• Переиндексация выборки критически важных URL («Проверить URL» с запросом на индексирование).

Аналитика и метрики после запуска

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

• логи веб-сервера: распределение по статусам HTTP, аномальные 404/5xx, скорость ответа;
• цепочки редиректов и количество хопов;
• долю страниц с HTTPS и корректным HSTS;
• количество проиндексированных URL в сравнении со старым доменом;
• позиции и клики по основным кластерам запросов.

Рекомендуется временно расширить логирование (например, добавить $scheme, $request_time, $upstream_status) и сохранять выборку редакторских/карточек/каталожных страниц в отдельный мониторинг. Это ускорит разбор инцидентов, если часть маршрутов окажется не покрыта маппингом.

Поддерживайте старый домен с редиректами и SSL не меньше нескольких месяцев, а лучше — до года, особенно если у вас сильный «хвост» старых ссылок. План отката держите на случай критических ошибок (например, неработающий checkout): с уменьшенным TTL вы сможете оперативно переключить трафик, но избегайте «качелей» — лишние смены адреса ухудшают сигналы.

Куки, CSP, CORS и безопасность

При смене домена пересмотрите политики безопасности и параметры куки:

• Set-Cookie: обновите Domain на новый хост/зону, включите Secure и актуальные SameSite;
• Content-Security-Policy: добавьте новый домен во все источники (img-src, script-src, connect-src и т.д.);
• Referrer-Policy и Permissions-Policy: проверьте, что они не ломают конверсии и метрики;
• CORS: если фронтенд и API на разных хостах, обновите список разрешённых источников.

Ошибки в этих местах часто маскируются под «просадку SEO», хотя по факту ломают индексируемость/рендеринг и метрики.

Интеграции и внешние точки входа

Не забудьте про все источники трафика за пределами поиска: ссылки в письмах и шаблонах транзакционных уведомлений, редиректы после оплаты, OAuth redirect URI, callback URL для вебхуков, ссылки в мобильных приложениях, короткие ссылки в соцсетях. Обновите whitelist доменов у платёжных провайдеров и партнёров. На период миграции держите трекинг UTM-меток и убедитесь, что редирект не сбрасывает их.

Частые ошибки и как их избежать

• 302 вместо 301. Для постоянного переезда используйте 301. Исключения — временные тесты.
• Цепочки редиректов. Обеспечьте один хоп: сразу со старого http/https на новый https.
• Редирект всего на главную. Настраивайте соответствия URL, иначе теряется релевантность и позиции.
• Нет SSL на старом домене. Редирект по HTTPS не сработает без валидного сертификата.
• Агрессивный HSTS с preload на старте. Сначала мягкий HSTS, preload — позже.
• Забыли обновить canonical/hreflang. Иначе роботы получают противоречивые сигналы.
• Mixed content. Чистите протокол-зависимые ссылки, используйте HTTPS везде.
• Неполная карта URL. Пропуски приводят к 404 и потере веса.
• Необновлённые sitemap/robots.txt. Роботы дольше «понимают» переезд.
• Потеря query-параметров при редиректе. Всегда сохраняйте строку запроса.

Мини-чек-лист миграции

1. Инвентаризация всех URL и топ-страниц; таблица соответствий.
2. Новый домен: SSL готов, контент развернут, внутренние ссылки обновлены.
3. Редиректы 301 настроены на сервере/CDN, один хоп, протестировано.
4. HSTS включён осторожно, без preload, без includeSubDomains при сомнениях.
5. Обновлены canonical, hreflang, sitemap.xml, robots.txt.
6. Search Console/Вебмастер: подтверждения, смена адреса, карты сайта.
7. Мониторинг логов, статусов, индекса и позиций; оперативные фиксы.
8. Старый домен c SSL и редиректами поддерживается 3–12 месяцев.

Вопросы и ответы

Сколько длится «просадка» трафика?

Если всё сделано корректно, заметная просадка либо отсутствует, либо длится 1–3 недели, пока роботы переиндексируют и перенесут сигналы. На высоконагруженных проектах процесс может занять дольше.

Нужно ли отключать старый сайт?

Не сразу. Сначала переведите его в режим «редирект-сервера» с валидным SSL и корректной схемой 301. Физически контент на старом домене не должен открываться.

Стоит ли делать 302 на первое время?

Нет. Google и Яндекс давно корректно переносят сигналы по 301, и лучше сразу отдавать постоянный редирект. 302 оставляет двусмысленность.

Как быть с внешними ссылками?

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

Можно ли менять структуру URL одновременно с доменом?

Лучше нет. Делайте одно крупное изменение за раз. Если иначе нельзя, готовьте подробную карту соответствий и уделите больше времени тестам.

Главная мысль: миграция — это управляемый процесс. Сделайте один хоп 301, везде HTTPS с валидным SSL, аккуратный HSTS, обновите каноникал и карты сайта, уведомьте веб-мастер-инструменты и смотрите в логи. Тогда «переезд» для робота будет таким же простой операцией, как смена адреса в визитке.