Редизайн сайта: план SEO-миграции и чек-лист запуска
Как совместно спланировать инвентаризацию URL, 301-редиректы, canonical, перенос контента и измерение после запуска при редизайне сайта.
Редизайн сайта не заканчивается вводом нового дизайна в эксплуатацию. Посетитель из органического поиска должен по старой ссылке попасть на нужный контент, отдел продаж должен продолжать получать заявки, а система измерения — выдавать сравнимые данные. План SEO-миграции — это документ сдачи, переносящий ценные точки входа со старого сайта в новый опыт. Если дизайн, контент и техническая команда не работают по одному документу, красиво выглядящий сайт может незаметно потерять заявки.
Это руководство подготовлено для компаний, обновляющих корпоративный сайт, и маркетинговых команд, принимающих проект. Таблицы ниже — предлагаемые нами рабочие шаблоны; цифры на графиках — не показатели клиентов. Для перехода сразу к практике — таблица решений по URL или чек-лист приёмки перед запуском.
Решения из этого руководства
- Рассматривайте смену дизайна и смену URL как отдельные решения.
- В инвентаризации страниц учитывайте не только трафик, но и заявки, внешние ссылки и назначение контента.
- Для каждого старого URL примите решение: сохранить, перенести, объединить или удалить.
- Принимайте техническую приёмку не по главной странице, а по реальным путям посетителей.
- Отслеживайте проблемы после запуска по группам страниц и каналам.
Сначала определите объём редизайна
Визуальное обновление на том же домене, смена системы управления контентом и полная перестройка всего дерева URL — разные проекты. Когда всё это оценивается под одним заголовком «редизайн сайта», работа по миграции часто остаётся невидимой. В предложении должно быть явно указано, сколько страниц переносится, сколько языков есть, каков объём файлового архива и кто отвечает за редиректы.
Мы рекомендуем на стартовой встрече сформировать три отдельных списка: функции, которые сохраняются, контент, который меняется, и активы, которые технически переносятся. Например, новое описание услуги — это работа с контентом; связь старой формы заявки с CRM — функциональная зависимость; скачиваемый каталог — переносимый актив. Хранение их в одном списке задач не даёт спутать завершение дизайн-макетов с завершением проекта.
Если платформа ещё не выбрана, прочитайте сравнение Next.js и WordPress, а по объёму и этапам сдачи — процесс корпоративного веб-проекта. Выбор технологии не отменяет владения текущим контентом и плана переноса.
Стартовое измерение и инвентаризация страниц
Перед закрытием старого сайта зафиксируйте стартовые показатели. Не ограничивайте это только общим числом визитов. Какие страницы услуг генерируют заявки, какие статьи блога ведут к страницам продукта, какие PDF используются в разговорах с продажами? Низкий трафик страницы не означает, что она бесценна; технический документ с малым числом посещений может быть важен в решении о покупке.
Вместо того чтобы брать инвентаризацию из одного источника, объедините список CMS, текущий sitemap, посадочные страницы аналитики и ссылки, используемые отделом продаж. Назначьте ответственного на каждую строку. Ответ на вопрос «где новый аналог этой страницы?» не должен оставаться на усмотрение разработчика.
| Поле инвентаризации | Что указывается | Какое решение поддерживает |
|---|---|---|
| Старый URL | Полный адрес и язык | Сопоставление и тестирование |
| Назначение контента | Информация, услуга, документ | Подходящая новая цель |
| Ценность для бизнеса | Заявки, поддержка продаж, референс | Приоритет |
| Новый URL | Утверждённый итоговый адрес | Реализация переноса |
| Ответственный за решение | Контент или продуктовый владелец | Устранение неопределённости |
| Статус приёмки | Ожидает, пройдено, ошибка | Готовность к запуску |
Выбирайте стартовый период в соответствии с ритмом бизнеса. Сравнение недели кампании с обычным месяцем даёт ложную тревогу. Помимо недавнего периода, если есть, зафиксируйте и аналогичный период прошлого года. Если настройка измерения изменится, отметьте в отчёте, используют ли оба периода одни и те же определения.
Таблица решений по URL
Руководство Google по переносу сайта рекомендует сопоставлять старые и новые URL и настраивать постоянные редиректы на подходящие цели. Массовая отправка нерелевантных страниц на главную может рассматриваться как мягкая 404. Таблица ниже — предлагаемый нами шаблон перевода этих принципов в рабочий процесс проекта.
| Решение | Пример ситуации | Реализация | Вопрос приёмки |
|---|---|---|---|
| Сохранить | Назначение услуги не изменилось | Новый дизайн на том же URL | По-прежнему закрывает старую потребность? |
| Перенести | Страница перешла в новую категорию | 301 или 308 на новый аналог | Ведёт к нужному контенту за один шаг? |
| Объединить | Два слабых руководства стали одним полным | Редирект на общую подходящую цель | Старые темы есть в новом тексте? |
| Удалить | Контент, который больше не предлагается, без аналога | 404 или 410 | Пользователю предложен путь продолжения? |
Приведённые здесь примеры путей — шаблон проекта, а не реальные маршруты этого сайта: адрес /старая-услуга может быть перенесён на страницу /services/связанная-услуга. Но если старая страница описывает договор на обслуживание, направление на общую страницу «о нас» не имеет смысла. Сопоставление URL — не операция по схожести слов, а работа по сохранению потребности пользователя.
Открыть данные графика в виде таблицы
| Сохранить по тому же адресу | 72 URL |
|---|---|
| Перенести на новый адрес | 28 URL |
| Объединить в связанный контент | 14 URL |
| Удалить без аналога | 6 URL |
В этом примере для 72 страниц работы по редиректу не требуется; тем не менее нужен контроль контента и форм. Для каждого из остальных 48 URL есть отдельное решение о приёмке. Такое распределение делает видимым, что число реализуемых редиректов и общий объём тестирования — не одно и то же.
Перенос контента и сохранение поискового намерения
Риск, на который стоит обратить внимание при редизайне, — сокращение текстов лишь до размера, помещающегося в новые блоки. Когда теряются объём услуги, состав поставки и сценарии использования, страница может выглядеть чище, но вопросы читателя останутся без ответа. Поэтому для каждой важной страницы мы рекомендуем составлять список информации, которую нужно сохранить из старого текста.
Оценивайте список в трёх разделах: информация, необходимая для принятия решения, информация, уже не актуальная, и информация, которую можно рассказать лучше. Вопросы прежних клиентов помогают найти первую группу. Перенос устаревшей цены в новый дизайн — ошибка актуальности контента. Цель не в копировании всего текста как есть, а в том, чтобы не потерять в новой структуре всё ещё верный ответ.
В объединённых статьях проверяйте подзаголовки по отдельности. Объединение только вводных абзацев двух страниц не создаёт исчерпывающего руководства. В новом тексте должны присутствовать техническое описание, шаги реализации и ссылка на подходящую услугу. Наш подход к SEO и GEO-контенту рассматривает эту целостность темы вместе с контент-планом.
Проверяйте canonical и языковые ссылки вместе
Canonical указывает предпочтительный адрес среди одинакового или очень похожего контента; это не абсолютная команда, принудительно определяющая выбор поисковой системы. Если редиректы, внутренние ссылки и sitemap указывают на разные адреса, сигналы смешиваются. Подробности — в документации Google по canonical.
На практике выберите пример из каждой группы страниц и начните с вопроса «какой опубликованный адрес этой страницы является основным?». Остался ли домен тестовой среды в исходном коде, единообразно ли правило конечного слэша, не представляется ли отфильтрованная страница ошибочно как независимый контент? Результаты этих проверок стоит вносить не в отдельный файл, а в ту же запись приёмки, что и таблицу редиректов.
В многоязычных проектах единицей контроля является не только русская страница. Языковая группа одного и того же контента должна переноситься вместе. Не указывайте на несуществующий перевод; используйте новый адрес страницы, у которой есть аналог. Для языковой архитектуры отправной точкой служит наше руководство по hreflang и i18n.
Чек-лист приёмки перед запуском
Приёмка запуска должна быть конкретнее фразы «сайт открывается». Записывайте чек-лист ниже не устно на встрече, а с полями результата, даты и ответственного. Прикладывайте скриншот или HTTP-ответ неудачных тестов. Так одна и та же ошибка не будет пересказываться заново между командой контента и командой разработки.
- Откройте на мобильном и десктопе важные страницы, принимающие органический трафик; проверьте заголовок, основной контент и ссылки.
- Посетите примеры старых URL; убедитесь, что после редиректа открывается нужная страница.
- Проверьте заявку сквозным реальным сценарием; контролируйте не только сообщение интерфейса, но и запись на бэкенде.
- Убедитесь, что блокировки индексации тестовой среды не перенесены в конфигурацию продакшена.
- Проверьте, что новый sitemap, canonical и, если есть, языковые ссылки используют одни и те же опубликованные адреса.
- Проверьте изображения для шаринга, перенесённые документы и важные адреса изображений.
- Проверьте, что аналитические события генерируются в ожидаемый момент и ровно один раз.
- Заранее письменно определите, кто принимает решение при ошибке и какая версия будет восстановлена.
Включите структурированные данные в тот же процесс приёмки. Услуги, больше не предлагаемые, или устаревшая информация об авторе не должны оставаться в JSON-LD. Google требует, чтобы разметка точно отражала содержимое страницы; синтаксическая корректность сама по себе не гарантирует появление функции в поиске. Принципы структурированных данных объясняют это различие.
Как настроить наблюдение после запуска
Мы рекомендуем рассматривать наблюдение в двух отдельных представлениях: техническое здоровье и бизнес-результат. Техническое представление показывает ошибочные ответы, неработающие потоки и неверные цели. Бизнес-представление отслеживает визиты, квалифицированные заявки и встречи по соответствующей группе страниц. Одного общего графика трафика для объяснения этих двух областей недостаточно.
Открыть данные графика в виде таблицы
| Открытые находки | Находки, блокирующие запуск | |
|---|---|---|
| T−7 | 24 | 6 |
| T−3 | 12 | 3 |
| Запуск | 5 | 0 |
| T+3 | 2 | 0 |
| T+7 | 0 | 0 |
На графике проблемы, блокирующие запуск, закрываются до момента запуска, а пункты меньшей важности продолжают отслеживаться. Это плановый пример. В реальном проекте заранее определите понятие «блокирующий»: например, потеря заявки формой, переход важной страницы на неверный адрес или недоступность основного контента. Не держите разницу тона цвета и потерю заявки на одном уровне приоритета.
Настройку измерения заявок мы подробно рассматриваем в руководстве по странице сбора B2B-заявок. Если число после запуска падает, сначала проверьте, работает ли измерение, затем источник трафика, затем опыт страницы. Такой порядок предотвращает предположение, что любое падение вызвано дизайном.
Решение об откате при возникновении проблемы
План отката — не только хранение старых файлов. Нужно определить, где хранятся заявки, созданные в новой системе, как откатывать изменения DNS или редиректов и как согласовывать старую версию с новыми записями. Особенно если данные форм будут разделены между двумя системами, требуется согласие ответственного за операции.
Не каждая ошибка требует отката всего сайта. Пока можно исправить одно правило редиректа, широкомасштабный откат может создать новые проблемы. Сначала оцените затронутый путь пользователя, распространённость проблемы и проверяемость исправления. Напротив, если потеря заявок продолжается, ждать только визуального исправления — неверный приоритет.
Что должно быть в файле сдачи проекта
При закрытии проекта вместе с адресом нового сайта нужно передать таблицу сопоставления URL, решения по контенту, результаты тестов, определения измерений и открытые пункты сопровождения. Человек, который будет разбирать проблему через месяц, должен иметь возможность работать, не зная, что обсуждалось в день запуска. С точки зрения бизнеса настоящая устойчивость начинается именно с этих документов.
Планируя редизайн с Piton Studios, вы можете поделиться текущим сайтом, приоритетными услугами и потоками, которые хотите сохранить. В рамках нашей услуги SEO и GEO мы можем обеспечить техническую видимость, а на встрече, начатой через страницу контактов, вместе оценить потребности переноса и сдачи.
Часто задаваемые вопросы
- Нужно ли менять URL при смене дизайна сайта?
- Нет. Если тема и назначение страницы сохраняются, сохранение текущего URL уменьшает объём миграции. Изменение URL должно опираться на конкретную причину — изменение информационной архитектуры, объединение контента или смену домена.
- Можно ли перенаправить каждую старую страницу на главную?
- Массовые нерелевантные редиректы — неверное решение. Старую страницу нужно направлять постоянным редиректом на новую страницу, закрывающую ту же потребность. Для удалённого контента без подходящего аналога рассматривайте ответ 404 или 410.
- Можно ли гарантировать отсутствие потери трафика после редизайна?
- Нет. Повторная обработка изменений поисковыми системами и одновременные колебания рынка могут создавать волатильность. Цель плана миграции — снизить число предотвратимых технических ошибок, быстрее найти место потери и сократить время исправления.
- 301-редирект и canonical — это одно и то же?
- Нет. Редирект переносит браузер на другой URL; canonical указывает предпочтительный URL среди одинакового или очень похожего контента. Тег canonical не может заменить редирект для удалённой страницы.
- Достаточно ли в день запуска проверить только главную страницу?
- Нет. Отдельно нужно протестировать органические посадочные страницы, детали услуг, поток обращений, языковые версии и примеры старых URL. То, что открывается главная страница, не доказывает, что старые ссылки ведут на правильные страницы.