New Як підготувати лендінг і VPS до запуску трафіку: покроковий чек-лист

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

У цьому гайді розглянемо, як підготувати статичний лендінг, розмістити його на VPS з Ubuntu та Nginx, підключити домен і HTTPS, а потім перевірити сторінку перед запуском платного трафіку.

Стаття розрахована на медіабаєра або невелику команду, у якої вже є HTML-шаблон, домен і доступ до обробника заявок, CRM або трекера. Якщо лендінг використовує PHP або інший серверний код, однієї установки Nginx недостатньо: потрібно окремо налаштувати середовище виконання, наприклад PHP-FPM. У цьому матеріалі розглядається простіший і швидший сценарій зі статичною сторінкою.

У статті розглянемо:

• як перевірити та адаптувати шаблон;
• що видалити з коду перед запуском;
• як налаштувати форми та аналітику;
• як обрати сервер під лендінг;
• як розгорнути статичну сторінку на Ubuntu та Nginx;
• як підключити домен і HTTPS;
• що перевірити до купівлі трафіку;
• як організувати оплату хостингу, доменів і робочих сервісів.

Крок 1. Підготуйте посадкову сторінку

Почніть з аналізу сторінок у своїй ніші. Завдання – не копіювати чужий сайт, а зрозуміти, які блоки, пропозиції, візуальні рішення та заклики до дії використовуються для схожої аудиторії.

Під час аналізу звертайте увагу на:

• порядок блоків і логіку сторінки;
• заголовок, підзаголовок і опис оффера;
• форму заявки або реєстрації;
• кнопки та шлях користувача до цільової дії;
• зображення та візуальні акценти;
• відображення на смартфонах;
• швидкість завантаження та кількість зовнішніх скриптів.

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

Якщо у вас уже є готовий HTML-шаблон, переходьте до технічної перевірки.

Крок 2. Перевірте код, форми та аналітику

Отриманий архів – лише заготовка. Перед запуском його потрібно розпакувати, перевірити та адаптувати під свою кампанію.

Для статичного лендінгу головним файлом зазвичай буде index.html. Його можна відкрити у Visual Studio Code, Notepad++ або іншому редакторі коду.

Якщо в архіві основним файлом указано index.php, а форма надсилає дані до локального lead.php, такий проєкт не можна розгорнути як звичайний статичний сайт. Спочатку уточніть вимоги шаблону та налаштуйте PHP-FPM або замініть локальний обробник готовою інтеграцією з CRM, трекером чи партнерською мережею.

Видаліть чужі лічильники та зовнішні підключення

Знайдіть підключення Meta Pixel, Google Analytics, TikTok Pixel, Яндекс Метрики та інших систем аналітики. Чужі лічильники можуть передавати дані про відвідування та дії користувачів попередньому власнику шаблону.

Перевірте:

• код у та перед закривним тегом ;
• підключувані JavaScript-файли;
• зовнішні скрипти та iframe;
• редиректи в JavaScript;
• посилання та запити до сторонніх доменів;
• форми, які можуть надсилати дані на чужу адресу.

Не обмежуйтеся пошуком назв відомих лічильників. Відкрийте сторінку локально та подивіться у вкладці Network, до яких доменів вона звертається. Після очищення підключіть лише власні системи аналітики та потрібні інтеграції.

Перевірте події аналітики

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

Не фіксуйте конверсію лише за кліком на кнопку. Подія ліда має спрацьовувати після успішної відповіді обробника або на сторінці подяки. Інакше в рекламний кабінет можуть потрапляти незавершені та помилкові відправки.

Для перевірки Meta можна використовувати Meta Ads Data Advisor – офіційне розширення, яке раніше називалося Meta Pixel Helper. Додатково перевірте події в розділі Test Events в Events Manager.

У DevTools використовуйте:

• вкладку Network – для запитів до аналітики та обробника;
• вкладку Console – для помилок JavaScript;
• вкладку Application – для перевірки файлів cookie та локального сховища, якщо вони використовуються.

Крок 3. Адаптуйте контент і мобільну версію

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

Перевірте та оновіть:

• заголовок і підзаголовок;
• опис переваг;
• ціни, умови та обмеження;
• зображення та банери;
• відгуки, рейтинги та інші соціальні докази;
• кнопки та заклики до дії;
• тексти помилок і підтвердження відправки форми.

