Переезд сайта без потери SEO: домен, CMS, URL и редиректы

Начните с границ переезда

Словом «переезд» часто объединяют несколько разных задач. Пока участники понимают их по-разному, один готовит новую CMS, другой уже меняет структуру, третий ожидает редизайн, а принимающая сторона не знает, что именно проверять. Поэтому первый результат проекта - не макет и не серверная настройка, а согласованный состав изменений.

Если меняется только хостинг, Google выделяет это в отдельный сценарий без видимого изменения URL: новый сервер тестируют заранее, затем переключают DNS и наблюдают логи старой и новой инфраструктуры (Google о смене хостинга). Карта редиректов для страниц в таком случае не нужна, потому что сами адреса остаются прежними.

Смена CMS тоже не обязана менять URL. Если текущая структура понятна, страницы получают трафик и отвечают задачам пользователей, перенос тех же адресов обычно проще, чем одновременная перестройка всего сайта. Материал о возможностях CMS для SEO помогает оценить платформу; здесь вопрос уже другой - как перенести сайт и принять результат.

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

Поставьте команде правильную цель миграции

Поисковые системы обрабатывают переезд по мере повторного обхода URL. Google предупреждает о возможных временных колебаниях видимости, а Яндекс прямо не гарантирует сохранение количества страниц, позиций или посещаемости при смене главного адреса (Google о миграции URL, Яндекс о переезде домена).

Цель проекта - не «заморозить позиции», а исключить предотвратимые потери. К ним относятся пропавшие страницы, ошибочные редиректы, закрытый от обхода новый сайт, устаревшие указания предпочтительного URL, удаленные внутренние ссылки, неработающие формы и потерянные счетчики. Это меняет разговор команды: вместо обещания, которое нельзя проверить в день релиза, появляются конкретные ошибки, владельцы и сроки реакции.

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

Соберите один реестр для всей команды

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

Реестр собирают из нескольких источников:

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

Google советует начинать с важных страниц из Sitemap, аналитики, логов и отчета по ссылкам, а в план миграции включать также медиафайлы и технические ресурсы (подготовка карты URL в Google).

Для каждого старого адреса фиксируют текущий код ответа, назначение, органический трафик, входящие ссылки, новый адрес, плановое действие и ответственного. Я бы добавила еще три поля: кто утверждает решение, как его проверить и что делать при ошибке. Полезно отдельно отметить страницы, которые приносят обращения или поддерживают важные внутренние маршруты. Это не означает, что любой старый URL нужно сохранять: решение зависит от содержания и реальной замены.

Назначьте каждому адресу одно решение

Карта миграции должна быть однозначной. У одной строки не может одновременно быть решений «сохранить», «удалить» и «потом решить». До разработки нужно назначить одного владельца спорных соответствий, иначе техническая команда будет принимать бизнес-решения в момент настройки.

Массовый редирект всех удаленных страниц на главную не сохраняет их смысл. Google предупреждает, что нерелевантное перенаправление многих URL на одну страницу может восприниматься как soft 404 - ответ без честной ошибки 404, который поиск все равно считает несуществующей страницей. Яндекс также рекомендует вести внутренние страницы старого сайта на аналогичные страницы нового, а не собирать все на главной (Google о запуске редиректов, Яндекс о переезде домена).

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

Превратите правила редиректов в критерии приемки

Способ настройки выбирает технический специалист, но результат должна уметь принять вся проектная команда. Формулировки «редиректы настроены» для этого недостаточно: в карте нужны ожидаемый код, конечный адрес и проверяемое условие успеха для каждой группы URL.

Для постоянного переноса Google рекомендует серверные 301 или 308. В Яндексе распознаются стандартные HTTP-коды 3xx, при этом 301/308 относятся к постоянным, а 302/303/307 - к временным (Google о редиректах, Яндекс об обработке редиректов). Базовая модель Google - прямой постоянный редирект на конечную равноценную страницу. У Яндекса есть документированное исключение: при одновременной смене домена и названий каталогов его инструкция описывает двойной маршрут «старый домен и путь -> новый домен со старым путем -> новый домен и путь» (Яндекс о переезде домена).

Проверять нужно не только наличие правила, но и фактический маршрут:

1. В обычном сценарии старый URL возвращает один ожидаемый редирект; исключение Яндекса для одновременной смены домена и каталога заранее зафиксировано в карте.
2. Заголовок Location ведет сразу на конечный новый адрес либо на единственный согласованный промежуточный адрес из этого исключения.
3. Конечный новый адрес возвращает 200, а не еще один неожиданный редирект, ошибку или авторизацию.
4. На конечной странице нет noindex и canonical на старый домен.
5. Внутренние ссылки уже указывают на новый URL, а не проходят через редирект.
6. Параметры, регистр, слеши и языковые версии обрабатываются по утвержденным правилам.
7. Нет циклов вида A -> B -> A и противоречащих правил на уровне CDN, сервера и CMS.

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

