Що саме може «зникнути» разом із сайтом?
Коли кажуть «мій сайт», уявляють один предмет. Насправді це ланцюжок. Домен — адреса, яку вводить відвідувач. DNS-записи підказують інтернету, який сервер відповідає за цю адресу. Хостинг — місце, де сайт працює. Код — джерело, з якого сайт збирають і оновлюють. А навколо — акаунти: реєстратор домену, панель хостингу, репозиторій коду, Search Console і аналітика.
У кожної ланки є логін, а в кожного логіна — власник. Сайт справді ваш лише тоді, коли ви потрапляєте в кожен із цих акаунтів, нікого не просячи про дозвіл. Якщо ні, щоб втратити сайт, не потрібен злам. Досить закритої фірми, забутого пароля, несплаченого рахунку чи сварки з тим, у кого логін.
Хто вважається власником домену?
Власник — це реєстрант: людина чи компанія, записана в реєстратора, який зареєстрував домен. ICANN, організація, що координує систему доменів, описує його роль на сторінці Registrants' Benefits and Responsibilities: реєстрант сам відповідає за реєстрацію та використання назви, подає достовірні контактні дані й оновлює їх. Ці обов'язки лежать на тому, хто вказаний у записі, а не на тому, хто заплатив рахунок чи зробив сайт.
Саме тут ховається ризик, коли розробник «для зручності» реєструє домен у власному акаунті. Реєстратор бачить власником його, а не вас, і слухає його вказівок. Нагадування про продовження теж приходять на його пошту.
Чому переносити домен повільно, якщо він не на вас?
Щоб перенести домен до іншого реєстратора, його власник просить у поточного код авторизації, який часто називають AuthInfo або EPP-кодом. У FAQs for Registrants: Transferring Your Domain Name від ICANN сказано, що цей код допомагає ідентифікувати власника й запобігає несанкціонованим переносам, а реєстратор мусить надати його протягом п'яти календарних днів після запиту. Видають його лише власнику за записом. Якщо це не ви, перший крок — запит до того, хто ним є.
Є й друга затримка. У тому ж FAQ сказано, що домен, як правило, не можна перенести до іншого реєстратора протягом 60 днів після зміни імені реєстранта, хоча деякі реєстратори дозволяють відмовитися від цього блокування. А ще реєстратор може відхилити перенос протягом 60 днів після першої реєстрації. Тож поспішна передача після конфлікту може на два місяці прив'язати сайт до старої домовленості. На старті проєкту ця сама зміна — звичайний технічний крок.
Чому контроль над DNS важить стільки ж, скільки сам домен?
DNS-записи вирішують, куди веде адреса, а документація Cloudflare про власні домени для Pages добре показує, скільки від них залежить. Щоб сайт працював на «голому» домені на кшталт example.com, домен потрібно додати як зону в акаунт Cloudflare й направити на Cloudflare його сервери імен. Для піддомену на стороні DNS-провайдера додають CNAME-запис, що веде на проєкт. Якщо додати цей запис раніше, ніж прив'язати домен у панелі Pages, попереджає документація, адреса не відкриється й покаже помилку 522.
Прочитайте це навпаки: хто керує DNS-акаунтом, той за кілька хвилин може перенаправити вашу адресу. Тому «домен на мене» — лише половина відповіді. Запитайте ще, де знаходяться сервери імен і чий акаунт ними керує.
Де в цьому хостинг і код?
Хостинг — це акаунт, на якому працює сайт і на який приходить рахунок. Якщо розробник тримає кількох клієнтів в одному акаунті, ваш сайт — лише папка в його налаштуваннях. Просіть акаунт на своє ім'я, навіть якщо розробник його створює й щодня обслуговує.
Код зазвичай зберігається в репозиторії, а на багатьох проєктах репозиторій ще й публікує сайт. На проєкті Fedenko, наприклад, кожен пуш у головну гілку автоматично публікується на хостингу через GitHub Actions. Коли публікація прив'язана до репозиторію, він і є пультом керування: хто його володар, той вирішує, що піде в мережу. Володарем, а не просто співробітником, маєте бути ви.
Чому акаунти Search Console і аналітики теж мають бути вашими?
Довідка Google Verify your site ownership пояснює механізм. Підтверджений власник має найвищий рівень дозволів. Підтвердження діє, доки Search Console бачить токен підтвердження. Якщо видалити HTML-файл підтвердження, воно скасовується, а DNS-запис, що використовується для підтвердження, має залишатися на місці. Якщо всі підтверджені власники втрачають доступ, його втрачають усі користувачі ресурсу.
Практичний висновок: першим підтвердженим власником маєте бути ви, а розробника додають як додаткового власника чи користувача й прибирають, коли роботу завершено. Пошукові дані сайту накопичуються саме в цьому акаунті, а сайт, що переїхав у новий порожній ресурс, починає читати статистику з нуля. Саме тому в послузі SEO, аналітика й налаштування Google ці акаунти створюються на ваше ім'я.
Як за чверть години перевірити власну ситуацію?
- Увійдіть до реєстратора зі своєю поштою. Якщо не виходить, з'ясуйте, хто може, і чиє ім'я стоїть у записі реєстранта.
- Запишіть дату продовження та адресу, на яку приходить нагадування.
- З'ясуйте, де керують DNS і в кого цей логін.
- Запитайте, на кого оформлено акаунт хостингу та його рахунки.
- Запитайте, хто володар репозиторію коду і чи він же публікує сайт.
- Відкрийте Search Console і аналітику та перевірте, що ви власник, а не гість.
- Переконайтеся, що пошта, прив'язана до цих логінів, під вашим контролем і не є скринькою на домені самого сайту. Якщо домен прострочиться, зникне й скринька, а скидання паролів перестане працювати.
- Увімкніть двоетапну перевірку в кожному акаунті й тримайте коди відновлення в себе.
Що не дає домену прострочитися?
Домен реєструють на певний строк, і коли цей строк закінчується без продовження, він перестає працювати. На сторінці ICANN для реєстрантів перелічено звичайні обов'язки, які цьому запобігають: відповідати на запити реєстратора протягом 15 днів, підтримувати актуальними дані акаунта і, якщо ввімкнено автопродовження, актуальними платіжні дані. Нічого складного, але все це припускає, що листи реєстратора доходять до людини, яка їх справді читає.
Саме тому контактна пошта в акаунті реєстратора має бути спільною робочою адресою, а не особистою скринькою одного працівника чи розробника. Коли ця людина йде, нагадування не повинні йти разом із нею. Занесіть дату продовження в календар, який бачить більше однієї людини, і одразу перевірте, коли спливає строк дії платіжної картки.
Що має містити акт передачі доступів?
Щоразу, коли розробник створює чи перебирає ваш сайт, просіть односторінкову нотатку з передачі й зберігайте її разом із документами компанії. Вона не мусить бути довгою, але в ній не має бути прогалин.
- Усі акаунти з адресою входу, іменем, на яке кожен зареєстрований, і поштою, що отримує його листи.
- Реєстратор, ім'я реєстранта та дата продовження домену.
- Де керують DNS і які записи важливі, зокрема ті, що використовуються для підтвердження Search Console чи пошти.
- Акаунт хостингу, спосіб публікації сайту та місце зберігання коду.
- Хто має доступ сьогодні, з яким рівнем прав і кого слід прибрати після завершення робіт.
- Де зберігаються коди відновлення та пристрої для двоетапної перевірки.
Найбільше така нотатка потрібна в день, коли щось ламається. Сайт, який вимкнувся п'ятничного вечора, значно легше відновити, коли людина, що має діяти, знаходить потрібний логін за кілька хвилин, а не перешукує старе листування.
Як це влаштовано на моїх проєктах?
Я фіксую письмово два правила: ціна в договорі не змінюється, а домен, хостинг, код і всі доступи оформлені на вас. Тому передача — останній із чотирьох кроків на сторінці сайту під ключ: сайт запускається на домені та хостингу на ваше ім'я, а ви отримуєте код і всі доступи. На проєкті Oskar, редизайні дельфінарію, який ще в роботі, запуск на власному домені замовника запланований після того, як він затвердить готовий сайт.
Що робити, якщо сайт уже оформлений на когось іншого?
- Письмово попросіть перелік усіх акаунтів, пов'язаних із сайтом, із зазначенням, на кого кожен записаний.
- Почніть із домену, бо він найповільніший. Попросіть реєстранта розблокувати його й надіслати код авторизації або змінити реєстранта на вас, і врахуйте 60-денне блокування.
- Далі перейміть DNS, хостинг і репозиторій — саме в такому порядку.
- Лише після цього робіть новий сайт чи редизайн. Редизайн на чужих акаунтах просто переносить проблему на наступну версію.
- Якщо людина не виходить на зв'язок, звертайтеся до підтримки реєстратора. Сторінка ICANN про права реєстрантів стверджує, що ви маєте право на чітку інформацію про канали підтримки та вирішення спорів у реєстратора.