Переезд сайта для SEO: как проверить карту редиректов до релиза и не потерять важные страницы
Переезд сайта на новую CMS или смену домена часто считают завершённым, когда старые адреса отдают код 301, а новые открываются с 200. На практике это означает только техническую работоспособность перенаправлений. Посетитель, пришедший за инструкцией по настройке конкретной модели, может оказаться в общем разделе поддержки без нужного материала. Технический переход работает, но ответ на задачу пользователя исчез из маршрута. Приёмку переезда для поисковой оптимизации стоит строить по соответствию старых и новых страниц, а затем по доступности и поисковому результату. Проверка только кодов ответа оставляет за пределами отчёта главное: сохранился ли смысл страницы для человека.
Фиксация границ проекта: что именно меняется
Смена хостинга без изменения адресов и перенос с новыми URL требуют разного плана действий. Google рассматривает эти сценарии отдельно. Для миграции с изменением URL официальное руководство рекомендует подготовить новый сайт, сопоставить адреса, настроить перенаправления и наблюдать за старой и новой версиями, учитывая возможные временные колебания видимости.
На старте полезно зафиксировать краткое описание границ: меняются ли домен, пути, состав страниц, контент, навигация, аналитика и оформление. Это помогает понять, какой результат команда сможет объяснить после запуска. Если вместе с адресами переписали описания услуг и удалили половину каталога, последующее изменение трафика нельзя уверенно приписать только редиректам. По возможности рекомендую разделять крупные изменения. Если это невозможно, хотя бы сохраняйте их перечень и даты.
Распределение ответственности
Одна общая задача «сделать SEO-переезд» не объясняет, кто должен решить спор о замене удалённой инструкции. Необходимо назначить владельца карты соответствий, ответственного за серверные правила перенаправления и человека, который принимает содержимое новых страниц. Чёткое разделение зон ответственности исключает ситуацию, когда разработчик считает переезд завершённым по кодам ответа, а контент-менеджер обнаруживает потерю важных материалов уже после релиза.
Сбор исходного реестра старых URL
Начальный список рекомендую собирать из нескольких источников: обхода текущего сайта, файла Sitemap, системы веб-аналитики, отчётов поисковых систем (Google Search Console), реестра материалов CMS и доступных серверных логов. Разные источники отвечают на разные вопросы: что существует сейчас, куда приходили люди, какие адреса использовались ранее.
Почему нельзя ограничиваться топовым трафиком
Не стоит оставлять в реестре только страницы с большим трафиком за последний месяц. В список могут не попасть сезонная услуга, инструкция с редкими, но важными переходами или документ, который регулярно отправляют клиентам в письмах. Сначала сохраните исходные выгрузки, затем создайте рабочий реестр со столбцами: старый URL, тип материала, идентификатор сущности, назначение страницы, источник обнаружения и приоритет проверки. Рядом добавьте новый адрес, решение по переносу, владельца и статус согласования.
Отдельный учёт файлов и ресурсов
Для файлов полезен самостоятельный раздел реестра. Если статья сохранилась, а её PDF-инструкция больше не открывается, пользовательский путь остаётся сломанным. Аналогично стоит проверить изображения и другие ресурсы, на которые ведут прямые внешние ссылки. Приоритет — средство организации работы, а не разрешение забыть остальные URL. Раньше проверяйте страницы с обращениями, продажами, существенными внешними ссылками и критичными инструкциями, но отдельный список исключений всё равно должен пройти ручное согласование.
Согласование смыслового соответствия
Для каждого старого адреса предлагаю выбрать одно из четырёх решений: перенос без изменения задачи (1-к-1), перенос с обновлением материала, объединение в более полный материал или удаление без подходящей замены. В условном каталоге старая инструкция
Риск soft 404 при массовых редиректах
Google предостерегает от массовых редиректов на нерелевантные страницы, например на главную: они могут рассматриваться как soft 404. При реальном объединении нескольких материалов в один перенаправление на объединённую страницу допустимо. Это различие описано в документации по запуску миграции. Поэтому поле «новый URL» не стоит заполнять автоматически только ради отсутствия пустых ячеек. Для спорных строк добавьте обоснование: какой раздел новой страницы отвечает на прежний вопрос и кто это проверил. В схеме редактор или владелец продукта подтверждает смысловую замену, а SEO-специалист проверяет её техническую реализацию. Это особенно важно при объединении услуг: название нового раздела может выглядеть подходящим, хотя условия, аудитория и действие для посетителя уже другие.
Работа с удалёнными материалами
Удаление без замены — допустимое решение, если оно принято осознанно. Наличие старого URL в реестре не обязывает создавать для него искусственную посадочную страницу. Google не индексирует адреса с ответом 404 или 410 и со временем удаляет ранее проиндексированные страницы с такими ответами. При этом код 200 сам по себе не гарантирует индексирование.
Рекомендую отдельно согласовать список удалений с владельцами разделов. Для каждого пункта сохраните причину и решение по пользовательскому маршруту. Возможно, человеку полезна понятная страница ошибки с поиском по сайту, но это не делает её эквивалентом удалённой инструкции. После запуска такой список помогает различать ожидаемые 404 и реальные дефекты. Без него любой рост ошибок превращается в спор: разработчик считает удаление плановым, маркетолог — потерей страницы, а подтвердить решение нечем.
Полная техническая проверка перехода
Для постоянного переноса Google рекомендует по возможности серверный постоянный редирект. Коды 301 и 308 обозначают постоянное перемещение; выбор временного или постоянного варианта должен соответствовать ситуации. В проверочной выгрузке сохраняйте исходный ответ, каждый переход, конечный URL, финальный статус, заголовки и подтверждение нужного содержимого. Так становится видно, что правило отправляет на старую промежуточную страницу или на адрес, который затем возвращает ошибку.
Пилотная проверка на представительных классах URL
Перед полной автоматической проверкой проведите пилот на ограниченном наборе, покрывающем основные сценарии:
- Обычная страница, переезжающая один к одному.
- Материал с изменённым названием и путём.
- Несколько материалов, объединённых в один.
- Удалённая страница без замены.
- URL с параметрами и альтернативным написанием, если такие варианты реально используются.
- Файл, на который ведут прямые внешние ссылки.
Это примеры классов проверки, а не универсальная норма объёма выборки. После пилота автоматическая проверка должна охватить согласованный реестр; ручная оценка нужна там, где результат зависит от смысла страницы.
Контроль правил замены путей на исключениях
Правила замены путей (rewrite rules) отдельно проверяйте на исключениях. Формула может правильно перенести большинство товаров и ошибиться на услуге с похожим адресом. Для выпуска важно знать конкретные исключения, а не только общий процент успешных ответов.
Валидация сигналов на новых страницах
У нового URL есть собственные настройки, способные противоречить плану. Поэтому проверка не заканчивается на успешном открытии в браузере. Google рассматривает редиректы и
Внутренние ссылки и навигация
Отдельно проверьте ссылки в навигации, карточках и редакционных материалах: они должны соответствовать выбранной архитектуре. Google использует ссылки для обнаружения страниц и рекомендует доступные для обхода ссылки с атрибутом href. В приёмке полезно проверить реальные маршруты от разделов к важным новым материалам.
Директивы индексирования
Проверьте
Корректность нового Sitemap
Новый Sitemap проверяйте как отдельный результат сборки: корректность адресов, отсутствие случайных тестовых доменов и соответствие реестру. Отправка карты не гарантирует обход и индексирование всех перечисленных URL — это ограничение указано в справке по Sitemap.
Критерии приёмки релиза
Техническая приёмка включает: согласованные соответствия, разобранные исключения, правильные конечные страницы, доступную навигацию, проверенные настройки индексирования и работоспособную аналитику. Для критичных дефектов заранее определяются основания переноса релиза или отката.
Сохраните исходную конфигурацию, финальную карту, результаты проверки и перечень известных ограничений. План отката должен учитывать не только код, но и опубликованный контент и новые данные: простой возврат старой CMS может оказаться неприемлемым для бизнеса. После запуска не ограничивайтесь проверкой главной страницы. Повторите проверки приоритетных маршрутов на публичной инфраструктуре. Если тестовое окружение и рабочий CDN отличаются, успешная проверка до релиза не подтверждает поведение рабочего сайта.
Отдельно назначьте срок сопровождения старого домена и правил перенаправления. Google рекомендует сохранять перенаправления как можно дольше, обычно не менее года. Это рекомендация из руководства по миграции, а не обещание, что через год все риски исчезнут.
Наблюдение за группами страниц после запуска
Рекомендую объединять старый и новый URL в одну аналитическую пару. Иначе отчёт по старым адресам покажет падение даже тогда, когда переходы переместились на новые. Для объединённых материалов нужна группа соответствий, а не механическое сравнение одной страницы с одной. Смотрите отдельно доступность, обход, индексирование, показы и переходы, затем обращения и продажи. При падении разбирайте конкретные группы: тип страницы, раздел, страна, устройство, брендовые и небрендовые запросы. Общий график скрывает ситуацию, когда один раздел растёт, а другой теряет важные посадочные.
Не каждое изменение после релиза вызвано миграцией. Google перечисляет среди причин падения поискового трафика технические проблемы, изменения спроса и алгоритмов. Для диагностики полезно руководство по анализу падения трафика. Для GEO и AEO отдельно фиксируйте старые ссылки в ответах и доступность назначения. Google требует индексирования и допуска к сниппету для возможности появления поддерживающих ссылок в AI Overviews и AI Mode, но не гарантирует включение. Это позиция Google из справки об ИИ-функциях, а не универсальное правило всех ИИ-сервисов.
Вопросы и ответы
Достаточно ли проверять только коды ответа 301 и 200 при приёмке переезда?
Нет. Коды ответа подтверждают только техническую работоспособность перенаправления. Они не гарантируют, что на целевой странице сохранился смысл и контент, отвечающий на задачу посетителя старого URL. Необходимо сверять смысловое соответствие и наличие нужного материала на странице-назначении.
Как поступать со страницами, для которых нет релевантной замены на новом сайте?
Удаление без замены допустимо, если решение принято осознанно и согласовано с владельцем раздела. Такие URL должны отдавать код 404 или 410. Важно зафиксировать причину удаления и пользовательский сценарий (например, показ понятной страницы ошибки с поиском), чтобы после релиза отличать плановые 404 от технических дефектов.
Почему нельзя сразу после релиза оценивать результат только по общему трафику?
Общий график трафика скрывает разницу по разделам: один может расти, а другой терять ключевые посадочные страницы. Необходимо анализировать группы соответствий (пары старый/новый URL) по отдельным сегментам: тип страницы, раздел, гео, устройство, тип запроса. Также изменения трафика могут быть вызваны не миграцией, а алгоритмами или спросом.