# balldecor.ru

A commercial project to migrate the existing BallDecor website to HAIH.

## Objective

Rebuild the website on a modern engine without losing existing search demand and commercial scenarios, while simultaneously improving landing page structure, offer clarity, and conversion to leads.

## Initial Context

The current website combines B2C and B2B directions: event decoration, helium balloon delivery, balloon printing and branding, seasonal and event services. Organic reach is built on a large number of historical landing pages and old URLs, so the migration requires careful handling of the indexable structure and redirects.

## Migration Principle

The legacy system is used as a source of requirements, content, URLs, and validated user scenarios, but not as an architectural template. The new runtime and content model are built on HAIH.

Migration of the BallDecor commercial website to HAIH while preserving and developing SEO and lead generation.

balldecor.ru

# Migration of balldecor.ru to HAIH

## Objective
Transfer the active BallDecor website to HAIH while preserving search visibility, commercially significant content, and core interaction workflows, without migrating the legacy architecture as-is.

## What is important to preserve
- active indexed URLs and their search value;
- key business directions: event decoration, balloon delivery, printing/branding, seasonal and event services;
- telephone numbers, request forms, callback/contact workflows, and available communication methods;
- images and content that actively contribute to organic traffic and service sales;
- historical links from search and external sources via 1:1 URLs or correct 301 redirects.

## What needs to be rebuilt
1. Inventory the current website: routes, page templates, data, forms, integrations, assets, and actual runtime.
2. Extract the domain core and implement it on HAIH using modern vertical slices.
3. Do not copy legacy technical debt unless it serves as an external contract.
4. Preserve or improve SSR/indexability, metadata, canonical tags, sitemap, robots.txt, structured data, and loading speed.
5. Reproduce forms and lead generation, and verify the delivery of requests and contacts.
6. Before switching, perform a full crawl of the old website and the new staging environment, mapping URLs, status codes, titles, H1 tags, canonicals, links, assets, and forms.
7. After launch, check 301 redirects, 404 errors, sitemap/robots.txt, search accessibility, and analytics.

## Definition of Done
The new balldecor.ru runs on HAIH, core user and commercial workflows are verified, SEO migration contracts are checked, significant old URLs are not lost, forms and analytics are operational, and further marketing improvements can be performed independently of the technical legacy.

Rebuild the active BallDecor commercial website on HAIH without losing SEO or operational ordering workflows.

Migrate balldecor.ru to HAIH

# SEO During Migration

## Objective
Preserve the existing organic visibility of balldecor.ru and eliminate the SEO risks posed by the current historical site structure.

## Key Tasks
- Compile a complete registry of indexable URLs, including old .html pages, categories, services, and seasonal landing pages;
- For each page, record the status, title, description, H1, canonical, robots, internal links, and primary search intent;
- Identify duplicates and cannibalization between similar pages, especially regarding balloon printing/branding, delivery, and event decor;
- Make a decision for each URL: keep 1:1, merge via 301, block from indexing, or remove only if proven to have no value;
- Prepare a redirect map and test it with a crawler before launch;
- Rebuild sitemap.xml, robots.txt, canonical tags, and structured data;
- Preserve images and their alt text/URLs where they drive search traffic;
- After launch, check indexing, 404/5xx errors, redirect chains, and lost landing pages.

## Definition of Done
All significant old URLs have a clear decision and a verified new route; there are no mass 404s, accidental de-indexing, or unjustified loss of search intents.

Lock in the current search footprint and transfer it without losing valuable URLs and intents.

Preserve and Improve SEO During Migration

# Marketing and Conversion

## Context
The current website simultaneously sells B2C services and B2B directions. On the homepage and several landing pages, the commercial offer is mixed with a large amount of historical SEO text, making it not always obvious to the user where to go and what to order.

## Main Scope of Work
- define 3–5 main commercial directions and visitor roles;
- separate B2C and B2B scenarios where their needs and arguments differ;
- formulate clear offers, benefits, and CTAs for key landing pages;
- create distinct, strong scenarios for balloon printing/branding, event decoration, and delivery;
- structure proof elements: work examples, prices/ranges, timelines, delivery terms, reviews, FAQs, B2B processing;
- remove text for the sake of text: SEO content should support the purchase decision, not hinder it;
- check the mobile user journey to submitting a request, call, or messenger chat;
- determine the minimum set of forms and fields to avoid lowering conversion rates.

## Definition of Done
Key segments quickly understand the offer, see relevant proof, and can take the target action without unnecessary steps.

Separate key B2C/B2B scenarios, strengthen the offer, and make pages conversion-oriented.

Rebuild marketing architecture and conversion

# Analytics and Launch Control

## Main Tasks
- record current analytics systems, ad tags, and events;
- define key conversions: form submission, call back request, phone call/click, messenger click, B2B lead;
- transfer analytics and events to the new version without duplication;
- configure correct transmission of UTMs and referrers to leads where possible;
- take a baseline of Core Web Vitals/Lighthouse and key commercial pages;
- before launch, perform a crawl and smoke-test of forms, phone numbers, links, images, and analytics events;
- after launch, check real leads, 404/5xx errors, speed, Search Console/Webmaster, and indexability.

## Definition of Done
After the switchover, it is possible to reliably see whether the site is working technically, whether organic traffic is being preserved, and whether inquiries are coming through key channels.

Make leads and the technical quality of the new version measurable before and after the switchover.

Configure Analytics and Launch Quality Control

# Redesign the registration cost calculator

## Problem
The current calculator is a long multi-step quiz that asks users to spend time answering questions, and then on the final screen hides the promised result behind a mandatory phone and email input.

