Переезд сайта не заканчивается, когда открылась новая главная. Он заканчивается, когда у каждого ценного старого адреса есть обоснованное решение, клиент по-прежнему может заказать товар или отправить заявку, поисковые системы получают согласованные сигналы, а команда видит и объясняет отклонения.
Надёжный принцип: меняйте только необходимое; до запуска назначьте решение каждому важному URL; принимайте новую страницу вместе с её редиректом; определите условия отката, пока откат ещё возможен. Колебания позиций во время повторного обхода ожидаемы. Массовые 404, закрытые от индексации страницы и конфликтующие canonical — нет.
Сначала уточните, что именно переезжает
«Новый сайт» может означать смену хостинга без изменения адресов, замену CMS, редизайн, новый домен или полную перестройку каталога. Риск у этих проектов разный. Google рекомендует по возможности разносить крупные изменения во времени. Если вместе меняются домен, платформа, тексты, навигация и аналитика, причину падения сложно найти и ещё сложнее быстро устранить.
Составьте одностраничный паспорт миграции: бизнес-причина, сайты и языковые версии в периметре, окно запуска, владельцы со стороны бизнеса, разработки, SEO и аналитики, критичные пользовательские сценарии, время заморозки изменений, право остановить релиз и последний безопасный момент для отката. Отдельно перечислите то, что остаётся прежним. Переезд на другой хостинг обычно не требует менять пути страниц.
До переключения DNS сохраните исходные показатели: органические входы и конверсии по страницам, клики и показы Search Console, индексируемые шаблоны, важные внешние ссылки, рекламные посадочные, завершение форм и оформления заказа, скорость, серверные ошибки и полное сканирование. При достаточном объёме разделите данные по устройствам, странам и типам поиска. Это не гарантия ровного графика, а база для диагностики.
Один реестр URL вместо разрозненных файлов
Соберите адреса из XML sitemap, CMS или товарной базы, аналитики, Search Console, серверных логов, backlink-отчётов, рекламных кампаний и документации. Google советует объединять источники: ни один из них не показывает всё. Добавьте изображения, документы, промостраницы, субдомены, параметры и старые URL, которые получают посещения, даже если на них уже нет внутренних ссылок.
| Поле | Решение | Доказательство приёмки |
|---|---|---|
| Старый URL | Сохранить, перенаправить, объединить, 404 или 410 | Записаны текущий статус и источник ценности |
| Новый URL | Один ближайший эквивалент либо отсутствие цели | Финальная страница отдаёт 200 и индексируется |
| Контракт | Интент, контент, метаданные, язык, функция | Назначенный владелец принял результат |
| Редирект | 301 или 308 для постоянного переноса | Один переход до финального canonical URL |
| Бизнес-сценарий | Форма, корзина, оплата, вход, файл | Контрольная операция завершена |
| Исключение | Владелец, приоритет, срок | Нет критичных строк без решения |
Не отправляйте все удалённые страницы на главную. Google предупреждает: массовые нерелевантные редиректы могут считаться soft 404. Перенаправляйте страницу на ближайшую замену, только если она отвечает тому же намерению пользователя. Когда честного эквивалента нет, верните настоящий 404 или 410, удалите адрес из внутренних ссылок и sitemap, а на странице ошибки дайте понятную навигацию.
Приоритизируйте реестр по ценности для бизнеса, а не по количеству URL. Потерянная страница тарифов, адрес обратного вызова платёжной системы, URL из товарного фида или русскоязычная посадочная могут быть важнее тысяч фильтров каталога. Для верхнего уровня задайте жёсткое правило: ни одной нерешённой строки к запуску.
Сохраните контракт страницы
Ответ 200 ещё не доказывает успешный перенос. Для каждой важной страницы сравните пользовательский интент, основной текст, title и description, заголовки, canonical, возможность индексации, структурированные данные, внутренние ссылки, изображения, файлы, языковые альтернативы и целевое действие. Для магазина добавьте SKU или GTIN, варианты, цену, наличие, валюту, доставку, возврат, отзывы, URL в Merchant Center и путь от карточки товара до подтверждения платежа.
Проверяйте HTML, который получает робот, а не только внешний вид в браузере. Основной контент и ссылки должны быть доступны для обхода, структурированные данные — совпадать с видимыми фактами, robots.txt — разрешать рабочие страницы, а временный noindex из тестовой среды не должен попасть в релиз. До запуска тестовую среду защищайте, но финальные правила подготовьте заранее.
Canonical, sitemap, внутренние ссылки, hreflang, фиды и редиректы должны указывать на один предпочтительный адрес. Редирект на один URL при canonical на другой заставляет поисковую систему самостоятельно разрешать конфликт. Внутренние ссылки сразу заменяйте финальными: редирект страхует старые входы, а не служит постоянной навигацией.
Редиректы должны проходить приёмочные тесты
Для постоянного переноса используйте серверные 301 или 308. Старый адрес должен вести сразу на финальный, без цепочек и циклов. Google указывает, что permanent redirects не теряют PageRank, и советует сохранять правила минимум год. Для пользователей, закладок и долговечных внешних ссылок полезные редиректы разумно держать дольше.
Формируйте правила из утверждённого реестра и прогоняйте весь список в среде, близкой к рабочей. Проверяйте статус, конечный адрес, число переходов, параметры запроса, регистр, завершающий слеш, кодирование кириллицы, языковые префиксы, файлы и характерные параметры фильтров. Шаблонное правило безопасно лишь при реальном соответствии старой и новой структуры.
Ошибка должна блокировать релиз, если ценный URL возвращает 404, ведёт на нерелевантную страницу, зацикливается, создаёт лишнюю цепочку или заканчивается на noindex. После переключения заново просканируйте новый сайт и найдите внутренние ссылки, проходящие через redirect. Их следует заменить конечными адресами.
Запуск через контрольные ворота и с готовым откатом
Выбирайте менее рискованное время, но только когда доступны специалисты, способные поправить приложение, CDN, DNS, аналитику и платежи. Ночной релиз без команды не безопасен лишь потому, что посетителей мало. При смене домена или хостинга заранее уменьшите DNS TTL, проверьте сертификаты, сохраните старую среду и запишите точную последовательность отката.
Условия остановки нужны до запуска: не работает оформление заказа или форма; критичные маршруты возвращают ошибки; рабочий сайт остался под noindex; robots блокирует важные разделы; значительная часть редиректов отсутствует; canonical ссылается на тестовую среду или прежний домен; аналитика не собирает события; команда не отличает тесты от реальных действий клиентов. Откат — предусмотренный контроль риска.
При смене домена подтвердите старые и новые ресурсы в Search Console. Текущая инструкция Google требует подать Change of Address для всех релевантных подтверждённых вариантов, включая нужные субдомены и www/non-www. Отправьте новый sitemap. Другие поисковые системы уведомите их средствами; Bing тоже рекомендует permanent redirects и корректное обновление перемещённых либо удалённых адресов.
Оценивайте когорты страниц, а не общий график
В первые сутки следите за ошибками приложения и CDN, неудачными редиректами, доступом роботов, загрузкой sitemap, структурированными данными, формами, платежами и верхним уровнем URL-реестра. На первой неделе сравнивайте старые и новые когорты в Search Console и логах. Ищите старые адреса с показами без рабочей цели, новые страницы, исключённые из-за canonical или noindex, неожиданные soft 404 и важные шаблоны, которые робот не посещает.
Повторите разбор через 30, 60 и 90 дней. Разделяйте брендовые и небрендовые запросы, типы страниц, языки, устройства и рынки. Посещения старых URL должны снижаться, соответствующих новых — расти. Google отмечает, что обработка большей части малого или среднего сайта может занять несколько недель, крупного — дольше. Один плохой день не даёт диагноза; устойчивая проблема в конкретном каталоге или шаблоне даёт.
Критерии приёмки формулируйте измеримо: ноль сломанных критичных сценариев; ноль индексируемых URL тестовой среды; все приоритетные редиректы исправны; sitemap доступен; доля обойдённых новых страниц увеличивается; органические конверсии сравниваются с сезонностью и обычным разбросом. Не объявляйте успех по позициям, если перестали учитываться заявки или продажи.
Дополнительные проверки для магазина и нескольких языков
В ecommerce синхронно переезжают сайт, структурированные данные и товарный фид. URL, идентификатор, цена, наличие, валюта, доставка и возврат должны совпадать во всех трёх. По возможности сохраните товарные ID и связи вариантов. Протестируйте корзину, промокоды, налоги, доставку, обратные вызовы платёжной системы, подтверждение, письма, изменение остатков и возврат средств.
В многоязычной миграции отдельное решение нужно каждой локали. Не перенаправляйте все украинские или русские страницы на английскую главную. Каждая версия ведёт на соответствующий перевод, содержит self-referencing canonical и входит в полный взаимный набор hreflang. Google требует, чтобы локализованная страница перечисляла себя и все альтернативы. Проверьте переключатель языка, метаданные и локальную навигацию.
Чек-лист не гарантирует неизменных позиций: алгоритмы, конкуренты, сезонность, изменение контента и темп обхода не подконтрольны проектной команде. Хорошая миграция устраняет лишнюю неопределённость, ускоряет поиск ошибок и защищает путь клиента, пока поисковые системы обрабатывают перенос.
Частые вопросы
Можно ли переехать без потери SEO-трафика?
Гарантировать прежние позиции нельзя. Но сохранение полезных страниц, карта URL один к одному, постоянные редиректы, согласованные canonical и sitemap и мониторинг по когортам заметно уменьшают предотвратимый технический ущерб.
Как долго хранить 301 редиректы?
Google рекомендует не менее года. Ценные правила стоит оставлять дольше, если старые URL живут в закладках, рекламе, письмах или внешних ссылках.
Можно ли одновременно менять дизайн и домен?
Только когда бизнес-ограничение важнее диагностического риска. Раздельные изменения позволяют быстрее понять причину проблемы и безопаснее её исправить.
Когда нужен откат?
Когда не работают критичные операции, рабочий сайт закрыт от индексации, массово отсутствуют важные редиректы, основные сигналы указывают на неверный хост или команда потеряла наблюдаемость.
Источники и дата проверки
Проверено 9 сентября 2026 года по официальным материалам Google Search Central о переносе сайта, локализованных страницах и структурированных данных ecommerce, а также по официальным Bing Webmaster Guidelines. Срок восстановления зависит от масштаба, спроса, доступных ресурсов для обхода и количества изменений.
Планируете редизайн, новую CMS или домен? Rendframe поможет собрать реестр URL, автоматизировать проверки, настроить редиректы, наблюдаемость и план отката. Посмотрите услугу разработки цифровых продуктов или закажите оценку рисков миграции.