Выгрузите URL из CMS, краула, Sitemap, аналитики, Search Console, логов, фидов и внешних ссылок.
Что обновлено 24.08.2026: добавлена карта языкового кластера и QA перед индексацией.
Карта языкового кластера для темы «Миграция международного сайта»
Ниже показан контракт адресов, а не данные конкретного проекта. Вместо условных полей подставляют фактический хост, путь и доступные локали. В каждом кластере все страницы отвечают 200, канонизируются на себя и взаимно перечисляют эквиваленты.
| Адресная схема | Язык и регион | Canonical | Связь в кластере |
|---|---|---|---|
| {host}/ru-ru/{path}/ | ru-RU | self-canonical | Ссылки на все эквиваленты и x-default |
| {host}/ru-kz/{path}/ | ru-KZ | self-canonical | Взаимная связь с тем же содержанием для Казахстана |
| {host}/en-gb/{path}/ | en-GB | self-canonical | Английская версия для Великобритании |
| {host}/en-us/{path}/ | en-US | self-canonical | Английская версия для США |
| {host}/{path}/ | x-default | self-canonical | Страница выбора либо нейтральная версия |
QA перед открытием индексации
проверить HTTP-код и отсутствие редиректа на каждой целевой версии;
сверить язык основного текста, навигации, форм и юридических блоков;
убедиться, что каждая аннотация имеет возвратную ссылку;
не канонизировать локальную страницу на другую языковую версию;
выбрать одну реализацию hreflang — HTML или Sitemap — и проверять её как единый источник;
не перенаправлять робота и пользователя принудительно только по IP или языку браузера.
Если версия не готова содержательно или операционно, её не открывают для индексации ради полноты кластера. Сначала выпускают проверяемый пилот и только после QA расширяют покрытие.
Примечание. Миграция международного сайта умножает обычный риск переноса на число языков и рынков. Нужно сохранить не только соответствие старого и нового URL, но и связи между версиями, локальные canonical, внутренние ссылки, Sitemap, фиды и аналитику. Запуск без полной карты превращает hreflang в сеть редиректов и 404.
Соберите единый реестр URL
| Поле | Зачем | Критерий |
|---|---|---|
| Старый URL | Источник редиректа и исходных метрик | Каждый индексируемый адрес учтен |
| Новый URL | Конечная локальная страница | 200 и та же задача пользователя |
| Language/market | Контроль версии | Не определяется только по тексту URL |
| Stable ID | Связь эквивалентов | Один объект объединяет языковые версии |
| Redirect | Правило переноса | Один 301 без цепочки |
| Canonical | Предпочитаемый URL версии | Не ведет на другой язык |
Порядок миграции
Сопоставьте старые и новые страницы по назначению и стабильному ID, а не механической замене пути.
Отдельно обработайте удаленные рынки, отсутствующие переводы, объединенные страницы и измененный ассортимент.
Сгенерируйте 301 на конечные URL, новые canonical, hreflang-кластеры и Sitemap.
Перепишите внутренние ссылки, переключатель языков, structured data, фиды и ссылки в письмах/шаблонах.
Разверните копию в тестовой среде и проведите полный краул старых и новых списков.
В день релиза проверьте DNS, SSL, robots, noindex, коды, редиректы и ключевые пользовательские пути.
После запуска ежедневно контролируйте логи, индексирование, выбранные версии, трафик и конверсии по рынкам.
Как переносить неполные наборы
Если у старой страницы нет нового эквивалента на том же языке, не направляйте ее на страницу другого языка только ради сохранения URL. Выберите релевантный раздел, архив или 404/410 по ценности. Новый hreflang-кластер строится только из существующих версий.
Почему нельзя менять все одновременно
Смена домена, CMS, дизайна, структуры, контента и аналитики в один день лишает команду возможности локализовать причину падения. Если бизнес позволяет, разделяйте изменения. При едином релизе сохраняйте контрольные выборки и независимые тесты каждого слоя.
Критерии допуска к релизу
100% приоритетных старых URL имеют утвержденное действие.
Редиректы ведут за один переход на конечный URL той же задачи и локали.
Новые страницы возвращают 200 и не закрыты noindex/robots.
Canonical и hreflang содержат только новые конечные URL.
Внутренние ссылки, Sitemap и фиды не используют старые адреса.
Переключатель переводит между эквивалентами после миграции.
Аналитика сохраняет источники, market/language и целевые события.
Есть ответственный за откат и список условий остановки релиза.
Мониторинг после запуска
Разделите показатели на технические и поисковые. Сразу проверяйте 5xx, 404, цепочки, доступность ресурсов и конверсию. Затем — обход старых/новых URL, выбранные canonical, индексирование и показы. Сравнивайте рынки отдельно: ошибка одного поддомена не должна растворяться в общем трафике.
Когда удалять старую инфраструктуру
Не сразу после релиза. Сохраняйте редиректы и доступ к логам достаточно долго, чтобы поисковые роботы и внешние ссылки перешли на новые URL. Решение принимают по снижению обращений к старым адресам и завершению основных циклов переобхода, а не по календарной дате без данных.
Дневной отчет миграции
5xx и время ответа по каждому хосту и рынку.
Старые URL без 301 и новые URL не с кодом 200.
Цепочки, циклы и редиректы между языками.
Canonical и hreflang со старыми адресами.
Изменение обхода, индексируемых URL и органических входов.
Конверсия, формы и оплата по рынкам.
Как расследовать падение одного рынка
Сначала отделите техническую доступность от ранжирования: коды, robots, canonical, hreflang, внутренние ссылки и логи. Затем сравните соответствие старых и новых страниц и локальный контент. Не откатывайте весь международный сайт из-за ошибки одного поддомена, если архитектура позволяет изолированный релиз.
Частые вопросы
Нужно ли редиректить все старые страницы
Только если есть релевантная замена. Массовый редирект на главную или чужой язык создает плохой пользовательский результат и может восприниматься как мягкая 404.
Когда обновлять hreflang
Вместе с релизом новых URL. Он должен сразу указывать на конечные страницы, а не проходить через старые адреса и редиректы.
Приёмка обновлённой версии
каждая версия отвечает 200 и имеет self-canonical;
hreflang взаимный и содержит только доступные эквиваленты;
язык, рынок, формы и предложение согласованы;
нет обязательного редиректа только по IP или языку браузера;
масштабирование начинается после успешного пилота.
Итог
Старые адреса имеют однозначную замену, а языковые кластеры остаются взаимно согласованными. Масштабировать решение можно только после проверки на реальных URL и фактических данных проекта; если критерии не выполняются, сначала исправляют причину, а не увеличивают объём страниц, публикаций или автоматизации.
Получите бесплатный аудит и стратегию роста
Изучим сайт, покажем точки роста и подготовим прогноз до квалифицированных лидов и оборота из SEO/GEO.