Редизайн сайта компании: когда он нужен и с чего начать

Редизайн сайта компании — это не просто смена обложки. Это миграция с устаревших протоколов (например, SOAP на REST API), оптимизация серверной части (Nginx, Redis) и пересборка UI на основе данных аналитики. В статье — конкретные шаги, протоколы и чек-лист, который сэкономит вам 40% бюджета.

Когда владелец бизнеса слышит «редизайн сайта», он часто представляет новый логотип и свежие картинки. На деле это глубокая инженерная работа: от рефакторинга кода до настройки кеширования через Redis и замены устаревших протоколов аутентификации (например, Basic Auth на OAuth 2.0 + JWT). В этой статье мы разберем, как объективно определить необходимость редизайна, и пройдем по этапам — от анализа поведения пользователей до верстки с учетом Core Web Vitals.

Когда сайт компании объективно устарел: 5 технических признаков

Не ждите, пока конверсия упадет. Проверьте эти параметры:

1. Скорость загрузки > 3 секунд — если TTFB (Time to First Byte) превышает 800 мс, а LCP (Largest Contentful Paint) > 2.5 с, проблема не в хостинге, а в архитектуре. Часто виноваты монолитные запросы к БД без кеширования (Redis/Memcached).
2. Устаревшие протоколы интеграции — если 1С общается с сайтом через SOAP или самописные XML-парсеры, а не через REST API с JSON и CommerceML 3.0, редизайн неизбежен. Современные ERP требуют OAuth 2.0 и JWT для безопасного обмена данными.
3. Отсутствие адаптивности под мобильные устройства — Google индексирует mobile-first версию. Если ваш сайт использует фиксированную верстку (px вместо rem/vw) или не поддерживает touch-события, вы теряете большую часть трафика.
4. Проблемы с безопасностью — старые версии CMS (например, WordPress 4.x без обновлений) имеют уязвимости в wp-config.php (неправильные ключи AUTH_KEY, открытый доступ к wp-admin). Редизайн включает миграцию на актуальные версии с настройкой .htaccess для блокировки ботов и Nginx для защиты от DDoS.
5. Невозможность масштабирования — если при росте каталога до 10 000 товаров сайт «ложится», а RabbitMQ не справляется с очередями заказов, нужна новая архитектура.

Этапы редизайна: от аналитики до верстки

Этап 1. Анализ поведения пользователей и технический аудит

Перед тем как трогать дизайн, мы в AVOdigital проводим аудит текущей архитектуры. Собираем данные через Google Analytics 4, Яндекс.Метрику (карты кликов, скроллинга) и инструменты вроде Hotjar. Параллельно проверяем:

• Логи сервера (Nginx/Apache) на предмет 404, 500 ошибок.
• Структуру базы данных — есть ли индексы, не дублируются ли записи.
• Протоколы интеграции — если используется REST, проверяем версию (1.0 vs 2.0), наличие HATEOAS, корректность JWT-токенов.

Результат — карта «узких мест»: например, большая часть пользователей уходят с формы заказа из-за долгой загрузки (отсутствие кеширования через Redis).

Этап 2. Проектирование новой архитектуры

На основе аудита выбираем стек. Вот таблица сравнения популярных CMS/фреймворков для редизайна:

Для интернет-магазинов с 1С мы рекомендуем Laravel + CommerceML через REST, так как это дает гибкость в настройке очередей (RabbitMQ) и кеширования (Redis).

Этап 3. UI/UX-дизайн с учетом Core Web Vitals

Дизайн — это не только эстетика. Мы проектируем интерфейс так, чтобы минимизировать CLS (Cumulative Layout Shift) и LCP. Используем:

• CSS Grid и Flexbox для адаптивности (без медиа-запросов для базовых случаев).
• Lazy loading изображений через атрибут loading="lazy".
• WebP и AVIF форматы для графики.
• Микроанимации на CSS (без JS, чтобы не блокировать рендеринг).

Важно: на этом этапе мы уже знаем, какие протоколы будут использоваться. Например, если форма авторизации переходит на OAuth 2.0, дизайн должен предусматривать кнопки «Войти через Google/Яндекс».

Этап 4. Верстка и интеграция

Верстка выполняется на компонентной архитектуре (React/Vue.js или чистый HTML+CSS с БЭМ). Мы настраиваем:

• Серверную часть: Nginx как reverse proxy, настройка gzip, brotli, кеширование статики через заголовки Cache-Control.
• Безопасность: .htaccess для блокировки доступа к wp-admin (если WordPress), настройка CORS для REST API, использование JWT с коротким временем жизни (15 минут).
• Интеграции: CommerceML через REST с валидацией JSON Schema, очереди через RabbitMQ для обработки заказов.

Пример из практики AVOdigital: при редизайне сайта дилерского центра мы заменили SOAP-интеграцию с 1С на REST API с JWT-аутентификацией. Время синхронизации каталога (50 000 товаров) сократилось с 4 часов до 12 минут благодаря Redis-кешированию и RabbitMQ-очередям.

Пошаговый чек-лист редизайна сайта компании

1. Аудит текущего состояния: проверьте TTFB, LCP, CLS через PageSpeed Insights. Соберите карты кликов и воронки.
2. Технический аудит: проверьте версии CMS, PHP, MySQL. Убедитесь, что протоколы интеграции (REST, CommerceML) поддерживают OAuth 2.0.
3. Выбор стека: определитесь с CMS/фреймворком (см. таблицу выше). Если нужна кастомизация — Laravel, если быстро и дешево — WordPress.
4. Проектирование архитектуры: настройте Redis для кеширования, RabbitMQ для очередей, Nginx для балансировки.
5. Дизайн: создайте прототипы с учетом Core Web Vitals. Используйте Figma с плагинами для проверки контрастности.
6. Верстка: используйте БЭМ или CSS Modules. Настройте .htaccess и Nginx для безопасности.
7. Интеграция: подключите REST API, CommerceML, OAuth. Проверьте JWT-токены на утечку.
8. Тестирование: нагрузочное тестирование (JMeter), проверка безопасности (OWASP Top 10), A/B тесты.
9. Запуск: постепенная миграция (canary release) с мониторингом через Grafana + Prometheus.

Частые вопросы