URL
Старые адреса должны либо сохраниться, либо однозначно вести на новые эквиваленты.
Практическое SEO · миграция
Как перенести сайт без потери позиций и трафика
Безрискового переезда не существует, но большую часть проблем можно предотвратить: заранее зафиксировать старую структуру, подготовить соответствия URL, проверить новую среду и после переключения контролировать редиректы, canonical, Sitemap и обход поисковых роботов.
Коротко
Переезд — это смена сигналов, а не просто копирование файлов
Для поисковой системы важны не только тексты и дизайн. Она знает сайт как набор конкретных URL, HTTP-ответов, внутренних ссылок, canonical, Sitemap и внешних ссылок. Если при переносе эти связи меняются хаотично, часть накопленной поисковой истории может перестать соответствовать новым адресам.
Доступность
Новая версия должна стабильно отвечать роботу и пользователю после переключения.
Сигналы
Canonical, внутренние ссылки и Sitemap должны согласованно указывать на новую структуру.
Контроль
После запуска нужно проверять не только главную, а все типы страниц и реальные обходы робота.
Яндекс прямо предупреждает: при смене главного адреса сохранение количества страниц, позиций и посещаемости не гарантируется. Поэтому задача правильного переезда — не обещать отсутствие просадки, а минимизировать технические причины потерь и быстро обнаруживать отклонения.
Шаг 1
Что может потеряться при неправильном переносе
Самые опасные изменения — те, которые ломают соответствие между старой и новой версией сайта. Это может произойти даже при полном визуальном совпадении страниц.
Старые URL
Если они начинают возвращать 404 или ведут все на главную, поисковику сложнее сопоставить старые документы с новыми.
Индексируемые страницы
Новая CMS может случайно закрыть разделы, поменять шаблоны canonical или сгенерировать другие адреса.
Внутренняя структура
Меню, хлебные крошки и ссылки могут вести через редиректы или на устаревшие версии страниц.
Стабильность
Новый сервер может быть медленнее старого, выдавать 5xx или не справляться с реальной нагрузкой.
Риск особенно высокий, если одновременно меняются домен, CMS, структура URL, дизайн и сервер. Чем больше переменных меняется за один запуск, тем сложнее понять причину отклонения после релиза.
Шаг 2
До переноса фиксируем текущее состояние
Перед изменениями нужен снимок старой версии. Минимум — список индексируемых и важных URL, HTTP-коды, Title, canonical, внутренние ссылки, Sitemap и основные посадочные страницы. Для крупных проектов полезно сохранить и данные о входящем поисковом трафике по URL.
Что обязательно сохранить
Главную, категории, карточки, услуги, статьи, региональные страницы, страницы с внешними ссылками, URL с поисковым трафиком и любые адреса, которые нельзя потерять бизнесу. Отдельно фиксируем robots.txt, Sitemap, правила редиректов и текущую структуру домена.
Шаг 3
Строим карту соответствия старых и новых URL
Если структура меняется, заранее составляем таблицу «старый адрес → новый адрес». Она становится основой для редиректов, контроля запуска и поиска пропущенных страниц.
| Старый URL | Новый URL | Тип страницы | Действие | Контроль |
|---|---|---|---|---|
| /services/seo/ | /technical-seo/ | Услуга | Прямой постоянный редирект | Финальный ответ 200, релевантное содержание |
| /blog/audit-site/ | /technical-seo-audit/ | Статья | Прямой постоянный редирект | Новая статья соответствует старому интенту |
| /catalog/item-old/ | /catalog/item-new/ | Карточка | Редирект на аналогичный товар | Не вести массово на категорию без причины |
| /old-section/ | Нет аналога | Удалённый раздел | 404/410 либо релевантный заменяющий документ | Не создавать ложное соответствие ради редиректа |
Яндекс рекомендует перенаправлять внутренние страницы старого сайта на аналогичные страницы нового. Массовый редирект всех старых URL на главную неудобен пользователям и ухудшает сопоставление документов. Инструкция Яндекса по переезду сайта.
Шаг 4
Собираем новую среду до переключения пользователей
Новая версия должна быть проверена до того, как DNS или домен начнут вести на неё основной трафик. Тестируем не только внешний вид, но и серверную конфигурацию, базу данных, формы, авторизацию, фоновые задачи, почту, API, HTTPS и реальные сценарии пользователей.
Если используется тестовый домен, важно не перенести его технические настройки в production: canonical, ссылки, robots.txt, Sitemap и абсолютные URL часто остаются от staging-среды и становятся причиной поисковых проблем сразу после запуска.
HTTP и HTTPS
Проверяем сертификат, перенаправления, единственную рабочую версию протокола и отсутствие смешанного контента.
Ресурсы
CSS, JavaScript, изображения и API должны работать с боевого адреса без старых абсолютных путей.
Сценарии
Формы, корзина, поиск, авторизация и фоновые процессы проверяются до изменения DNS.
Возврат
Перед переключением должна существовать рабочая точка восстановления, а не надежда «починить на лету».
Шаг 5
Настраиваем редиректы до запуска
Для постоянного изменения адреса используем постоянный серверный редирект. В реальном проекте важнее не сам код в конфигурации, а точность соответствия: старая страница должна вести на максимально близкий новый документ, а не на общий раздел только потому, что так проще.
Что проверяем
Нет ли циклов и длинных цепочек, сохраняются ли query-параметры там, где они нужны, не потерялись ли важные URL, нет ли редиректа через промежуточный домен и не ведёт ли новая страница дальше ещё на один адрес.
При смене структуры Яндекс рекомендует использовать 301 со старых адресов на новые; конечная цель редиректа должна быть индексируемой и отвечать корректно. Рекомендации по смене структуры сайта.
Шаг 6
Синхронизируем canonical, Sitemap и внутренние ссылки
После переноса все основные сигналы должны указывать в одну сторону. Если редирект ведёт на новый URL, а canonical остаётся на старом или тестовом домене, сайт сам создаёт противоречие.
Canonical
Новые страницы должны указывать на правильную основную версию, без ссылок на staging или старый домен.
Sitemap
В карте оставляем актуальные канонические URL с финальным 200, а не старые адреса и редиректы.
Внутренние ссылки
Меню, хлебные крошки и контент должны вести сразу на конечные URL, не через старые адреса.
robots.txt
Проверяем, что production-версия открыта для нужного обхода и не унаследовала тестовые запреты.
Яндекс использует Sitemap для получения актуальной структуры сайта, а canonical — как рекомендацию по основной версии документа. Эти сигналы должны согласовываться с реальными редиректами и внутренней архитектурой. Sitemap в Яндекс Вебмастере.
Шаг 7
Переключаем сайт только после контрольной проверки
Перед переключением полезно пройти короткий pre-launch контроль: открыть основные типы страниц, проверить редиректы, формы, сертификат, DNS, robots.txt, canonical, Sitemap и несколько URL через HTTP-инструмент. После этого меняем DNS или главный адрес.
Если меняется домен, добавляем старый и новый сайты в Яндекс Вебмастер, подтверждаем права и используем инструмент «Переезд сайта». Яндекс рекомендует, чтобы оба адреса были доступны роботу, содержимое соответствовало друг другу, а старые страницы перенаправлялись на аналогичные новые.
Не закрывайте старый домен сразу после запуска. Пока поисковая система и пользователи продолжают обращаться к старым URL, они должны стабильно перенаправлять на новую версию.
Шаг 8
После запуска контролируем не один день, а переходный период
Успешный первый час ещё не означает успешный переезд. Поисковые роботы будут постепенно переобходить старые и новые адреса, поэтому несколько дней и недель нужно наблюдать за HTTP-ошибками, количеством индексируемых страниц, редиректами и поисковым трафиком по типам URL.
Что смотреть после переключения
404 и 5xx в логах, старые URL без редиректа, неожиданно закрытые страницы, canonical на старый домен, появление новых дублей, состояние Sitemap, динамику обхода и реальные страницы входа из поиска.
При смене домена Яндекс указывает, что смена главного адреса может занимать несколько недель, а изменения числа страниц, позиций и посещаемости возможны в течение обновлений поисковой базы. Поэтому оцениваем не один общий график, а конкретные группы страниц и причины отклонений.
Практический пример
Как выглядит безопасная карта переноса
Допустим, компания меняет CMS и одновременно упрощает структуру. Часть URL сохраняется, часть получает новые адреса, несколько старых страниц больше не нужны. Вместо универсального правила для всех URL делаем карту решений.
| Ситуация | Старый URL | Новая версия | Решение | После запуска |
|---|---|---|---|---|
| Страница не меняется | /support/ | /support/ | Сохраняем URL без редиректа | Проверяем 200, canonical и контент |
| Услуга переименована | /seo-audit/ | /technical-seo-audit/ | Прямой 301 на эквивалент | Старая ссылка отвечает редиректом, новая — 200 |
| Две слабые страницы объединены | /seo-check/ и /site-audit/ | /technical-seo-audit/ | Обе ведут на единый сильный материал | Проверяем отсутствие конкурирующих дублей |
| Раздел удалён без замены | /old-service/ | Нет | 404/410, если релевантной замены нет | Убираем из меню, Sitemap и внутренних ссылок |
| Домен меняется | old.example/page/ | new.example/page/ | Редирект на соответствующую страницу нового домена | Контроль Вебмастера, обхода и старого домена |
До запускакарта URL и проверенная новая среда
Переключениередиректы, DNS, production-настройки
После запускалоги, обход, индексирование и трафик
Ключевой принцип: каждый старый важный URL должен иметь объяснимую судьбу. Он либо сохраняется, либо переезжает на конкретный эквивалент, либо корректно удаляется. «Все на главную» — не карта миграции.
Частые ошибки
Что чаще всего ломает SEO при переносе
Менять всё одновременно
Новый домен, CMS, URL и контент в один запуск усложняют диагностику любой последующей просадки.
Редиректить всё на главную
Старые документы теряют точное соответствие новым, а пользователи попадают не туда, куда ожидали.
Забыть staging-настройки
Noindex, canonical и абсолютные ссылки тестовой среды могут попасть в production.
Удалить старый домен
Старые URL перестают передавать пользователей и поисковых роботов на новые страницы.
Не обновить внутренние ссылки
Сайт продолжает сам ходить через редиректы, хотя конечные адреса уже известны.
Смотреть только главную
Проблема часто затрагивает конкретный шаблон: карточки, категории, статьи или региональные страницы.
Чек-лист
Перенос сайта без потери поисковых сигналов
- Сохранить снимок старой версии: URL, HTTP-коды, Title, canonical, Sitemap и важные страницы входа.
- Определить, что меняется: домен, CMS, сервер, структура URL, дизайн или несколько компонентов сразу.
- Составить карту URL: для каждого важного старого адреса определить новую судьбу.
- Подготовить новую среду: проверить PHP/БД, HTTPS, формы, API, cron, почту и реальные пользовательские сценарии.
- Проверить production-настройки: robots.txt, canonical, абсолютные ссылки и Sitemap не должны оставаться от staging.
- Настроить редиректы: старые страницы ведут на релевантные новые URL без циклов и лишних цепочек.
- Обновить внутренние ссылки: меню, хлебные крошки и контент сразу ведут на конечные адреса.
- Обновить Sitemap: оставить актуальные канонические URL с финальным ответом 200.
- Проверить старый и новый домен: оба доступны там, где это требуется для корректного перехода.
- При смене домена использовать Вебмастер: подтвердить права и отправить заявку через инструмент «Переезд сайта».
- После запуска проверить типы страниц: не только главную, но категории, карточки, услуги и статьи.
- Следить за логами и индексированием: 404, 5xx, обход, canonical и изменение числа страниц.
- Не выключать старую инфраструктуру преждевременно: редиректы должны продолжать работать в переходный период.
Вопросы
Короткие ответы о переносе сайта
Можно ли гарантировать, что позиции вообще не изменятся?
Нет. Поисковая система может временно перераспределять документы и сигналы даже при технически корректном переезде. Реальная задача — сохранить соответствие URL, доступность и поисковые сигналы, чтобы не создавать дополнительную просадку собственными ошибками.
Что лучше: сохранить старые URL или сделать новую красивую структуру?
Если старые адреса логичны и работают, их сохранение снижает объём изменений. Менять структуру стоит только когда есть реальная архитектурная причина, а не ради косметики URL.
Сколько держать редиректы со старого домена?
Не стоит отключать их сразу после смены главного адреса. Старые ссылки могут продолжать использовать пользователи, внешние сайты и поисковые роботы. Для важных миграций редиректы разумно сохранять длительно.
Нужно ли менять Sitemap сразу после запуска?
Да. Sitemap должен отражать актуальные канонические страницы новой версии. Старые URL с редиректами не должны оставаться основной картой текущей структуры.
Что делать, если после переноса страницы выпали из поиска?
Сначала проверить массовые причины: HTTP-коды, robots.txt, noindex, canonical, редиректы, Sitemap, доступность сервера и внутренние ссылки. Затем сопоставить выпавшие URL со старой картой и посмотреть причину исключения в Яндекс Вебмастере.
Практика NIC-SEO
Сначала карта зависимостей, потом переключение
Мы рассматриваем миграцию как изменение всей системы: URL, сервер, DNS, сертификаты, почта, интеграции и поисковая история должны перейти в согласованное состояние.