Смена домена — это не просто «переехали и живём дальше». На деле это всегда риск потерять часть трафика, посадить SEO и получить пачку 404, если 301-редиректы настроены кое-как. Я в таких переездах участвовал не раз, и честно говоря, в 2026 году ошибки всё те же: забывают старые URL, режут цепочки, кладут редиректы на уровне CMS вместо сервера и удивляются, почему Google и Яндекс месяцами тянут старый адрес.
Почему 301 после смены домена — это настройка, которую нельзя провалить
Если коротко, 301-редирект сообщает поисковикам и браузерам: «страница переехала навсегда». И если вы меняете домен, то каждая старая страница должна вести на максимально релевантную новую. Не на главную «для удобства», а именно туда, где пользователь реально найдёт тот же смысл. Иначе это уже не переезд, а потеря накопленного SEO-веса.
У меня был клиент с интернет-магазином на WordPress, который переехал с одного домена на другой «в один вечер». Разработчик поставил общий редирект с любого URL на главную нового домена. В итоге из 18 тысяч страниц в индексах осталась куча мусора, а органический трафик просел примерно на 38% за два месяца. И это при нормальном хостинге, PHP 8.2 и MySQL 8.0. Проблема была не в сервере, а в логике редиректов.
Если вам нужно не просто «переехать», а сделать всё аккуратно, я обычно советую сначала провести проверку сайта, а потом уже настраивать переезд. И если во время миграции всплывают доработки, лучше сразу решать их через доработку сайта, а не пытаться склеить всё костылями в .htaccess.
И ещё момент. 301 после смены домена — это не только SEO. Это ещё и аналитика, реклама, email-рассылки, внешние ссылки, закладки пользователей, старые карточки в соцсетях. То есть вопрос шире, чем просто «чтобы робот не ругался».
Подготовка к переезду: что сделать до включения редиректов
Я обычно начинаю не с правил редиректа, а с инвентаризации. Нужно понять, какие URL были на старом домене, какие должны быть на новом, что удалилось, что переименовалось, а что вообще не нужно переносить. Без этого редиректы превращаются в угадайку. А угадайка в SEO — это всегда дорого.
Составьте таблицу хотя бы в Google Sheets или Excel. Колонки простые: старый URL, новый URL, тип переноса, комментарий. Если сайт большой, выгружайте URL из sitemap, логов, CRM, CMS, Search Console, Яндекс.Вебмастера и базы данных. На больших проектах я ещё смотрю лог сервера за 3–6 месяцев, чтобы не потерять реальные входные страницы из поиска и внешних ссылок.
На моей практике очень выручает связка из трёх вещей: резервная копия, staging-среда и проверка перед боевым запуском. Если переезд идёт не в вакууме, а вместе с обновлением дизайна, структуры или движка, я бы сначала поднял staging по схеме из статьи Как настроить staging-среду для сайта в 2026 году, а потом тестировал редиректы уже там. Иначе можно очень красиво сломать весь проект одним деплоем.
Ещё одна вещь, которую многие забывают: canonical и sitemap. После смены домена старые canonical должны вести на новый домен, а XML sitemap должен содержать только новые адреса. Об этом я отдельно писал в статье Как настроить canonical URL для SEO в 2026 году и в материале про XML sitemap для SEO. Если оставить старые canonical, поисковик может долго путаться, особенно на WordPress и Bitrix-сайтах с несколькими шаблонами.
Как настроить 301-редиректы на Nginx
Если у вас Nginx, я почти всегда советую делать редиректы на уровне сервера. Это быстрее, чище и надёжнее, чем городить логику внутри CMS. Особенно если сайт на Laravel, Bitrix или WordPress крутится на PHP 8.1–8.3. Сервер обработает редирект раньше, чем PHP вообще проснётся, а это экономит и время ответа, и ресурсы.
Для полного переезда домена можно настроить редирект так, чтобы любой запрос со старого домена уходил на новый с сохранением пути и query string. Пример рабочий:
server {
listen 80;
server_name old-domain.ru www.old-domain.ru;
return 301 https://new-domain.ru$request_uri;
}
server {
listen 443 ssl http2;
server_name old-domain.ru www.old-domain.ru;
ssl_certificate /etc/letsencrypt/live/old-domain.ru/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/old-domain.ru/privkey.pem;
return 301 https://new-domain.ru$request_uri;
}Этот вариант нормальный, если структура URL на новом домене не менялась. То есть было /catalog/shoes/ на старом, стало то же самое на новом. Тогда Nginx просто переносит всё один в один. Если же структура изменилась, нужен отдельный файл map или набор location-правил.
Например, если раздел /blog/ переехал в /articles/, я обычно делаю явное соответствие:
location = /blog/ {
return 301 https://new-domain.ru/articles/;
}
location ^~ /blog/ {
rewrite ^/blog/(.*)$ https://new-domain.ru/articles/$1 permanent;
}И вот тут многие допускают ошибку: добавляют редирект через rewrite без проверки, не учитывают слэши, параметры и дублирующие правила. Потом получаются цепочки 301 → 301 → 200, а это уже лишняя нагрузка и плохой сигнал для SEO. Если надо, лучше сразу проверить цепочки через Screaming Frog, Netpeak Spider или хотя бы curl.
На проектах с высокой посещаемостью, где важно не терять миллисекунды, я обычно ещё проверяю обратный прокси Nginx и настройки кэша. Потому что если редирект на уровне nginx есть, а upstream и CDN живут своей жизнью, можно получить странные эффекты. Я видел сайт на VPS с Nginx и Redis-кэшем, где редирект срабатывал, но CDN упорно отдавал старую страницу из кэша ещё 20 минут. Это уже вопрос purge и заголовков.
.htaccess и WordPress: когда Apache всё ещё актуален
Да, в 2026 году Apache и .htaccess всё ещё живы. И на WordPress это встречается очень часто. Если у вас shared hosting или проект старого типа, редиректы после смены домена можно прописать через .htaccess. Но я предупреждаю сразу: аккуратно, без самодеятельности. Одна лишняя строка — и получите бесконечный редирект.
Базовый вариант для полного переноса домена выглядит так:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} ^old-domain\.ru$ [NC,OR]
RewriteCond %{HTTP_HOST} ^www\.old-domain\.ru$ [NC]
RewriteRule ^(.*)$ https://new-domain.ru/$1 [R=301,L]
</IfModule>Если нужно сохранить путь и параметры, этот вариант обычно хватает. Но если сайт на WordPress, обязательно проверьте, не конфликтует ли редирект с правилами самой CMS. WordPress любит переписывать URL через свои стандартные блоки, и иногда редирект надо ставить выше блока # BEGIN WordPress или делать его на уровне виртуального хоста.
На одном проекте у меня был случай, когда сайт на WordPress после переезда срабатывал правильно только для главной, а внутренние страницы выдавали 404. Оказалось, в .htaccess стоял редирект на новый домен, а потом ниже — старые правила кеш-плагина и дефолтный WordPress rewrite. В результате Apache обрабатывал правила не так, как ожидали. Решили за 15 минут, но до этого клиент успел понервничать и уже хотел «переустанавливать всё заново». Это, конечно, плохая идея.
Если проект на WordPress, я советую ещё посмотреть тему и плагины, которые могут вмешиваться в URL. Плагины типа Redirection, Rank Math, Yoast SEO умеют работать с 301, но после смены домена я не люблю полагаться только на них. Лучше держать базовый редирект на сервере, а плагины использовать для точечных исключений. И да, если сайт требует регулярной поддержки, проще подключить поддержку WordPress, чем потом ловить последствия по логам и метрике.
Mapping URL: что куда вести, если структура изменилась
Самый сложный сценарий — это не просто смена домена, а смена домена вместе со структурой. Например, было site-old.ru/category/product-name/, стало site-new.ru/catalog/product-name/. Вот здесь нельзя ограничиться одним глобальным правилом. Нужна карта переноса, где каждая важная страница получает свой адрес на новом домене.
Я обычно делю URL на группы: главная, категории, карточки товаров, статьи, услуги, служебные страницы, фильтры, старые хвосты с параметрами. Для интернет-магазинов на Bitrix и WooCommerce это критично. Один неверно настроенный редирект для каталога может сломать тысячи URL, а это уже не смешно. Если структура и на старом, и на новом домене отличается сильно, без нормальной доработки сайта лучше вообще не начинать.
Пример из реального проекта: у клиента было около 12 тысяч страниц, из них 7 тысяч — товары, 2 тысячи — статьи, остальное фильтры и служебка. Мы сохранили только 1:1 соответствие для товаров и статей, а фильтры отправили в категории или на ближайший релевантный раздел. Если бы мы все фильтры редиректили на главную, поисковик бы это проглотил, но пользы не было бы никакой.
Для больших проектов я часто делаю правила через map в Nginx или отдельную таблицу соответствий в приложении. В Laravel, например, можно хранить соответствия в базе и отдавать редирект через middleware, но я это использую только когда проект очень динамичный. В остальных случаях серверные правила проще и надёжнее.
И ещё важный момент. Если старый домен имел поддомены, например blog.old-domain.ru или shop.old-domain.ru, не надо тупо всё вести на главную нового домена. Поддомены надо маппить отдельно. Важно сохранить смысл и минимизировать количество промежуточных шагов.
Как проверить, что редиректы работают правильно
Проверка — это не «открыл в браузере и вроде перешло». Мне такое регулярно показывают клиенты, а потом оказывается, что браузер просто закэшировал старый ответ. Проверять надо через curl, Screaming Frog, логи сервера, Search Console, Яндекс.Вебмастер и хотя бы несколько ручных сценариев.
Я обычно проверяю три вещи: код ответа, конечный URL и отсутствие цепочки. Команда для быстрой проверки простая:
curl -I https://old-domain.ru/catalog/item-123/
curl -IL https://old-domain.ru/catalog/item-123/Первая команда покажет заголовки первого ответа. Вторая пройдёт по всей цепочке редиректов. Если вы видите что-то вроде 301 → 301 → 200, это уже повод править правила. Цепочка из двух редиректов иногда допустима, но в норме после смены домена лучше уложиться в один шаг.
Если сайт уже в проде, я всегда смотрю логи. На Nginx это помогает понять, какие старые URL ещё приходят от ботов и пользователей. На больших проектах полезны даже простые grep-запросы по access.log. И да, настройка логов и их анализ — это не скучная формальность. Я отдельно писал об этом в статье Настройка логов сайта: мониторинг и анализ ошибок в 2026.
На практике я ещё обязательно смотрю 404 после запуска. Если редиректы настроены криво, битые URL всплывут быстро. Здесь очень полезны материалы про 404-мониторинг и уведомления о битых ссылках в 2026 и 404-отчёт и мониторинг сломанных URL. Когда переезд сделан правильно, количество 404 после индексации новых адресов минимально и быстро падает.
SEO-последствия смены домена и как их не загнать в минус
SEO после смены домена почти никогда не стабилизируется мгновенно. Даже если вы сделали всё красиво, поисковикам нужно время, чтобы переобойти старые URL, обновить сигналы и перекинуть вес. Я видел проекты, где первые ощутимые улучшения начинались через 3–6 недель, а полная стабилизация занимала 2–4 месяца. На крупных сайтах — и дольше.
Чтобы не просесть сильнее, я рекомендую одновременно с редиректами обновить sitemap, canonical, hreflang, внутренние ссылки, Open Graph, robots.txt и данные в аналитике. Если домен сменился, а внутренняя перелинковка осталась старой, бот всё равно будет тратить ресурсы на лишние переходы. И это уже ненужная нагрузка.
Проверьте, чтобы новый домен был добавлен в Search Console и Яндекс.Вебмастер. Старый домен тоже оставляйте под контролем хотя бы несколько месяцев. На старом домене полезно сохранить редиректы минимум 12 месяцев, а лучше дольше, если есть входящий ссылочный профиль и старые внешние публикации. Забудьте про «месяц и удалили». Это не тот случай.
Если переезд затрагивает многоуровневую структуру, дополнительно смотрите статьи про XML sitemap и аудит robots.txt и XML Sitemap. Очень часто новая зона домена индексируется плохо именно потому, что robots.txt остался старый или в sitemap попали адреса старого домена. Это банально, но такие ошибки я видел десятки раз.
И ещё: если вместе со сменой домена вы меняете CMS или делаете крупный редизайн, обязательно сверьте это с материалом Редизайн сайта: когда нужен и как не потерять позиции. Смена домена сама по себе уже стресс для SEO. А если добавить ещё и новый шаблон, новые URL, новые метатеги и новый хостинг — шансы на проблемы растут в геометрической прогрессии.
Что сделать после запуска, чтобы не потерять трафик
После включения редиректов работа не заканчивается. Наоборот, начинается самая полезная часть — наблюдение. Я обычно первые 7–14 дней каждый день смотрю логи, Search Console, Яндекс.Вебмастер, отчёты 404 и позицию по основным запросам. Если что-то идёт не так, лучше поймать это в первые сутки, чем через месяц.
Проверьте, что новые страницы реально индексируются, а старые постепенно выбывают. Убедитесь, что внешние ссылки по возможности обновлены. Если у вас есть партнёрки, каталоги, PR-материалы или реклама с прямыми URL, их тоже лучше заменить. Редирект — это страховка, но не повод жить на старых адресах вечно.
На одном проекте в нише услуг мы после переезда забыли обновить несколько лендингов в рекламных кабинетах. Редирект работал, но часть трафика уходила через дополнительный переход, и конверсия просела примерно на 9%. Проблема оказалась не в SEO, а в UX и скорости. Вот почему я всегда говорю: 301 после смены домена — это не только про поисковики, но и про поведение пользователя.
Если нужно, после запуска я бы ещё сделал технический аудит, чтобы проверить, не осталось ли старых абсолютных ссылок внутри шаблонов, писем, выгрузок и PDF-файлов. Для этого иногда хватает обычного поиска по коду и базе. Но на сложных сайтах, особенно на Bitrix, часто приходится править несколько уровней: шаблон, компоненты, инфоблоки, SEO-шаблоны и почтовые события.
И да, если времени мало и домен уже «горит», можно подключать специалиста на настройку силами профи. На webfull.ru я бы в такой ситуации смотрел не только редиректы, но и общую техническую картину, потому что переезд — это обычно не одна проблема, а целый набор мелких косяков.
Типичные ошибки при настройке 301 и как их избежать
Самая типичная ошибка — отправлять весь старый сайт на главную страницу нового домена. Вторая — забывать про www и без www. Третья — делать редиректы в CMS, когда серверный уровень уже обрабатывает часть маршрутов. Четвёртая — не проверять HTTPS, из-за чего старый HTTP и старый HTTPS ведут себя по-разному.
Ещё одна классика — редиректить уже редиректнутые URL. В результате появляются цепочки и петли. Я видел даже редкий случай, когда старый домен редиректил на новый, а новый через плагин редиректил назад на старый из-за старых правил в базе. Это уже почти комедия, но для владельца сайта было не до смеха.
Чтобы не попасть в такую историю, я всегда держу под рукой чек-лист:
- проверить все версии домена: http, https, www, без www;
- сделать карту соответствий старых и новых URL;
- исключить цепочки редиректов;
- обновить canonical, sitemap и внутренние ссылки;
- проверить robots.txt и ответ сервера;
- сохранить редиректы минимум на 12 месяцев;
- следить за 404, логами и индексацией после запуска.
Если вам нужен именно аккуратный переезд без потери SEO, я бы не экономил на проверке и тестировании. Иногда выгоднее один раз сделать нормальную доработку сайта, чем потом месяцами чинить просадку и разбираться, почему трафик не вернулся. И да, если вы не уверены в схеме, можно сначала оценить объём работ через калькулятор стоимости сайта — это хотя бы даст понимание масштаба задач.
Если говорить совсем по-простому: 301 после смены домена в 2026 году — это не «поставить одну строчку и забыть». Это проект с планом, тестированием, мониторингом и нормальной технической дисциплиной. И если сделать всё аккуратно, сайт обычно переживает переезд без катастрофы. А вот если действовать на авось, потом придётся уже не настраивать редиректы, а спасать позиции, трафик и репутацию.
Нужна помощь с 301 редиректами после смены домена?
Поможем настроить редиректы без потери трафика, позиций и ошибок при переезде на новый домен.