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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Постоянный серверный редирект сообщает о переносе ресурса. Google поддерживает, в частности, статусы 301 и 308. Важно проверить не только статус, но и назначение: посетитель должен получить соответствующую страницу. Документация Google о перенаправлениях (откроется в новой вкладке).

Пример для точного пути в Nginx:

location = /goods/rack-a/ {
 return 301 /catalog/rack-a/;
}

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

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

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

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

Для целевых страниц посмотрите title, основной заголовок, содержание, canonical и ограничения индексации. Сравните видимую страницу с тем, что доступно в ее HTML и инструментах проверки поисковой системы.

Пример для новой основной страницы:

<link rel="canonical" href="https://example.ru/catalog/rack-a/">

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

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

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

На страницах, предназначенных для поиска, случайный noindex необходимо убрать. При этом правило в robots.txt и запрет индексации решают разные задачи: если робот не может обойти URL, он может не увидеть noindex. Как работает noindex в Google (откроется в новой вкладке).

Не делайте вывод по одному тегу. Целевая страница должна открываться, содержать нужный материал и не попадать под непредусмотренные ограничения на уровне сервера или CMS.

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

Отдельно проверьте поиск по сайту и фильтры, если они участвуют в выборе товара. Часто команда внимательно принимает карточку, но не пробует найти ее обычным покупательским маршрутом.

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

У релиза должен быть ответственный за решение о старте и человек, который координирует исправления. Список участников лучше записать заранее: разработчик, SEO-специалист, аналитик и представитель бизнеса.

Пример плана запуска:

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

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

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

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

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

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

В новой карте сайта должны находиться выбранные канонические URL. Sitemap помогает обнаруживать страницы, но не гарантирует их индексацию. Проверьте, что он доступен и соответствует рабочему сайту. Документация Google по sitemap (откроется в новой вкладке).

При смене домена используйте соответствующие инструменты переезда поисковых систем. Для Яндекса условия описаны в справке Вебмастера (откроется в новой вкладке). Смена оформления на прежних адресах сама по себе не является переездом на другой домен.

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

После изменения адресов трафик может перераспределяться между старыми и новыми URL. Смотрите связанные пары и группы страниц. Если сравнивать только старый адрес, его снижение легко принять за потерю всего направления.

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

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

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

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

Редиректы не стоит отключать сразу после появления новых URL в поиске. Google рекомендует сохранять их длительно, как правило не менее года; для посетителей старые ссылки могут оставаться полезными и дольше. Рекомендации по сроку сохранения перенаправлений (откроется в новой вкладке).

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

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

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

Обсудите проверку сайта с ЭНТЕРНО. Укажите текущий этап проекта и предполагаемую дату запуска: это поможет выбрать проверки, которые еще можно выполнить до переноса.