Перезапуск корпоративного сайта — это не косметический ремонт. Это операция на открытом сердце бизнеса, где любая ошибка конвертируется в упущенную выручку. По данным исследований, 60% редизайнов заканчиваются падением органического трафика в первые три месяца. Причина банальна: команды увлекаются новым дизайном и забывают, что сайт — это revenue-машина, а не холст для творчества.
Лорен Беккер, VP of Marketing в Box.com, столкнулась с кошмаром любого маркетолога. Сайт компании стоимостью в миллиарды долларов был построен на Drupal 7. Звучит нормально? Вот нюанс: весь контент был захардкожен в текстовые поля агентством, которое аутсорсило работу другому агентству. Чтобы обновить один логотип клиента, требовалось две недели и инженер, отвлечённый от продукта.
Команда получила задачу: полный редизайн 11 сайтов (основной плюс 7 существующих локализаций плюс 3 новых рынка), миграция на Drupal 8, переписывание 120 страниц контента, новый дизайн, новая архитектура. Дедлайн — пять месяцев. Результат — рост pipeline и revenue на 30% за полгода, снижение bounce rate на 10 процентных пунктов. Это не магия. Это методология.
ТОП-инструменты для мониторинга и оптимизации сайта при редизайне
Перед запуском и после редизайна критически важно отслеживать позиции, поведенческие факторы и техническое состояние сайта. Вот сервисы, которые решают эти задачи:
- SeoPapa — улучшение поведенческих факторов в Яндексе, что особенно актуально после редизайна, когда алгоритмы заново оценивают пользовательские сигналы
- Топвизор — мониторинг позиций по всем поисковикам и регионам, отслеживание динамики после запуска
- Rush Analytics — кластеризация семантики и отслеживание видимости
- PR-CY — комплексный аудит технических ошибок, которые часто появляются при миграции
- Labrika — автоматический поиск SEO-проблем и рекомендации по исправлению
Урок 1: Чётко сформулируй, зачем ты это делаешь
Редизайн ради редизайна — это дорогое развлечение без гарантированного результата. Прежде чем писать первую строчку кода или открывать Figma, ответь на вопрос: какую бизнес-проблему мы решаем?
В случае Box проблема была конкретной и измеримой. Маркетинговая команда научилась работать «вокруг сайта», а не «через сайт». Создавались лендинги на сторонних платформах, потому что обновить что-то на основном сайте было слишком долго и сложно. Сайт перестал быть центром лидогенерации — он превратился в музейный экспонат.
Сайт — это лицо компании и главный источник revenue. Если твоя команда работает в обход сайта, у тебя нет сайта.
Формулировка «почему» для Box выглядела так:
- Невозможно масштабировать бизнес, когда обновление одного логотипа занимает две недели
- Сайт должен приносить больше денег — конкретно, увеличить вклад в pipeline на 30%
- Маркетологи должны иметь возможность обновлять контент самостоятельно, без инженеров
Эта ясность определила все последующие решения. Когда возникал вопрос «а нужна ли нам эта фича?», ответ искали в контексте этих трёх пунктов.
Урок 2: Определи измеримые цели до старта работ
Цель редизайна — не запустить новый сайт. Цель — достичь конкретных бизнес-результатов. Это не семантика, это фундаментальный сдвиг в мышлении.
Команда Box зафиксировала три метрики:
Увеличение pipeline и revenue на 30% в течение шести месяцев после запуска. Не просто «улучшить конверсию», а конкретная цифра с дедлайном. Это сразу отсекает бесконечные дискуссии о «ещё одной итерации дизайна» — либо изменение двигает к цели, либо нет.
Снижение bounce rate на 10 процентных пунктов. Старый сайт имел высокий показатель отказов. Новая архитектура и контент должны были удерживать посетителей.
Рост engagement: время на сайте, глубина просмотра, взаимодействие с видео. Старая архитектура вообще не позволяла встраивать видео. А у компании были потрясающие кейсы клиентов, которые никто не видел.
Обрати внимание: метрики выбраны так, чтобы их можно было отслеживать, и чтобы они напрямую связывались с бизнес-результатами. «Сделать сайт красивее» — не метрика. «Увеличить конверсию в лиды на 30%» — метрика.
Урок 3: Собери правильную команду и убедись, что все понимают «зачем»
Проект такого масштаба требует людей из разных функций: инженеры, дизайнеры, копирайтеры, продуктовые маркетологи, проджект-менеджеры. Проблема в том, что эти люди обычно не работают вместе и у них разные приоритеты.
Команда Box столкнулась с интересной ситуацией. Копирайтер, которая написала весь контент для 120 страниц сайта, вышла на работу 3 января. У неё было семь дней, чтобы разобраться в продуктах, преимуществах и особенностях компании — и начать писать. Внешние разработчики Drupal сидели прямо в офисе вместе с командой. Проджект-менеджера одолжили у отдела продаж.
Критически важно было добиться эмоциональной вовлечённости каждого участника. Люди пришли на проект, потому что им сказали — не потому что они этого хотели. Этого недостаточно для проекта с нереальными дедлайнами.
«Дизайнер не должен думать, что он просто делает красивые страницы. Он должен понимать, что его работа напрямую влияет на то, как люди воспринимают продукт, покупают его, и в конечном счёте — как это меняет их бизнес. Некоторые клиенты буквально меняют свою индустрию благодаря нашему продукту.»
Этот подход называют «the power of why» — сила понимания «почему». Когда разработчик понимает, что его код не просто «работает», а приносит компании миллионы долларов и помогает клиентам трансформировать бизнес, отношение к работе меняется.
Урок 4: Вовлеки всю компанию, а не только проектную команду
Редизайн корпоративного сайта — это не проект маркетинга. Это проект всей компании. DevOps, продуктовая команда, HR, рекрутинг — все должны знать, что происходит и почему это важно.
Команда Box отправляла еженедельные апдейты руководству и ключевым стейкхолдерам. Не формальные отчёты, а реальный статус: на каком мы этапе, укладываемся ли в сроки, какая помощь нужна.
Зачем? Потому что каждый редизайн упирается в препятствия, которые проектная команда не может преодолеть самостоятельно. Может понадобиться срочное выделение инженерных ресурсов. Или юридическое согласование нового messaging. Или помощь с инфраструктурой.
Когда вся компания в курсе и понимает важность проекта, люди из других отделов сами предлагают помощь и быстро убирают блокеры. Когда проект существует в вакууме маркетинга — каждое согласование превращается в войну.
Урок 5: Сделай всю подготовительную работу до начала разработки
Самая частая ошибка — начать писать код или делать дизайн, не определив фундаментальные вещи. А потом переделывать половину работы, когда выясняется, что архитектура неправильная или контент пишется для не той аудитории.
Что нужно зафиксировать до старта:
Информационная архитектура. Какие страницы будут на сайте? Какая между ними связь? Как посетитель будет перемещаться от первого касания до конверсии?
Карта сайта и wireframes. Схематичное понимание каждой страницы: какие блоки, в каком порядке, какой контент.
Buyer personas. Для кого мы пишем? Какие у этих людей боли, вопросы, возражения? Box — enterprise-компания с multi-product предложением. Сайт должен был говорить на языке разных типов покупателей.
Контентная стратегия. Какой контент уже есть и что с ним делать — переписывать, удалять, объединять? Какой контент нужно создать с нуля?
Технические решения. Хостинг — внутренний или внешний? CMS — Drupal 7 или 8? Эти решения должны быть приняты до старта, а не в процессе.
Нет ничего хуже, чем обнаружить на полпути, что ты пишешь контент для неправильной аудитории или строишь архитектуру, которая не масштабируется.
Урок 6: Раздели изменения фронтенда и бэкенда
Это, пожалуй, самый важный тактический совет из всего опыта Box. Лорен Беккер формулирует его прямо: если ты делаешь фронтенд и бэкенд одновременно — это будет худший опыт в твоей карьере.
Почему? Когда ты меняешь всё сразу, невозможно изолировать проблемы. Страница ломается — это из-за нового дизайна, нового кода или проблем с инфраструктурой? Контент не отображается правильно — это CSS, JavaScript или бэкенд? Дебаг превращается в ад.
Правильная последовательность: сначала бэкенд, потом фронтенд.
Даже если ты знаешь, что весь дизайн и весь контент будут другими — сначала разберись с инфраструктурой. Мигрируй на новую CMS. Почини все технические проблемы. Убедись, что платформа стабильна.
Да, это кажется «выброшенной работой» — ты строишь модули для контента, который скоро заменишь. Но на практике это экономит огромное количество времени. Ты находишь проблемы с отступами, spacing, load balancing на старом контенте, который тебе знаком. И когда приходит время накатывать новый дизайн — платформа уже работает как часы.
Руководство всегда будет давить, чтобы делать всё одновременно. Это понятно — им нужен результат быстрее. Но твоя задача как специалиста — объяснить, почему последовательный подход в итоге быстрее и безопаснее.
Урок 7: Посади команду вместе
Звучит банально в эпоху удалённой работы, но физическое расположение команды критически влияет на скорость.
В Box ситуация была типичной для крупных компаний: инженеры сидели на третьем этаже в одном углу, дизайнеры — на третьем этаже в другом углу, копирайтеры — на шестом этаже, продуктовые маркетологи — в противоположном конце шестого этажа, проджект-менеджер — на пятом этаже в отделе продаж. Максимально далеко друг от друга, оставаясь в одном здании.
При таком расположении взаимодействие происходило раз в неделю на статус-митингах. Всё двигалось водопадом: дизайнер сделал макет, передал разработчику, разработчик сделал, передал копирайтеру, и так далее. Медленно. Много потерянного контекста. Много переделок.
Решение — собрать всех в одну комнату. Буквально. Когда у копирайтера возник вопрос по дизайну, она повернулась и спросила дизайнера. Когда дизайнер увидел, что его решение не работает технически, инженер тут же объяснил ограничения.
Slack помогает, но не заменяет физическое присутствие для сложных проектов с жёсткими дедлайнами и множеством зависимостей между участниками.
Урок 8: Тестируй на малом количестве страниц перед масштабированием
Соблазн огромен: у нас готовы дизайн, контент, код — давайте выкатим всё сразу. Не делай этого.
Команда Box совершила классическую ошибку. Они работали параллельно: инженеры строили инфраструктуру и модули, дизайнеры создавали систему компонентов, копирайтер писала контент для 120 страниц на основе спецификаций модулей.
Каждый элемент в изоляции был одобрен. Дизайн — утверждён. Контент — утверждён. Код — работает. А потом они собрались на восьмичасовой хакатон, чтобы собрать всё вместе и создать 120 страниц за одну ночь. Виски было много. Энтузиазма тоже. Результат... сравнили с антилопой гну.
«Знаете эту шутку на сафари про гну? Кто-то решил: хочу быстрое животное — дам ему ноги как у лошади. Хочу камуфляж — дам полоски как у зебры. Хочу агрессию — дам рога как у быка. Собрали вместе — получилось самое уродливое животное в Африке. Каждый элемент по отдельности имел смысл.»
То же самое произошло с сайтом. Дизайн модулей выглядел отлично в изоляции. Контент читался хорошо в документе. Но когда реальный контент лёг в реальный дизайн на реальной странице — результат был ужасным.
Правильный подход: собрать 5-10 страниц, посмотреть как всё работает вместе, исправить проблемы, и только потом масштабировать.
Урок 9: Используй поэтапный rollout с процентами трафика
Это золотой стандарт, который почему-то игнорирует большинство компаний. Вместо того чтобы «щёлкнуть выключателем» и запустить новый сайт для всех сразу, Box использовала методологию поэтапного развёртывания.
Этап 1: 1% трафика, три дня.
Цель — поиск багов. На этом этапе не собирается статистика, не делаются выводы о конверсии. Только проверка: все ли страницы открываются? Работают ли формы? Нет ли 404-ошибок? Корректно ли отображается контент на всех устройствах?
С реальным трафиком находишь то, что никогда не поймаешь на тестовом окружении.
Этап 2: 10% трафика, около трёх дней.
Цель — направленный анализ. Статистика ещё не статистически значима, но уже видны паттерны. Если pricing page показывает странное поведение — пора разбираться. На этом этапе сравниваются старая и новая версии бок о бок, привлекаются реальные клиенты для качественной обратной связи.
Этап 3: 25% трафика, около пяти рабочих дней.
Цель — выявление дополнительных проблем и быстрая адаптация перед полноценным A/B-тестом.
Этап 4: 50% трафика до достижения статистической значимости.
Полноценный сплит-тест. Старый сайт против нового. Чистые данные, на основе которых можно принимать решения.
Команда Box обнаружила на 25% трафика, что bounce rate взлетел до 80%. Все были в шоке — четыре месяца работы ради худшего сайта в мире? Оказалось, аналитики забыли исключить логины в продукт из данных. Урок: проверяй данные дважды, особенно когда они не имеют смысла.
Урок 10: Не недооценивай международный rollout
Если у тебя несколько языковых версий сайта — умножай оценку трудозатрат минимум на три.
Box использовала Lingotek для автоматизации переводов. Но даже с автоматизацией, QA девяти языковых версий — это колоссальный объём работы. Каждую страницу нужно проверить в контексте. Автоматический перевод ловит 80% проблем, оставшиеся 20% — критичны.
Ещё один сюрприз: внешний хостинг-провайдер уверял, что часть сайта может работать на Drupal 7, а часть — на Drupal 8. Когда дошло до реального развёртывания, выяснилось, что это невозможно. Весь сайт должен был быть на одной версии. Планировавшийся шестинедельный rollout международных версий сжался до одной недели.
Япония оказалась отдельной историей. Другая бизнес-модель, другие ожидания пользователей, другие культурные нормы. Фактически — отдельный проект внутри проекта.
Урок 11: Запуск — это день первый, а не финал
Самая опасная ментальная ловушка — думать, что с запуском нового сайта работа закончена. На самом деле она только начинается.
У команды Box были чёткие метрики: +30% к pipeline, -10 процентных пунктов bounce rate, рост engagement. Достижение этих целей требовало постоянной работы после запуска:
- A/B-тестирование отдельных элементов
- Анализ воронок и точек отсева
- Итерации по контенту на основе данных
- Работа с feedback от sales-команды
Сайт — это продукт. А продукт требует постоянного развития.
Как применить эти уроки: практический чек-лист
Если ты планируешь редизайн, вот что нужно сделать перед стартом:
Документация «почему»
Напиши одну страницу, объясняющую бизнес-причины редизайна. Не технические причины, не дизайнерские — бизнесовые. Какую проблему решаем? Какой результат получим?
Три измеримые цели
Выбери максимум три метрики, которые будешь отслеживать. Они должны быть конкретными, измеримыми и привязанными к срокам.
Карта стейкхолдеров
Кто должен знать о проекте? Кто может стать блокером? Кто может помочь? Составь план коммуникации для каждой группы.
Техническое решение о последовательности
Зафиксируй: бэкенд сначала, фронтенд потом. Или наоборот, если есть причины. Но зафиксируй до старта.
План rollout
Определи этапы и проценты трафика. Определи, что ты измеряешь на каждом этапе. Определи критерии перехода к следующему этапу.
Для отслеживания технического состояния сайта после миграции критически важен постоянный мониторинг. Сервисы вроде Ping-Admin и Monitorus позволяют моментально узнавать о любых проблемах с доступностью.
Инструменты для успешного редизайна
Редизайн затрагивает SEO, и здесь важно не потерять накопленные позиции. Несколько инструментов, которые помогут:
Аудит перед редизайном. Checktrust покажет общее качество сайта и профиль ссылок. Это важно понимать до начала работ — чтобы знать, что защищать.
Мониторинг позиций. После запуска каждого этапа rollout проверяй позиции по ключевым запросам. PixelTools и SEOlib дают детальную картину видимости.
Работа с редиректами. При изменении URL-структуры критически важно правильно настроить 301-редиректы. SiteAnalyzer поможет найти битые ссылки и проблемы с редиректами.
Ссылочный профиль. Если при редизайне меняется структура URL, проверь, что важные страницы с внешними ссылками корректно редиректятся. Иначе потеряешь ссылочный вес. Для анализа ссылок используй комплексные сервисы или биржи типа Gogetlinks для понимания текущего профиля.
A/B-тестирование после запуска: от идей к гипотезам
Сам по себе запуск нового сайта — только начало. Дальше начинается работа по оптимизации, и здесь нужен системный подход к A/B-тестированию.
Кара Харшман, экс-сотрудница Optimizely, описывает эволюцию тестирования так: от хаотичных идей («давайте попробуем красную кнопку») к формализованным гипотезам («если мы уберём поле телефона из формы, конверсия вырастет на 15%, потому что исследование показало, что 60% пользователей не хотят оставлять телефон»).
Где брать идеи для тестов:
Аналитика воронки. Найди страницы с максимальным отсевом. Это твои главные кандидаты на тестирование.
Тепловые карты. Посмотри, куда кликают люди, а куда не кликают. Часто важные элементы игнорируются из-за неудачного расположения.
Отчёты по ошибкам форм. Если форма выдаёт много ошибок валидации — это точка трения.
High-traffic, low-conversion страницы. Страницы с большим трафиком, но плохой конверсией — золотая жила для оптимизации.
Пример из практики: Hillary Clinton Campaign
Кайл Раш, работавший на кампанию Хиллари Клинтон, тестировал форму сохранения платёжных данных для повторных донатов. Оригинальный flow: после доната предлагалось сохранить карту, но для этого нужно было перейти на отдельную страницу, ввести email, зарегистрироваться...
Гипотеза: если убрать лишние шаги и использовать email из доната для автоматической идентификации, больше людей сохранят карту.
Результат: +239% к сохранению платёжных данных. Оригинальная конверсия была 9%, вариант показал 31%.
Приоритизация тестов
Не все идеи равны. Используй матрицу «сложность vs. потенциальный эффект»:
- Лёгкое + большой эффект = делай немедленно
- Лёгкое + малый эффект = делай, если есть время
- Сложное + большой эффект = тщательно валидируй гипотезу
- Сложное + малый эффект = забудь
Для серьёзной работы с тестированием нужна скоринговая система. Каждый тест получает баллы: сколько процентов аудитории затрагивает? Насколько важна страница для конверсии? Насколько сложна реализация? Тесты с высшим баллом идут в работу первыми.
Написание контента для SEO: что изменилось
Редизайн — отличный повод переписать контент с учётом актуальных требований поисковиков.
В 2001 году «писать для SEO» означало keyword stuffing — напихать ключевые слова везде, где можно. В 2008 — ключевые слова всё ещё важны в точном соответствии, доменные имена с ключевиками давали преимущество.
Сегодня всё иначе. Google научился понимать intent — намерение пользователя. Страница «синие часы» и «синие наручные часы» могут ранжироваться одинаково, если отвечают на один и тот же запрос.
Что реально важно в 2024-2025:
Решение задачи пользователя. Контент, который лучше всего решает задачу пользователя, ранжируется выше. Не «оптимизированный контент», а полезный.
Соответствие intent. Если по запросу пользователи ищут информацию — давай информацию. Если ищут возможность купить — давай возможность купить. Смотри на текущую выдачу, чтобы понять intent.
Критически важные места для ключевых слов. Title и body content — единственные места, где ключевые слова по-настоящему важны. Остальное — nice to have: H1-H2, URL, meta description, alt-атрибуты изображений.
Связанные термины. Google ожидает увидеть слова и фразы, которые обычно ассоциируются с темой. Статья про районы Нью-Йорка должна упоминать Бруклин, Манхэттен, Квинс — даже если это не твои ключевые слова.
Процесс написания контента для SEO:
- Собери все ключевые слова, на которые таргетируется страница (они должны иметь общий intent)
- Опиши, что пользователь пытается достичь, когда ищет эти слова
- Создай визуальный layout страницы: где заголовок, где основной контент, где CTA
- Напиши текст, затем добавь ключевые слова и связанные термины
- Придумай hook — то, что заставит людей ссылаться и шарить
Заголовки, которые работают везде
При редизайне приходится переписывать десятки и сотни заголовков. Проблема в том, что заголовок должен работать для трёх разных аудиторий:
SEO: содержать ключевые слова, обеспечивать высокий CTR в выдаче, снижать pogo-sticking
Социальные сети: побуждать к шерингу, вызывать эмоции, часто работать даже без клика по ссылке
Посетители сайта: соответствовать контенту, не обманывать ожидания, конвертировать
Эти цели иногда конфликтуют. Загадочный заголовок хорошо работает в соцсетях, но плохо — в поиске. Keyword-stuffed заголовок помогает SEO, но убивает CTR в социальных сетях.
Алгоритм создания универсального заголовка:
- Определи приоритетный канал (SEO, социальные сети, on-site)
- Напиши максимально прямой вариант заголовка
- Напиши максимально «кликбейтный» вариант
- Совмести их, сохранив ключевые слова и эмоциональный триггер
Пример для новости о новой системе безопасности Nest:
Прямой: «Nest выпустила систему безопасности: камера, звонок и сигнализация»
Кликбейтный: «Nest больше не только термостат — их новая система изменит домашнюю безопасность»
Компромисс: «Новая сигнализация, звонок и камера от Nest — must-have для каждого дома»
Что НЕ влияет на ранжирование (и не стоит тратить время)
При редизайне легко увлечься оптимизацией вещей, которые на самом деле не влияют на позиции. Вот что точно можно игнорировать:
Возраст домена. Google не даёт бонусов за то, что сайт зарегистрирован в 1998 году. Важно, сколько авторитета и ссылок накоплено, а не когда был куплен домен.
Использование сервисов Google. Нет, Google Analytics не «помогает» ранжироваться. Google Search Console не даёт преференций. Эти инструменты полезны для анализа, но не влияют на позиции.
Лайки и шеры в соцсетях. Количество расшариваний не является фактором ранжирования. Косвенно может влиять через рост ссылок и узнаваемости бренда, но напрямую — нет.
Абсолютные значения bounce rate и time on site. Google смотрит на относительные показатели и на pogo-sticking (возврат в выдачу и выбор другого результата), а не на абсолютные метрики из твоей аналитики.
Технологический стек. React, Vue, Node, PHP, .NET — Google всё равно, на чём построен сайт, если контент рендерится корректно и доступен для краулинга.
Knowledge panel и sitelinks. Наличие или отсутствие этих элементов в выдаче по брендовым запросам не влияет на ранжирование по другим запросам.
Разделитель в title. Пайп (|), тире (-) или двоеточие — без разницы. Выбирай, что нравится.
H1 vs H2. Google смотрит на визуальное представление контента, а не на конкретные теги. Если заголовок большой и вверху страницы — он будет восприниматься как главный, независимо от тега.
Частые вопросы о редизайне корпоративных сайтов
Как долго падает трафик после редизайна?
При правильном подходе с поэтапным rollout и корректными редиректами значительного падения быть не должно. Если падение есть — это сигнал проблемы, которую нужно диагностировать.
Нужно ли уведомлять Google о редизайне?
Специального механизма нет. Google сам обнаружит изменения. Важнее — правильно настроить редиректы, сохранить sitemap.xml актуальным и не блокировать краулинг.
Что делать со старыми страницами, которые удаляются?
Если страница имела трафик или внешние ссылки — настрой 301-редирект на наиболее релевантную новую страницу. Если страница была бесполезной — редирект на категорию или главную.
Стоит ли менять URL-структуру при редизайне?
Только если есть серьёзные причины. Каждое изменение URL — это риск потери ссылочного веса и временного падения позиций. Если меняешь — 301-редиректы обязательны для каждого старого URL.
Как убедить руководство в необходимости поэтапного rollout?
Объясни в терминах риска. Мгновенный переключатель означает: если что-то сломается — сломается для 100% посетителей. Поэтапный rollout: если сломается — пострадает 1-10% трафика, пока мы чиним.
Ещё больше рабочих инструментов и кейсов — в Telegram-канале.