Почему ваш веб-сайт сломался после того, как разработчик ушел
Паттерн, который постоянно повторяется
Разработчик завершает работу. Передает сайт. Все выглядит хорошо. Клиент доволен.
Через три месяца: сайт загружается медленно. Или плагин перестал работать. Или платежи не проходят. Или сайт полностью падает. Разработчик не отвечает.
Это не неудача. Это предсказуемое следствие того, как большинство небольших веб-проектов передаются.
Причина 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:
- Обновление плагинов и темы: ежемесячно
- Мониторинг безопасности: постоянно
- Резервное копирование: ежедневное или еженедельное автоматическое
- Периодическая проверка платежного потока и ключевых страниц: ежемесячно
Ничто из этого не является постоянной ответственностью разработчика, если вы специально за это не платите. Если никто этого не делает, сайт будет деградировать.
Настройка на долгосрочную стабильность
При передаче проекта попросите у разработчика:
- Список всех плагинов и их назначение
- Данные для входа на хостинг и домен
- Как безопасно обновлять плагины (обновлять по одному, проверять после каждого)
- Какие шаги предпринять, если сайт перестал работать (например, проверить хостинг, обновить плагины)
- Настроено ли автоматическое резервное копирование
Пять минут документации при передаче предотвращают часы кризисного управления позже.
Если вы попробовали шаги выше и сайт все еще не работает (или не хотите делать это самостоятельно) — обратитесь к нам, и мы быстро разберемся с проблемой.