Короткий ответ
Миграция роняет трафик в четырёх точках: непокрытые 301-редиректы, потерянные при переносе title, description и тексты, случайно оставшийся на проде noindex или Disallow: /, отвалившаяся разметка hreflang на многоязычном сайте. Всё остальное вторично.
Поэтому весь чек-лист сводится к одному документу: карте соответствия «старый URL → новый URL», в которой закрыт каждый адрес, приносивший показы или клики за последние 12 месяцев. Карта делается до разработки. Если она появляется в день переключения, миграция уже провалена, просто вы узнаете об этом через три недели.
Трафик падает не от переезда, а от четырёх вещей
Сам по себе переезд для Google нейтрален: Search Central описывает перенос сайта как штатную процедуру и указывает, что при постраничных 301 сигналы переносятся на новые адреса. То же самое касается смены сервера, и это я разбирал в статье о том, влияет ли хостинг на позиции. Падение возникает там, где переезд что-то теряет по дороге.
| Что ломается | Как выглядит симптом | Где видно |
|---|---|---|
| Часть старых URL никуда не ведёт | Рост категории «Не найдено (404)» через 1–2 недели | Search Console, отчёт «Индексирование страниц» |
| Редирект ведёт не на аналог, а на главную | Адреса выпадают из индекса как soft 404 | Search Console плюс краул старых адресов |
| Новые страницы получили шаблонные title | Показы держатся, CTR падает | Отчёт «Эффективность», сравнение по страницам |
На проде остался Disallow: / или noindex | Обвал показов на 3–7 день, резкий и по всему сайту | Отчёт «Индексирование», проверка URL |
| hreflang указывает на старые адреса | В выдаче показывается не та языковая версия | Краул и отчёты Search Console |
Последняя строка — специфика эстонских проектов. Сайт на трёх языках после переезда часто получает hreflang, ссылающийся на прежние адреса эстонской и русской версии, и Google перестаёт связывать версии между собой. Типовые ошибки такой разметки я разбирал отдельно в материале про настройку hreflang.
Карта соответствия URL — единственный документ, который решает исход
Карта — это таблица из двух колонок и одного правила: у каждого старого адреса есть ровно один новый адрес с тем же смыслом. Не «похожий раздел», а страница, ради которой человек шёл по ссылке. Полнота считается по показам за 12 месяцев в Search Console, а не по числу строк в старом sitemap.xml.
Собирается карта из четырёх источников, и ни один из них не покрывает всё: краул видит только то, на что ссылаются, Search Console — только то, что показывалось в выдаче, логи — только последний месяц.
- Краул старого сайта (Screaming Frog, Sitebulb) даёт адреса, доступные по внутренним ссылкам.
- Экспорт отчёта «Эффективность» за 12 месяцев по страницам даёт адреса, которые реально приносят трафик, включая те, на которые внутри сайта уже никто не ссылается. Это страницы-сироты, и краул их не покажет.
- Логи сервера за месяц показывают, какие адреса всё ещё обходит Googlebot и по каким приходят люди с внешних ссылок.
- Старый
sitemap.xmlдаёт то, что задумывалось как индексируемое.
Дальше по каждому адресу принимается одно из трёх решений: 301 на аналог; 404 или 410, если аналога нет и не будет; либо страница сохраняет прежний адрес без изменений. Третий вариант самый недооценённый: если структура URL уже нормальная, менять её при переезде на новую CMS не нужно вообще. Разницу между 301, 404 и 410 я разбирал в статье про то, что отдавать на удалённых страницах.
Что снять со старого сайта до переключения
До релиза снимается слепок старого сайта: не бэкап файлов, а 4 набора данных, по которым через 30 дней ищут потерю. Все 4 снимаются в один день, включая выгрузку из Search Console за 12 месяцев, чтобы даты совпадали.
- Экспорт краула со столбцами URL, title, description, H1, количество слов, код ответа. Файл кладётся в репозиторий проекта, а не в переписку.
- Экспорт «Эффективность» за 12 месяцев отдельно по страницам и по связке «запрос → страница». Search Console хранит 16 месяцев данных, но после переезда связку старых URL с новыми она не восстановит.
- Список внешних ссылок на уровне конкретных URL, а не доменов: именно эти адреса нельзя терять ни при каких условиях.
- Снимок позиций по основному ядру — точка отсчёта, чтобы через месяц спорить с цифрами, а не с ощущениями.
На стейджинге проверяется ровно четыре вещи: закрыт ли он от индексации (basic-auth надёжнее, чем robots.txt), совпадают ли title и тексты с картой, отдают ли новые адреса 200 без промежуточных редиректов, собран ли новый sitemap.xml. Как он должен быть устроен вместе с robots.txt, я описывал в статье про sitemap.xml и robots.txt.
День переключения: порядок операций
- Снять basic-auth со стейджинга и открыть новый сайт.
- Убрать
noindexи проверитьrobots.txtна проде вручную, открыв/robots.txtв браузере. Это операция номер один по числу провалов:Disallow: /со стейджинга уезжает в прод регулярно. - Включить 301-редиректы по карте. Не по маске «всё старое на главную», а постранично.
- Отправить новый
sitemap.xmlв Search Console, оставив старый доступным: он помогает роботу быстрее наткнуться на редиректы. - При смене домена подать заявку через инструмент «Смена адреса».
- Проверить счётчики: GA4 и Tag Manager после смены шаблона отваливаются чаще, чем редиректы.
- Прогнать краулером список старых URL из карты и убедиться, что каждый отдаёт 301 за один шаг.
Седьмой пункт и есть приёмка: 100 % адресов из карты отвечают 301 за один переход, ноль цепочек из двух и более редиректов. Пока это не проверено краулером, релиз не закрыт, даже если сайт визуально работает.
Что проверять в первые две недели
Ежедневно смотрится отчёт «Индексирование страниц» в Search Console. Интересуют три категории: «Не найдено (404)», «Страница с редиректом» и «Страница является копией, Google выбрал другой канонический URL». Первая показывает дыры в карте, вторая — цепочки редиректов, третья — что новые адреса конкурируют между собой, то есть на сайте появились дубли страниц.
Отдельно проверяется скорость: новая тема часто тянет за собой шрифты, слайдеры и скрипты, которых раньше не было. Полевые данные Core Web Vitals в Search Console считаются по скользящему окну в 28 дней, поэтому первую оценку приходится делать по лабораторным замерам в PageSpeed Insights и сравнивать их с тем, что было до релиза.
Сколько длится просадка и когда пора паниковать
По моим наблюдениям на переездах небольших сайтов услуг стабилизация занимает две-три недели. На каталогах в несколько тысяч страниц счёт идёт на месяцы: Google переобходит адреса не одновременно, и часть старых URL висит в индексе, пока робот до них не дойдёт. Это не поломка, а краулинговый бюджет.
Тревожный признак не падение само по себе, а его форма.
- Постепенное снижение с восстановлением за две-три недели — нормальный переходный процесс.
- Обвал в первые трое суток по всему сайту означает
noindexили закрытыйrobots.txt. - Падение по одному разделу — потерянный кусок карты редиректов.
- Ровное плато заметно ниже прежнего уровня через полтора месяца — потерянный контент: тексты при переносе шаблона обрезали, и вернуть трафик без возврата текста не получится.
Что чаще всего ломается в эстонских проектах
Три вещи повторяются из проекта в проект. Первая: разработчик переносит эстонскую версию, а русскую и английскую делает «потом», и сайт месяц живёт с битыми языковыми связками. Вторая: адреса на эстонском теряют täpitähed по-новому, старый URL содержал õ в percent-кодировке, новый транслитерует его в o, и совпадение адресов ломается там, где его никто не ждал. Третья: у старого сайта русская версия жила на поддомене, у нового живёт в папке, и карту редиректов для поддомена просто не собирают, потому что краул шёл по основному домену.
Все три ловятся одним действием: краул старого сайта в Screaming Frog запускается отдельно по каждому языковому разделу, и карта соответствия собирается своя для эстонской, русской и английской версии.