rel="canonical" не заменяет редирект, когда старый адрес больше не нужен пользователю: этот атрибут обозначает предпочтительную версию среди доступных копий. Для Google новые URL должны ссылаться canonical на себя. У Яндекса на этапе заявки «Переезд сайта» действует отдельное правило: наличие rel="canonical" на страницах будущего главного сайта указано как причина отклонения заявки, и атрибут требуется удалить перед повторной отправкой. Поэтому единая настройка для двух поисковых систем здесь неверна; команда фиксирует отдельные критерии приемки по инструкции Google и инструкции Яндекса.

Зафиксируйте контракт страницы при смене CMS

Новая CMS может отдавать ту же страницу иначе. Даже при неизменном URL нужно сравнить старую и новую версии не по скриншоту, а по содержательному и техническому контракту. Для сопровождения проекта это принципиальная граница: «страница выглядит похоже» не равно «страница перенесена».

Проверьте для каждого типа страниц:

• основной текст, таблицы, изображения, видео и файлы;
• title, description, H1 и структуру заголовков;
• canonical, robots meta и HTTP-заголовки;
• хлебные крошки, навигацию и контекстные внутренние ссылки;
• структурированные данные и видимый текст, который они описывают;
• пагинацию, фильтры, параметры и правила индексирования;
• языковые или региональные ссылки, если они используются;
• формы, телефоны, электронную почту и следующий шаг;
• счетчики, цели, согласия и передачу источника обращения;
• коды ответа для существующих, удаленных и закрытых страниц.

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

Подробная связь структуры, страниц и спроса описана в материале про сайт и SEO как единую архитектуру. В миграционном плане эта архитектура считается уже утвержденной: задача статьи - сохранить или корректно переназначить ее адреса.

Примите новую версию до запуска

Тестовый сайт должен быть доступен принимающей команде и закрыт от случайной индексации. Google предлагает использовать среду с ограничением по IP либо временный хост с noindex; перед переключением временные блокировки нужно удалить (Google о смене хостинга). Парольная защита надежнее одной надежды на robots.txt, потому что тестовая копия не должна становиться публичным дублем.

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

Перед релизом проводят автоматическую и ручную проверку:

Автоматическая проверка

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

Ручная проверка

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

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

Полный перенос форм, базы, интеграций и контента на новую платформу должен получить собственный производственный план. В SEO-приемке они проверяются как зависимости: страница может индексироваться правильно, но бизнес все равно потеряет обращения, если форма перестала отправляться или аналитика записывает другой источник.

Согласуйте порядок запуска при смене домена

Когда меняется домен, старый и новый сайты некоторое время участвуют в одном переходном процессе. Перед переключением я бы провела короткую встречу go/no-go: каждый владелец подтверждает свой участок, блокирующие ошибки закрыты, окно запуска и канал связи известны, а право остановить релиз закреплено за конкретным человеком. После этого последовательность выглядит так.

1. Добавьте и подтвердите права на старый и новый адреса в Яндекс Вебмастере и Google Search Console.
2. Проверьте историю нового домена, безопасность, прежние ограничения и доступность для роботов.
3. Разверните новый сайт, сохранив утвержденное соответствие содержания и URL.
4. Удалите временные noindex, запреты обхода и ограничения, которые не должны действовать после запуска.
5. Включите прямые постоянные редиректы со старых страниц на соответствующие новые.
6. Обновите внутренние ссылки, языковые и региональные hreflang-ссылки, Sitemap, профили компании и рекламные ссылки. Для Google задайте self-canonical на новых URL; перед заявкой в Яндексе отдельно примените его текущее требование к rel="canonical" на будущем главном сайте (Google, Яндекс).
7. Протестируйте выборку критичных URL и всю карту автоматическим скриптом.
8. В Яндекс Вебмастере отправьте заявку через «Индексирование -> Переезд сайта» со старого адреса (инструкция Яндекса).
9. Для смены домена используйте Change of Address в Google Search Console после запуска редиректов. Для перехода HTTP -> HTTPS этот инструмент не применяется (справка Google).
10. Отправьте Sitemap с новыми URL и начните наблюдение за обходом, индексированием, трафиком и ошибками.

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

