Редизайн сайта и SEO: что проверить до запуска новой версии

Определите масштаб изменений и коммерческий риск

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

Если меняются URL, домен или CMS, одного чек-листа редизайна недостаточно. Google выделяет изменение адресов в отдельный процесс миграции сайта, а Яндекс отдельно описывает действия при смене структуры и дизайна. Такой проект получает два контура: производственный запуск новой версии и сохранение поисковых маршрутов старых страниц.

Редизайн нельзя принимать по принципу «стало современнее». У каждой важной страницы должны остаться владелец, задача и измеримый критерий качества.

Зафиксируйте коммерческий baseline до разработки

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

Начинают не со всех URL подряд, а с карты типов страниц и приоритетов. В нее включают:

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

Для каждой важной страницы фиксируют не только адрес. Нужны ее назначение, основной интент, владелец, HTTP-статус, robots, canonical, Title, Description, H1, основные смысловые блоки, входящие и исходящие внутренние ссылки, видимая форма или следующий шаг. Отдельно сохраняют поисковые и бизнес-показатели в сопоставимом периоде: показы, клики, запросы, целевые действия и подтвержденные обращения, если такие данные уже собираются.

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

Назначьте четыре решения для каждого элемента

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

1. Сохранить. смысл, доказательство или ссылка остаются без изменений.
2. Улучшить. задача сохраняется, но формулировка или представление становятся понятнее.
3. Заменить. прежний блок получает равноценную по функции альтернативу.
4. Удалить. команда фиксирует, почему элемент больше не нужен и как проверит последствия.

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

Сохраните способность страницы приводить к решению

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

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

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

Из этого не следует, что JavaScript запрещен. Следует другое: критический текст, заголовки и ссылки должны надежно появляться в итоговом HTML без ошибки API, обязательного клика или зависшего состояния загрузки.

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

Что сравнить на старой и новой странице

• основной ответ и границы обещания;
• факты о компании, услуге, продукте или кейсе;
• H1 и последовательность содержательных H2-H3;
• видимые доказательства, документы, изображения и подписи;
• автора, должность, даты и источники, если они нужны типу страницы;
• CTA, форму, телефон, мессенджер и следующий шаг;
• текст ссылок и фактические адреса переходов;
• содержимое мобильной версии;
• состояния без данных, ошибки и загрузку интерактивных блоков.

Не дайте шаблону перезаписать весь тип страниц

Новый компонент часто выглядит правильно в макете, но генерирует одинаковые метаданные для разных страниц, ставит canonical на раздел, наследует noindex со staging или возвращает 200 для экрана ошибки. Один такой дефект способен одновременно убрать из поиска целую группу услуг и сократить входящий спрос. Поэтому приемка идет не только по полям CMS, а по фактическому ответу URL.

Для каждого шаблона проверяют:

• окончательный HTTP-статус без неожиданной цепочки переходов;
• один осмысленный H1 и корректную структуру заголовков;
• уникальные Title и Description, соответствующие назначению страницы;
• robots meta и X-Robots-Tag без случайного noindex;
• canonical на утвержденный основной URL, без общего шаблонного адреса;
• hreflang, если сайт использует языковые или региональные версии;
• структурированные данные, которые совпадают с видимым содержанием;
• Open Graph и изображение предпросмотра, если они входят в стандарт сайта;
• Sitemap, если изменился набор индексируемых адресов.

Поле в административной панели не считается доказательством. Доказательство - итоговый HTML, HTTP-заголовок и результат проверки публичного или тестового URL.

Разделите общие и локальные ошибки

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

Сравните навигацию и внутренние ссылки

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

Сначала снимают граф старых внутренних ссылок. После сборки новой версии повторяют обход и сравнивают:

• какие индексируемые страницы потеряли все входящие ссылки;
• куда ведут меню, хлебные крошки, карточки и связанные материалы;
• остаются ли ссылки обычными элементами <a href>;
• доступны ли следующие страницы пагинации без обязательного пользовательского действия;
• не появились ли ссылки на staging, старый домен или параметры;
• не ведут ли многочисленные карточки на один общий URL вместо своих страниц;
• не изменились ли анкоры так, что назначение перехода стало непонятным.

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

Проверьте мобильную версию как основную поисковую поверхность

Мобильный вариант нельзя принимать как уменьшенный десктоп. Google использует мобильный контент для индексирования и рекомендует сохранять на мобильной версии основной материал, метаданные, структурированные данные, важные изображения и доступные ссылки (рекомендации Google).

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

• основной ответ и доказательства не удалены ради компактности;
• меню открывается и содержит нужные переходы;
• кнопки, формы и поля доступны с клавиатуры и касания;
• фиксированные панели не перекрывают контент и CTA;
• изображения имеют подходящие размеры и alt, когда несут смысл;
• отложенная загрузка не требует прокрутки, клика или другого действия для появления основного материала;
• Title, Description, robots и canonical не отличаются от утвержденной версии;
• мобильная страница не возвращает ошибку там, где десктопная доступна.

Связывайте производительность с поведением и заявками

Тяжелые шрифты, видео, фоновые анимации, большие изображения и клиентские компоненты способны изменить скорость загрузки, реакцию интерфейса и стабильность макета. Google относит к Core Web Vitals LCP, INP и CLS. На дату проверки рекомендуемые хорошие значения составляют: LCP до 2,5 секунды, INP до 200 миллисекунд и CLS до 0,1 (Google о Core Web Vitals).

