Як опублікувати сайт у Google: домен, GitHub і sitemap

Що це за кейс і що буде на виході

«Вайб-Кодинг» починався не як великий медіапроєкт, а як сайт української Telegram-спільноти. Його головне завдання просте: відповідати на практичні запити про AI-розробку, давати перевірені матеріали українською та допомагати зацікавленій людині перейти в чат.

Для запуску не була потрібна традиційна команда з дизайнера, верстальника, SEO-фахівця й адміністратора сервера. AI допоміг підготувати структуру, тексти, HTML і CSS, але рішення про призначення сторінок, перевірку фактів, домен, безпеку та публікацію залишилися за людиною.

Крок 1. Спочатку структура, потім дизайн

Одна довга головна сторінка може презентувати проєкт, але погано відповідає на різні наміри користувачів. Людина, яка шукає визначення вайб-кодингу, потребує іншої відповіді, ніж та, що намагається захистити API-ключ або створити сайт із Lovable.

Тому контент було розділено на окремі повноцінні матеріали: пояснення терміна, практичне порівняння AI-інструментів для програмування, створення сайту з ШІ, безпека ключів, перевірка AI-коду та сторінка української Telegram-спільноти. Кожна сторінка отримала власні title, description, H1, canonical і зрозумілу URL-адресу.

Перед генерацією сторінки корисно дати AI такий запит:

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

Крок 2. Розділіть GitHub і хостинг

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

GitHub не обов’язково є хостингом. Репозиторій може зберігати код, а сайт — працювати на Sites, Vercel, Netlify, Cloudflare Pages або іншій платформі. Для простого статичного HTML можна використати GitHub Pages. Офіційно він уміє публікувати файли з вибраної гілки або через GitHub Actions; другий варіант потрібен, коли перед публікацією сайт треба зібрати.

1. Створіть репозиторій. Для відкритого навчального сайту він може бути публічним. Для комерційного проєкту або коду з конфігурацією обирайте приватний.
2. Збережіть першу робочу версію. Це ваша точка повернення до того, як AI почне наступну серію правок.
3. Робіть один логічний коміт на задачу. Наприклад: «додати мобільне меню» або «підключити аналітику», а не «оновлення сайту».
4. Переглядайте diff. Переконайтеся, що агент не видалив метатеги, аналітику, перевірку Search Console або важливий текст.
5. Не зберігайте секрети. API-ключі, паролі й токени не повинні потрапляти в репозиторій навіть на кілька хвилин.

Відкритий репозиторій «Вайб-Кодингу» також пов’язує бренд сайту з реальним GitHub-профілем і може містити корисні шаблони. Але репозиторій не варто створювати лише заради посилання: він має давати людині файли, приклади або зрозумілу історію змін.

Крок 3. Власний домен, DNS і HTTPS

Безкоштовна адреса платформи підходить для тесту. Для довготривалого проєкту власний домен простіше запам’ятати, поширювати й переносити між платформами. У цьому кейсі використовується vibe-coding.com.ua.

Платформа публікації показує, які DNS-записи потрібно додати у реєстратора домену. Для кореневого домену це часто A-записи, для піддомену www — CNAME. Значення не можна копіювати з чужого гайда: вони залежать від конкретної платформи й можуть змінитися.

• Основна адреса відкривається через https:// без попередження браузера.
• http:// перенаправляє на HTTPS.
• Варіант із www не показує інший або застарілий сайт.
• На всіх сторінках canonical указує на вибрану основну версію домену.
• Сертифікат охоплює потрібні варіанти адреси.

DNS оновлюється не миттєво. Під час нашого підключення різні варіанти адреси певний час показували суперечливі результати, тому перевіряли не лише головну, а й HTTP, HTTPS та www. Це важливо і для людей, і для Google: пошуковик не повинен бачити кілька різних версій одного сайту.

Якщо використовуєте GitHub Pages, спочатку додайте домен у налаштування Pages, а вже потім змінюйте DNS. GitHub радить окремо підтвердити домен TXT-записом: це зменшує ризик, що після від’єднання репозиторію чужий акаунт перехопить адресу. Не використовуйте wildcard-запис *.example.com без реальної потреби.

Крок 4. Як додати сайт у Google

Публікація сайту ще не означає миттєву появу в пошуку. Є три окремі етапи: сайт доступний людям; Google знаходить і сканує URL; після оцінки сторінка може потрапити до індексу. Search Console допомагає з виявленням і діагностикою, але не купує місце в результатах.