Використовуйте зображення відповідного розміру та формату. Для фотографій часто підходять WebP або AVIF із резервним варіантом, а для простих ілюстрацій – SVG. Не завантажуйте зображення шириною в кілька тисяч пікселів, якщо на сторінці воно показується в невеликому блоці.

Мінімальний чек-лист мобільної версії

• текст читається без масштабування;
• основний CTA видно на першому екрані або швидко доступний;
• форма не перекривається екранною клавіатурою;
• зображення не ламають верстку;
• поля використовують відповідний тип введення, наприклад tel для телефону;
• немає горизонтального скролу;
• інтерактивні елементи не розташовані надто близько один до одного;
• сторінка завантажується без помітних затримок на мобільному інтернеті.

Для додаткової перевірки використовуйте Google PageSpeed Insights. Він показує лабораторні дані, а для сторінок із достатньою статистикою – також польові дані Chrome UX Report. Оцінюйте не лише підсумковий бал, а й конкретні причини уповільнення: важкі зображення, блокувальні ресурси, сторонні скрипти та затримку відповіді сервера.

Крок 4. Оберіть хостинг під завдання

Для одного простого статичного лендінгу може бути достатньо shared-хостингу. VPS корисний, коли потрібен доступ до налаштувань вебсервера, кілька сайтів, власні правила маршрутизації або додаткові сервіси.

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

VPS або виділений сервер

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

Під час вибору сервера враховуйте:

• локацію – сервер ближче до аудиторії зазвичай зменшує мережеву затримку; для кількох регіонів можна використовувати CDN;
• диск – NVMe корисний для проєктів з активною роботою з файлами та базою даних, але не замінює оптимізацію самої сторінки;
• мережу та ліміти трафіку – перевірте швидкість порту, місячний ліміт і обмеження постійного навантаження;
• IP-адресу – уточніть, чи входить окремий IPv4 у тариф і чи можна замінити адресу за технічної потреби;
• резервне копіювання – дізнайтеся частоту створення копій, строк зберігання та вартість відновлення;
• підтримку та SLA – перевірте години роботи, доступні види допомоги та порядок дій під час збою;
• можливість апгрейду – заздалегідь з’ясуйте, чи можна збільшити CPU, RAM і диск без тривалого перенесення.

Для розміщення лендінгів можна розглянути VPS від Hoster.Solutions, обравши локацію та конфігурацію під завдання. Перед замовленням перевірте правила користування та обмеження конкретного тарифу.

Якщо проєкту потрібні ресурси окремої фізичної машини, можна розглянути виділені сервери Hoster.Solutions.

Крок 5. Розгорніть статичний лендінг на Ubuntu та Nginx

Для початку підготуйте:

• VPS із підтримуваною версією Ubuntu LTS;
• адміністративний доступ через SSH;
• домен;
• готову папку з index.html, стилями, скриптами та зображеннями;
• адресу обробника заявок, якщо форма надсилає дані до зовнішнього сервісу.

Hoster.Solutions встановлює обрану операційну систему, але не надає власні DNS-сервери. DNS-записи можна налаштувати в реєстратора домену або в зовнішньому DNS-сервісі.

1. Підключіться до сервера

Використовуйте користувача, указаного провайдером:

ssh USER@SERVER_IP

Якщо провайдер видав лише доступ root, використовуйте його для первинного налаштування, потім створіть окремого користувача з sudo та налаштуйте вхід за SSH-ключем. Постійна робота під root збільшує наслідки випадкової помилки.

2. Встановіть Nginx

sudo apt update
sudo apt install nginx -y
sudo systemctl status nginx

Після встановлення відкрийте в браузері IP-адресу сервера. Якщо Nginx доступний, з’явиться стандартна сторінка вітання.

3. Налаштуйте firewall

Спочатку дозвольте SSH, щоб не втратити доступ до сервера, потім відкрийте HTTP та HTTPS:

sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable
sudo ufw status

Якщо SSH працює на нестандартному порту, додайте відповідне правило до ввімкнення firewall.

4. Створіть каталог сайту

