Практическая диагностика · миграция
Если позиции просели после миграции, важно не гадать про «переоценку сайта», а сравнить старую и новую версии по URL, редиректам, canonical, robots, Sitemap и доступности. Чаще всего причина находится в конкретном техническом расхождении.
Быстрый маршрут
Сначала выясняем, что именно изменилось: домен, URL, CMS, хостинг или несколько вещей одновременно.
Старые страницы ведут на правильные новые адреса без цепочек.
Новая версия не закрыта после staging.
Canonical указывает на текущие URL.
В карте нет старых адресов и мусора.
Нет массовых 4xx/5xx и медленного ответа.
Шаг 1
Главная ошибка миграции — редиректить всё на главную или родительскую категорию. Для страниц с эквивалентом нужен прямой 301 на соответствующий новый URL.
Если структура не менялась, внутренние ссылки всё равно должны сразу использовать новые адреса, а не ходить через редиректы.
Шаг 2
Перед запуском тестовый сайт часто закрывают noindex, robots.txt или авторизацией. После переключения домена эти ограничения иногда остаются.
Смотрим meta robots, X-Robots-Tag, robots.txt и фактический HTML важных шаблонов. Одной проверки главной недостаточно.
Шаг 3
После копирования базы canonical может продолжать ссылаться на старый домен или staging. В итоге редиректы говорят одно, а canonical — другое.
Массово выгружаем canonical по типам страниц и проверяем self-canonical там, где это ожидается.
Шаг 4
Новая CMS может потерять H1, текст категории, метатеги, пагинацию, карточки или важные внутренние ссылки. Тогда причина просадки не только в переносе URL, но и в изменении содержимого.
Сравниваем несколько ключевых шаблонов до и после, а не только визуальную похожесть дизайна.
Шаг 5
Массовые 404, 502, цепочки 301 и таймауты после запуска замедляют обработку новой структуры. Сверяем краулинг, серверные логи и статистику обхода.
Если проблемы начались сразу после переключения DNS, отдельно проверяем, не обслуживают ли разные узлы разные версии сайта.
Практический пример
Главная получила корректный 301 и быстро появилась по новому адресу, но категории потеряли большую часть показов. Визуально новая версия почти не отличается от старой.
Карта URL показывает, что старые категории редиректятся не на соответствующие новые категории, а на общий каталог. Дополнительно canonical части новых страниц всё ещё указывает на старый домен. Исправляем оба сигнала и обновляем внутренние ссылки.
| Сигнал | Что нашли |
|---|---|
| Главная | точный 301 — без проблемы |
| Категории | массовый 301 на общий каталог |
| Canonical | часть шаблона указывает на старый домен |
Типовые сценарии
Разные типы просадки после миграции требуют разного приоритета проверки.
| Симптом | Вероятная причина | Первое действие |
|---|---|---|
| Просели только старые URL | нет/неверные 301 | проверить карту соответствий |
| Из поиска исчез почти весь сайт | noindex/robots/canonical | проверить глобальные шаблоны |
| Главная держится, категории просели | потеря контента/ссылок/пагинации | сравнить шаблон категорий |
| Ошибки появились волнами | DNS или нестабильный сервер | проверить логи и разные IP |
| Падает только новый домен | не завершён перенос сигналов | проверить редиректы и Вебмастер |
Чего не делать
Становится невозможно отделить эффект миграции от редакционных изменений.
Теряется соответствие старых и новых документов.
Поисковик и внешние ссылки ещё могут обращаться к старым URL.
HTML, canonical и внутренние ссылки могут отличаться при одинаковом дизайне.
Чек-лист
Когда нужен доступ к проекту
Если миграция большая, нужен доступ к старой карте URL, логам и конфигурации редиректов. Без этого невозможно надёжно отличить потерянные соответствия от изменений контента.
Вопросы
Колебания возможны, но это не повод игнорировать технические ошибки. Сначала нужно исключить конкретные проблемы миграции.
Пока старые URL продолжают использоваться поиском и внешними ссылками; редиректы обычно сохраняют надолго.
Нет. Важнее корректные редиректы, Sitemap и доступность структуры.
Только если найден критический сбой. Без диагностики откат может добавить ещё один слой изменений.
