Підрядник зник. Що залишилося від твого сайту?

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

Відповіді немає.

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

Ось тут і з’ясовується, що «ми замовили сайт» та «ми можемо ним керувати» - дві різні історії. У першій є рахунок і красивий результат. У другій ще є доступи, зрозумілі відповідальні, оплачені сервіси й можливість запросити нового фахівця без сеансу спіритизму.

Ця стаття допоможе перевірити другу історію. Бажано, поки твій підрядник відповідає швидше, ніж комета повертається до Сонця.

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

Із сайтом залежність може бути схожою. Ти відкриваєш сторінку й бачиш свій бізнес, але за нею є кілька окремих частин. Домен - адреса на кшталт example.com. Хостинг - сервіс, де працює сайт. Адмінка дозволяє змінювати контент. Файли й база даних зберігають те, з чого сайт складається. Пошта приймає звернення. А форма на сторінці ще має кудись їх доставити.

Цими частинами не обов’язково керує одна компанія. Домен може бути в одного постачальника, хостинг - в іншого, корпоративна пошта - у третього. І це нормально, якщо ти знаєш, хто за що відповідає та як туди потрапити.

Проблема починається з відповіді: «Я не знаю, це все Сергій налаштовував».

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

Якщо сайт колись продавали як послугу «під ключ», корисно перевірити, що саме мало входити в результат. Про різницю між красивою назвою пакета й зрозумілою домовленістю ми вже писали в матеріалі «Послуга “під ключ”: як уникнути непорозумінь».

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

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

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

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

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

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

Наступна приємна знахідка: у тебе є пароль від сайту. Можна видихнути? Трохи. Потім варто перевірити, що саме цей пароль дозволяє робити.

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

Тому перевіряй через дію. Чи можеш ти запросити іншого спеціаліста під його власним обліковим записом? Чи бачиш список користувачів? Чи можеш знайти постачальника хостингу, стан оплати та підтримку? Якщо відповідь невідома, попроси пояснити й показати. Знімок екрана з написом «Administrator» приємний, але перевірений вхід із твого пристрою приємніший.

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

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

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

«Бекапи є» - прекрасна фраза. До неї хочеться одразу додати: де, за яку дату й хто перевіряв, що з них можна відновити сайт?

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

Тут важливо знати, що саме копіюється. Наприклад, для повного відновлення типового WordPress-сайту потрібні і файли, і база даних. Файли містять, зокрема, теми, плагіни та зображення; база - записи й інші дані сайту. Це прямо пояснює офіційна документація WordPress про резервні копії. Завантажити лише папку сайту й очікувати повного відновлення може бути недостатньо.

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

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

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

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

Іноді сайт передали нормально, а все, що допомагає зрозуміти його роботу, залишилося у фахівця. Ти отримуєш щомісячний звіт, але не можеш відкрити рекламний кабінет. Бачиш графік відвідувань у презентації, але не знаєш, де сама аналітика. Гарні діаграми є. Доступу немає. Бізнес у жанрі «повір мені, я дивився».

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

У Google Ads є різні рівні доступу з різними можливостями. Вони перелічені в офіційній довідці Google. Окремо існують керуючі акаунти агенцій. Позначка їхньої «власності» всередині платформи описує набір адміністративних повноважень; не варто робити висновки лише з одного слова в інтерфейсі. Деталі зв’язку пояснює довідка про керуючі акаунти. Практична мета - переконатися, що твій бізнес має перевірений доступ і розуміє, як змінити виконавця.

У Google Analytics доступ може надаватися на рівні акаунта або окремого ресурсу - тобто конкретного об’єкта аналітики. Для додавання й зміни користувачів потрібна відповідна роль адміністратора; права вищого рівня впливають на нижчі. Це описано в документації Google Analytics. Сам факт, що ти бачиш звіт, ще не відповідає на питання, чи можеш керувати потрібними доступами.

Однак не видаляй підрядника з усіх сервісів одним натисканням, поки не зрозумів зв’язки. Форми можуть надсилатися через окремий поштовий сервіс, події - налаштовуватися через Google Tag Manager, а заявки - потрапляти в CRM, систему обліку клієнтів. Перед зміною доступів варто скласти карту цих зв’язків і перевірити передачу.

Якщо треба розібратися, що саме вимірюється та куди потрапляють дані, це вже задача налаштування аналітики. А для перевірки рекламного акаунта й вимірювання результатів можна почати зі сторінки Google Ads. Назва послуги сама по собі нічого не виправить; корисний результат тут - зрозумілі доступи, зв’язки й перевірена робота.

Не кожна залежність від підрядника виникла через поганий намір. На старті всім хотілося запуститися, людина створила потрібні акаунти, а передати їх нормально потім не встигли. Те саме «потім», у якому вже живуть оновлення прайсу, нові фото й відпустка.

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

Можна написати так:

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

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

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

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

Потім пройди перевірку в такому порядку:

1. Увійди сам. Домен, хостинг, адмінка, основна пошта, рекламний акаунт та аналітика - там, де вони є у твоєму бізнесі. Не користуйся відкритою сесією підрядника як доказом свого доступу.
2. З’ясуй свої права. Чи можеш запросити нового виконавця? Які зміни доступні тобі, а для яких треба звернутися до іншого адміністратора?
3. Перевір відновлення доступу. Які контакти та способи підтвердження налаштовані? Чи контролює їх відповідальна людина в бізнесі? Не скидай робочі паролі просто заради експерименту.
4. Знайди оплати й строки. Домен, хостинг, пошта, ліцензії. Запиши, хто отримує рахунки та як дізнається про продовження.
5. Попроси перевірку резервної копії. Де вона, що містить, за яку дату й чи можна з неї відновитися в тестовому середовищі?
6. Надішли контрольне звернення. Заздалегідь погодь тест, перевір отримання заявки й те, чи не створює він зайвих дій у робочих системах.

Припустімо, ти власник невеликої майстерні. Домен продовжуєш сам, адмінку бачиш, але форма пише «Дякуємо!» і подальша доля звернення невідома. Умовний висновок із цієї перевірки - спочатку розібратися з доставкою заявки. Міняти весь сайт для цього ще не потрібно. Повідомлення про успіх на сторінці не доводить, що лист або запис у CRM справді отримано.

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

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

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

Звертайся до офіційної підтримки конкретного постачальника. Реєстратор, хостинг і рекламна платформа мають різні процедури перевірки та відновлення. Що саме вони зможуть зробити, залежить від обставин і підтверджень. Обіцянка «повернемо все, просто заплати» без перевірки акаунтів звучить красиво, але поки що це лише обіцянка.

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

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

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

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