# balldecor.ru

Коммерческий проект по переносу действующего сайта BallDecor на HAIH.

## Цель

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

## Исходный контекст

Текущий сайт объединяет B2C и B2B-направления: оформление мероприятий, доставка гелиевых шаров, печать и брендирование шаров, сезонные и событийные услуги. Органический охват построен на большом количестве исторических посадочных страниц и старых URL, поэтому миграция требует аккуратной работы с индексируемой структурой и редиректами.

## Принцип миграции

Legacy используется как источник требований, контента, URL и подтверждённых пользовательских сценариев, но не как архитектурный шаблон. Новый runtime и модель контента строятся на HAIH.

Миграция коммерческого сайта BallDecor на HAIH с сохранением и развитием SEO и лидогенерации.

balldecor.ru

# Перенос balldecor.ru на HAIH

## Цель
Перевести действующий сайт BallDecor на HAIH, сохранив поисковую видимость, коммерчески значимый контент и основные сценарии обращения, но не перенося legacy-архитектуру как есть.

## Что важно сохранить
- действующие индексируемые URL и их поисковую ценность;
- ключевые направления бизнеса: оформление мероприятий, доставка шаров, печать/брендирование, сезонные и событийные услуги;
- телефоны, формы заявок, callback/контактные сценарии и доступные способы обращения;
- изображения и контент, который реально участвует в органическом трафике и продаже услуг;
- исторические ссылки из поиска и внешних источников через 1:1 URL или корректные 301.

## Что нужно пересобрать
1. Инвентаризировать текущий сайт: маршруты, шаблоны страниц, данные, формы, интеграции, ассеты и фактический runtime.
2. Выделить предметное ядро и реализовать его на HAIH современными вертикальными срезами.
3. Не копировать технический долг legacy, если он не является внешним контрактом.
4. Сохранить или улучшить SSR/индексируемость, metadata, canonical, sitemap, robots, structured data и скорость загрузки.
5. Воспроизвести формы и лидогенерацию, проверить доставку заявок и контактов.
6. Перед переключением выполнить полный crawl старого сайта и нового стенда, сопоставить URL/status/title/H1/canonical/links/assets/forms.
7. После запуска проверить 301, 404, sitemap/robots, поисковую доступность и аналитику.

## Критерий готовности
Новый balldecor.ru работает на HAIH, основные пользовательские и коммерческие сценарии подтверждены, SEO-контракты миграции проверены, старые значимые URL не потеряны, формы и аналитика работают, а дальнейшие маркетинговые улучшения могут выполняться независимо от технического legacy.

Пересобрать действующий коммерческий сайт BallDecor на HAIH без потери SEO и рабочих сценариев заказа.

Перенести balldecor.ru на HAIH

# SEO при миграции

## Задача
Сохранить существующую органическую видимость balldecor.ru и убрать SEO-риски, которые создаёт текущая историческая структура сайта.

## Основные работы
- собрать полный реестр индексируемых URL, включая старые .html-страницы, категории, услуги и сезонные посадочные;
- для каждой страницы зафиксировать status, title, description, H1, canonical, robots, внутренние ссылки и основной поисковый интент;
- выявить дубли и каннибализацию близких страниц, особенно вокруг печати/брендирования шаров, доставки и оформления мероприятий;
- принять решение по каждому URL: сохранить 1:1, объединить через 301, закрыть от индексации или удалить только при доказанном отсутствии ценности;
- подготовить redirect map и проверить её crawl-ом до запуска;
- пересобрать sitemap.xml, robots.txt, canonical и structured data;
- сохранить изображения и alt/URL там, где они участвуют в поиске;
- после запуска проверить индексацию, 404/5xx, цепочки редиректов и потерянные посадочные.

## Критерий готовности
Для всех значимых старых URL есть явное решение и проверенный новый маршрут; нет массовых 404, случайной деиндексации и необоснованной потери поисковых интентов.

Зафиксировать текущую поисковую поверхность и перенести её без потери значимых URL и интентов.

Сохранить и улучшить SEO при миграции

# Маркетинг и конверсия

## Контекст
Текущий сайт одновременно продаёт B2C-услуги и B2B-направления. На главной и ряде посадочных коммерческий оффер смешан с большим объёмом исторического SEO-текста, поэтому пользователю не всегда очевидно, куда идти и что заказать.

