Начните не с редиректов, а с карты того, что существует
Первый риск миграции — переносить только страницы, которые помнит команда. В реальности у сайта есть важные URL из меню, sitemap, внутренних ссылок, аналитики, Search Console, рекламных кампаний, старых публикаций и внешних ссылок. Карта нужна не для красивой таблицы, а чтобы для каждого типа страниц было принято решение: сохранить, перенести, объединить, вывести из эксплуатации или проверить отдельно.
Google рекомендует подготовить соответствие текущих URL их новым адресам до включения редиректов и отдельно тщательно протестировать новый сайт. Это напрямую совпадает с нормальным релизным процессом: сначала новый контур доказывает соответствие карте, затем команда меняет production в согласованное окно.
Пять решений, которые должны появиться до релиза
| Решение | Что фиксируем | Что проверяем |
|---|---|---|
| 1. Scope | Что именно меняется: домен, путь URL, CMS, дизайн, хостинг, контент или несколько вещей. | Можно ли разделить несвязанные изменения на последовательные волны, а не менять всё одновременно. |
| 2. Baseline | Приоритетные URL, разделы, шаблоны, формы, sitemap, ключевые события и исходные технические сигналы. | Что нельзя потерять и кто владеет каждым фактом или системой. |
| 3. Карта переходов | Старый URL, новый URL или отдельное решение; причина соответствия и владелец исключения. | Что перенаправляется на релевантную страницу, а что должно отдавать корректный статус удаления. |
| 4. Go/no-go | Список блокирующих проверок, окно релиза, ответственные и rollback. | Новый HTML, статусы, canonical, robots, ссылки, формы, аналитика и серверная доступность. |
| 5. Post-release | Набор URL и сигналов для проверки после запуска, период наблюдения и канал фиксации инцидентов. | Фактическое поведение production, а не то, что работало у разработчика. |
Карта URL: не все старые страницы имеют одинаковую судьбу
Качественная карта не делает вид, что любой старый адрес должен попасть на главную. Если страница переехала в релевантное новое место, ей соответствует конкретный новый URL. Если несколько страниц действительно объединены в одно полезное содержание, они могут вести к этому объединённому материалу. А если содержание больше не существует и не имеет релевантной замены, нужен честный сценарий удаления с корректным HTTP-статусом.
Google отдельно предостерегает от массового перенаправления несвязанных URL на одну нерелевантную страницу: это путает посетителя и может выглядеть как soft 404. Поэтому правило «на всякий случай отправим на главную» не заменяет решения о судьбе контента.
Что проверять на preview до запуска
- Маршруты и серверные ответы. Приоритетные адреса должны вести туда, куда предписывает карта, без циклов, цепочек и непонятных замен.
- Страница как документ. Проверяются `title`, H1, canonical, `robots`, основной HTML, доступность важного текста и ссылки на соседние разделы.
- Навигация. Внутренние ссылки на новом сайте должны вести на новые канонические URL, а не оставлять старые пути в меню, карточках и шаблонах.
- Пользовательские сценарии. Формы, контакты, поиск по сайту, корзина или другой критичный путь проверяются отдельно от поисковых метаданных.
- Наблюдаемость. Проверяется sitemap, доступ к нужным Search Console-свойствам и аналитике, а также способность сервера выдержать дополнительный обход после миграции.
После релиза: сначала факты, затем исправления
Значительная миграция может дать временные колебания, пока поисковая система обходит старые и новые URL. Нельзя объявлять релиз успешным только по тому, что открылась главная, и нельзя паниковать из-за одного колебания. Вместо этого команда повторяет заранее согласованный срез: критичные URL, статусы, редиректы, canonical, sitemap, внутренние ссылки, формы, ошибки сервера и доступные данные Search Console.
Если переезжает домен или поддомен, в Search Console нужны подтверждённые свойства старой и новой поверхности и отдельный процесс Change of Address. Он не требуется для обычного изменения HTTP/HTTPS, варианта www внутри того же домена или только пути URL. Такие различия лучше определить в плане, а не искать в день запуска.
Безопасный порядок при большой миграции
- Выбрать ограниченный, стабильный раздел, если проект допускает поэтапный запуск.
- Зафиксировать baseline и migration map для этой волны.
- Проверить preview и подготовить условия go/no-go и rollback.
- Получить явное подтверждение владельца на production-окно.
- После запуска проверить фактический результат и только затем расширять миграцию.
Это не бюрократия ради процесса. Каждая новая переменная — домен, CMS, дизайн, контент и инфраструктура — усложняет диагностику. Последовательный план оставляет команде возможность понять, что именно изменилось, и откатить ограниченную часть, если это требуется.
Чего не обещает этот чек-лист
- он не гарантирует сохранение позиций, трафика, заявок или срока переиндексации;
- он не даёт агенту право менять DNS, домен, SSL, сервер, CMS, редиректы или sitemap без preview и подтверждения;
- он не заменяет разработчика, DevOps, QA, владельца домена, безопасность или юридическую проверку переноса данных;
- он не разрешает массово удалять или перенаправлять URL без карты и rollback.
С чего начать
Если у миграции уже есть дата и команда, нужен отдельный контур SEO-сопровождения миграции: baseline, карта URL, требования к preview, release checklist и post-release контроль. Если сначала надо спроектировать новый сайт до макетов, начните с SEO для нового сайта. Ни одна из этих услуг не запускает изменение production без отдельного согласования.
Первичные источники
- Google: site moves with URL changes — карта URL, редиректы, sitemap, поэтапный перенос и контроль после запуска.
- Google: changing web hosting — порядок работы при смене инфраструктуры без видимых изменений URL.
- Google: redirects and Google Search — назначение постоянных редиректов и выбор релевантного назначения.
Частые вопросы
Нужно ли переносить всё одним релизом?
Не всегда. Для крупного сайта Google допускает перенос по частям; безопасная последовательность зависит от связей URL, сезонности, технических ограничений и того, можно ли проверить один раздел до расширения. Нельзя делить миграцию, не имея карты переходов и условий контроля для каждой волны.
Можно ли перенаправить удалённые страницы на главную?
Не следует массово направлять несвязанные старые URL на главную: это сбивает пользователя и может быть воспринято как soft 404. Для релевантно объединённого контента нужен осмысленный целевой URL; для действительно удалённого — корректный статус 404 или 410 по ситуации.
Гарантирует ли карта редиректов сохранение позиций?
Нет. Во время значительной миграции возможны колебания, пока поисковая система обходит и переиндексирует старые и новые URL. Карта снижает управляемые риски, но не отменяет влияние спроса, качества нового сайта, скорости сервера и решений поисковой системы.