Редизайн сайта без потери SEO и заявок: план миграции

Редизайн часто воспринимают как задачу про интерфейс: обновить дизайн, собрать сайт на другой CMS, ускорить фронтенд. Для бизнеса это ещё и миграция работающей воронки. У старых страниц уже есть показы, переходы, внешние ссылки, закладки, кампании и сценарии заявок. Если при запуске изменить адреса, удалить контент, сломать форму или потерять события аналитики, новый дизайн может выглядеть лучше, но перестать приводить тот спрос, который сайт уже получал.

Эта статья — план для компании, которая меняет сайт, структуру, CMS, домен или одновременно несколько компонентов. Она актуальна на 17 августа 2026 года. Фокус не на поисковом аудите вообще, а на управлении изменением: как зафиксировать исходную систему, перенести URL и содержание, проверить аналитику, провести релиз и наблюдать за ним после запуска. Google и Яндекс не дают гарантий сохранения позиций или трафика: при существенной миграции колебания возможны, а скорость переобхода зависит от конкретного сайта и серверов. Задача команды — не обещать «нулевую просадку», а убрать предотвращаемые потери.

Когда редизайн становится SEO-миграцией

Миграция начинается не только при смене домена. Она происходит, если меняются пути страниц, правила формирования URL, HTTP/HTTPS, www-вариант, CMS, шаблоны рендеринга, структура каталога, языковые или региональные версии. Даже при сохранении URL риск остаётся: новый шаблон может добавить noindex, закрыть CSS или JavaScript, изменить canonical, убрать текст, заменить ссылки кнопками без обычного href или нарушить отправку формы.

Полезно разделить изменения на два потока:

Один владелец миграции должен вести общую таблицу решений. Без неё дизайнер может удалить блок как «лишний», разработчик — изменить URL ради удобства роутинга, а маркетолог — обнаружить исчезнувшую цель уже после падения заявок.

Что считать успешным результатом

Не задавайте критерий в виде «после релиза позиции не меняются». Поисковые системы переобрабатывают перенос постепенно и по URL. Google прямо предупреждает о временных колебаниях при значимых изменениях. Более проверяемые критерии выглядят так:

1. Каждый важный старый URL либо отдаёт 200 OK на сохранённой странице, либо одним понятным редиректом ведёт на смысловой аналог, либо осознанно отдаёт 404/410.
2. Новые приоритетные страницы доступны роботу, имеют согласованные canonical и присутствуют в актуальном XML sitemap.
3. Основные пользовательские действия проходят на мобильном и десктопе, а успешные лиды доходят до CRM.
4. В системах аналитики и вебмастерах есть сравнимая исходная точка и план наблюдения, чтобы отличать сезонность от технической ошибки.

Это не гарантия видимости или выручки. Это контроль условий, на которые команда реально влияет.

Шаг 1. Зафиксируйте границы проекта и заморозьте лишние изменения

Сначала ответьте письменно: что именно меняется — дизайн, структура, CMS, домен, протокол, каталог, язык, трекинг? Отметьте, какие изменения можно отложить. Google рекомендует менять по одному крупному фактору за раз, когда это возможно: так проще найти причину проблемы и снизить число неизвестных.

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

Не запускайте миграцию в момент, когда бизнес зависит от краткосрочной кампании, сезонного пика или важного промо, если его можно избежать. Это не правило поисковой системы, а способ снизить цену ошибки и получить более читаемые данные.

Шаг 2. Постройте инвентарь не «всех страниц», а всех ценных точек входа

Карта URL — фундамент переноса. Экспорт CMS полезен, но недостаточен: в нём нет удалённых страниц, на которые ещё ведут внешние ссылки, и не всегда видны параметры, редиректы или файлы. Соберите единый реестр из нескольких источников:

• XML sitemap и краул текущего сайта;
• URL из Google Search Console и Яндекс Вебмастера, особенно страницы с показами, кликами и ошибками;
• веб-аналитика: входные страницы, конверсии, источники, устройства;
• CRM: страницы и кампании, которые дают квалифицированные обращения;
• список внешних ссылок из вебмастеров;
• реклама, e-mail, соцсети, QR-коды, презентации и партнёрские ссылки;
• PDF, изображения, инструкции и другие файлы, если на них есть поисковой спрос или ссылки.