## Основные работы
- определить 3–5 главных коммерческих направлений и роли посетителей;
- развести B2C и B2B-сценарии там, где у них разные потребности и аргументы;
- сформулировать понятные офферы, преимущества и CTA для ключевых посадочных;
- сделать отдельные сильные сценарии для печати/брендирования шаров, оформления мероприятий и доставки;
- структурировать доказательства: примеры работ, цены/диапазоны, сроки, условия доставки, отзывы, FAQ, работа с юрлицами;
- убрать текст ради текста: SEO-контент должен поддерживать решение о покупке, а не мешать ему;
- проверить мобильный путь до заявки, звонка или мессенджера;
- определить минимальный набор форм и полей, чтобы не снижать конверсию.

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

Развести ключевые B2C/B2B-сценарии, усилить оффер и сделать страницы ориентированными на заявку.

Пересобрать маркетинговую архитектуру и конверсию

# Аналитика и контроль запуска

## Основные работы
- зафиксировать текущие системы аналитики, рекламные метки и события;
- определить основные конверсии: отправка формы, заказ звонка, звонок/клик по телефону, переход в мессенджер, B2B-заявка;
- перенести аналитику и события на новую версию без дублирования;
- настроить корректную передачу UTM и рефереров в лиды, где это возможно;
- снять baseline по Core Web Vitals/Lighthouse и ключевым коммерческим страницам;
- перед запуском провести crawl и smoke-test форм, телефонов, ссылок, изображений и аналитических событий;
- после запуска проверить реальные лиды, ошибки 404/5xx, скорость, Search Console/вебмастер и индексируемость.

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

Сделать измеримыми лиды и техническое качество новой версии до и после переключения.

Настроить аналитику и контроль качества запуска

# Переделать калькулятор стоимости оформления

## Проблема
Текущий калькулятор — длинный многошаговый квиз, который просит пользователя потратить время на ответы, а затем на финальном экране скрывает обещанный результат за обязательным вводом телефона и e-mail.

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

## Что особенно плохо в текущем сценарии
- слишком много шагов для первичной оценки;
- пользователь не понимает заранее, какие данные понадобятся и что именно он получит;
- прогресс интерфейса неоднозначен;
- вопросы местами сформулированы не как естественные решения клиента, а как поля внутренней анкеты;
- до самого конца нет полезного промежуточного результата;
- финальный шаг сообщает «тест пройден», но всё ещё не показывает расчёт;
- телефон фактически обязателен для получения обещанного результата;
- e-mail запрашивается ещё и «для получения подарка и предложения», что смешивает расчёт с маркетинговым согласием;
- CTA «Получить результат расчёта» ведёт не к мгновенному результату, а к передаче контактов;
- после 8–9 экранов отказ на последнем шаге означает полностью потерянное время пользователя.

## Принцип новой версии
Сначала дать пользователю обещанную ценность, потом попросить контакт для следующего шага сделки.

Калькулятор должен честно отвечать на вопрос: «Сколько примерно будет стоить моё оформление?» Даже если точная смета невозможна без менеджера, пользователь должен получить ориентир: диапазон цены, пример состава заказа, факторы, влияющие на стоимость, либо несколько подходящих пакетов.

## Что сделать
1. Разобрать текущие вопросы и определить, какие действительно влияют на стоимость. Всё, что нужно только менеджеру после квалификации лида, вынести за пределы расчёта.
2. Сократить сценарий до минимально необходимого числа смысловых решений — ориентир 3–5 этапов или один экран с последовательным раскрытием.
3. Сгруппировать ввод по логике клиента, например:
   - тип события / что нужно оформить;
   - масштаб или желаемый состав;
   - дата и место;
   - дополнительные опции.
4. Показывать понятный прогресс словами: что уже выбрано и что осталось.
5. Давать ориентировочную стоимость или диапазон сразу после достаточного набора данных, **до обязательного ввода телефона/e-mail**.
6. На экране результата показать:
   - ориентировочную стоимость или диапазон;
   - что примерно входит;
   - от чего цена может измениться;
   - примеры/пакеты, если они помогают принять решение.
7. После результата предложить следующий шаг:
   - получить точную смету;
   - обсудить детали с менеджером;
   - отправить расчёт себе;
   - перейти в мессенджер/позвонить.
