Редизайн часто обсуждают как набор экранов: новая сетка, типографика, карточки и меню. Для поискового трафика внешний вид вторичен. Риски появляются там, где одновременно меняются URL, внутренняя перелинковка, HTML шаблонов, скорость ответа и доступность контента для робота. Если эти зависимости не зафиксировать до разработки, SEO-специалист подключается уже к собранному стенду и вынужден выбирать между переносом релиза и исправлениями после потери данных. Хорошие SEO-требования заранее описывают наблюдаемый результат: какие страницы должны сохраниться, какой ответ обязан возвращать каждый тип URL, где формируются метатеги и чем команда подтвердит готовность релиза.
Начните с границ редизайна
Сначала отделите визуальные изменения от структурных. Замена CSS и компонентов при неизменных URL несёт один набор рисков. Пересборка каталога, перенос разделов и смена платформы — другой. В коротком паспорте проекта перечислите:
- какие домены, поддомены и языковые версии входят в релиз;
- меняются ли адреса страниц и правила формирования параметров;
- какие шаблоны будут переписаны;
- останется ли серверный HTML или часть содержания появится только после выполнения JavaScript;
- затрагиваются ли аналитика, формы, поиск по сайту и личный кабинет;
- кто принимает каждый блок и кто может остановить публикацию.
Такой паспорт не заменяет техническое задание. Он не даёт незаметно расширить задачу: например, добавить к новому дизайну реорганизацию каталога за неделю до запуска. Если меняется структура, заранее подготовьте карту старых и новых адресов; базовые принципы разобраны в материале о структуре сайта и URL.
Зафиксируйте исходное состояние сайта
Требование «сохранить всё как было» невозможно проверить, пока нет снимка исходной версии. До разработки выгрузите индексируемые URL из нескольких источников: sitemap, обход сайта, отчёты поисковых систем, аналитику и серверные журналы, если они доступны. Источники пересекаются не полностью. Страница может приносить переходы, хотя её уже нет в sitemap, или оставаться в карте сайта, не имея внутренних ссылок.
Для приоритетных адресов сохраните код ответа, итоговый URL после переходов, title, description, canonical, robots, H1, основные текстовые блоки и число внутренних входящих ссылок. Отдельно отметьте страницы с органическими входами, внешними ссылками, заявками и продажами. Эти данные превращаются в эталон для сравнения со стендом.
Не стремитесь сохранить каждую техническую особенность старого сайта. Дубли, цепочки перенаправлений и пустые страницы переносить не нужно. Их судьбу согласуют отдельно, чтобы исправление старой ошибки не выглядело как случайная потеря URL.
Опишите требования через матрицу шаблонов
Проверять тысячи адресов вручную нерационально, но принять только главную страницу ещё опаснее. Составьте матрицу типов: главная, раздел, листинг, карточка, статья, служебная страница, результаты фильтра, пагинация, локализованная версия. Для каждого типа выберите несколько URL, включая крайние состояния — пустую категорию, карточку без изображения, длинный заголовок, вторую страницу списка.
В строках матрицы полезно закрепить конкретные признаки:
| Область | Проверяемое требование |
|---|---|
| Ответ сервера | Рабочая страница возвращает 200, удалённая — согласованный 404 или 410 |
| Индексация | robots и canonical соответствуют назначению шаблона |
| Содержание | Основной текст и ключевые ссылки присутствуют в полученном HTML |
| Заголовки | Один содержательный H1, логичная вложенность последующих уровней |
| Медиа | У информативных изображений есть осмысленный alt, размеры заданы |
| Навигация | Хлебные крошки и ссылки работают без зависимости от указателя мыши |
Матрица нужна и дизайнеру: она заранее показывает, какие элементы нельзя удалить ради чистого макета. Например, исчезновение ссылок пагинации может отрезать роботу путь к товарам, а одинаковый заголовок карточек лишит страницы различимых сигналов.
Установите правила для URL и перенаправлений
Лучший сценарий редизайна — сохранить адреса ценных страниц. Когда это невозможно, каждому старому URL назначают один наиболее близкий новый адрес и постоянное перенаправление. Массовый перевод всех удалённых страниц на главную скрывает проблему от пользователя, но не сохраняет смысл исходных документов.
В требованиях должны быть отдельно описаны регистр, завершающий слеш, www, HTTP/HTTPS, параметры сортировки и фильтрации. Для каждого варианта задают единственный канонический вид. Переход от старого адреса к итоговому должен происходить за один шаг; цепочки усложняют диагностику и создают лишние запросы. Перед реализацией команде пригодится руководство по проверке редиректов.
Храните карту перенаправлений как версионируемый артефакт со старым URL, новым URL, причиной решения, ожидаемым кодом и статусом проверки. Сообщение в чате не даёт такого контроля. Исключения согласуются с владельцем контента: некоторые страницы правильнее вернуть как удалённые, чем вести на формально похожий, но бесполезный раздел.
Защитите рендеринг, метаданные и разметку
Новый интерфейс может выглядеть корректно в браузере и при этом отдавать роботу пустой каркас. Поэтому отдельно укажите, что основной контент, навигационные ссылки, title, description, canonical и необходимые директивы должны быть доступны в первоначальном HTML либо в проверяемой схеме рендеринга, принятой командой. Это особенно существенно при переходе на клиентское приложение.
Метаданные задаются на уровне шаблонов, но проверяются на конкретных страницах. Нужно предусмотреть уникальные значения, корректное экранирование, обработку отсутствующих полей и длину, которая не ломает интерфейс редактора. Не копируйте старые ошибки автоматически: дубли title сначала классифицируют, затем решают, какие из них являются дефектом.
Если используется структурированная разметка, требования должны ссылаться на видимые сущности страницы. Новый дизайн способен удалить цену, автора или хлебные крошки, хотя JSON-LD продолжит заявлять их наличие. Проверяйте разметку вместе с отображаемым содержанием; изолированная проверка фрагмента кода пропустит расхождение.
Включите производительность в критерии приёмки
Слово «быстро» непригодно для приёмки. Зафиксируйте среду измерения, набор страниц, состояние кэша и метрики, с которыми сравнивается новый вариант. Лабораторный тест удобен для повторяемости, полевые данные — для оценки реального опыта; они решают разные задачи. При редизайне особенно следят за крупными изображениями первого экрана, подключением шрифтов, ростом JavaScript и сдвигами макета.
Не назначайте разработчику произвольную цифру без исходной базы и понимания инфраструктуры. Практичнее задать запрет на заметную регрессию по согласованному сценарию и отдельные бюджеты для ресурсов: размер начальной загрузки, число шрифтов, вес изображений. Причины и способы диагностики метрик подробно разобраны в руководстве по Core Web Vitals.
Тестировать следует не только главную. Тяжёлая карточка с галереей, длинный листинг и статья с встраиваемым видео обычно ближе к реальным ограничениям шаблонов.
Проведите двухэтапную приёмку
Первый этап проходит на стенде. Его нельзя закрывать от поисковых роботов способами, которые попадут на боевой сайт по ошибке. Команда обходит согласованный набор URL, сравнивает эталонные поля, проверяет мобильное представление, ссылки, статусы, карту перенаправлений и аналитические события. Найденные дефекты фиксируют с URL, ожидаемым и фактическим результатом.
Второй этап начинается сразу после публикации. На боевом домене повторяют критический набор: главная, ключевые разделы, карточки, формы, robots.txt, sitemap, редиректы и канонические адреса. Затем запускают расширенный обход и сравнивают его с исходным снимком. Проверка после релиза обязательна, потому что конфигурация CDN, прокси, переменные окружения и правила веб-сервера на стенде могут отличаться.
Для независимого контрольного снимка можно использовать полную проверку сайта reChecker. Решение о выпуске опирайте на матрицу критичных страниц и бизнес-сценариев: автоматический отчёт служит одним из источников данных для неё.
Закрепите владельца и доказательство
Документ готов к работе, когда у каждого пункта есть ответственный, срок проверки и понятный артефакт: выгрузка, снимок HTML, результат обхода, таблица перенаправлений или протокол ручного сценария. Формулировка считается слабой, если два участника могут по-разному решить, выполнена ли она.
К плану релиза приложите четыре артефакта: исходный список ценных URL, матрицу шаблонов, карту перенаправлений и протокол проверок стенда. В каждой строке укажите владельца и доказательство выполнения. Этот комплект одинаково читается дизайнером, разработчиком, редактором и человеком, который принимает решение о запуске.