Эти значения оценивают пользовательский опыт, но не обещают высокие позиции. Google прямо указывает, что хорошие результаты отчета Core Web Vitals не гарантируют место в выдаче и не заменяют релевантность и общую полезность страницы (Google об удобстве страниц). С коммерческой стороны важна не абстрактная оценка скорости, а связь изменения с отказами, переходами к CTA, отправками форм и качеством обращений на конкретных типах страниц.

Поэтому сравнивают два вида данных:

• лабораторные тесты - чтобы найти проблему до релиза;
• реальные пользовательские данные - чтобы понять результат на устройствах и соединениях аудитории после накопления наблюдений.

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

Закройте staging и не перенесите запрет в production

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

Если на staging используется noindex, перед релизом его удаление становится отдельным обязательным пунктом. Проверка проводится не по настройке проекта, а по нескольким итоговым URL каждого шаблона и по HTTP-заголовкам. Аналогично снимаются временные canonical, ссылки на тестовый домен, заглушки, демонстрационные schema и тестовые счетчики.

До запуска команда выполняет два прохода:

1. Автоматический. обход URL, статусы, robots, canonical, метаданные, заголовки, ссылки, дубли, ресурсы и структурированные данные.
2. Ручной. смысл страницы, мобильная версия, меню, формы, ошибки, состояния загрузки, согласие на cookies, телефон, мессенджеры и путь заявки до системы учета.

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

Соберите матрицу приемки до релиза

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

Не каждое отклонение требует отмены запуска. Например, изменение формулировки Description может быть согласованным улучшением. Но статус такого решения должен быть записан до релиза, а не объяснен задним числом.

Запускайте изменения так, чтобы видеть коммерческую причину

Если проект позволяет, крупные слои разводят по времени: сначала инфраструктура, затем шаблоны, затем содержательные изменения. Это не требование поисковой системы, а способ уменьшить число одновременных причин. Когда все меняется одним релизом, до запуска нужны более полный baseline, расширенная выборка URL и строгий план отката. Иначе падение обращений нельзя уверенно связать ни с потерей видимости, ни с новой формой, ни с изменением предложения, ни с обработкой лидов.

Порядок контроля строится по событиям, а не по обещанию «позиции восстановятся за N дней»:

1. До переключения замораживают карту версии, список URL, доказательства приемки и ответственных.
2. Сразу после переключения проверяют доступность, robots, canonical, HTML, формы и счетчики.
3. После первого обхода сравнивают отчеты поисковых панелей, серверные логи и индексирование приоритетных страниц.
4. После накопления сопоставимого периода сравнивают показы, клики, запросы, целевые действия и подтвержденные обращения.
5. Каждое отклонение связывают с URL, шаблоном и временем изменения, а не только с общей цифрой по сайту.

Запрос переобхода уместен только после публичной проверки важной страницы. Если изменилось много адресов или их состав, обновляют Sitemap и проверяют его фактическую выдачу. Инструменты поисковых панелей ускоряют обнаружение изменений, но не исправляют ошибочные canonical, robots, контент или ссылки.

Останавливайте запуск по факту поломки, а не по тревоге

Откат заранее связывают с наблюдаемым техническим или бизнес-блокером. К таким сигналам относятся:

• значимая группа страниц возвращает 4xx, 5xx или бесконечные переходы;
• важный контент отсутствует в итоговом HTML или мобильной версии;
• production наследует noindex, тестовый canonical или ссылки на staging;
• меню и внутренние ссылки перестают открывать важные разделы;
• формы, телефон, мессенджеры или передача заявки не работают;
• счетчики и события перестают давать сопоставимые данные;
• общий компонент создает массовый дефект метаданных или schema;
• новый ресурс вызывает подтвержденную критическую деградацию ключевых шаблонов.

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

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

Частые ошибки при редизайне

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

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

Старый текст сохраняют без проверки роли

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

Принимают только главную страницу

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

Верят настройке CMS без проверки HTML

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

Считают зеленый отчет коммерческим результатом

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

Не фиксируют изменения аналитики

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

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

Содержание и структура

• У каждого важного URL зафиксированы назначение, владелец и решение по содержанию.
• Основной ответ, доказательства, следующий шаг и связанные материалы сохранены или осознанно заменены.
• H1-H3 отражают структуру страницы, а критический текст доступен в итоговом HTML.
• Навигация, хлебные крошки, карточки, пагинация и контекстные ссылки ведут на финальные URL.
• Важные страницы не стали сиротами.

Технические сигналы

• Приоритетные страницы возвращают ожидаемые HTTP-статусы.
• Robots meta, X-Robots-Tag и robots.txt не закрывают production.
• Canonical указывает на утвержденную основную версию.
• Title, Description и H1 заполнены по странице, а не одним общим шаблоном.
• Структурированные данные совпадают с видимым содержанием.
• В Sitemap нет тестовых, удаленных или неканонических URL.

Мобильность и производительность

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

Бизнес-приемка

• Формы, телефон и мессенджеры проходят контролируемый тест.
• События аналитики и источник обращения сохраняются.
• Назначены ответственные за технические, поисковые и бизнес-показатели.
• Зафиксированы блокеры запуска, допустимые отклонения и условия отката.
• Сохранена предыдущая рабочая версия и понятен способ возврата.

Следующий шаг: соберите одну матрицу для бизнеса и команды

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