8. Контакт просить только в обмен на дополнительную ценность после уже показанного базового результата. Не смешивать обязательный контакт для расчёта с отдельным маркетинговым согласием.
9. Не требовать одновременно телефон и e-mail без необходимости. Для первичного лида достаточно одного удобного канала связи, выбранного пользователем.
10. Сделать удобную мобильную версию: крупные варианты выбора, минимум ручного ввода, нормальный выбор даты, без горизонтального скролла.
11. Добавить аналитику воронки: старт, ответы по этапам, просмотр результата, выбор CTA, отправка контакта, отказ.

## Метрики
Смотреть не только на `lead submitted`, но и на:
- долю начавших расчёт;
- completion rate расчёта;
- долю увидевших результат;
- конверсию из результата в контакт;
- долю квалифицированных лидов;
- дальнейшую конверсию в заказ, если данные доступны.

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

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

Заменить текущий длинный квиз на понятный расчёт, который даёт ценность до запроса контакта и не превращает результат в приманку.

Переделать калькулятор стоимости оформления

# Улучшить показатели Lighthouse и Core Web Vitals

## Baseline текущего сайта
По текущему замеру главной страницы balldecor.ru:
- Performance: **52**
- Accessibility: **57**
- Best Practices: **74**
- SEO: **100**

SEO-score высокий, но остальные показатели заметно проседают. При переносе на HAIH это нужно использовать как измеримый технический baseline и не воспроизводить проблемы legacy.

## Цель
Добиться заметно лучших показателей производительности, доступности и best practices на новой версии сайта, не жертвуя SEO, функциональностью и маркетинговыми сценариями.

## Что сделать
1. Снять воспроизводимый baseline Lighthouse для главной и нескольких ключевых коммерческих страниц в mobile и desktop режимах.
2. Разобрать основные причины потерь Performance:
   - LCP и тяжёлый hero-контент;
   - размеры и форматы изображений;
   - лишний JavaScript/CSS;
   - блокирующие ресурсы и сторонние скрипты;
   - шрифты;
   - CLS;
   - TBT/INP;
   - серверный ответ и кеширование.
3. Оптимизировать изображения: современные форматы, responsive sizes/srcset, корректные размеры, lazy loading вне первого экрана, preload только действительно критичных ресурсов.
4. Минимизировать client-side JS и гидратацию там, где достаточно SSR/обычного HTML; не тащить тяжёлые библиотеки без необходимости.
5. Настроить кеширование статических ресурсов, compression, immutable assets и CDN/cache layer, если он используется в HAIH-развёртывании.
6. Исправить accessibility-проблемы:
   - контраст;
   - корректные label/aria;
   - семантическую структуру заголовков;
   - keyboard navigation/focus;
   - размеры touch targets;
   - alt-тексты;
   - доступность форм и калькулятора.
7. Исправить Best Practices: ошибки консоли, устаревшие/небезопасные API, проблемы загрузки ресурсов, security headers и прочие замечания Lighthouse.
8. Не допустить ухудшения SEO: SSR, indexability, metadata, canonical, structured data и внутренние ссылки должны сохраниться.
9. Добавить Lighthouse/Pagespeed-проверку в финальный smoke-test перед запуском и использовать её как регрессионный контроль после крупных изменений.

## Целевые ориентиры
Для ключевых страниц новой версии стремиться к:
- Performance: **90+**
- Accessibility: **95+**
- Best Practices: **95+**
- SEO: **95–100**

Цели не должны достигаться за счёт удаления важных для бизнеса функций или искусственного упрощения страницы.

## Критерий готовности
Ключевые страницы новой версии стабильно заметно превосходят legacy baseline, критические Core Web Vitals находятся в приемлемой зоне, а основные проблемы Lighthouse устранены и не возвращаются при последующих изменениях.

Повысить производительность, доступность и техническое качество нового balldecor.ru с фиксацией baseline и регрессионным контролем.

Задачи

Улучшить показатели Lighthouse и Core Web Vitals

Переделать калькулятор стоимости оформления

Настроить аналитику и контроль качества запуска

Пересобрать маркетинговую архитектуру и конверсию

Сохранить и улучшить SEO при миграции

Перенести balldecor.ru на HAIH