Переезд сайта без потери трафика

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

Нулевые колебания обещать нельзя: Google предупреждает, что во время значительных миграций видимость может временно меняться, пока новые URL обходятся и переиндексируются. Задача SEO-подготовки — не «заморозить позиции», а сохранить содержание, связи и сигналы настолько однозначно, насколько это возможно.

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

Что поисковик должен увидеть после переезда

Для каждого важного старого URL должна существовать понятная судьба:

• есть равноценная новая страница → постоянный редирект на неё;
• несколько старых страниц объединены → редирект на действительно соответствующую объединённую;
• контент удалён без замены → честный 404 или 410;
• URL не меняется → код 200, новый контент и самоссылочный canonical.

Самая ценная часть проекта — не правило в .htaccess, а карта соответствий URL. Без неё разработчик вынужден угадывать, а массовое правило легко отправляет товары, статьи и категории не туда.

Шаг 1. Зафиксируйте показатели до переезда

Соберите контрольную точку минимум за несколько дней до запуска:

• органический трафик и конверсии по посадочным;
• клики, показы и запросы из панелей вебмастеров;
• позиции по приоритетному ядру;
• число индексируемых URL по типам;
• страницы с внешними ссылками;
• текущие sitemap, robots.txt и canonical;
• коды ответа и цепочки редиректов;
• скорость и доступность ключевых шаблонов.

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

Шаг 2. Выгрузите все значимые старые URL

Один источник не даст полного списка. Объедините:

• URL из текущего sitemap;
• страницы, найденные краулером;
• посадочные с органическим трафиком;
• URL с показами в Яндекс Вебмастере и Search Console;
• страницы с внешними ссылками;
• адреса из рекламных кампаний, писем и профилей;
• важные файлы, изображения и документы.

Удалите технические параметры и дубли только после того, как поймёте, как они обрабатываются сейчас. Иногда «мусорный» URL получает трафик или внешние ссылки и поэтому тоже нуждается в корректном перенаправлении.

Результат — таблица-инвентаризация:

Рекомендуем инструмент ITSEO

Проверка цепочек редиректов в ITSEO

Мгновенно протестируйте корректность 301-редиректов, отсутствие петель и промежуточных ответов при миграции сайта.

Проверить редиректы

Шаг 3. Постройте соответствие один к одному

Лучшее перенаправление ведёт на страницу с тем же назначением и максимально близким содержанием:

/catalog/kresla/model-a/ → /office-chairs/model-a/

Плохой вариант:

/catalog/kresla/model-a/ → /

Google отдельно рекомендует не перенаправлять множество старых URL на нерелевантную главную: такое поведение может восприниматься как soft 404. Если точной замены нет, выберите ближайшую полезную страницу только при реальном соответствии. Иначе возвращайте 404/410 и удаляйте ссылку из навигации и sitemap.

Автоматическое правило допустимо, когда структура меняется предсказуемо:

/catalog/{slug}/ → /products/{slug}/

Исключения всё равно вынесите в таблицу и протестируйте отдельно.

Шаг 4. Подготовьте постоянные редиректы

Для окончательного переноса используют серверные постоянные редиректы — обычно 301 или 308. Они сообщают, что ресурс получил новый постоянный адрес.

Для Apache правила часто задают в .htaccess. Пример единичного перенаправления:

Redirect 301 /old-page/ https://example.ru/new-page/

У реального проекта могут быть условия по протоколу, хосту, query-параметрам и исключениям. Ошибка в регулярном выражении затронет тысячи URL, поэтому не вставляйте универсальный фрагмент без теста.

Сформировать основу можно в генераторе редиректов .htaccess ITSEO, а затем передать конфигурацию разработчику или администратору сервера.

Шаг 5. Избегайте цепочек и циклов

Плохая цепочка:

http://www.example.ru/page
→ https://www.example.ru/page
→ https://example.ru/page
→ https://example.ru/new-page/

Лучше, чтобы каждый известный старый вариант сразу вёл на финальный URL. Цепочки замедляют переход, усложняют диагностику и повышают вероятность обрыва. Цикл A → B → A вообще делает страницу недоступной.

После настройки загрузите контрольные адреса в проверку редиректов ITSEO. Тестируйте:

• главную;
• категории и карточки;
• статьи;
• URL со слешем и без;
• HTTP, HTTPS, www и без www;
• адреса с параметрами;
• удалённые страницы;
• изображения и документы, если они менялись.

Шаг 6. Согласуйте все сигналы на новом сайте

