Фрілансер перестав відповідати: покроковий план повернення контролю над сайтом

Вісім місяців тиші. Останнє повідомлення читається, але відповіді немає. Ви заходите в адмінку WordPress і бачите 43 оновлення, що очікують. PHP 7.4. Якийсь незнайомий плагін, якого ви не встановлювали. І страшно навіть натиснути “Оновити все”, бо незрозуміло, що після цього станеться.

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

Чому фрілансер перестав відповідати, і це не завжди про вас

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

Зупиніться. Найчастіше зникнення розробника не має нічого спільного з вашим проєктом.

Ось реальні причини, чому фрілансер перестав відповідати:

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

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

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

Крок 0: Інвентаризація доступів, що у вас є прямо зараз

Перш ніж щось робити, складіть список. Відкрийте нотатник або таблицю і дайте відповіді на п’ять запитань.

Перше: хостинг. Ви знаєте, де хоститься сайт? Чи є у вас логін і пароль до панелі хостингу? Оплата йде з вашої картки, чи розробник платить і виставляє рахунок вам?

Друге: домен. Хто реєстрував домен? Чи є у вас доступ до акаунту реєстратора? Коли закінчується термін дії домену?

Третє: WordPress. Чи є у вас логін і пароль до адмінки? Чи пам’ятаєте адресу входу (зазвичай yoursite.com/wp-admin)?

Четверте: FTP або файловий менеджер. Чи є доступ до файлів сайту напряму? Це може знадобитись, якщо щось піде не так під час оновлень.

П’яте: пошта. Яка електронна адреса прив’язана до хостингу, домену і WordPress? Чи є у вас доступ до цієї поштової скриньки?

Що повинно бути у вашому списку доступів

Складіть таблицю з такими колонками:

• Хостинг: назва провайдера, URL панелі, логін, пароль, електронна адреса облікового запису
• Домен: назва реєстратора, URL, логін, пароль, дата закінчення реєстрації
• WordPress адмінка: URL входу, логін адміністратора, пароль
• FTP/SSH: хост, порт, логін, пароль
• База даних: назва, логін, пароль (є в cPanel або в файлі wp-config.php)
• Google Analytics: чи є у вас доступ власника до GA4-властивості вашого сайту
• Google Search Console: чи підтверджений ваш сайт і чи є у вас доступ власника

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

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

Крок 1: Що робити, якщо домен або хостинг оформлені на розробника ⏱ 1-3 дні

Це найболючіший сценарій. Якщо доступів немає зовсім, а розробник не відповідає, потрібно починати з відновлення доступів через провайдерів.

Як перевірити, хто власник домену

Перший крок, WHOIS-пошук. Зайдіть на who.is і введіть ваш домен. Ви побачите:

• Registrant Name, ім’я власника домену
• Registrant Email, контактна пошта власника
• Registrar, реєстратор, у якого зареєстровано домен
• Expiry Date, дата закінчення реєстрації

Якщо ваше ім’я або назва вашої компанії стоїть у полі Registrant, домен формально ваш. Просто потрібно відновити доступ до акаунту реєстратора. Зверніться до підтримки реєстратора і поясніть ситуацію.

Якщо там ім’я розробника, ситуація складніша, але вирішувана.

Домен зареєстрований на розробника, алгоритм дій

Не панікуйте. Ось що робити по кроках:

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

Другий крок. Зверніться до підтримки реєстратора домену. Поясніть ситуацію: ви замовник, розробник не відповідає, домен зареєстровано на його ім’я. Надайте докази.

Третій крок. Для доменів у зоні .UA є окрема процедура через nic.ua. Може знадобитись надати документи, що підтверджують вашу особу або право на домен. Детальна інструкція є на сторінці ukraine.com.ua.

Строки: зазвичай 3-10 робочих днів для перенесення домену. Це небистро, але вирішувано.

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

Хостинг на акаунті розробника, що робити

Хостинг-провайдери стикаються з цією ситуацією регулярно. Вони розуміють, що трапляється, і мають процедури для таких випадків.

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

Що знадобиться надати:

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

Більшість провайдерів вирішують це питання протягом 24-48 годин. Хостинг-провайдери розуміють цю ситуацію, вона трапляється часто.

Якщо хостинг і домен у вас є, або щойно відновлені, рухайтесь далі.

Крок 2: Аудит стану без паніки ⏱ 30 хвилин

Зайшли в адмінку. Добре. Тепер не натискайте нічого, поки не зрозумієте, де ви знаходитесь.

Перше, відкрийте Dashboard → Updates. Подивіться, скільки оновлень чекає. Запишіть: поточна версія WordPress, кількість плагінів з оновленнями, кількість тем з оновленнями. Якщо версія WordPress нижче 6.x, це пріоритет номер один.

Друге, перевірте версію PHP. Зайдіть в Tools → Site Health (документація). Там вказано поточну версію PHP і чи є критичні проблеми. PHP 7.4 і нижче вже не підтримується і є ризиком безпеки. Актуальна версія для WordPress, PHP 8.1 або 8.2.

Site Health показує не тільки PHP. Там є розділ “Critical Issues” і “Recommended Improvements”. Критичні проблеми, це те, що потрібно вирішити в першу чергу. Рекомендовані, потім.

Третє, подивіться на список плагінів у Plugins → Installed Plugins. Чи всі знайомі? Чи є щось, що ви не встановлювали? Активні плагіни, яких ви не впізнаєте, можуть бути ознакою злому або просто залишками роботи попереднього розробника. Не видаляйте їх ще, але зафіксуйте.

