После переезда не ждите месяц, чтобы понять, всё ли прошло нормально. В первые часы проверьте доступность важных страниц, редиректы, canonical, robots.txt, sitemap, формы и аналитику. Затем следите за обходом, индексацией, страницами входа и заявками. Любое отклонение сначала привязывайте к конкретным URL и изменениям, а уже потом исправляйте.
Переездом может быть смена CMS, домена, структуры адресов, дизайна или сервера. Во всех случаях задача одна: пользователь и поисковый робот должны получать рабочий аналог прежнего сайта, а обращения не должны теряться.
С чего начать
Для контроля нужна исходная точка: таблица старых и новых URL, список приоритетных страниц и данные до переезда. Если карту не подготовили заранее, соберите её из старого sitemap, аналитики, поисковых панелей, внешних ссылок и резервной копии.
Для каждой важной страницы запишите старый и новый адрес, ожидаемый код ответа, canonical, тип страницы, органические входы до переезда и найденные ошибки. Рядом укажите ответственного и срок исправления.
Общий график трафика годится как сигнал, но не как диагноз. При снижении выясните, какой раздел просел и какие страницы перестали быть входными. Учитывайте выходные, сезонность и остановку рекламы.
Если перенос только планируется, сначала пройдите чек-лист по переезду сайта на новую CMS. Дальше речь о ситуации, когда новая версия уже открыта посетителям.
Первые два часа: критические маршруты
Пройдите сайт как посетитель с телефона и компьютера. Откройте главную, основные услуги, категорию, несколько статей, контакты, страницу благодарности, файл для скачивания и заведомо несуществующий адрес. Отправьте форму и проверьте не сообщение «готово», а фактическое получение обращения.
Порядок проверки:
- Основной домен открывается по HTTPS без предупреждений.
- HTTP и альтернативное зеркало одним переходом ведут на выбранный адрес.
- Ключевые страницы отвечают 200, показывают текст, изображения и кнопки.
- Старые URL отдают прямой 301 на смысловые аналоги, без цепочек.
- Адрес без аналога возвращает 404 или 410, а не 200 со страницей ошибки.
- Canonical указывает на основной публичный URL самой страницы.
- Robots.txt не закрывает сайт или важные разделы после тестового запуска.
- В sitemap нет тестового домена, редиректов, старых адресов и noindex-страниц.
- Формы, телефоны, мессенджеры, скачивания и оплата работают.
- Аналитика фиксирует действие один раз и сохраняет источник перехода.
Откройте исходный код нескольких страниц. Внешне страница может выглядеть исправно, хотя canonical ведёт на тестовый домен или meta robots содержит noindex. Разобраться в статусах поможет руководство по HTTP-кодам и SEO.
Первые сутки: полный технический обход
Краулер показывает системные ошибки, которых не видно при ручной проверке. Включите JavaScript-рендеринг, если без него не появляется контент, и сопоставьте результат с картой URL.
Проверьте:
- старые адреса без редиректа, цепочки и циклы;
- переходы на нерелевантные страницы или главную;
- внутренние ссылки на старый домен;
- страницы 200 с пустым или урезанным текстом;
- пропавшие title, description и H1;
- canonical на другой URL без ясной причины;
- нужные страницы под noindex или запретом robots.txt;
- ошибки загрузки файлов и URL в sitemap с ответом, отличным от 200;
- страницы без входящих внутренних ссылок.
Группируйте ошибки по шаблонам. Если canonical неверен у одной категории, проверьте все категории. Если исчезло описание у статьи, посмотрите весь блог. Исправление шаблона обычно надёжнее ручной правки десятков страниц.
Внутренние ссылки должны сразу вести на конечные URL. Редиректы нужны для старых внешних маршрутов, а не для повседневной навигации по новому сайту. Системный поиск таких разрывов описан в статье про битые ссылки на сайте.
Дни 2-3: обход и индексация
Отсутствие нового URL в выдаче на следующий день ещё не означает ошибку. Сначала выясните, доступна ли страница роботу, обнаружена ли она и нет ли противоречивых указаний.
В поисковых панелях смотрите отчёты по sitemap, исключённым страницам, сканированию и отдельным URL. Для приоритетных страниц сравните старый адрес, новый адрес и URL из canonical. При корректной смене адреса старый URL отдаёт 301, новый отвечает 200, разрешён для индексации, стоит во внутренних ссылках и sitemap, а canonical ссылается на него самого.
Требуют внимания ситуации, когда:
- новый URL отвечает 200, но canonical указывает на старый;
- старый и новый адреса одновременно отдают 200 с одинаковым содержанием;
- sitemap содержит URL, запрещённый в robots.txt;
- внутренняя ссылка ведёт на адрес, который перенаправляет обратно;
- основной текст появляется только после действия пользователя или ошибки;
- сервер периодически отвечает 5xx при массовом обходе.
Не отправляйте на переобход весь сайт после каждой мелкой правки. Исправьте шаблон, снова запустите краулер, проверьте результат, затем запросите проверку важных страниц и обновите sitemap. Подробный порядок действий есть в материале о том, как проверить индексацию сайта.
Дни 3-7: страницы входа и обращения
Поисковые отчёты обновляются с задержкой, а обращения нужно контролировать сразу. Если заявок стало меньше, разделите проблему на четыре вопроса:
- Приходят ли люди из поиска?
- Попадают ли они на подходящие страницы?
- Видят ли предложение, условия и нужные доказательства?
- Работает ли целевое действие и его учёт?
Например, переходы на страницу услуги сохранились, но форма после смены шаблона завершается ошибкой. Это не потеря видимости, хотя для бизнеса итог тот же. Другая ситуация: форма исправна, но старый URL услуги отправляет на общую страницу, где посетитель не находит нужного предложения. Эти причины требуют разных исправлений.
Сравнивайте услуги с услугами, статьи со статьями, категории с категориями. Популярная публикация может скрыть падение коммерческого раздела.
Неделя 2: отложенные ошибки
Ко второй неделе в серверных журналах накапливаются данные. Проверьте обращения к старым URL без 301, ответы 5xx, медленные шаблоны, потерянные файлы, дубли и ссылки на тестовый домен.
Посмотрите разделы, которые почти не обходятся: возможно, до них трудно добраться по ссылкам. Повторный визит робота на старый адрес сам по себе не проблема. Важно, чтобы URL стабильно возвращал предусмотренный ответ.
Отдельно проверьте архивы, пагинацию, фильтры, теги и поиск по сайту: они способны создавать дубли и бесконечные комбинации параметров. Не включайте бесполезные параметры в sitemap и постоянную навигацию.
Недели 3-4: оценка по сегментам
К концу месяца соберите отчёт по услугам, категориям, статьям, брендовым и небрендовым запросам, обращениям. Укажите страницы входа, изменения, открытые ошибки и исправления.
Не привязывайте восстановление к обещанной дате: скорость обхода зависит от размера сайта и масштаба переезда. Важно, чтобы страницы были доступны, старые адреса перенаправлялись, а отклонения имели понятную причину.
Если отдельный раздел продолжает снижаться, проверьте полноту контента, соответствие прежней задаче страницы, заголовки, внутренние ссылки и canonical. Убедитесь, что шаблон не стал заметно тяжелее на телефоне, разметка не сломалась, а разные по смыслу страницы не объединили в одну общую.
Не откатывайте весь сайт из-за локальной ошибки. Исправьте карту URL или шаблон, повторите проверку и запишите дату изменения.
Как расставлять приоритеты
Сначала устраняйте то, что закрывает доступ пользователю, ломает обращение или даёт поисковой системе неверный сигнал:
- Недоступность сайта, проблемы DNS и HTTPS, ответы 5xx.
- Неработающие формы, оплата, звонки и передача данных.
- Запрет индексации, неверный canonical, массовые 404, циклы редиректов.
- Потеря контента, навигации, изображений и важных ссылок.
- Ошибки метатегов, разметки и отдельных малопосещаемых страниц.
- Косметические недочёты, не мешающие доступу и действию.
Учитывайте не только количество ошибок, но и роль страницы. Один неверный canonical на ключевой услуге может быть важнее множества ошибок на ненужных тегах.
Частые ошибки
Проверять только главную. Пока она работает, статьи могут отдавать 404, категории могут быть закрытыми, а формы - терять заявки.
Отправлять все удалённые URL на главную. Это не сохраняет смысл адреса. Выберите близкий аналог, а если его нет, верните честный статус удаления.
Менять всё одновременно. Массовая редактура текстов и шаблонов затрудняет поиск причины. После запуска фиксируйте каждую правку и сначала закрывайте технические ошибки.
Смотреть только общий трафик. Среднее значение скрывает падение услуг за ростом блога. Разделяйте данные по типам страниц, запросам и обращениям.
Быстро удалять редиректы. Старые URL остаются во внешних ссылках, письмах, документах и закладках. Редиректы для ценных страниц нужно сохранять, пока ими пользуются.
Считать любой спад аварией. На данные влияют спрос, сезонность, реклама и изменения выдачи. Сначала найдите пострадавший сегмент, затем проверяйте его URL.
Чек-лист на 30 дней
В день запуска
- проверить домен, HTTPS, зеркало и ключевые страницы;
- пройти формы и другие целевые действия;
- проверить старые URL и прямые 301;
- сверить robots.txt, sitemap, canonical и meta robots;
- подтвердить работу аналитики и получение тестовой заявки;
- выполнить полный обход и сохранить отчёт.
В первую неделю
- устранить массовые ошибки по шаблонам;
- обновить внутренние ссылки до конечных URL;
- проверить индексацию приоритетных страниц;
- следить за страницами входа и обращениями;
- сравнить мобильную и компьютерную версии;
- записывать исправления и даты проверок.
Во вторую неделю
- изучить серверные журналы и поисковые панели;
- проверить фильтры, пагинацию и редкие шаблоны;
- найти старые адреса без корректного ответа;
- проверить изображения и документы;
- повторить обход после исправлений.
К концу месяца
- сравнить сегменты трафика и обращений с исходной точкой;
- отдельно разобрать просевшие разделы;
- подтвердить стабильность редиректов и canonical;
- назначить ответственных за оставшиеся ошибки;
- сохранить отчёт и план следующей проверки.
FAQ
Нужно ли оставлять старый домен подключённым?
Да, если менялся домен и со старых адресов настроены редиректы. Иначе переходы по внешним ссылкам и сохранённым адресам перестанут работать. Продление и настройки старого домена должны оставаться под контролем владельца сайта.
Можно ли закрыть старые URL в robots.txt?
Обычно не стоит закрывать адрес, с которого поисковый робот должен увидеть 301. Запрет обхода может помешать обработать перенаправление. Решение зависит от типа URL, поэтому сначала проверьте ожидаемый ответ по карте миграции.
Нужно ли менять внешние ссылки на старый домен?
Ссылки на ресурсах, которыми вы управляете, лучше обновить до конечных адресов: так пользователь не проходит лишний переход. Но редиректы всё равно нужно сохранять для ссылок, которые изменить нельзя.
Что делать с тестовой версией после запуска?
Закройте её от публичного доступа и убедитесь, что на тестовый адрес не ведут ссылки с основного сайта. Саму среду можно оставить для разработки, но она не должна становиться доступной копией боевого сайта.
Как учитывать изменения в аналитике после смены домена?
Отметьте дату запуска, проверьте адрес сайта и настройки источников в используемой системе. Сопоставляйте периоды с одинаковыми правилами учёта: изменение целей или фильтров одновременно с переездом исказит сравнение.
Что делать дальше
Контроль после переезда - это последовательная проверка, а не ожидание графика. Составьте карту URL, пройдите критические маршруты, разделите технические сигналы и бизнес-результат, фиксируйте каждую правку. Если нужна помощь с диагностикой и приоритетами, напишите в Telegram. Для подготовки структуры, FAQ и рабочих черновиков можно использовать нейросеть XelaGroup, но редиректы, факты, формы и публичный результат должен проверять человек.
Нужно проверить сайт после переезда?
Разберём критические URL, технические сигналы и путь заявки, а затем расставим исправления по приоритету.