1. Виберіть одну основну адресу. Наприклад, https://example.com/page. Саме вона має стояти в canonical, sitemap і внутрішніх посиланнях; інші версії повинні перенаправлятися.
2. Створіть robots.txt. Він не повинен випадково забороняти потрібні сторінки. Додайте повну адресу sitemap.
3. Створіть sitemap.xml. Додайте абсолютні canonical-адреси лише тих сторінок, які справді мають потрапити в пошук. Оновлюйте lastmod тільки після суттєвої зміни вмісту.
4. Додайте ресурс у Search Console. Domain property охоплює HTTP, HTTPS і всі піддомени та підтверджується через DNS. URL-prefix property охоплює лише точний префікс і підтримує більше методів підтвердження.
5. Подайте sitemap один раз. Search Console покаже, чи Google зміг прочитати файл. Повторно надсилати незмінний sitemap щодня не потрібно.
6. Перевірте найважливіші URL. URL Inspection показує доступність, індексацію та canonical, вибрану Google. Для кількох нових або суттєво оновлених сторінок можна натиснути «Request indexing».

Мінімальний robots.txt для відкритого інформаційного сайту:

Мінімальний запис у sitemap для однієї сторінки:

А на самій сторінці в <head>:

Google вказує реалістичний діапазон від кількох днів до кількох тижнів. Запит сканування не гарантує індексацію, а повторне натискання для того самого URL не прискорює процес. Якщо сторінка не з’явилася, спершу перевірте технічну доступність, canonical, унікальність і внутрішні посилання, а не створюйте її дублікат.

Крок 5. Перевірте опубліковану версію

Локальний файл і бойовий сайт можуть поводитися по-різному. Перевіряйте саме публічну адресу після розгортання, бажано у приватному вікні браузера та на телефоні.

Для швидкої технічної перевірки можна виконати curl -I https://example.com/page. У відповіді шукайте фінальний статус 200; для старої адреси нормально побачити 301 або 308 і заголовок location із правильною новою URL. Це не замінює перегляд сторінки в браузері, але швидко знаходить зайві перенаправлення.

Крок 6. Вимірюйте корисну дію, а не лише перегляди

Для «Вайб-Кодингу» перегляд статті — не кінцева мета. Важливо зрозуміти, чи людина після читання переходить у Telegram. Тому GA4 підключено на всіх сторінках, а натискання посилання на чат надсилає окрему подію telegram_click.

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

Для зовнішніх публікацій додавайте UTM-параметри до посилання на сайт. Тоді можна відрізнити перехід із конкретного допису від звичайного прямого відвідування. А для Telegram варто використовувати окремі запрошувальні посилання за джерелами, якщо потрібно рахувати вже не кліки, а фактичні вступи.

Що в цьому процесі найчастіше ламається

• Усе розміщено на одній сторінці. Читачеві важко знайти точну відповідь, а Google — визначити тему кожного блоку.
• AI отримує надто загальний промпт. Результат виглядає ефектно, але не має конкретної аудиторії, перевірок і наступної дії.
• Немає Git-історії. Після невдалої правки доводиться відновлювати сайт вручну.
• Домен налаштований частково. Основна адреса працює, а www або HTTP веде на помилку чи стару сторінку.
• Sitemap містить неправильні адреси. Відносні URL, дублікати або неосновні версії домену створюють плутанину.
• Аналітика рахує лише перегляди. Власник не знає, які сторінки приводять заявки, покупки або переходи в спільноту.
• Публікуються десятки слабких AI-текстів. Це не створює довіру й не замінює власний досвід, перевірені приклади та зрозуміле авторство.

Що можна зробити безкоштовно, а за що доведеться платити

GitHub, Google Search Console та базове використання GA4 доступні без оплати. Простий сайт також можна створити й опублікувати на безкоштовному плані AI-конструктора або хостингу, якщо його обмежень достатньо.

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

Фінальний чекліст запуску

• Кожна сторінка вирішує окрему задачу користувача.
• Сайт нормально читається на телефоні й не має горизонтального прокручування.
• Код збережено в GitHub, а важливі зміни мають зрозумілі коміти.
• У репозиторії немає API-ключів, паролів і приватних даних.
• Основний домен, HTTPS, HTTP і www працюють узгоджено.
• На сторінках є унікальні title, description, H1 і canonical.
• robots.txt доступний і посилається на актуальний sitemap.
• Search Console підтверджена, а sitemap прийнято без помилок.
• Аналітика фіксує не лише перегляди, а й головну корисну дію.
• Кнопка або форма перевірена як звичайним користувачем, а не лише власником.

Поширені запитання

Чи можна опублікувати сайт і додати його в Google безкоштовно?

Так. GitHub, Search Console та базова GA4 доступні без оплати, а для простого статичного сайту можна знайти безкоштовний хостинг. Головна передбачувана витрата — власний домен.

Чи гарантує sitemap появу в Google?

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

Скільки чекати на індексацію після запиту?

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

Навіщо GitHub, якщо сайт уже відкривається?

Щоб мати історію, порівнювати AI-правки й швидко повернутися до робочої версії. Репозиторій і хостинг при цьому можуть бути різними сервісами.