Редизайн сайта: когда пора менять дизайн и как снизить риск потери позиций

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

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

Когда редизайн сайта действительно нужен

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

• Оформление перестало соответствовать компании. Изменились продукты, позиционирование или фирменный стиль, а страницы представляют прежний бизнес. Соберите конкретные расхождения: фотографии, иерархия предложения, оформление каталога. Одной нелюбви к цвету кнопок недостаточно для перестройки сайта.
• На телефоне трудно пользоваться сайтом. Меню не раскрывается, таблица уходит за экран, клавиатура перекрывает форму. Проверьте путь от услуги до отправки заявки на своём устройстве. Для Google мобильное содержание служит основой индексирования и ранжирования — это прямо описано в документации о мобильных сайтах.
• Посетители приходят, но целевых обращений мало. Сначала проверьте учёт заявок, источники переходов, само предложение и работоспособность формы. Низкая конверсия — повод искать препятствие. Она сама по себе не доказывает, что нужно менять весь дизайн.
• Обновление контента требует постоянного участия разработчика. Редактор не может добавить услугу, таблицу или новый тип материала. Попросите показать такую задачу на действующей CMS: причина может быть в настройке полей или шаблона, а не в платформе целиком.

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

Редизайн или доработка: выбрать объём изменений

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

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

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

Пошаговый план: от исходных данных до наблюдения после запуска

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

1. Зафиксировать исходное состояние. Собрать страницы, показатели поиска и заявок, тексты и настройки. Выделить материалы, потеря которых особенно заметна бизнесу.
2. Согласовать границы проекта. Определить, что меняется в оформлении и сценариях, какие URL сохраняются, нужна ли смена CMS. Для каждого изменения указать причину.
3. Спроектировать на настоящем содержании. Показать услуги, категории, карточки и статьи с реальными названиями, таблицами и условиями, включая мобильный вариант.
4. Подготовить перенос. Сопоставить старые и новые адреса, перенести поля и материалы, собрать тестовую копию с ограниченным доступом.
5. Принять и запустить. Проверить страницы, переходы, заявки и аналитику; подготовить резервную копию и действия при критической ошибке.
6. Наблюдать за результатом. Сверить рабочий сайт с планом, затем контролировать индексирование, поисковые переходы и обращения.

По возможности разнесите крупные перемены: домен, CMS, оформление. Это соответствует рекомендации Google менять элементы последовательно. Если разделить работы технически нельзя, опишите зависимости в плане и предусмотрите проверку каждого изменившегося шаблона. Общие требования удобно собрать в техническом задании на разработку.

До макетов: сохранить то, что уже приносит пользу

Сначала соберите реестр действующих страниц. Не ограничивайтесь верхним меню: включите статьи, категории, карточки, посадочные страницы и документы, на которые ведут ссылки. Сопоставьте выгрузку CMS, карту сайта, данные аналитики и поисковых кабинетов. Так проще заметить полезную страницу, которую редко открывают через главную.

• Адрес и назначение: полный URL, тип страницы, продукт или вопрос, который она раскрывает.
• Содержание: title, description, H1, основной текст, таблицы, изображения, документы и ссылки на связанные материалы.
• Поиск: показы и клики по страницам и запросам; при наличии — данные наблюдения за позициями в одинаковых условиях.
• Бизнес-результат: поисковые визиты, достижения выбранных целей, реальные обращения и заказы по доступным данным компании.
• Будущее страницы: сохранить, содержательно обновить, объединить с другой или удалить с объяснением решения.

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

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

URL и 301-редиректы: решить судьбу каждой страницы

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

Для постоянной смены адреса страницы Яндекс рекомендует серверный 301. Google описывает 301 и 308 как постоянные перенаправления. В примерах ниже используем 301: этот код прямо рекомендуют обе справки. Временный 302 не стоит выбирать по привычке для постоянного переноса страниц.

Учебная карта решений — пути вымышлены и показывают принцип, а не настройки нашего сайта:

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

Почему не стоит отправлять всё на главную

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

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

Если вместе с дизайном меняется домен

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

Перенести содержание и SEO-поля без случайных потерь

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

Title — название документа, description — метаописание, H1 — заголовок внутри страницы. Подробности разобраны в статье о заполнении SEO-полей. Руководство Google связывает хороший заголовок с точным описанием содержания. Поисковый сниппет при этом может отличаться от заполненных полей.

Для каждой самостоятельной страницы проверьте canonical — указание предпочтительного адреса при дублях. Он не должен случайно вести на главную, другую услугу или тестовый поддомен. В Google это сигнал о выборе канонического URL, а не замена постоянному перенаправлению. Ссылки, карта сайта и canonical должны указывать согласованные рабочие адреса.

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

Яндекс в справке о смене дизайна предупреждает строже: содержимое, которое генерирует JavaScript, его робот может не проиндексировать, поэтому основной текст лучше отдавать в HTML-коде сразу при открытии страницы (справка Вебмастера). Если новые шаблоны подгружают характеристики или описания скриптом, проверьте исходный HTML отдельно.

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

Тестовая копия: закрыть от поиска и проверить перед выпуском

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

Если тестовую страницу необходимо оставить публично доступной, согласуйте запрет индексирования. Например, такой метатег размещают в head тестовой HTML-страницы:

<meta name="robots" content="noindex">

Это инструкция для поисковика, а не защита от просмотра по прямой ссылке. По правилам Google, робот должен получить страницу, чтобы увидеть noindex. Если обход запрещён в robots.txt, робот Google не увидит метатег, и адрес может остаться в выдаче, например при ссылках с других страниц. Поэтому одного Disallow недостаточно, чтобы надёжно исключить известный HTML-адрес из выдачи Google.

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