В таблице одной строкой храните старый URL, тип страницы, трафик/конверсии за согласованный период, внешние ссылки, новый URL, решение, ответственный и статус проверки. Решений обычно три: «сохранить», «перенести на смысловой аналог», «удалить с 404/410». Четвёртого решения «перекинуть всё на главную» в хорошей карте нет.

Приоритет задавайте не красотой URL, а ценностью: услуги, категории, лидогенерирующие статьи, страницы с заметным поисковым спросом, документы с внешними ссылками. Проверьте варианты протокола и хоста, URL со слешем и без, а также исторические адреса. Именно в этих «хвостах» часто остаются непредусмотренные входы.

Шаг 3. Согласуйте судьбу контента до дизайна

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

Для каждого приоритетного URL отметьте:

1. Основную задачу и поисковой интент: услуга, категория, инструкция, сравнение, поддержка.
2. Обязательные смысловые блоки: предложение, условия, цена или способ её расчёта, доказательства, FAQ, кейс, характеристики.
3. Медиа и файлы, которые имеют отдельные URL и входы.
4. Ближайшую новую страницу, если контент объединяется.

Объединение допустимо, когда новая страница действительно отвечает на ту же задачу и даёт пользователю ожидаемый материал. Если старый URL был про конкретную услугу, а новый ведёт на общую главную, это не миграция смысла. Google называет массовую отправку разных старых URL на нерелевантную единственную страницу потенциальным soft 404; Яндекс также советует не перенаправлять все внутренние страницы на главную.

Не копируйте старый сайт бездумно. Устаревшие, юридически рискованные или повторяющиеся материалы можно удалить, но такое решение должно быть явным. Для удалённого без замены адреса настройте фактический HTTP-ответ 404 или 410, а не страницу «не найдено» с кодом 200.

Шаг 4. Подготовьте карту редиректов и правила каноникализации

В большинстве постоянных изменений адреса рабочим выбором будет серверный 301 или 308. Google рассматривает постоянные серверные редиректы как сильный сигнал для выбора новой канонической страницы; временные 302, 303 и 307 сообщают другую семантику. Точный технический вариант должен соответствовать инфраструктуре и тому, постоянна ли замена.

Ключевое правило — соответствие «один старый URL → один наиболее релевантный новый URL». Если несколько действительно схожих материалов объединились, несколько старых адресов могут вести на одну новую содержательную страницу. Но не используйте редирект как способ скрыть отсутствие контента.

В карте редиректов предусмотрите поля: old_url, new_url, ожидаемый код, причина, тип соответствия, статус теста. Затем проверьте её автоматизированно и выборочно в браузере. Ищите:

• цепочки из двух и более переходов;
• петли;
• переходы на 404, 5xx, staging или неканонический хост;
• замену query-параметров, которая ломает кампании и пользовательские сценарии;
• редирект важных файлов на HTML-страницы без смысловой связи.

На новых страницах rel="canonical" должен указывать на их итоговый собственный URL, если страница не является дублем. Canonical, внутренние ссылки, XML sitemap и редиректы не должны спорить друг с другом. Внутренние ссылки после релиза обновляют сразу на финальные URL: это улучшает путь пользователя и уменьшает лишнюю нагрузку от перенаправлений.

Google советует оставлять редиректы как можно дольше, обычно не менее года при переносе URL; для пользователя и внешних ссылок часто разумно сохранять их дольше. Это не отменяет необходимости убрать цепочки и обновить собственные ссылки.

Шаг 5. Соберите среду тестирования, но не оставьте её в состоянии «закрыто»

На staging допустимы ограничения доступа и временный noindex, чтобы тестовая версия не попала в поиск. Риск возникает на проде: после копирования конфигурации блок остаётся в robots.txt, метатеге robots или заголовке X-Robots-Tag. До запуска создайте отдельный список вещей, которые снимаются только при релизе: пароль, IP-ограничение, noindex, запрет обхода, тестовые canonical, тестовые счётчики и ссылки на staging.

Проверьте шаблоны, а не только пару URL. Результат зависит от типа страницы: главная, услуга, категория, статья, карточка, поиск/фильтр, 404, форма, файл. На каждом шаблоне проверьте:

