За двенадцать лет через меня прошло около тридцати запущенных сайтов и сервисов, и контентные порталы всегда стояли особняком. Если интернет-магазин можно перезапустить с относительно небольшими потерями в две недели, то портал с многолетним органическим трафиком требует хирургической аккуратности. Редизайн здесь — это не про «сделать красивее». Это управляемый перенос накопленного контента, сохранение поискового трафика, неубитые пользовательские сценарии и понятная редакции платформа для дальнейшего роста. Побеждает не тот, кто быстрее рисует макеты, а тот, кто раньше считает риски, структуру и влияние на SEO.
Помню свой ранний проект, где мы за две недели перерисовали весь портал, не проверив карту редиректов. Закономерный результат — минус 40% трафика через месяц после запуска. С тех пор я перестал считать редизайн вопросом визуала. Это инженерная задача с конкретными метриками успеха.
Когда редизайн действительно нужен
Переезд на новый движок обычно инициируют не из эстетических соображений. На практике список причин звучит предельно утилитарно:
- сайт сложно и дорого поддерживать;
- редакция страдает от неудобной админки;
- текущая CMS не позволяет развивать структуру;
- медленно работают шаблоны и публикация материалов;
- накопились технические ограничения по SEO и аналитике;
- портал вырос, а архитектура осталась на уровне «сделали как получилось».
Когда проект действительно перерос свою платформу — редизайн и смена движка оправданы и чаще всего необходимы. Но пропорция здесь прямая: чем больше у портала органического трафика, тем выше цена ошибки. Если на кону десятки тысяч визитов в месяц, ставка повышается многократно. Мой принцип такой: если страница приносит хотя бы один переход в сутки, она должна пережить миграцию без потерь.
Чем редизайн отличается от переезда на новый движок
На собеседованиях я часто задаю проджект-менеджерам простой вопрос: «Ты понимаешь разницу между редизайном и переездом на новый движок?» К сожалению, далеко не все различают эти сценарии. А разница принципиальная — и по рискам, и по объёму работ, и по бюджету.
| Сценарий | Что меняется | Риски |
|---|---|---|
| Только редизайн | Визуальная часть, компоненты, верстка | Можно сохранить URL, структуру и SEO-сигналы почти без потерь |
| Редизайн + новый движок | Интерфейс, шаблоны, логика, админка, иногда структура сайта | Выше риск потери трафика, индексации и накопленных метрик |
| Полная миграция портала | Дизайн, CMS, структура разделов, URL, контентные связи | Нужен полноценный миграционный план и жесткий контроль запуска |
Если меняется только внешний слой — управляемая история. Но когда вместе с интерфейсом переезжает вся контентная система, SEO- и аналитические настройки необходимо проверять как на полностью новом продукте, а не как на «обновлении сайта». Это уже не косметический ремонт, а переезд офиса — и относиться нужно соответственно.
С чего начинается проект: не с дизайна, а с аудита
Успешный запуск всегда начинается с инвентаризации. Мы фиксируем картину того, что уже работает, до того как кто-либо откроет графический редактор. Это скучно, долго, не вдохновляет — и именно поэтому многие предпочитают пропускать этот этап и сразу «рисовать красиво». А потом мы получаем проект, где забыли три сотни старых URL из поиска Яндекса.
Что обязательно собрать до старта
- полный список всех URL;
- страницы, которые дают органический трафик;
- страницы с входящими ссылками;
- самые конверсионные материалы и разделы;
- шаблоны страниц и их различия;
- текущие title, description, H1, canonical;
- карту внутренней перелинковки;
- структуру рубрик, тегов и фильтров;
- показатели скорости и Core Web Vitals;
- список форм, событий и целей аналитики.
Без такого первичного аудита новый портал практически всегда стартует с потерями: что-то забыли, что-то не перенесли, что-то случайно закрыли от индексации. И самое неприятное — потери эти зачастую обнаруживаются не в день запуска, а через недели, когда позиции уже ползут вниз, а восстановление занимает месяцы.
Практический принцип
За годы я сформулировал для себя простое правило, которое выручало на самых сложных миграциях: если страница приносит трафик, ссылки или заявки, она должна иметь в новой версии:
- понятный новый адрес;
- корректный редирект;
- сохраненный смысл;
- актуальные метаданные;
- рабочие внутренние ссылки;
- не хуже, чем раньше, поведенческий сценарий.
Это минимальный набор, и он не обсуждается. Удалить страницу с трафиком без эквивалентной замены — это всегда дорогое удовольствие.
Архитектура нового контентного портала
Наблюдал десятки раз одну и ту же картину: заказчик убеждён, что если «красиво упаковать» старую хаотичную структуру, всё волшебным образом начнёт работать. Не начнёт. На контентном портале структура важнее любого декора. Внешний вид можно поправить итерациями, а кривая архитектура останется с вами надолго.
Что нужно спроектировать заранее
- главную страницу и ее роль;
- рубрики и подрубрики;
- карточки материалов;
- страницы авторов;
- теги и тематические подборки;
- служебные страницы;
- страницы поиска и фильтрации;
- сценарии возврата пользователя к контенту.
Хорошая структура отвечает на один простой вопрос: как человек за 2–3 клика попадет из общей темы в нужный материал и дальше — в связанный контент. Если навигация превращается в лабиринт, пользователь просто уйдёт искать информацию в другом месте.
На что смотреть особенно внимательно
- не плодить дубли разделов;
- не создавать слишком глубокую вложенность;
- не делать теги вместо нормальной рубрикации;
- не смешивать редакционную логику и SEO-логику;
- не превращать фильтры в индексируемый мусор.
Последний пункт регулярно становится головной болью на проектах. Фильтры с уникальными URL, которые не закрыты от индексации, множатся как кролики, создавая сотни дублей. Поисковик видит мусор, тратит краулинговый бюджет и начинает хуже ранжировать действительно важные страницы. Решение простое: фильтры должны быть либо через JavaScript без отдельных URL, либо закрыты через robots.txt и noindex.
Как подготовить редиректы без потери трафика
Редиректы — это страховка всей миграции, а не техническая формальность в бэклоге разработчика. В одном из проектов я потратил три полных рабочих дня только на выверку сопоставления старых и новых URL, и это было лучшее вложение времени. Каждый старый адрес должен получить понятный новый URL или осознанное решение о его удалении с пониманием последствий.
Базовый принцип
Для каждой старой страницы должно быть принято одно из трех решений:
- перенести на аналогичную страницу;
- объединить с другой страницей;
- закрыть и вернуть 404/410, если материал больше не нужен.
Таблица редиректов должна отвечать на вопросы
| Старый URL | Новый URL | Тип решения | Комментарий |
|---|---|---|---|
| Статья | Новая статья | 301 | Сохраняется смысл и трафик |
| Устаревший дубль | Каноническая версия | 301 | Убирается дублирование |
| Удаленная страница | Нет аналога | 410 или 404 | Если контент неактуален и замены нет |
Такая таблица должна быть не наброском на листочке, а полноценным документом, по которому разработчики настраивают серверные правила. И обязательно проверяется на стенде.
Типовые ошибки
- массовый редирект всех страниц на главную;
- редирект на раздел вместо точного аналога;
- цепочки редиректов;
- петли редиректов;
- забытые старые URL из фильтров, тегов и пагинации.
Если карта редиректов не протестирована до запуска, проблемы найдутся уже в поиске — и обычно не сразу, а через недели. А исправлять редиректы на живом портале намного больнее, чем на тестовом сервере.
Что нельзя потерять при переносе контента
Контентный портал живёт не только текстами. Внутри страниц упаковано множество сигналов, которые поисковики и пользователи используют для оценки качества. Это как переезд не с тремя чемоданами, а с целым складом вещей, и потеря даже одной коробки может аукнуться.
Обязательные элементы переноса
- заголовки H1–H3;
- title и description;
- основной текст;
- списки и таблицы;
- изображения и alt;
- хлебные крошки;
- внутренние ссылки;
- микроразметку;
- даты публикации и обновления;
- блоки автора и редакции.
Часто забывают
- ссылки на связанные материалы;
- карточки из подборок;
- данные авторов;
- блоки «похожие статьи»;
- FAQ-разметку;
- Open Graph для соцсетей;
- шаблоны пагинации;
- параметры сортировки.
Пропуск даже вроде бы незначительной детали — например, alt-тегов у изображений или разметки «хлебных крошек» — больно бьёт по длинному хвосту запросов. А именно он часто даёт порталу до половины общего поискового трафика.
Чек-лист перед запуском
Ни один запуск за мою практику не прошёл идеально с первого раза. Но хороший чек-лист превращает катастрофу в управляемую ситуацию с коротким временем восстановления. Проверяю всегда по трём направлениям: SEO, контент, аналитика с бизнес-логикой — и добавляю технический блок.
SEO и индексация
- все важные страницы открываются без ошибок;
- canonical указывает на правильные URL;
- robots.txt не закрывает нужные разделы;
- sitemap.xml актуален;
- 301-редиректы работают корректно;
- нет дублей с www/без www, http/https;
- нет случайных noindex на ключевых страницах.
Контент
- заголовки перенесены без искажений;
- тексты не обрезались;
- изображения не потерялись;
- ссылки внутри текстов рабочие;
- блоки автора и даты отображаются корректно;
- страницы рубрик и тегов наполнены осмысленно.
Аналитика и бизнес-логика
- подключены счетчики;
- настроены цели и события;
- формы отправляют данные;
- заявки приходят туда, куда нужно;
- e-commerce или CRM-интеграции не сломаны;
- фильтры и поиск измеряются отдельно.
Техническая часть
- сайт корректно работает на мобильных;
- скорость загрузки приемлема;
- нет критических ошибок в консоли;
- формы и всплывающие элементы не конфликтуют;
- шаблоны одинаково работают в популярных браузерах.
Практический совет: не поручайте проверку одному человеку. Отдайте чек-лист разработчику, редактору, SEO-специалисту и менеджеру — каждый заметит то, что пропустили остальные.
Пошаговый план запуска
Ниже — проверенная последовательность, которая работала на разных по масштабу порталах. Нарушение порядка или пропуск любого шага неизбежно аукнется.
Шаг 1. Зафиксировать базу
Снять текущие показатели: трафик, позиции, конверсии, поведенческие метрики, список ключевых страниц. Без этого вы не сможете понять, ухудшилось или улучшилось.
Шаг 2. Собрать структуру
Утвердить новую карту разделов, шаблонов и сценариев навигации. Здесь нужны не прототипы на салфетке, а задокументированная схема, по которой будут работать дизайнеры и разработчики.
Шаг 3. Подготовить миграцию
Перенести контент, настроить метаданные, внутренние ссылки, редиректы и шаблоны. Ручной перенос — зло; лучше написать парсер и проверять выгрузку чеклистами.
Шаг 4. Протестировать на стенде
Проверить не отдельные страницы, а все типовые сценарии: чтение, поиск, фильтрация, формы, авторизация, комментарии, сохранение материалов. Однажды тестирование на стенде вскрыло, что форма обратной связи отправляла данные на старый движок, а новый ничего не получал.
Шаг 5. Запустить в спокойный период
Не стоит выпускать новый портал одновременно с рекламной кампанией, редизайном лендингов и другими рисковыми изменениями. Идеально — спокойный вторник или среда в начале месяца, когда можно наблюдать за поведением минимум два дня без выходных перерывов.
Шаг 6. Сразу проверить после запуска
Сверить редиректы, индексацию, sitemap, роботов, аналитику и критические шаблоны. Первый час на бою — самый важный для обнаружения очевидных провалов.
Шаг 7. Наблюдать 2–6 недель
В этот период обычно всплывают проблемы с дублями, логикой фильтров, внутренними ссылками и просевшими страницами. Обязательно ставьте еженедельные контрольные точки.
Как понять, что запуск прошел успешно
Первые признаки удачной миграции:
- трафик просел незначительно или восстановился в короткий срок;
- ключевые страницы сохранили видимость;
- поисковики быстро переиндексировали новый сайт;
- редакция спокойно публикует материалы;
- пользователи не жалуются на сломанные сценарии;
- заявки и цели работают без провалов.
Если же вырос процент отказов, упали переходы из поиска и появились дубли — миграция прошла с нарушением логики контента или технической базы. Не паникуйте, а методично проходите по чек-листу. В большинстве случаев проблема лежит на поверхности: нерабочий редирект, закрытый от индексации раздел или потерянные метаданные.
Таблица: что важнее всего контролировать на каждом этапе
| Этап | Главный риск | Что проверить в первую очередь |
|---|---|---|
| До разработки | Потеря структуры и приоритетов | URL, трафик, редиректы, шаблоны |
| Во время дизайна | Красиво, но неудобно | Навигация, читабельность, сценарии |
| Перед запуском | Технические ошибки | Индексация, canonical, sitemap, формы |
| После запуска | Просадка SEO и аналитики | Редиректы, позиции, события, ошибки 404 |
Типовые ошибки, которые дорого обходятся
- перенос только внешнего вида без анализа структуры;
- отсутствие владельца контента и редиректов;
- запуск без стендового тестирования;
- игнорирование страниц, которые дают «длинный хвост» трафика;
- замена сложной структуры на слишком упрощенную;
- отсутствие контроля после запуска;
- попытка исправить все уже на боевом сайте.
Самая опасная ошибка — считать миграцию завершенной в день релиза. На деле именно после запуска начинается настоящая проверка качества. Я видел порталы, которые в день релиза выглядели идеально, а через месяц теряли треть органического трафика из-за незакрытых дублей фильтров и потерянных canonical.
FAQ
Нужно ли сохранять старые URL любой ценой?
Не любой. Но если страница даёт трафик или ссылки, лучше сохранить адрес или настроить точный 301-редирект. Если трафика нет, входящих ссылок нет — можно удалять без сожалений, но с пониманием того, что доступ к этой информации кому-то может быть нужен.
Можно ли одновременно менять дизайн, движок и структуру?
Можно, но это уже полноценная миграция с высоким риском. И чем больше изменений в одном релизе, тем важнее качественный предпроектный аудит и сквозное тестирование. Я бы советовал разбивать такие проекты на фазы, если это позволяет бизнес-контекст. Но реальность такова, что бюджеты и сроки часто вынуждают делать всё разом — тогда только дисциплина подготовки спасает.
Что важнее: SEO или удобство редакции?
На практике нужен баланс. Если редакция не сможет быстро и без ошибок публиковать материалы, портал не будет развиваться. Но если потерять SEO, новый движок не окупится. Хорошая админка и сохранённые позиции не должны быть конфликтующими целями — их можно и нужно достигать одновременно. В одном из проектов мы потратили существенное время на кастомный интерфейс публикации, и это окупилось: редакторы перестали допускать типовые SEO-ошибки просто потому, что админка не позволяла их совершить.
Когда лучше запускать редизайн контентного портала?
В период, когда можно спокойно отслеживать реакцию, быстро вносить правки и не мешать запуску другими маркетинговыми активностями. Категорически не рекомендую делать это в разгар сезона, во время крупных рекламных кампаний или акций.
Что делать, если после запуска упал трафик?
Сначала проверить редиректы, индексацию, robots.txt, canonical, изменение структуры и потерянные страницы. Часто проблема не одна, а сразу несколько — например, часть URL ведёт в никуда, robots.txt закрывает новый раздел, а метаданные на десятках материалов не заполнены. Методичная диагностика по чек-листу почти всегда находит корень проблемы.
Вывод
Редизайн контентного портала на новом движке — это в первую очередь управление рисками, а не обновление внешнего вида. За каждым успешным запуском стоит скучная предварительная работа: сбор данных, инвентаризация URL, проектирование структуры, подготовка редиректов, проверка каждого сценария и непрерывный мониторинг после переезда. Чем сложнее портал, тем важнее не скорость разработки, а качество подготовки и дисциплина на каждом шаге. Миграция не заканчивается в день релиза — она только начинается. И хороший управленец остаётся на связи с проектом ещё как минимум месяц, пока цифры не подтвердят: переезд прошёл без потерь.