Редизайн сайта: как обновить внешний вид и сохранить обращения из поиска

Определите проблему, которую должен решить редизайн

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

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

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

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

Соберите реестр страниц до начала макетов

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

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

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

Согласуйте судьбу каждого меняющегося адреса

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

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

Попросите специалиста проверить внутренние ссылки, canonical и карту сайта. Canonical сообщает поисковой системе, какой адрес страницы вы считаете основным; sitemap перечисляет адреса для поиска. После выпуска они должны соответствовать новой рабочей структуре. Эти настройки не исправят отсутствие нужного содержания и не заменят переход со старого адреса там, где он необходим.

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

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

Принимайте новую версию до переключения сайта

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

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

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

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

Проверьте формы и измерения отдельно от внешнего вида

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

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

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

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

Составьте план переключения и возврата

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

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

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

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

Наблюдайте за страницами, которые действительно менялись

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

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

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

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

Лист готовности к редизайну

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

• Проблемы старой версии и ожидаемые улучшения описаны конкретно.
• Важные страницы и материалы учтены; перенесённым страницам назначены новые адреса, а удалённым без замены — корректный ответ об отсутствии.
• Работа форм, CRM и аналитики проверена на тестовых обращениях.
• Есть резервная версия, ответственные и согласованные основания возврата.
• После запуска назначены проверки адресов, поиска и полученных обращений.

Для обсуждения редизайна со ШТАБ ИТ подготовьте текущий сайт, список затруднений и доступные сведения о важных страницах. В обращении укажите, что требуется сохранить: адреса, материалы, интеграции и рабочие сценарии. Это позволит оценивать обновление по выполненной задаче и сохранённым функциям, а не только по новым макетам.