Четверте, перевірте наявність SSL-сертифіката. Сайт відкривається через https:// (замок у браузері) чи через http://? Без SSL Google вже рік як понижує сайти в пошуку. Якщо сертифіката немає, зверніться до хостинг-провайдера. Більшість надають Let’s Encrypt безплатно через cPanel.

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

Крок 3: Безпека, перш ніж що-небудь оновлювати ⏱ 20 хвилин

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

Перше: змініть пароль адміністратора WordPress. Зайдіть в Users → All Users. Знайдіть свій акаунт (роль Administrator) і встановіть новий складний пароль. Мінімум 16 символів, комбінація літер, цифр і спецсимволів. WordPress має вбудований генератор паролів, використайте його.

Друге: перевірте список користувачів. Подивіться на всіх адміністраторів. Чи є акаунти, яких ви не впізнаєте? Якщо є підозрілі користувачі з роллю Administrator, видаліть їх негайно.

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

Четверте: перевірте FTP-акаунти. В cPanel або аналогічній панелі знайдіть список FTP-акаунтів. Видаліть або деактивуйте ті, що більше не потрібні.

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

Крок 4: Бекап, до того, як щось чіпати ⏱ 30-60 хвилин

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

Встановіть плагін UpdraftPlus. Це безплатний і надійний інструмент для резервного копіювання, яким користуються мільйони сайтів.

Після встановлення зайдіть в Settings → UpdraftPlus Backups і налаштуйте:

• Куди зберігати: Google Drive або Dropbox. Не на сервер хостингу, інакше бекап і сайт загинуть разом.
• Частота: хоча б раз на тиждень для файлів, раз на тиждень для бази даних.
• Кількість копій: зберігайте мінімум 3 останніх бекапи.

Зробіть ручний бекап прямо зараз, натиснувши “Backup Now”. Дочекайтесь завершення. Зазвичай це займає від 5 до 30 хвилин залежно від розміру сайту. Перевірте, що файли з’явились у вашому Google Drive або Dropbox.

Після бекапу у вас є “точка відновлення”. Навіть якщо щось піде не так під час оновлень, ви зможете повернутись до стану “до” буквально за кілька кліків. Це знімає 90% тривоги, яка заважає починати.

Тільки після цього, до оновлень.

Крок 5: Оновлення, по одному, не всі одразу ⏱ 1-2 години

Якщо у вас 40+ оновлень, спокуса натиснути “Update All” велика. Не робіть цього.

Оновлення по одному дає вам контроль: якщо щось зламалося, ви точно знаєте, що саме стало причиною. “Update All” у разі проблеми залишає вас з питанням “а що саме зламало сайт?” без чіткої відповіді.

Порядок оновлень такий:

Перший: WordPress core. Оновіть саму платформу. Якщо є перехід між мажорними версіями (наприклад, з 5.x на 6.x), прочитайте release notes на wordpress.org, там завжди вказані зміни, що можуть вплинути на сумісність.

Другий: плагіни по одному. Починайте з найважливіших: плагіни безпеки (Wordfence, iThemes Security), кешування (WP Rocket, W3 Total Cache), SEO (Yoast, Rank Math). Після кожного оновлення перевіряйте сайт: головна сторінка, одна з внутрішніх, форма контакту або кошик (якщо є).

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

Третій: теми. Теми оновлюйте в останню чергу. Якщо ви використовуєте дочірню тему (child theme), батьківська тема оновлюється безпечно. Якщо дочірньої немає, оновлення теми може перезаписати ваші зміни у CSS і PHP-файлах. Перед оновленням теми уточніть у нового підрядника, чи є дочірня тема.

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

Що далі: як не потрапити в ситуацію “фрілансер перестав відповідати” знову

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

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

Червоні прапорці при виборі наступного розробника

Це ознаки, які мають насторожити ще на старті:

• Не передає доступи на початку роботи. Якщо через тиждень після початку проекту у вас нема доступу до хостингу і адмінки, це проблема.
• Не пояснює, що робить. Якщо на питання “що ви змінили на сайті?” у відповідь тільки мовчання або технічний жаргон, це погана ознака.
• Немає відповіді більше 48 годин. Не 48 хвилин, а 48 годин. Навіть у вихідні. Хоча б коротке “бачу, відповім у понеділок”.
• Ніколи не ініціює зустрічі або дзвінки. Хороший підрядник хоче розуміти ваш бізнес, а не просто виконувати технічні задачі.
• Немає договору або рахунків. Робота без договору, це ризик для обох сторін, але особливо для вас.

Зелені прапорці

Ознаки надійного підрядника:

• Передає всі доступи в перший тиждень. Без зайвих запитань і затягувань.
• Є договір з переліком зобов’язань. Де написано, що входить у підтримку, яка реакція на звернення, що відбувається при розірванні.
• Реагує протягом 24 годин. Навіть якщо не може вирішити одразу, дає знати, що побачив і коли буде відповідь.
• Пояснює рішення простою мовою. Можливо не завжди у деталях, але хоча б на рівні “оновив плагін безпеки, бо була вразливість”.
• Є план регулярної технічної підтримки. Планові оновлення, перевірки безпеки, бекапи за розкладом.

Якщо ви пройшли всі кроки самостійно, добре. Ваш сайт у значно кращому стані, ніж був. Якщо хочете, щоб хтось взяв це на себе і побудував нормальний процес підтримки, зв’яжіться з нами. Без зникань і без нерозуміння.