• ответ сервера и финальный URL;
• title, description, H1 и canonical;
• robots meta и HTTP-заголовки;
• доступность критичного текста и ссылок без авторизации;
• XML sitemap и robots.txt;
• мобильное меню, CTA, форму и страницу/сообщение успешной отправки;
• скорость и ошибки браузера в реальном пользовательском пути.

Не полагайтесь лишь на визуальный QA. Страница может выглядеть нормально и при этом возвращать 200 для несуществующего адреса, иметь canonical на staging или не передавать форму из-за блокировщика скриптов.

Шаг 6. Перенесите измерение заявок как отдельную поставку

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

Минимальный сценарий теста выглядит так: открыть приоритетную страницу на мобильном, заполнить форму валидными данными, увидеть подтверждение, получить событие именно об успешной отправке, увидеть лид в CRM или Telegram/почте и сопоставить его с источником и URL. Повторите для звонка, мессенджера, заказа или другого реального CTA. Клик по кнопке — полезная микроконверсия, но он не доказывает появление заявки.

Проверьте согласие на обработку данных, антиспам, обязательные поля, UTM-метки, referrer и кросс-доменные переходы, если форма, платёж или CRM живут на другом домене. Не публикуйте тестовые контакты в рабочую воронку без пометки: договоритесь, как команда их отличит.

До релиза сохраните базовый снимок: поисковые показы и клики по группам URL, органические сессии, конверсии, долю ошибок, входы на 404, скорость и статусы лидов. Сравнивать «вчера» и «сегодня» недостаточно — выбирайте сопоставимые периоды и учитывайте рекламу, сезонность и другие изменения.

Шаг 7. Проведите релиз по чек-листу, а не по памяти

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

1. Сделайте контрольный экспорт текущих URL, настроек и базовых метрик.
2. Разверните продовую версию и включите подготовленные правила редиректов.
3. Снимите только временные ограничения staging.
4. Проверьте главную, важные шаблоны и выборку приоритетных старых URL: статус, цепочку, финальную страницу, canonical, форму.
5. Проверьте robots.txt, XML sitemap, HTTP/HTTPS и www/non-www правила.
6. Убедитесь, что аналитика принимает тестовые успешные события, а лид дошёл до нужной системы.
7. Отправьте в Google Search Console новый sitemap. При переносе домена используйте Change of Address по инструкции Google; при переходе только с HTTP на HTTPS этот инструмент не нужен.
8. В Яндекс Вебмастере сообщите об изменениях через раздел с sitemap; если меняется главный адрес в поддерживаемом сценарии, используйте инструмент «Переезд сайта» согласно его условиям.

Перед нажатием «опубликовать» полезен принцип двух пар глаз: один участник проверяет технический лист, другой проходит путь посетителя. Это дешевле, чем искать пропавший номер телефона после запуска рекламы.

Шаг 8. Мониторьте последствия, а не объявляйте миграцию завершённой в день релиза

Для Google перенос считается завершённым, когда Googlebot посетит каждый старый и новый URL хотя бы раз; фиксированной частоты обхода нет. Поэтому после запуска нужна очередь наблюдения, а не единственный «переобход». Ежедневно в начале релиза смотрите доступность, ошибки 5xx, долю 404, редиректы, отправку форм, реальные лиды и аномалии трафика. Затем регулярно сверяйте:

• Google Search Console: индексирование, проверку URL, sitemap, эффективность и ошибки;
• Яндекс Вебмастер: страницы в поиске, диагностику, статистику обхода, проверку ответа сервера, внешние ссылки;
• аналитику и CRM: органические входы, конверсии, ошибки форм, качество и обработку заявок;
• логи сервера или мониторинг: всплески ошибок, боты, нагрузку и неожиданные URL.

Сегментируйте отчёты по типу страниц и группам URL. Если просели только карточки, не усредняйте их с блогом; если заявки исчезли на iOS, не ждите, пока поисковые отчёты «устаканятся». Создавайте задачу с URL, наблюдением, предполагаемой причиной, владельцем и датой повторной проверки.

Типичные ошибки, которые дорого стоят

Редизайн и смена CMS запускаются одновременно без карты соответствий

Команда получает слишком много переменных: меняются URL, HTML, сервер, контент и трекинг. Карта URL и поэтапность не делают работу медленной — они делают ошибки локализуемыми.

Все старые страницы отправляют на главную

Это ломает ожидание человека и лишает поисковик ясного сигнала о новом местоположении темы. Делайте редирект на содержательный аналог или отдавайте корректный 404/410, если аналога нет.

