Переїзд лендінга з LP-Mobi: що переносити, а що зібрати заново

Скопіювати сторінку і переїхати лендінгом — різні задачі. Верстка й тексти справді переїжджають майже одразу. А прийом заявок, події пікселя, мітки трекера, домен і документи в підвалі — окрема робота, частина якої взагалі не залежить від вашої швидкості: ви чекаєте поширення DNS, підтвердження домену в рекламному кабінеті й випуск сертифіката.

Найдорожча помилка виглядає так: домен уже дивиться на нову копію, бюджет відкручується, а форма нікуди не надсилає заявки. Ви оплачуєте трафік, з якого не дізнаєтеся нічого: скільки саме заявок втрачено, відновити вже нема звідки.

Розкладемо переїзд на три купи: що переїде саме, що доведеться підключати руками і що не переїде взагалі.

Купа перша: переїжджає один в один

Це вся «статична» частина сторінки — те, що видно у вихідному HTML:

• Верстка й структура — порядок екранів, сітка, відступи, кнопки.
• Тексти — офер, заголовки, буліти, гарантії, блок питань-відповідей.
• Оформлення — кольори, шрифти, іконки.
• Зображення — фото товару, фони, до/після.

Пастка тут одна, і на ній горять регулярно. Багато способів «копіювання сторінки» лишають картинки посиланнями на сховище старого конструктора. Сторінка виглядає цілою рівно доти, доки живий старий акаунт: відключили тариф — і замість фото товару порожні прямокутники, а дізнаєтеся ви про це з падіння конверсії, а не з листа. Тому після копіювання перевірте, звідки вантажаться зображення: права кнопка → «Відкрити зображення в новій вкладці» → подивіться на домен. Перенесення з LP-Mobi за посиланням у LandEmpire саме через це складає картинки у власне сховище, а форму одразу підключає до нашого прийому заявок.

Купа друга: підключається заново

Усе, що не є розміткою, а є зв'язком із зовнішнім світом. Копія сторінки цього не тягне: ці речі прив'язані до акаунта й домену. Тут важливо розділяти дві різні речі: те, що ви робите руками за один захід, і те, на що ви просто чекаєте.

| Що | Чому не переїде саме | Ваша робота чи очікування |
|---|---|---|
| Прийом заявок | Форма ходила на бекенд старого сервісу | Робите руками, чекати нема чого |
| Telegram, CRM, вебхуки | Токени й адреси прив'язані до старого акаунта | Робите руками |
| Підтвердження домену в Meta | Кабінет не знає вашого нового домену | Хвилини роботи (TXT-запис або мета-тег) плюс очікування підтвердження |
| Пріоритетні події | Налаштовуються на підтверджений домен | Тільки після того, як домен підтвердився |
| Свій домен і сертифікат | DNS міняєте ви, сертифікат випускається на новому боці | Хвилини роботи плюс поширення DNS: хвилини, якщо TTL знизили заздалегідь, і до доби, якщо ні |
| Мітки й clickid | Нова сторінка має приймати sub-параметри та clickid і віддавати їх із заявкою, а в трекері треба замінити URL лендінга. Якщо постбек надсилає трекер, а не лендінг, то сам постбек у партнерці чіпати не потрібно — але перевірте свою схему | Робите руками |
| Документи в підвалі | Політика, оферта, контакти містять стару назву сервісу й старий домен | Робите руками |

Про події варто окремо. Якщо ціль у кабінеті була зав'язана на піксель старого конструктора, після переїзду вона перестає спрацьовувати — тихо. Кампанія продовжує крутитися, але алгоритм не бачить конверсій і оптимізується всліпу по кліках. Помітите ви це радше зі звіту партнерки, ніж із кабінету: там усе зелене. Тому першу тестову заявку після переїзду перевіряють не у формі, а в Events Manager.

Купа третя: не переїде взагалі

Є сторінки, які фізично неможливо скопіювати за посиланням — і чесний сервіс має сказати це вголос, а не віддавати вам порожню оболонку.

Класичний випадок — сторінки, які малює скрипт конструктора. У вихідному HTML там майже нічого немає: браузер вантажить конструкторський JavaScript, той тягне опис сторінки і вже потім збирає блоки. Будь-яка копія «за посиланням» дасть каркас без контенту. Ми в LandEmpire на таких сторінках прямо відмовляємо в перенесенні: розбиратися з кривою копією потім довше, ніж зібрати сторінку заново з блоків.

Що робити з такою сторінкою:

1. Зняти скріншоти всіх екранів і скопіювати тексти в документ.
2. Витягнути оригінали фото — зі старого акаунта, з картки постачальника або зі свого диска.
3. Зібрати заново з блоків: перший екран із ціною та знижкою, таймер, залишок, відгуки, форма заявки.

Так само не переїжджає накопичене: історія заявок, статистика, результати A/B-тестів. Вивантажте заявки до відключення старого акаунта. Якщо вивантаження в CSV там немає — скопіюйте таблицю руками або зніміть скріншотами: критично зберегти телефони, дати й статуси. Після відключення доступ до історії ви втрачаєте.

Порядок переїзду без простою

Правило одне: домен переводимо в останню чергу, а старий лендінг гасимо ще пізніше.