• Проверьте robots.txt рабочего домена: важные страницы и нужные ресурсы доступны для обхода.
• Посмотрите итоговый HTML и HTTP-заголовки: нет случайного noindex в meta robots или X-Robots-Tag.
• Проверьте canonical, ссылки, Sitemap и адреса файлов: они не ведут на тестовую копию.
• Откройте заполненные шаблоны без входа в админку. Основной текст и элементы управления доступны обычному посетителю.
• Пройдите меню, поиск, фильтры, формы и заказ, если они есть. Проверьте положительный результат и понятное сообщение об ошибке.

Файл robots.txt и карта сайта решают разные задачи; порядок их настройки разобран в материале о robots.txt и sitemap.xml. Для запуска нужен фактически проверенный результат на рабочем домене: правильный файл в архиве ещё не означает, что сервер отдаёт именно его.

Чек-лист запуска: что принять до переключения и сразу после

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

Перед переключением

• Есть реестр прежних URL и согласованная судьба каждой переносимой страницы.
• Подготовлены перенаправления, проверены их цели и сохранение содержания.
• Перенесены SEO-поля, тексты, изображения, документы и навигация.
• Приняты заполненные шаблоны на компьютере и телефоне, проверена загрузка и работа элементов.
• Подготовлены рабочие настройки индексирования и актуальный Sitemap.
• Сохранены доступы к Метрике, Вебмастеру и Search Console, а также подтверждение прав на сайт.
• Есть копия файлов и данных, понятен способ восстановления и сохранения новых обращений.

Сразу на рабочем сайте

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

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

Для нового кода счётчика справка предлагает добавить к адресу параметр _ym_debug=2, например открыть главную как /?_ym_debug=2. Если панель не появилась или установлен прежний код, в инструкции есть проверка через консоль. Проверяйте именно нужный счётчик и нужную цель, а не просто наличие события с похожим названием.

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

После запуска: Вебмастер, Search Console и Метрика

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

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

В Search Console проверьте конкретные URL и динамику показов и кликов. После изменения путей анализируйте старую и новую страницу как связанную пару. Отсутствие кликов у прежнего адреса само по себе не означает потерю, если переходы получает его преемник.

В Метрике откройте «Отчёты → Источники → Поисковые системы» и выделите нужные страницы входа. Сравните Яндекс и Google отдельно, затем устройства и цели. Клики поискового кабинета и визиты счётчика — разные показатели; не требуйте их точного совпадения.

Если графики снизились: с чего начать проверку

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

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

Частые ошибки, которые стоит исключить из проекта

• Согласовали только главную. Добавьте к приёмке услугу, категорию, карточку и статью — те шаблоны, которыми действительно пользуется компания. Проверьте длинные названия и реальные материалы.
• Переименовали URL ради новой структуры меню. Сначала выясните, можно ли улучшить навигацию, сохранив пути. Любая смена адреса должна иметь причину и понятного преемника.
• Убрали тексты, чтобы макет выглядел легче. Согласуйте, где теперь находятся характеристики, условия и ответы. Оценивать нужно полноту информации, а не совпадение длины страниц.
• Проверили только код ответа 200. Сверьте содержимое: код 200 у пустой заглушки не равен готовой странице, а сам по себе не гарантирует её индексирование.
• Запустили сайт и убрали тестовый поддомен из плана. Он должен остаться закрытым, а рабочие настройки нужно проверить отдельно. Особенно внимательно — ссылки и адреса файлов, перенесённые из копии.
• Оценили проект по общему трафику. Разберите поиск отдельно, затем страницы, устройства, цели и реальные обращения. Рост рекламы может скрыть снижение поисковых переходов.

В договорённостях о приёмке замените формулировку «SEO сохранено» перечнем результатов: адреса проверены, контент перенесён, доступность подтверждена, аналитика работает, дальнейшее наблюдение назначено. Эти результаты можно предъявить и проверить. Обещание неизменной выдачи — нельзя.

Частые вопросы

Нужно ли переделывать сайт через определённое число лет?

Мы советуем ориентироваться на задачи и проверяемые проблемы. Возраст дизайна сам по себе не объясняет, что мешает компании. Если посетители находят нужное, формы работают, а редактор может развивать содержание, начните с локальных улучшений и проверки предложения.

Можно ли гарантировать редизайн без потери позиций?

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

Если все URL остались прежними, нужны ли редиректы?

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

Обязательно ли менять CMS при редизайне?

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

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

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

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

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

Источники

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

• Планирование переноса, карта URL и сохранение перенаправлений — Google Search Central, How to move a site.
• Редизайн при прежних адресах и перенос страниц — Яндекс Вебмастер, «Смена структуры и дизайна сайта»; смена домена — «Переезд сайта на новое доменное имя».
• Постоянные перенаправления — Google Search Central, Redirects and Google Search; ответы сервера — Google, How HTTP status codes affect Google's crawlers.
• Защита содержимого и запрет индексирования — Google Search Central, Control what you share with Google Search и Block Search indexing with noindex.
• Мобильное содержание — Google Search Central, Mobile site and mobile-first indexing best practices.
• Содержание и метаданные — Google Search Central, SEO Starter Guide; канонические адреса — How to specify a canonical URL.
• Проверка Google и анализ просадок — Google Search Central, Get started with Search Console и Debugging drops in Google Search traffic.
• Наблюдение за индексированием — Яндекс Вебмастер, «Мониторинг важных страниц».
• Проверка аналитики — Яндекс Метрика, «Проверка цели» и «Отчёт „Поисковые системы“».