Если меняется структура внутри прежнего домена, отдельный инструмент смены домена не нужен. Яндекс рекомендует настроить 301 со старых страниц на новые, обновить Sitemap и навигацию; Google - использовать карту URL, постоянные редиректы и новые внутренние ссылки (Яндекс о смене структуры, Google о миграции URL).

Ведите единый контроль после переключения

Переезд не заканчивается ответом главной страницы 200. Первые проверки должны показать, получают ли люди и роботы именно те страницы, которые предусмотрены картой. Технический, поисковый и бизнес-контроль нельзя разносить по несвязанным отчетам: у них общая задача и общие приоритеты, хотя владельцы показателей разные.

Технический контроль

• доступность DNS, TLS-сертификата для защищенного HTTPS-соединения и нового сервера из разных сетей;
• коды старых и новых URL;
• ошибки 4xx и 5xx, циклы и неожиданные редиректы;
• обход роботов в логах и способность сервера выдержать повышенную активность;
• актуальные robots.txt, Sitemap, canonical и внутренние ссылки;
• загрузка изображений, файлов, CSS и JavaScript;
• отсутствие тестового noindex и ссылок на временный домен.

Google предупреждает, что после миграции новый сервер может получать дополнительную нагрузку: робот обращается и к новым URL, и к старым адресам, которые затем перенаправляются. При смене хостинга логи старой и новой инфраструктуры помогают понять, куда еще идет реальный трафик (Google о подготовке новой инфраструктуры).

Поисковый контроль

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

Бизнес-контроль

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

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

Заранее определите условия остановки и отката

Откат не должен зависеть от общего ощущения команды. До релиза нужно согласовать блокирующие ошибки и право остановить запуск. Тогда серьезная неисправность не превращается в спор между участниками под давлением времени.

Остановить переключение или вернуть предыдущую версию разумно, если:

• критичные страницы массово возвращают 4xx или 5xx;
• редиректы ведут на нерелевантные адреса, образуют циклы или теряют параметры, нужные приложению;
• новый сайт закрыт от обхода или canonical указывает на тестовую среду;
• формы, оплата, авторизация или основной контактный маршрут не работают;
• аналитика не фиксирует проверочные события, поэтому результат нельзя наблюдать;
• сервер не выдерживает нагрузку и нестабилен;
• команда не может быстро восстановить корректную карту на действующей версии.

Небольшое изменение позиций само по себе не является техническим основанием мгновенно откатывать домен: поисковым системам требуется время на обработку. Основанием служит проверяемая неисправность или выход метрики за заранее утвержденный порог.

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

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

Единый чек-лист приемки переезда

До запуска

• Тип миграции и границы изменений названы.
• Есть полный реестр старых URL и ресурсов.
• Для каждой строки утверждено одно действие.
• Карта редиректов протестирована на тестовом окружении.
• Новый сайт сохраняет нужное содержание, метаданные и внутренние связи.
• Robots, canonical, Sitemap и structured data проверены по шаблонам.
• Формы, счетчики, цели и маршруты обращения прошли тест.
• Права на поисковые панели и аналитику не потеряются.
• Определены блокирующие ошибки, порядок отката и ответственные.

В момент запуска

• Удалены временные запреты и тестовые адреса.
• Включены прямые постоянные редиректы.
• Критичные старые и новые URL проверены фактическими запросами.
• Формы и аналитика проверены после переключения.
• Новый Sitemap доступен и отправлен в панели.
• Для нового домена выполнены нужные действия в Вебмастере и Search Console.

После запуска

• Логи старого и нового серверов наблюдаются.
• Ошибки группируются по типам страниц и приоритету.
• Индексирование старых и новых адресов сопоставляется с картой.
• Показы, клики, обращения и конверсии сравниваются с базой.
• Внутренние, рекламные и важные внешние ссылки обновляются.
• Редиректы не снимаются только потому, что закончился проектный календарь.

Итог: одна карта и одно принятое решение

Безопасный переезд строится вокруг одной проверяемой карты: какой старый URL существует, какую задачу он решал, что должно открываться вместо него и кто принимает результат. Я считаю проект готовым к запуску, когда домен, CMS и структура меняются только в согласованных границах; постоянные редиректы ведут на точные замены; новый сайт сохраняет содержание, внутренние связи и измерение; блокирующие ошибки закрыты, а старые ответы не выключаются вслепую.

Если бизнес готовит смену домена, CMS или структуры, SEO-команда Медиакода может собрать карту URL и критерии поисковой приемки, а команда разработки сайтов - спланировать технический перенос и проверку рабочих сценариев. Эти две части должны использовать одну таблицу решений, но иметь отдельных ответственных за реализацию и приемку.