This may increase the number of collected contacts, but a contact alone does not equal a deal. For some users, this mechanic creates the feeling that the promised calculation was used as bait: the user has already invested time, but instead of the result gets another barrier. This reduces brand trust and can impair not only the conversion to a qualified lead, but also the willingness to continue interaction.

## What is particularly bad in the current scenario
- too many steps for an initial estimate;
- the user does not understand in advance what data will be needed and what exactly they will receive;
- interface progress is ambiguous;
- questions are sometimes phrased not as natural customer decisions, but as internal questionnaire fields;
- no useful intermediate result until the very end;
- the final step reports "test passed", but still doesn't show the calculation;
- the phone number is effectively mandatory to get the promised result;
- email is also requested "to receive a gift and an offer", which mixes the calculation with marketing consent;
- the "Get calculation result" CTA leads not to an instant result, but to the transfer of contacts;
- after 8–9 screens, dropping off at the last step means the user's time is completely wasted.

## Principle of the new version
Give the user the promised value first, then ask for a contact for the next step of the deal.

The calculator should honestly answer the question: "How much will my registration approximately cost?" Even if an exact estimate is impossible without a manager, the user should receive a reference point: a price range, an example of the order composition, factors affecting the cost, or several suitable packages.

## What to do
1. Analyze current questions and determine which ones actually affect the cost. Move everything that is only needed by the manager after lead qualification outside of the calculation.
2. Reduce the scenario to the minimum necessary number of meaningful decisions — target 3–5 stages or a single screen with progressive disclosure.
3. Group inputs according to the customer's logic, for example:
   - event type / what needs to be registered;
   - scale or desired composition;
   - date and location;
   - additional options.
4. Show clear progress in words: what has already been selected and what remains.
5. Provide an estimated cost or range immediately after a sufficient set of data, **before the mandatory phone/email input**.
6. On the result screen, show:
   - estimated cost or range;
   - what is approximately included;
   - what the price might change based on;
   - examples/packages if they help make a decision.
7. After the result, suggest the next step:
   - get an exact estimate;
   - discuss details with a manager;
   - send the calculation to yourself;
   - go to messenger / call.
8. Ask for a contact only in exchange for additional value after the basic result has already been shown. Do not mix mandatory contact for the calculation with separate marketing consent.
9. Do not require both a phone number and an email simultaneously without necessity. For an initial lead, one convenient communication channel chosen by the user is sufficient.
10. Create a user-friendly mobile version: large choice options, minimum manual input, normal date selection, no horizontal scrolling.
11. Add funnel analytics: start, answers by stages, result viewing, CTA selection, contact submission, drop-off.

## Metrics
Monitor not only `lead submitted`, but also:
- share of users who started the calculation;
- calculation completion rate;
- share of users who saw the result;
- conversion from result to contact;
- share of qualified leads;
- further conversion to order, if data is available.

The goal is not to maximize the number of contacts at any cost, but to increase the number of users who received a useful result and voluntarily moved to the next step of the deal.

## Definition of Done
The user understands in advance what they will get, quickly goes through the calculation, and sees a useful cost reference without forced contact transfer. The contact is requested after the result as a natural next step for clarification and a deal, rather than as payment for an already promised result.

Replace the current long quiz with a transparent calculation that provides value before contact collection and doesn't use the result as bait.

Redesign the registration cost calculator

# Improve Lighthouse and Core Web Vitals metrics

## Current site baseline
Based on the current measurements for the balldecor.ru homepage:
- Performance: **52**
- Accessibility: **57**
- Best Practices: **74**
- SEO: **100**

The SEO score is high, but the other metrics are noticeably lagging. During the migration to HAIH, this must be used as a measurable technical baseline to avoid reproducing legacy issues.

## Objective
Achieve significantly better performance, accessibility, and best practices scores on the new version of the site without sacrificing SEO, functionality, or marketing scenarios.

## Action items
1. Establish a reproducible Lighthouse baseline for the homepage and several key commercial pages in both mobile and desktop modes.
2. Analyze the main causes of Performance losses:
   - LCP and heavy hero content;
   - image sizes and formats;
   - excess JavaScript/CSS;
   - render-blocking resources and third-party scripts;
   - fonts;
   - CLS;
   - TBT/INP;
   - server response time and caching.
3. Optimize images: modern formats, responsive sizes/srcset, correct dimensions, lazy loading for off-screen images, and preloading only truly critical resources.
4. Minimize client-side JS and hydration where SSR/plain HTML is sufficient; avoid dragging in heavy libraries unnecessarily.
5. Configure static asset caching, compression, immutable assets, and a CDN/cache layer if used in the HAIH deployment.
6. Fix accessibility issues:
   - contrast;
   - correct labels/ARIA;
   - semantic heading structure;
   - keyboard navigation/focus;
   - touch target sizes;
   - alt texts;
   - form and calculator accessibility.
7. Fix Best Practices: console errors, outdated/unsafe APIs, resource loading issues, security headers, and other Lighthouse warnings.
8. Prevent SEO degradation: SSR, indexability, metadata, canonical tags, structured data, and internal links must be preserved.
9. Add Lighthouse/PageSpeed checks to the final smoke test before launch and use them for regression control after major changes.

## Target benchmarks
For key pages of the new version, aim for:
- Performance: **90+**
- Accessibility: **95+**
- Best Practices: **95+**
- SEO: **95–100**

Targets must not be achieved by removing business-critical features or artificially simplifying the page.

## Definition of done
Key pages of the new version consistently and noticeably outperform the legacy baseline, critical Core Web Vitals are within the acceptable range, and major Lighthouse issues are resolved and do not recur with subsequent changes.

Enhance performance, accessibility, and technical quality of the new balldecor.ru with baseline establishment and regression control.