Крок 0. Заздалегідь, до переїзду — усе, що вимагає очікування. Знизьте TTL для A- чи CNAME-запису до 300 секунд, щоб у день переїзду зміна DNS розійшлася за хвилини, а не за години. Врахуйте: саме нове значення TTL розходиться не миттєво, а за старим — якщо там стоїть доба, то й знижувати треба відповідно раніше, інакше в день переїзду частина резолверів ще триматиме стару адресу. Одночасно додайте запис для підтвердження домену в рекламному кабінеті. Це єдиний пункт, який не можна зробити в день переїзду: підтвердження ви не прискорите, а без нього не зібрати пріоритетні події.

Крок 1. Копія на технічній адресі. Перенесіть або зберіть сторінку на службовому піддомені нового сервісу. Старий лендінг у цей час працює й приймає трафік — ви його не чіпаєте.

Крок 2. Заявка на себе. З телефона, в режимі інкогніто, з реальним номером. Перевіряєте не «форма відправилась», а весь ланцюг: повідомлення дійшло в Telegram, у CRM створилась угода, ім'я в полі імені, телефон у полі телефону, мітки долетіли. Заповніть двічі — з мітками й без, щоб побачити, як виглядає заявка з порожніми параметрами.

Крок 3. Тестовий пролив. Пустіть на нову адресу невелику частку трафіку, одним креативом. На цьому кроці ви ловите поломки, а не конверсію: чи дійшли заявки в Telegram і CRM, чи долетіли sub-мітки й clickid, чи спрацював Lead рівно один раз, як сторінка вантажиться на мобільному. Порівнювати конверсію за пару годин безглуздо: на кількох заявках різниця у відсотках — шум, та й нове оголошення з новим URL перші години поводиться інакше. Висновок про конверсію робіть на порівнянному обсязі й через нормальний A/B-тест, а не на око.

Крок 4. Перевід домену. Міняєте DNS-запис, чекаєте сертифікат, відкриваєте сторінку з телефона по https, перевіряєте, що працює і з www, і без. Не робіть цього в п'ятницю ввечері: якщо не встане сертифікат або відваляться події, лагодити доведеться на вихідних, поки бюджет уже крутиться.

Крок 5. Старий тариф не вимикайте одразу. Закладіть у переїзд ще один платіж старому сервісу — це дешевше, ніж відкочуватися всліпу. Гасіть, коли минув тиждень без інцидентів і всі заявки вивантажені.

Чек-лист після переїзду

Половину пунктів проходять з телефона, половину — з ноутбука, і плутати їх не варто.

З телефона:

• Форма. Тестова заявка дійшла в Telegram і в CRM. Валідація не пропускає порожній телефон і не блокує нормальний.
• Сторінка подяки. Після відправки людина бачить підтвердження, а не «нічого не сталося».
• Таймер і залишок. Таймер справді йде і не показує від'ємних чисел. Залишок не скидається на початкове значення при кожному перезавантаженні, якщо ви цього не хотіли.
• Мобільний вигляд. Кнопка не тікає за екран, текст не залазить на фото, форма видима без горизонтальної прокрутки.
• Дрібниці. Клікабельний номер телефону, посилання на месенджер, заголовок вкладки.

З ноутбука:

• Вихідний код. Ctrl+U: якщо тексти видно — сторінка статична.
• Домен зображень. Жодна картинка не вантажиться зі сховища старого сервісу.
• Піксель і події. PageView на завантаженні, Lead — після реальної відправки форми, і рівно один раз, а не двічі. Дивитися в Events Manager, а не на око.
• Документи в підвалі. Політика конфіденційності, оферта, контакти ФОП відкриваються, і в них новий домен та ваша назва. Це обов'язковий елемент, і за нашим досвідом їх відсутність — одна з типових причин відхилення на модерації.
• Швидкість. Мобільний профіль, холодний кеш. Орієнтир — загальновідомі пороги Core Web Vitals: перший екран до 2,5 секунди вважається добрим результатом, до 4 секунд — ще терпимим, зсув макета до 0,1 — добрим. Для наочності один наш замір (вересень 2026, мобільний профіль, холодний кеш): сторінка 244 КБ, перший екран близько 290 мс, зсув макета 0; до оптимізації та сама сторінка важила 381 КБ і показувала перший екран за 612 мс. Це один замір, а не норматив ринку.

Що насправді розтягує переїзд

Не робота зі сторінкою: копію, форму, Telegram, CRM і документи ви робите за один захід. Збирання модульної сторінки заново займе більше — залежно від кількості екранів і наявності оригіналів фото.

Розтягують переїзд паузи, на які ви не впливаєте: поширення DNS, підтвердження домену в рекламному кабінеті, випуск сертифіката. Тому переїзд планують навколо цих пауз і запускають їх заздалегідь — до того, як домен почне дивитися на нову сторінку.

Що зробити сьогодні

1. Відкрийте свій лендінг і подивіться вихідний код (Ctrl+U). Бачите тексти — сторінка переїде копією. Бачите порожній каркас і скрипт — закладайте час на ручне збирання.
2. Вивантажте заявки зі старого сервісу; якщо вивантаження немає — збережіть таблицю руками. Складіть в одну папку скріншоти всіх екранів і оригінали фото.
3. Знизьте TTL домену до 300 секунд (зміна розійдеться не миттєво, а через час старого TTL — тому робіть це заздалегідь) і одразу додайте запис для підтвердження домену в рекламному кабінеті — це та частина, яка чекає без вас.
4. Зробіть копію на технічній адресі й відправте собі тестову заявку з телефона — перевірте весь ланцюг до угоди в CRM.
5. Випишіть список подій і міток, які треба перепідключити. Те, чого немає в списку, ви точно забудете.