С помощью нейросети можно быстро собрать первую версию сайта: витрину, каталог, корзину и админку. Такой подход часто называют вайб-кодингом. Но готовый экран еще не показывает, что произойдет с заказом, кто сможет прочитать данные и как восстановить сайт после сбоя.
В нашей практике был интернет-магазин Belkson, который нестабильно открывался из России, а затем перестал запускаться на зарубежной платформе. Перенесли сайт и базу на сервер в России, настроили доступы, резервные копии и обновления. За три дня выпустили 14 релизов. Этот опыт полезен для проверки быстро собранных сайтов независимо от того, каким инструментом их создавали.
Ниже девять вопросов, которые стоит разобрать до первых заказов. Часть проверок можно выполнить самостоятельно, а для проверки прав доступа и восстановления потребуется помощь разработчика.
1. Открывается ли сайт у ваших клиентов
Проверьте публичную ссылку с компьютера и телефона, через домашнюю сеть и мобильный интернет. Если клиенты находятся в России, проверьте доступность оттуда без VPN. Пройдите весь путь от главной до отправки заявки или оформления заказа.
Запишите, где возникают ошибки. Сам факт размещения в определенной стране не гарантирует доступность сайта: значение имеют также внешние подключения и настройки приложения.
2. Где хранятся данные клиентов
Выясните, куда записываются заявки и заказы, где лежат загруженные файлы и кто имеет к ним доступ. У сайта могут быть разные поставщики размещения, базы, аналитики и почты.
Зафиксируйте эту схему и передайте ее специалисту, который проверяет требования к обработке персональных данных в вашем проекте. Адрес главной страницы или расположение одного сервера не дают полной картины. Техническая проверка не заменяет юридическую оценку.
3. Закрыты ли функции админки
Страница входа сама по себе не доказывает, что данные защищены. Проверять нужно запросы, которые читают и изменяют заказы, товары и цены.
На тестовой копии попросите разработчика показать, что посетитель без входа и обычный пользователь не получают права администратора. Не проводите такие проверки на чужих сайтах.
4. Как устроен доступ администратора
Уберите тестовые учетные записи, которые больше не нужны, и замените пароли из примеров. Для администратора используйте уникальный пароль и второй фактор, если он поддерживается.
Уточните, как реализовано хранение паролей. Их не следует сохранять открытым текстом или в публичном коде. Для собственной системы входа нужна корректная реализация безопасного хеширования, которую проверяет разработчик.
5. Можно ли восстановиться из копии
Спросите, какие данные копируются, как часто и где находятся копии. Затем проверьте восстановление на отдельном окружении. Наличие архива еще не означает, что из него получится запустить приложение.
Код, база заказов и фотографии могут храниться отдельно. Убедитесь, что копирование охватывает необходимые части, и согласуйте допустимую потерю последних изменений при сбое.
6. Какие внешние сервисы нужны сайту
Составьте список подключений: шрифты, изображения, вход, почта, оплата и другие функции. Проверьте, что видит пользователь при недоступности каждого важного сервиса.
Статические ресурсы, которые можно размещать самостоятельно, стоит рассмотреть для локального хранения. Для остальных зависимостей нужен понятный сценарий ошибки. Например, недоступная почта не должна создавать ложное впечатление, что заявка успешно отправлена.
7. Что загружается на мобильном интернете
Посмотрите, сколько данных получает браузер и что загружается раньше всего. Большие изображения и лишние данные могут мешать работе даже при небольшой странице.
В Belkson объем данных страницы из 20 товаров удалось сократить с 6,5 МБ примерно до 10 КБ. Изображения стали загружаться отдельно и кешироваться. Это размер данных каталога, а не всей страницы с фотографиями и кодом. Подробнее об изменениях написали в кейсе Belkson.
8. У кого находятся код, домен и доступы
Проверьте, что владелец проекта имеет доступ к коду, размещению и управлению доменом. Зафиксируйте, кто оплачивает сервисы и получает уведомления об окончании подписок.
Если с проектом работает подрядчик, заранее договоритесь о передаче изменений, доступах и документации. Это поможет продолжить поддержку при смене команды.
9. Что произойдет после неудачного обновления
Нужна проверенная версия, с которой можно сравнить изменения, и порядок публикации новой. До обновления определите, как заметить сбой и кто будет восстанавливать работу.
Возврат старого кода может оказаться недостаточным, если изменена база. Возможность отката проверяют с учетом данных и совместимости версий. Автоматизация полезна, но не заменяет этот план.
С чего начать, если ответы неизвестны
Выберите самый важный сценарий: заявку, покупку или запись клиента. Проверьте его целиком и соберите ответы на девять вопросов. Неизвестные ответы дадут основу для плана работ.
Мы проводим аудит и доработку сайтов после AI. Экспресс-аудит небольшого сайта начинается от 15 тыс. ₽. Исправления оцениваем отдельно после диагностики. Размещение и сопровождение небольшого сайта стоит от 5 тыс. ₽ в месяц. Актуальный состав работ и условия указаны на странице стоимости.