На прод попали запреты со staging

noindex, Disallow, пароль и canonical на тестовый домен часто выглядят как мелкие настройки. На деле они могут сделать новый сайт невидимым для поиска. Вынесите их в отдельный обязательный пункт релизного листа.

Успех оценивают по кликам, а форму не проверяют

Органический трафик может сохраниться, но заявки исчезнуть из-за маски телефона, капчи, интеграции или события. Приёмка обязана доходить до фактического получения лида.

После старта меняют всё каждое утро

Новые правки могут быть нужны, но фиксируйте их и выпускайте контролируемо. Иначе невозможно понять, почему изменились индексация, конверсия или скорость.

Чек-лист перед запуском редизайна

• Составлен реестр старых URL из sitemap, краула, вебмастеров, аналитики, внешних ссылок и кампаний.
• Для всех приоритетных URL выбрано решение: сохранить, перенести на релевантный аналог или вернуть 404/410.
• Согласована и протестирована карта серверных редиректов без цепочек, петель и переходов на staging.
• Новые страницы содержат нужный смысл, медиа, CTA и внутренние ссылки.
• Canonical, sitemap, robots и внутренние ссылки указывают на финальные URL и не противоречат друг другу.
• На проде не останутся временные noindex, пароль, блокировки обхода и тестовые теги.
• На каждом типе шаблона проверены коды ответов, title, H1, canonical и мобильный сценарий.
• Успешная отправка каждой основной формы подтверждена в аналитике и CRM.
• Верифицированы свойства старого и нового сайта в Search Console, если этого требует сценарий переноса.
• Подготовлены базовые метрики, мониторинг, владелец инцидентов и понятный план отката.

FAQ

Нужен ли 301, если меняется только дизайн, а URL остаются прежними?

Нет, редирект нужен для переноса адреса, а не для нового оформления. Но при неизменных URL всё равно проверьте ответы сервера, robots, canonical, контент, ссылки, sitemap, формы и аналитику: именно здесь часто возникает потеря видимости или заявок.

Можно ли перенаправить удалённые страницы на главную, чтобы не было 404?

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

Когда позиции и трафик восстановятся после миграции?

Единого срока нет. Google указывает, что обработка происходит по URL и зависит, среди прочего, от масштаба сайта и возможностей сервера; Яндекс также связывает скорость с обходом и обновлением данных. Не обещайте срок заранее. Наблюдайте за данными вебмастеров и исправляйте подтверждённые проблемы.

Нужно ли оставлять старый домен и редиректы?

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

Можно ли закрыть новый сайт от индексации до релиза?

Да, тестовую среду обычно закрывают. Важно иметь проверяемую процедуру снятия временных запретов на проде и после релиза удостовериться, что robots.txt, meta robots, X-Robots-Tag и canonical соответствуют боевой версии.

Нужен редизайн, который не обрывает поток обращений?

ClickShot проектирует и разрабатывает сайты как коммерческие системы: сначала фиксируем ценные точки входа и путь пользователя, затем переносим структуру, контент, аналитику и технические сигналы в управляемом релизе. Если Вы планируете смену сайта или платформы, закажите разработку сайта и SEO-сопровождение миграции — подготовим карту работ, критерии приёмки и понятный мониторинг после запуска без обещаний неподконтрольного результата.

Источники

Ссылки проверены 17 августа 2026 года.

1. Google Search Central — Site Moves and Migrations — подготовка миграции, карта URL, мониторинг, sitemap, Change of Address и типовые ошибки.
2. Google Search Central — Redirects and Google Search — постоянные и временные редиректы.
3. Google Search Central — SEO starter guide: технические сценарии — постоянный перенос URL, 301 и корректный 404.
4. Google Search Central — Sitemaps overview — роль sitemap в обнаружении URL.
5. Google Search Central — Canonicalization — сигналы канонического URL.
6. Яндекс Вебмастер — Смена структуры и дизайна сайта — изменение URL, редиректы, проверка ответа сервера и sitemap.
7. Яндекс Вебмастер — Переезд сайта на адрес с www и обратно — соответствие внутренних страниц, редиректы и инструмент «Переезд сайта».
8. Яндекс Вебмастер — Инструкции по настройке популярных платформ сайтов — ссылки на настройки редиректов для CMS.