Чому ваш веб-сайт зламався після того, як розробник пішов
Патерн, який постійно повторюється
Розробник завершує роботу. Передає сайт. Все виглядає добре. Клієнт задоволений.
Через три місяці: сайт завантажується повільно. Або плагін перестав працювати. Або платежі не проходять. Або сайт повністю падає. Розробник не відповідає.
Це не невдача. Це передбачуваний наслідок того, як більшість невеликих веб-проєктів передаються.
Причина 1: Оновлення WordPress і плагінів
WordPress оновлюється. WooCommerce оновлюється. Кожен плагін оновлюється — іноді щотижня. Ці оновлення необхідні для безпеки, але вони можуть зламати щось.
Коли розробник створює ваш сайт, все працює з тими версіями, які існували на той момент. Коли через три місяці виходить WordPress 6.5, а ваша тема була створена для 6.3, щось може зламатися.
Це не провина розробника за те, що він це створив — це частина реальності роботи сайту на WordPress. Але це означає, що хтось повинен керувати оновленнями, тестувати після кожного оновлення та виправляти несумісності. Якщо ніхто цього не робить — сайт поступово ламається сам.
Що робити: Оновлюйте плагіни вручну: зайдіть в адмін-панель WordPress → Оновлення. Оновлюйте по одному плагіну, після кожного перевіряйте, чи працює сайт. Особливо тестуйте сторінки оформлення замовлення та контактні форми. Не просто натискайте "Оновити все" та йдіть.
Причина 2: Термін дії хостингу закінчується або змінюється
Провайдери хостингу змінюють версії PHP. Те, що працювало на PHP 7.4, може не працювати на PHP 8.2. Термін дії планів хостингу закінчується. Змінюються ліміти ресурсів.
Сайт, який ідеально працював на одній конфігурації сервера, може зламатися після оновлення сервера. Це інфраструктурний дрейф — сайт був стабільним, а середовище навколо нього змінилося.
Що робити: Знайте свого хостинг-провайдера. Налаштуйте нагадування про продовження. Коли хостинг повідомляє про зміну версії PHP або міграцію сервера — негайно протестуйте ваш сайт після цього. Зайдіть у панель хостингу (cPanel або аналог) та перевірте, яка версія PHP зараз встановлена; якщо потрібно, тимчасово відкладіть зміну або зверніться в підтримку хостингу. Не ігноруйте ці листи.
Причина 3: Сторонні сервіси змінили своє API
Ваш сайт підключається до платіжних шлюзів, служб доставки, CRM-систем, поштових провайдерів. Будь-який з них може оновити своє API, змінити методи автентифікації або припинити підтримку функції.
Коли Liqpay оновлює свій процес оформлення замовлення, ваша платіжна інтеграція WooCommerce може перестати працювати. Коли Nova Poshta змінює версію API, ваш автозаповнення адреси ламається. Це не помилки вашого сайту — це зміни зовнішніх сервісів.
Що робити: Знайте, які зовнішні сервіси залежать від вашого сайту. Коли щось ламається, перевірте, чи опублікував сервіс якісь оновлення. Також перевірте, чи вийшло оновлення плагіна, що відповідає за цей сервіс — часто розробники випускають сумісну версію.
Причина 4: Сайт ніколи не був повністю стабільним
Іноді розробник здав щось, що працювало в його тестовому середовищі, але мало приховані проблеми в робочій конфігурації. Сайт працював нормально певний час, а потім щось переповнило чашу — стрибок трафіку, додатковий плагін, база даних, яка стала більшою.
Це важче виявити без належного проміжного середовища та навантажувального тестування, яких більшість невеликих проєктів не включають.
Що робити: Під час приймання пройдіть весь шлях клієнта: додайте товар у кошик, оформіть замовлення, надішліть контактну форму, перевірте електронні листи. Спробуйте крайні випадки — наприклад, дуже довгі назви або неправильні індекси. Чим більше ви тестуєте при передачі, тим раніше виявите нестабільності.
Причина 5: Ніхто не спостерігає
Багато сайтів ламаються мовчки. Помилка з'являється лише за певних умов. Сторінка, яка рідко отримує трафік, має помилку, яку ніхто не помічає. Сайт працює добре для 95% відвідувачів, але не працює для 5%, які використовують конкретний телефон або браузер.
Якщо ніхто не моніторить сайт, проблеми можуть існувати тижнями, не будучи виявленими.
Що робити: Налаштуйте базовий моніторинг доступності (UptimeRobot безкоштовний). Отримуйте сповіщення електронною поштою, коли сайт падає. Перевіряйте свій сайт на телефоні раз на тиждень.
Питання про обслуговування, яке ніхто не задає
До завершення проєкту запитайте: "Що потрібно цьому сайту, щоб продовжувати добре працювати, і хто це робить?"
Чесна відповідь для сайту на WordPress/WooCommerce:
- Оновлення плагінів і теми: щомісяця
- Моніторинг безпеки: постійно
- Резервне копіювання: щоденне або щотижневе автоматичне
- Періодична перевірка платіжного потоку та ключових сторінок: щомісяця
Ніщо з цього не є постійною відповідальністю розробника, якщо ви спеціально за це не платите. Якщо ніхто цього не робить, сайт деградуватиме.
Налаштування на довгострокову стабільність
При передачі проєкту попросіть у розробника:
- Список усіх плагінів та їх призначення
- Дані для входу на хостинг та домен
- Як безпечно оновлювати плагіни (оновлювати по одному, перевіряти після кожного)
- Які кроки зробити, якщо сайт перестав працювати (наприклад, перевірити хостинг, оновити плагіни)
- Чи налаштоване автоматичне резервне копіювання
П'ять хвилин документації при передачі запобігають годинам кризового управління пізніше.
Якщо ви спробували кроки вище й сайт все ще не працює (або не хочете робити це самостійно) — зверніться до нас, і ми швидко розберемося з проблемою.