Уяви це як три коробки. Cursor — місце, де ти редагуєш сайт. GitHub — безпечна копія з історією змін. Vercel — публічна версія, яку люди відкривають у браузері. Якщо ці три місця налаштовані нормально, сайт можна змінювати без страху все втратити.
Що отримаєш
- Репозиторій GitHub, де сайт безпечно зберігається
- Проєкт Vercel з робочим публічним посиланням
- Зрозумілий список приватних налаштувань: ключі форми, email-токени й подібні речі
- Простий порядок оновлень: правка, збереження, публікація, перевірка
- Шлях відкату, якщо нова версія зламає сайт
● Кроки
Від Cursor до живого сайту: GitHub і Vercel без паніки
Підготуй проєкт перед публікацією
Відкрий сайт у Cursor і перевір, що він запускається на твоєму комп'ютері. Команду зазвичай видно в package.json, найчастіше це npm run dev. Відкрий локальне посилання в браузері й пройди основні сторінки. Результат: ти знаєш, що проєкт не був зламаний ще до GitHub і Vercel.
Створи репозиторій GitHub
Зайди на GitHub, створи новий репозиторій і дай йому просту назву, наприклад bakery-website або clinic-site. Якщо проєкт ще сирий, зроби репозиторій приватним. Результат: у тебе є порожня онлайн-папка, де сайт буде зберігатися з історією змін.
Збережи першу версію коду
У Cursor відкрий панель Source Control або термінал. Додай файли, напиши коротке повідомлення на кшталт first working version і відправ код у GitHub. Не змішуй перший збережений варіант із десятьма експериментами. Результат: у GitHub лежить той самий проєкт, який є на твоєму комп'ютері.
Імпортуй репозиторій у Vercel
Відкрий Vercel, вибери Add New Project, укажи репозиторій із GitHub і дай Vercel визначити тип проєкту. Перед кнопкою Deploy перевір команду збірки й налаштування, які показує Vercel. Результат: Vercel збирає сайт із GitHub, а не з випадкової папки на ноутбуці.
Додай приватні налаштування у Vercel
Якщо на сайті є форма, відправка листів, аналітика або платний API, додай ключі у Vercel Project Settings -> Environment Variables. Ніколи не вставляй приватні ключі у звичайні файли з кодом. Результат: публічний сайт може користуватися приватними сервісами, але відвідувачі не бачать секрети.
Перевір живе посилання як клієнт
Відкрий посилання Vercel на телефоні й комп'ютері. Перевір меню, кнопки, форму, повідомлення після відправки, загальне відчуття швидкості й очевидні помилки в тексті. Відправ тестову заявку самому собі. Результат: ти підтверджуєш, що сайт працює для реального відвідувача, а не лише всередині Cursor.
Використовуй безпечний порядок оновлень
Для кожної майбутньої правки: зміни в Cursor, перевір локально, збережи маленький commit, відправ у GitHub, дочекайся preview у Vercel і тільки потім перевір production. Якщо нова версія щось зламала, відкрий Vercel Deployments і поверни попередній робочий deployment. Результат: ти можеш покращувати сайт без паніки й без здогадок, як усе відновити.
Де найчастіше ламається
- Тримати єдину копію проєкту тільки в Cursor або папці Downloads
- Публікувати до перевірки, що сайт запускається локально
- Вставляти приватні ключі прямо у файли з кодом
- Змінювати налаштування у Vercel і не записувати, що саме змінилось
- Не тестувати живу форму після деплою
- Робити величезні змішані commits, які складно відкотити
Деплой застряг або страшно чіпати?
Надішли посилання GitHub, скрін проєкту Vercel і живий URL. Я знайду, де рветься ланцюг, і залишу зрозумілий порядок публікації, який можна повторювати.
- Build падає, а помилка незрозуміла
- Environment variables відсутні або задубльовані
- Живий сайт працює інакше, ніж у Cursor
- Потрібен безпечний відкат перед змінами на production
● Пов'язані гайди
Пов'язані гайди
Не хочеш платити за сайт? Зроби сам.
Практичний шлях від ідеї до live-сайту: AI-assisted coding, GitHub, Vercel, домен, форма та базове SEO.
TAPE-03Промпти для Cursor, щоб він не робив сміття
Структура промпта для сайтів малого бізнесу: контекст, секції, обмеження, перевірки та цикл правок.
TAPE-04Чому AI-сайти виглядають як дешеві демо
Типовий патерн провалу: фейковий copy, слабкий офер, зламаний mobile, немає форм та індексації.