sudo mkdir -p /var/www/landing
sudo chown -R "$USER":"$USER" /var/www/landing

На локальному комп’ютері завантажте вміст папки з лендінгом:

scp -r ./landing/. USER@SERVER_IP:/var/www/landing/

Конструкція ./landing/. копіює весь вміст каталогу, включно з прихованими файлами.

5. Створіть конфігурацію Nginx

Створіть файл /etc/nginx/sites-available/landing:

server {
listen 80;
listen [::]:80;

server_name example.com www.example.com;

root /var/www/landing;
index index.html;

location / {
try_files $uri $uri/ =404;
}
}

Замініть example.com на свій домен. Якщо піддомен www не використовується, видаліть його з server_name.

Увімкніть конфігурацію та перевірте синтаксис:

sudo ln -s /etc/nginx/sites-available/landing /etc/nginx/sites-enabled/landing
sudo nginx -t
sudo systemctl reload nginx

Якщо nginx -t показує помилку, не перезавантажуйте конфігурацію, доки не виправите її.

6. Налаштуйте DNS

У панелі реєстратора або DNS-сервісу створіть:

• A-запис для основного домену, спрямований на IPv4 сервера;
• A-запис або CNAME для www, якщо цей піддомен використовується;
• AAAA-запис лише в тому разі, якщо на сервері справді налаштовано IPv6.

Активація стандартного VPS у Hoster.Solutions зазвичай займає кілька хвилин. Оновлення DNS частіше відбувається приблизно за годину, але залежно від реєстратора та кешування може зайняти до 24–48 годин.

7. Підключіть HTTPS

Certbot рекомендує більшості користувачів установлення через snap:

sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/local/bin/certbot

Перед випуском сертифіката переконайтеся, що домен спрямовано на сервер, Nginx відповідає через HTTP, а порти 80 і 443 відкриті.

Отримайте сертифікат:

sudo certbot --nginx -d example.com -d www.example.com

Указуйте www.example.com лише за наявності відповідного DNS-запису.

Після встановлення перевірте автоматичне продовження:

sudo certbot renew --dry-run

Відкрийте сайт через https:// та переконайтеся, що HTTP-версія перенаправляє користувача на захищене з’єднання.

Крок 6. Організуйте оплату робочих сервісів

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

У Pay2.House доступні віртуальні картки з BIN різних країн і регіонів для оплати реклами та онлайн-сервісів. Можливість оплати конкретного сервісу залежить від його правил, параметрів картки та самої транзакції, тому перед випуском потрібно перевірити актуальні картки та умови.

Для організації витрат можна використовувати:

• окремі картки для хостингу, доменів, реклами та підписок;
• ліміти та контроль операцій;
• картки та ролі для учасників команди;
• історію транзакцій в єдиному інтерфейсі;
• масовий випуск та API для автоматизації операцій, якщо вони доступні на обраному тарифі.

Наприклад, окрема картка для хостингу та доменів допомагає не змішувати інфраструктурні платежі з рекламними витратами. Перед запуском перевірте баланс, дату наступного продовження та налаштування автоматичного списання в кожного сервісу.

Скільки часу займає підготовка

Якщо шаблон, домен, сервер і обробник заявок уже підготовлені, технічну частину можна виконати за кілька годин. Нижче наведено орієнтир для простого статичного лендінгу:

Ці значення не включають очікування активації нестандартної конфігурації сервера, оновлення DNS, виправлення помилок шаблону та налаштування PHP або іншого серверного застосунку.

Що перевірити перед запуском трафіку

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

Висновок

Підготовка лендінгу до запуску – це не лише перенесення файлів на сервер. Потрібно очистити шаблон від чужих лічильників, налаштувати власну аналітику, перевірити форму та передачу параметрів, підготувати Nginx, DNS і HTTPS, а потім пройти весь користувацький шлях до появи заявки в робочій системі.

VPS дає контроль над конфігурацією, але потребує самостійного налаштування та дотримання обмежень провайдера. Для статичного лендінгу краще починати з простої конфігурації, стежити за фактичним навантаженням і збільшувати ресурси за потреби.

Чим ретельніше перевірено сторінку, сервер, аналітику та платежі до старту, тим менше часу команда витратить на технічні проблеми після запуску трафіку.