Как сохранить видимость при обновлении сайта: руководство по SEO-миграции

1. Сначала определите тип изменения и уровень риска

Не каждое обновление является переездом. Если меняются компоненты и визуальный язык, но URL сохраняются, основные риски связаны с рендерингом, содержанием, внутренними ссылками и скоростью. При смене домена, протокола, поддомена, каталогов или технологии поисковой системе приходится заново связывать старые адреса с новыми.

На первой странице плана зафиксируйте затронутые домены, число индексируемых URL, меняющиеся шаблоны, сокращаемый контент, формы и CRM-процессы, а также правила переноса языков. Дизайн, разработка, контент, SEO, аналитика и продажи должны работать с одним документом объёма проекта.

Приоритет отдавайте страницам, которые приводят органический трафик, получают внешние ссылки, поддерживают кампании или участвуют в генерации лидов. Включайте PDF и загружаемые файлы: низкий трафик не означает отсутствие ценности.

2. Зафиксируйте инвентарь старого сайта и исходные показатели

До переноса нужно понимать, что именно вы сохраняете. Объедините данные краулера, XML sitemap, посадочные страницы аналитики, Search Console, ссылки, рекламные цели и выгрузку CMS. Для каждого URL укажите статус, canonical, title, H1, органические клики, конверсионную роль, новый адрес и принятое решение.

Сохраните данные за 8–12 недель по запросам, страницам входа, каналам, устройствам и конверсиям, а при возможности сравните тот же сезон прошлого года. Архивируйте скриншоты ключевых страниц, результаты структурированных данных и показатели производительности — это позволит искать проблему по шаблону и этапу воронки, а не обсуждать общее «падение трафика».

Инвентарь не является списком на удаление. Редко посещаемый URL может иметь внешнюю ссылку, поддерживать клиента или помогать продаже. Объединённая страница должна действительно отвечать исходному намерению.

• Перечислены все индексируемые HTML-страницы и файлы.
• Зафиксированы органический трафик, внешние ссылки и конверсионная роль.
• Проверены canonical, hreflang, robots и структурированные данные.
• Документированы формы, звонки, письма и CRM-маршруты.
• Архивированы исходные данные аналитики и Search Console.

3. Стройте карту URL по намерению страницы

Хорошая карта связывает адреса не по похожести текста, а по ожидаемому результату пользователя. Сохраняющейся категории нужен равнозначный адрес; два перекрывающихся руководства можно объединить в более полное; материал без реальной замены не следует отправлять на нерелевантную главную страницу.

Google рекомендует постоянные серверные редиректы 301 или 308. Массовое направление несвязанных URL на одну страницу может интерпретироваться как soft 404. Чтобы не создавать задержку, старый адрес должен вести сразу к конечной цели, а правила нужно проверять как на примерах, так и массово.Google Search Central — редиректы и Google ПоискGoogle Search Central — руководство по переезду сайта со сменой URL

Добавьте к карте тип решения: сохранить, перенести, объединить, удалить или изучить. У каждой строки должен быть владелец и статус теста. Автоматически проверяйте старые sitemap, посадочные страницы и URL с сильными ссылками, включая параметры, регистр и варианты завершающего слеша.

4. Создайте контроль качества до публикации на staging

Не утверждайте сайт по скриншотам. Просканируйте все шаблоны и сравните статус-коды, title, description, H1, canonical, hreflang, разметку, alt-тексты, внутренние ссылки и пагинацию. Убедитесь, что основной контент и ссылки, создаваемые JavaScript, рендерятся; меню, поиск, фильтры и формы проверьте с клавиатуры и на настоящих устройствах.

Закройте staging от поиска и оформите снятие блокировки отдельной задачей релиза. Случайно перенесённые в production robots или noindex способны обнулить результат всей миграции.

Сделайте критерии выхода измеримыми: отсутствие битых ссылок в критичных шаблонах, стопроцентная проверка приоритетной карты URL, успешная запись формы в CRM, контроль событий в DebugView, бюджет производительности и доступность. Давление даты не превращает невыполненный критерий в выполненный.

5. Условный сценарий: перенос сайта услуг на новую CMS

Это гипотетический пример, а не результат клиента. Представим многоязычный сайт консалтинговой компании из 180 URL. Дизайнеры хотят объединить 60 старых отраслевых и сервисных страниц в 20 современных. В первом плане все адреса ведут на главные разделов, языковые каталоги меняются, а форма больше не открывает отдельную страницу успеха.

Команда классифицирует материалы по намерению и роли в продаже: 24 действительно похожие страницы превращаются в шесть руководств, 18 уникальных сохраняются, ещё 18 снимаются после проверки ссылок и спроса. Для каждого языка готовится отдельная карта, а форма тестируется специальным событием аналитики и реальной записью в CRM.

Публикация проходит в период низкой нагрузки с готовым планом DNS и отката. В первые часы контролируются критичные URL, затем 404 и формы, позже — группы запросов и качество конверсий. Колебания позиций всё ещё возможны, но источник проблемы и ответственный становятся видимыми.

6. Управляйте днём запуска как операцией

В плане должны быть владельцы решения, технического релиза, SEO и аналитики. До старта проверяются DNS, CDN, сертификаты и зависимости; критерии отката фиксируются заранее.

После включения редиректов проверьте новые canonical, robots и sitemap. При смене домена используйте инструмент Change of Address для подходящих ресурсов Search Console. Google советует сохранять постоянные редиректы не менее года, а для пользователей — по возможности дольше. Внутренние ссылки и важные внешние профили также нужно обновить.Google Search Central — руководство по переезду сайта со сменой URL

В первые сутки отслеживайте статусы критичных URL, формы, события, оплату или запись и серверные ошибки. В первую неделю ежедневно проверяйте 404, сканирование, sitemap, органические входы и конверсии по каналам; затем снижайте частоту только после стабилизации приоритетных страниц.

• Старые URL ведут прямо к правильной конечной странице.
• Canonical, hreflang и sitemap содержат только новые адреса.
• Robots и noindex корректны для production.
• Аналитика, согласия и CRM работают.
• Ресурсы Search Console подтверждены и уведомления отправлены.
• Назначены владельцы панелей 404, 5xx, форм и конверсий.

7. Типичные ошибки, границы и итоговое решение

Главная ошибка — подключить SEO только перед запуском, хотя структура URL, объём контента и JavaScript-архитектура определяются раньше. Другая — оценивать новый сайт без исходных данных. Третья — одновременно менять домен, CMS, информационную архитектуру, тон контента и модель аналитики: при сбое невозможно понять, какая переменная сработала.

Не всякое колебание означает ошибку. Google предупреждает о временных изменениях позиций, пока страницы крупного переезда сканируются и индексируются заново. Но 404 на критичном URL, canonical на старый домен или исчезнувшее событие формы не являются нормальной волатильностью. Заранее заданные пороги помогают быстро разделить эти случаи.

Если новый дизайн можно внедрить на существующих адресах, не меняйте их только ради эстетики. Переезд должен давать реальную пользу пользователю, содержанию или технологии.