Редирект не спасёт миграцию, если остальные элементы продолжают указывать старые адреса.

На новом сайте проверьте:

• canonical указывает на новый URL;
• внутренние ссылки ведут сразу на новый адрес;
• hreflang использует новые абсолютные URL и обратные связи;
• Open Graph и структурированные данные обновлены;
• изображения, CSS и JS не загружаются со старого закрытого домена;
• формы и платёжные сценарии работают;
• аналитика установлена и не задваивает события;
• production-страницы не содержат noindex;
• robots.txt не копирует запрет тестового стенда.

Не оставляйте внутренние ссылки через редирект «потому что он всё равно работает». Пользователь и робот должны сразу получать финальный адрес.

Шаг 7. Создайте чистый sitemap нового сайта

В новый sitemap включайте только канонические URL, которые:

• отвечают кодом 200;
• разрешены к индексированию;
• не перенаправляют;
• должны находиться в поиске.

Укажите абсолютные адреса нового домена и честный lastmod, если система умеет обновлять его по реальному изменению страницы.

Проверьте файл в валидаторе robots.txt и sitemap ITSEO, затем отправьте новый sitemap в Google Search Console и Яндекс Вебмастер. Для контроля миграции полезно сохранить отдельный список старых URL: по нему видно, как поисковик переходит от старых адресов к новым.

Шаг 8. Подготовьте панели вебмастеров и внешние системы

При смене домена:

1. заранее подтвердите права на старый и новый сайты;
2. настройте редиректы;
3. отправьте новый sitemap;
4. используйте предусмотренный поисковой системой инструмент переезда;
5. обновите адреса в аналитике, рекламе, картах, каталогах и профилях;
6. попросите владельцев самых ценных внешних ссылок заменить URL.

Инструмент смены адреса не заменяет редиректы. Он является дополнительным сигналом, а не транспортом для пользователей и роботов.

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

Что проверять в первые часы после запуска

Сразу после переключения:

• главная и ключевые шаблоны отвечают 200;
• старые URL перенаправляют на правильные новые;
• нет циклов и массовых 404;
• robots.txt и sitemap доступны;
• canonical, hreflang и noindex корректны;
• аналитика получает визиты и конверсии;
• сервер выдерживает дополнительный обход;
• SSL-сертификат действует для всех нужных хостов.

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

Мониторинг в первые недели

Сделайте отдельный журнал миграции и отслеживайте по датам:

Сравнивайте не только общие суммы. Если трафик упал на 10%, выясните, какие типы страниц дали разницу: товары, категории, статьи, городские поддомены. Один забытый шаблон объясняет проблему лучше общего графика.

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

Чего не стоит совмещать с миграцией

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

• смену домена;
• новую CMS;
• редизайн;
• полное переписывание контента;
• изменение структуры каталога;
• новый трекинг аналитики.

Google рекомендует менять по одному крупному компоненту за раз. Если это невозможно, зафиксируйте каждое изменение и расширьте тестовое покрытие.

План отката

До запуска письменно определите:

• какие симптомы требуют отката;
• кто принимает решение;
• сколько времени допустима недоступность;
• как вернуть DNS, приложение и конфигурацию;
• что произойдёт с новыми заказами и данными;
• какие исправления можно внести без полного возврата.

Падение позиции на одну строку — не причина откатывать миграцию. Массовый 5xx, бесконечный редирект или закрытие сайта от роботов — причина действовать немедленно.

Финальный чек-лист

• Собрана контрольная точка трафика, позиций и индексации.
• Выгружены URL из краулера, аналитики, вебмастеров, sitemap и внешних ссылок.
• Для каждого значимого URL назначено действие.
• Редиректы ведут на релевантные страницы, а не массово на главную.
• Нет цепочек и циклов.
• Canonical, внутренние ссылки, hreflang и разметка используют новые URL.
• Sitemap содержит только индексируемые страницы с кодом 200.
• В панелях подтверждены старый и новый сайты.
• Проверены SSL, robots.txt, аналитика и ключевые пользовательские сценарии.
• Составлены график мониторинга и план отката.

Практически работа начинается с таблицы старый URL → новый URL. После её согласования создайте правила в генераторе .htaccess, прогоните контрольный список через проверку редиректов и только затем переключайте сайт. Именно карта и тесты сохраняют управляемость переезда.

Источники и полезные материалы

• Google: перенос сайта с изменением URL
• Google: редиректы и поиск
• Яндекс: что такое переезд сайта
• Яндекс: файлы Sitemap