Миграция домена без потери SEO: план 301 редиректов, canonical, новая карта сайта, поиск дублей и проверка индексации, чтобы позиции не просели.
Смена домена для поисковика почти как переезд магазина на другую улицу. Контент может быть тем же, но адреса меняются, и системе нужно время, чтобы снова связать старые сигналы (ссылки, поведение, историю) с новым местом. Поэтому переезд без потери SEO - это не одна настройка редиректов, а снижение рисков на каждом шаге.
Чаще всего ломается базовая техника: часть URL начинает отдавать 404, редиректы ведут не туда, появляются цепочки (старый URL -> промежуточный -> новый), теряются UTM и другие параметры, меняется структура внутренних ссылок. Иногда «съезжают» мета-теги или шаблоны, и вместе с ними падает релевантность. Отдельная проблема - когда и старый, и новый домен доступны без понятного сигнала, где оригинал. Тогда поисковик может считать это дублями.
Даже если «все сделали правильно», трафик часто проседает на 2-6 недель. Причина простая: переобход и перенос сигналов занимают время. Часть запросов временно теряет позиции, пока поисковик проверяет, что новый домен стабилен, а страницы совпадают по смыслу. Чем больше сайт и чем больше URL, тем заметнее колебания.
Самые уязвимые страницы - те, которые дают основную долю входов и имеют много вариантов адресов. Обычно это карточки товаров и услуг, статьи, страницы категорий, а также фильтры и сортировки, где легко наделать параметрических дублей.
До и после миграции фиксируйте и сравнивайте метрики:
Эти показатели быстро покажут, проблема в индексации, в редиректах или в дублях. И помогут исправить просадку до того, как она станет долгой.
Переезд домена начинается не с редиректов, а с инвентаризации. Задача простая: понять, что именно переезжает и какие адреса должны быть доступны поисковику в новом виде.
Сначала разберите сайт на типы страниц и шаблоны: главная, разделы, карточки, статьи, теги, поиск, страницы фильтров, служебные (404, политика), а также любые посадочные страницы из рекламы. Такой разбор помогает не забыть «маленькие» страницы, которые стабильно приносят трафик.
Дальше выгрузите список текущих URL. Нужны не только «красивые» адреса из меню, но и хвосты: пагинация, UTM и другие параметры, варианты со слэшем и без, http/https, www/без www. Если на сайте есть фильтры и сортировки, заранее решите, какие параметры должны индексироваться, а какие должны схлопнуться в один канонический адрес.
Чтобы после переезда было с чем сравнивать, зафиксируйте базовые точки отсчета:
И последнее - выберите дату и одно понятное окно работ. Переезд, растянутый на недели с ежедневными правками, почти всегда рождает путаницу: часть редиректов уже стоит, часть еще нет, а поисковик видит смесь старого и нового. Лучше один аккуратный «день Х», а затем несколько дней спокойной проверки и точечных исправлений.
Карта соответствий URL - это таблица, где у каждого старого адреса есть один конкретный новый адрес. Без нее переезд превращается в угадайку: часть страниц уйдет в 404, часть начнет редиректиться на главную, а поисковику придется дольше разбираться, что вы хотели сделать.
Главное правило простое: один старый URL должен вести на максимально близкую по смыслу новую страницу. Не на «похожую», а на ту, которая отвечает на тот же запрос и дает пользователю то же действие.
Редирект на раздел (категорию) допустим, когда отдельной страницы больше нет, и раздел реально помогает человеку продолжить путь. Но если у страницы был конкретный интент (инструкция, тариф, описание услуги), переводить всех на общую категорию или на главную почти всегда плохая идея.
Проверьте карту по типовым ситуациям:
Отдельно разберите URL с параметрами и пагинацией. Если параметры создавали дубли (сортировка, фильтры, метки), чаще всего их не нужно редиректить все подряд. Сведите их к «чистым» основным страницам и заранее решите, какие варианты должны индексироваться, а какие нет. Для пагинации важно, чтобы каждая страница серии вела на соответствующую страницу серии, а не на первую.
Для переезда на новый домен важен именно 301 редирект. Он сообщает поисковику, что страница переехала навсегда, и помогает передать вес и накопленные сигналы. Редирект должен срабатывать на старом домене, на уровне сервера, до загрузки страницы. Если сначала открывается контент, а потом происходит переадресация скриптом, эффект для SEO хуже.
Выберите один канонический вариант адресов и приведите к нему все входы. Решите заранее: HTTPS или HTTP (почти всегда HTTPS), www или без www, нужен ли слэш в конце. Затем настройте редиректы так, чтобы любой альтернативный вариант сразу приводил к финальному адресу на новом домене.
Самая частая причина просадок при миграции - цепочки и петли. Цепочка выглядит так: старый URL -> промежуточный URL -> новый URL. Поисковики проходят такие пути хуже, а часть веса теряется. Петля еще опаснее: редирект возвращает пользователя на исходный адрес, и страница становится недоступной для обхода.
Проверьте настройку быстрым прогоном важных страниц:
Не забывайте про медиа и служебные URL. Если изображения и файлы меняют адреса, настройте 301 и для них, иначе страницы могут потерять видимость из-за битых ресурсов. Для служебных страниц (например, поиск по сайту) редиректы нужны не всегда, но важные публичные разделы с входящим трафиком лучше перенести аккуратно и проверить вручную.
Canonical нужен там, где один и тот же контент доступен по разным URL. При смене домена это особенно важно: даже если 301 редиректы настроены, поисковик какое-то время может видеть старые и новые адреса одновременно и выбрать не тот вариант основным. Поэтому canonical работает как явная подсказка, какой URL считать оригиналом.
После переезда canonical на каждой индексируемой странице должен указывать на новый домен и на «чистый» канонический адрес без лишних параметров.
<link rel="canonical" href="https://newsite.ru/katalog/telefon" />
Самое простое правило: страница на новом домене должна канонизировать сама себя (self-canonical), но именно на новом домене. Старый домен после переезда не должен отдавать canonical на себя. Если старый сайт еще доступен на время миграции, он либо редиректит, либо (в редких случаях) ставит canonical на новую версию, но не наоборот.
Фильтры, сортировки, UTM-метки, пагинация часто плодят дубли: смысл один, адресов много. В таких случаях canonical должен вести на основную версию страницы без параметров. Если у вас есть важные страницы фильтров, которые должны ранжироваться, не канонизируйте их «в никуда». Заранее определите, какие комбинации фильтров индексируются, а какие нет.
Проверка простая: откройте несколько страниц после миграции и убедитесь, что canonical на каждой указывает на правильный URL на новом домене и совпадает с тем, что вы хотите видеть в поиске.
После смены домена поисковик быстрее понимает структуру сайта не только по редиректам, но и по двум простым сигналам: актуальной карте сайта и понятному robots.txt. Если они устарели, вы замедляете переиндексацию и повышаете риск дублей.
Сгенерируйте новую sitemap для нового домена и включайте туда только те страницы, которые должны индексироваться и которые вы считаете каноническими. Если у страницы есть варианты (параметры, сортировки, версии со слешем и без), в карту должна попасть только одна финальная версия.
Проверьте карту руками: в ней не должно быть старого домена, тестовых поддоменов, адресов со staging, а также URL с метками из рекламы. Одна лишняя группа таких адресов может создать впечатление, что на новом домене появились сотни дублей.
Если сайт большой, удобнее разделить карту по типам страниц: отдельно категории, карточки, статьи, служебные страницы. Так проще заметить перекос (например, пропали все карточки или внезапно появилась тысяча страниц фильтров).
robots.txt должен отражать новую реальность. Он не переносится «сам» правильно: часто там остаются старые пути, запреты для временных разделов или забытая блокировка, которая была нужна только на время.
Проверьте в robots.txt основные вещи:
Пример из практики: после переезда интернет-магазина фильтры по параметрам иногда начинают индексироваться просто потому, что в robots.txt забыли закрыть URL с параметрами, а в sitemap они случайно попали вместе с основными страницами. Итог: часть веса уходит на дубли, а нужные страницы растут медленнее.
Сделайте финальную проверку: sitemap содержит только нужные канонические страницы на новом домене, а robots.txt не мешает им индексироваться и при этом отсеивает «мусор».
При переезде на новый домен важно перенести не только URL, но и смысл каждой страницы. Поисковик оценивает страницу по набору сигналов: заголовки, текст, внутренние ссылки, блоки. Если после переезда страница стала короче, поменяла структуру или потеряла навигацию, позиции могут просесть даже при идеальных 301.
Сначала сравните шаблоны старого и нового сайта. Проверьте, что title и description на месте, H1 не пропал и не дублируется, а подзаголовки H2-H3 сохранили логику. Если вы использовали микроразметку (например, организация, хлебные крошки, FAQ), убедитесь, что она не сломалась при смене шаблона или CMS.
Дальше проверьте, что контент не «усох». Частая ситуация: на старом домене были блоки с преимуществами, таблица, отзывы, ответы на вопросы, а на новом остался только короткий текст. Для поисковика это уже другая страница. Ключевые блоки лучше переносить без упрощений, а обновления делать позже, после стабилизации индексации.
Внутренняя перелинковка должна остаться живой. Меню, хлебные крошки, футер, сквозные блоки и ссылки из текста должны вести на новые адреса, без переходов на старый домен и без лишних редиректов.
Проверьте также медиа: изображения, PDF и другие файлы. Ошибки в путях и недоступные файлы ухудшают качество страницы и скорость.
Короткий контрольный список перед запуском:
Дубли страниц при переезде часто маскируют главную ошибку: поисковик видит несколько «одинаковых» вариантов и не понимает, какой показывать. В итоге сигналы ранжирования распыляются, а новые URL индексируются медленно или закрепляются не там.
Самые частые дубли появляются из-за мелочей в адресах. Важно, чтобы после миграции у каждой страницы остался один канонический вариант URL, а все остальные строго приводили к нему.
Быстрые кандидаты на дубли:
/page и /page//Catalog и /catalog?utm=..., ?ref=..., ?sort=price (особенно у каталогов и фильтров)www и безЕсли при этом 301 редиректы настроены не до конца, дубли быстро превращаются в хаос: часть вариантов отвечает 200, часть редиректит на разные места, а часть уходит в цепочки.
Даже при хороших редиректах возможны дубли по содержанию: одинаковые заголовки, слишком похожие страницы услуг, повторяющиеся мета-описания на десятках URL. На миграции это опаснее обычного, потому что поисковик одновременно видит старый домен, новый домен и, возможно, «промежуточные» копии.
Отдельно проверьте технические дубли: тестовые поддомены, временные копии, staging, зеркала на другом хосте. Частая ситуация: команда оставляет открытым тестовый домен с тем же сайтом, и он начинает индексироваться.
Не нужно начинать с тысячи страниц. Возьмите выборку: главная, 10-20 самых посещаемых страниц, 10 карточек или статей, 5 страниц из категорий с фильтрами. Для каждой проверьте вручную: один ли URL открывается с кодом 200, все ли альтернативы приводят к нему, и не появляется ли «второй вариант» из-за параметров или слэшей.
Пример: после переезда страница «Тарифы» открывается как /pricing и /pricing/ с кодом 200. Это уже два дубля, даже если текст один и тот же. Оставьте один вариант, а второй отправьте 301 на основной и закрепите canonical на выбранный адрес.
В день миграции важна дисциплина: вы не «переносите сайт», вы переключаете поиск и пользователей на новый домен. Заранее назначьте короткое окно работ и подготовьте план отката (бэкап, снимок, возможность быстро вернуть старую конфигурацию).
Сначала убедитесь, что тестовые окружения не индексируются и не доступны случайно. Частая проблема: открытый staging на новом домене создает дубли и путает поисковик. Если у вас есть функция снимков и отката на хостинге или платформе, сделайте снимок перед переключением, чтобы вернуть все за минуты.
Дальше действуйте по понятному чеклисту и фиксируйте результаты (время, что проверяли, что нашли):
После переключения отправьте новую карту сайта в панели вебмастеров и дайте поиску время на переобход. В первые 24-72 часа обычно всплывают «мелочи», которые сильнее всего бьют по SEO: один неправильный шаблон canonical, забытая внутренняя ссылка или редирект на промежуточный URL.
Самая болезненная часть переезда - не сами редиректы, а мелкие несостыковки, из-за которых поисковик видит хаос: дубли, разные версии страниц и неясно, где «главная» версия. Из-за этого восстановление может растянуться на месяцы.
Частый сценарий: все старые URL ведут на главную нового домена. Кажется, что так «хоть что-то откроется», но для поиска это потеря релевантности. Страница про услугу, которая стала вести на главную, перестает подтверждать свой запрос, и позиции падают.
Другая ловушка - забыть обновить canonical (и, если используется, hreflang). Если canonical остается на старом домене, вы сами говорите поисковику: «оригинал там». В итоге новый домен может долго не закрепляться как основной.
Еще один типичный сбой - смешанные зеркала: часть страниц открывается по HTTP, часть по HTTPS, плюс добавляются варианты с www и без. Это быстро размножает дубли и размывает сигналы.
К этому часто добавляется «невидимая» проблема: внутренние ссылки внутри сайта продолжают вести на старый домен. Редиректы сработают, но вы создадите лишние переходы и нагрузите обход.
Наконец, опасно делать два больших изменения одновременно: переезд и переработку структуры или контента. Когда меняется и домен, и URL, и тексты, поиску сложнее понять, что именно произошло.
Короткая проверка перед запуском:
Простой пример: если у вас был лендинг /pricing и вы переносите его на новый домен, но одновременно переименовали в /plans и переписали блоки, вы усложняете диагностику. Лучше сначала закрепить переезд, а уже потом улучшать страницы.
Представьте: блог на 500 страниц (статьи, теги, страницы «О нас» и «Контакты») переезжает с old.ru на new.ru. Цель простая: все важные страницы должны открываться по новым адресам и не плодить дубли.
Карта соответствий обычно выглядит так: слева старый адрес, справа новый, рядом тип (301) и примечание. Для начала достаточно проверить 10 ключевых URL вручную: главную, 3 самые посещаемые статьи, 2 страницы тегов (или категорий), «О нас», «Контакты», поиск (если он индексировался), и одну страницу с параметрами (если такие были).
Пример строки:
| Было (old.ru) | Стало (new.ru) | Редирект | Примечание |
|---|---|---|---|
| /blog/seo-migration | /blog/seo-migration | 301 | Без изменений |
| /category/marketing | /topics/marketing | 301 | Переименовали раздел |
| /?utm_source=... | / | 301 | Убираем параметры |
Мини-чеклист на 15 минут (чтобы поймать то, что чаще всего ломает переезд):
После переезда важны не только настройки, но и контроль по дням:
Чтобы не утонуть в мелких задачах, удобно вести план миграции как список работ с ответственными и проверками. Если вы делаете технические изменения через платформы с режимом планирования и снапшотами, это заметно снижает риск. Например, в TakProsto (takprosto.ai) можно заранее разложить шаги по плану, а перед переключением домена сохранить снимок, чтобы при необходимости быстро откатиться.
Обычно просадка длится от 2 до 6 недель, даже если все настроено корректно. Поиску нужно время, чтобы переобойти новые URL и перенести сигналы со старых адресов. На больших сайтах колебания заметнее, потому что страниц и вариантов URL больше.
301 сообщает поисковику, что переезд постоянный, и помогает перенести вес и историю страницы на новый адрес. 302 воспринимается как временное решение, поэтому сигналы переносятся хуже и дольше. Для миграции домена базовый выбор — 301 на уровне сервера, чтобы редирект срабатывал сразу.
Редирект на главную почти всегда убивает релевантность: страница отвечала на конкретный запрос, а пользователь попадает на общий экран без нужного контента. Поисковик видит подмену смысла и хуже переносит позиции. Делайте редирект на максимально близкую по интенту страницу, а если аналога нет — честнее отдать 404/410 и убрать внутренние ссылки.
Начните с инвентаризации: выгрузите список всех текущих URL и разберите сайт по типам страниц и шаблонам. Зафиксируйте, какие страницы дают основной трафик и конверсии, какие запросы важны и какие ошибки сканирования уже есть. Это станет базой для карты соответствий и позволит быстро понять, что именно сломалось после переключения.
Карта соответствий — это таблица, где у каждого старого URL есть один конкретный новый URL. Она нужна, чтобы не потерять страницы в 404 и не делать хаотичные редиректы «куда-нибудь». По ней удобно проверять переезд: открываете старый адрес, видите, куда он обязан вести, и быстро находите отклонения.
Canonical — это явная подсказка поисковику, какой URL считать основным, когда контент доступен по нескольким адресам. После переезда canonical на индексируемых страницах должен указывать на новый домен и на «чистую» версию без лишних параметров. Ошибка, когда canonical остается на старом домене, часто задерживает закрепление нового сайта в выдаче.
Цепочка — это когда старый URL ведет на промежуточный адрес, а уже потом на конечный, из-за чего обход и перенос сигналов ухудшаются. На практике это выглядит как несколько последовательных 301 вместо одного. Проверьте ключевые страницы: со старого домена должен быть один шаг на финальный URL, а на новом домене — сразу ответ 200.
Sitemap помогает быстрее подсказать поиску структуру нового сайта, но в ней должны быть только канонические URL нового домена. robots.txt должен не мешать обходу важных разделов и при этом отсекать технический «мусор» вроде поиска, корзины и лишних параметров, если они не должны индексироваться. Частая ошибка — случайно добавить в sitemap параметрические URL или оставить старые правила robots.txt после переезда.
Параметры и сортировки часто создают дубли, поэтому сначала решите, какие варианты должны индексироваться, а какие нет. Обычно UTM и технические параметры нужно схлопывать в один канонический URL без параметров, чтобы не размножать одинаковые страницы. После миграции проверьте вручную несколько страниц каталога: открывается ли только один вариант с кодом 200 и ведет ли canonical на правильную «чистую» версию.
В день миграции важно иметь короткое окно работ, готовый план отката и заранее подготовленные редиректы по карте соответствий. Сразу после переключения проверьте руками ключевые страницы, коды ответов, canonical и внутренние ссылки, чтобы они не указывали на старый домен. Если вы работаете на платформе, где есть режим планирования и снимки с откатом, например TakProsto, это помогает безопаснее развернуть изменения и быстро вернуть конфигурацию при ошибке.