Как перезапустить сайт без потери трафика

Перезапуск — это миграция, даже если домен не меняется

Компания может сохранить домен и всё равно провести рискованный переезд. Меняются адреса услуг, структура каталога, технология рендеринга, тексты, внутренняя перелинковка и скорость загрузки. Для поисковой системы и пользователя это новая конфигурация сайта, которую нужно заново сопоставить со старой.

Трафик теряется не из-за самого нового дизайна, а из-за разрыва сигналов. Популярная страница исчезает, старый адрес начинает отдавать мягкую 404, несколько материалов перенаправляют на главную, важный текст становится доступен только после сложного скрипта, а тестовый запрет индексации случайно попадает на рабочий сайт. Такие ошибки предотвращаются до переключения.

Шаг 1. Соберите инвентаризацию действующего сайта

Не полагайтесь только на меню. В поиске могут находиться страницы, которых давно нет в навигации: старые статьи, PDF, карточки услуг, адреса рекламных кампаний и параметры. Список собирают из нескольких источников и объединяют по нормализованному URL.

• Выгрузка всех доступных внутренних ссылок и файла sitemap.xml.
• Страницы с показами и кликами в кабинетах поисковых систем.
• Страницы входа и конверсии из системы аналитики.
• Адреса, на которые ведут внешние ссылки, реклама, письма и партнёрские материалы.
• Служебные URL, файлы, изображения и страницы с параметрами.
• Текущие коды ответа, canonical, robots и метаданные.

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

Шаг 2. Сопоставьте содержание, а не только адреса

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

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

• Сохранить или улучшить самостоятельный ответ страницы на запрос.
• Перенести подтверждённые кейсы, таблицы, FAQ и документы.
• Не менять одновременно смысл и адрес без необходимости.
• Обновить внутренние ссылки сразу на конечные URL.
• Сохранить важные фрагменты, на которые ссылаются другие материалы.
• Отдельно проверить страницы, которые приводят обращения, даже если у них мало просмотров.

Шаг 3. Подготовьте карту постоянных редиректов

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

• Старый и новый протокол, www и вариант без www приводятся к одному каноническому хосту.
• Правила учитывают регистр, завершающий слеш и реальные исторические варианты.
• Параметры сохраняются только там, где они нужны и безопасны.
• Удалённые страницы не получают случайный редирект на главную.
• Внутренние ссылки, sitemap и canonical сразу используют новые адреса.
• Редиректы остаются доступными достаточно долго для пользователей и внешних ссылок.

Для неизвестного маршрута сайт должен возвращать настоящий код 404 и полезную страницу с навигацией. Визуально красивая страница ошибки с кодом 200 сообщает поисковой системе, что несуществующий адрес является обычным документом.

Шаг 4. Проверьте новую сборку до переключения

Тестовая версия должна быть недоступна для случайной индексации и защищена способом, который не мешает команде проверять реальные сценарии. Перед запуском временные ограничения включают в отдельный чек-лист снятия. История знает много случаев, когда рабочий сайт наследует noindex или запрет robots.txt именно потому, что проверка ограничивается внешним видом главной.

1. 01

   Сравнить URL

   Все строки карты миграции имеют реализованный конечный маршрут или корректный ответ.

2. 02

   Проверить разметку

   У страниц уникальные title, description, H1, canonical и нужные структурированные данные.

3. 03

   Пройти содержимое

   Нет заглушек, тестовых контактов, потерянных блоков и битых изображений.

4. 04

   Проверить JavaScript

   Основное публичное содержание доступно при загрузке и не скрыто за обязательным пользовательским действием.

5. 05

   Протестировать формы

   Успешная, ошибочная и повторная отправка корректно отображаются и доходят в рабочий контур.

6. 06

   Проверить мобильную версию

   Навигация, таблицы, формы и длинные заголовки не перекрываются.

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

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

• Зафиксировать рабочую версию и резервную копию.
• Проверить конфигурацию домена, TLS, CDN и кэширования.
• Развернуть новую сборку и применить карту редиректов.
• Снять временные запреты индексации.
• Проверить главную, ключевые входные страницы, формы и 404.
• Опубликовать sitemap с каноническими URL.
• Проверить логи сервера и доступность ресурсов.
• Назначить ответственного на период наблюдения.

Если одновременно меняются домен, система управления, структура и содержание, число переменных растёт. Где возможно, изменения разделяют на проверяемые шаги. Но искусственно растягивать миграцию тоже не нужно: решение зависит от архитектуры и способности сохранять единое каноническое состояние.

Шаг 6. Мониторьте обход, индексирование и обращения

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

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

Типовые ошибки при перезапуске

• Собирать список редиректов вручную в день публикации.
• Удалять старые тексты как «неподходящие к новому дизайну» без оценки их роли.
• Менять все URL ради визуальной аккуратности.
• Перенаправлять десятки разных страниц на главную или каталог.
• Оставлять canonical на тестовом домене или старом адресе.
• Закрывать CSS, JavaScript или изображения, необходимые для отображения страницы.
• Публиковать sitemap со старыми, редиректными или закрытыми URL.
• Забывать снять noindex после тестирования.
• Проверять только десктопную главную и не тестировать формы.
• Удалять резервную копию до окончания периода наблюдения.

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

Короткий чек-лист безопасной миграции

1. 01

   До разработки

   Выгрузить URL и данные, определить ценность страниц, спроектировать будущую структуру.

2. 02

   До готовности дизайна

   Сопоставить старое и новое содержание, утвердить постоянные адреса.

3. 03

   До запуска

   Реализовать редиректы, проверить метаданные, формы, 404, sitemap и запреты индексации.

4. 04

   В момент запуска

   Сделать резервную копию, переключить конфигурацию, пройти критические URL и проверить логи.

5. 05

   После запуска

   Наблюдать обход, индексирование, трафик по группам страниц, ошибки и обращения.

Цель миграции — не законсервировать старый сайт, а сохранить полезные сигналы, пока структура и продукт улучшаются. Можно менять дизайн, тексты и технологию, если команда понимает роль каждой страницы, создаёт содержательное соответствие и проверяет переход от старого состояния к новому.