Проверка сайта перед покупкой бизнеса начинается не с отчёта о прибыли, а с доступа к хостингу и админ-панели. За годы разработки я не раз оказывался на стороне покупателя, которому нужно было быстро понять, во что он ввязывается: продавец присылает скриншот Яндекс.Метрики с растущим графиком заявок, а на деле сайт держится на связке из забытых плагинов, чужого API-ключа для эквайринга и домена, зарегистрированного на человека, который давно не имеет отношения к бизнесу. Технический аудит перед сделкой закрывает такие риски и даёт конкретные цифры для торга по цене, а не формальную бумажку для отчёта.
Зачем технический аудит сайта нужен до сделки, а не после
Продавец готового бизнеса заинтересован показать сайт в лучшем виде, и это нормально: так делают на любом рынке. Проблема в асимметрии информации: покупатель видит витрину, а не то, что происходит на сервере и в коде. Я сталкивался с ситуацией, когда интернет-магазин на WooCommerce работал на десятке premium-плагинов, скачанных с пиратских форумов вместе с закладками, отправлявшими данные корзины на сторонний сервер. Внешне магазин работал исправно, заказы приходили, эквайринг T‑Bank/WooCommerce принимал платежи, а находка обнаружилась только при построчном разборе кода темы.
Второй частый случай: Telegram-бот на aiogram, через который бизнес принимает заявки, зарегистрирован в BotFather на личный аккаунт фрилансера, которого продавец давно не может найти. После сделки такой бот нельзя ни передать, ни перевыпустить без потери истории диалогов и части базы подписчиков.
Аудит перед сделкой стоит в разы дешевле, чем разгребать такие находки после перевода денег, и занимает от одного до пяти рабочих дней в зависимости от сложности сайта.
Проверка домена, хостинга и SSL сайта
Домен и хостинг это фундамент, который не видно на скриншотах, но именно от него зависит, останется ли сайт доступен на следующий день после сделки. Смотрю по такому списку:
- Регистрант домена по данным whois: совпадает ли с продавцом, или бизнес зарегистрирован на третье лицо, с которым нет прямого договора;
- Срок действия домена: если до продления меньше двух-трёх месяцев, включаю в договор обязанность продавца продлить его до передачи или закладываю это в цену;
- Способ автопродления: привязана ли карта продавца, кто получает уведомления об истечении;
- Процедура передачи домена: код авторизации для зон вроде .com или переоформление через личный кабинет регистратора для .ru;
- Доступ к панели регистратора и к DNS-записям, а не только к хостингу;
- Бэкапы на хостинге: частота, место хранения, можно ли скачать архив прямо сейчас;
- Договор с хостинг-провайдером: переоформляется на нового владельца или платёж бессрочно идёт через карту продавца.
SSL-сертификат проверяю отдельно от домена: тип сертификата, дату окончания и способ продления. Бесплатный DV-сертификат через Let’s Encrypt обычно продлевается автоматически на хостинге, а платный OV или EV привязан к юридическому лицу, и при смене ИП или ООО такой сертификат придётся перевыпускать заново на новые реквизиты.
Цена продления домена зависит только от зоны: для .ru она заметно ниже, чем для .com, и не связана с тем, лендинг это или интернет-магазин. Цена SSL-сертификата зависит от типа сертификата, DV, OV или EV, а не от платформы сайта: что Tilda, что WordPress используют его одинаково.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Аудит кода, CMS и безопасности сайта
Дальше смотрю в код и админку, и здесь чек-лист сильно зависит от платформы:
| Платформа | Что проверяю в первую очередь | Что запрашиваю у продавца |
|---|---|---|
| Tilda | кастомные скрипты в блоках, куда они отправляют данные форм, чужие вебхуки | доступ к аккаунту Tilda с ролью владельца, а не «редактор» |
| WordPress/WooCommerce | список плагинов и тем, наличие nulled-версий, права пользователей в админке | доступ к хостингу, базе данных и wp-admin, а не только к фронтенду |
| Кастомная разработка на Laravel, Next.js и похожем стеке | доступ к репозиторию, историю коммитов, зависимости в composer.json или package.json | полные права в git-репозитории, а не архив с кодом «на память» |
| Интернет-магазин на CMS | структуру базы данных, привязку заказов и клиентов, наличие резервных копий базы | дамп базы данных для независимой проверки |
Отдельно ищу следы взлома и SEO-спама: скрытые ссылки в подвале, дорвейные страницы в индексе, редиректы, которых не должно быть в структуре сайта. Если сайт заражён, лечение и восстановление после заражения это отдельная работа, которая у меня стоит от 15 000 ₽ и зависит от объёма повреждений, и эту сумму разумно вычесть из цены сделки, а не тратить сверху после покупки.
Если код лежит только на ноутбуке у бывшего разработчика и никогда не был в репозитории, это тоже риск: любое обновление превращается в лотерею, потому что нет истории изменений и отката.
Проверка трафика, SEO-истории и аналитики
Скриншот из Яндекс.Метрики ничего не доказывает, поэтому прошу доступ администратора к счётчику и Яндекс.Вебмастеру, а не выгрузку в PDF. Смотрю на:
- Историю трафика минимум за 12 месяцев: резкие провалы часто совпадают с фильтром поисковика или блокировкой рекламного кабинета;
- Наличие ручных санкций и предупреждений в Яндекс.Вебмастере и Google Search Console;
- Профиль обратных ссылок: если в бизнесе есть договорная закупка ссылок с сомнительных площадок, после смены владельца это может обернуться фильтром;
- Долю органического трафика от общего: иногда стабильный трафик держится только на рекламе, которую продавец готов отключить сразу после сделки;
- Позиции по ключевым запросам сейчас, а не в отчёте месячной давности.
Отдельно смотрю на счётчики: если Метрика стоит без доступа к «Целям» и «Конверсиям», значит цифры заявок в презентации продавца это его собственные прикидки, а не данные из системы.
Аудит платежей, доставки и CRM-интеграций
Интеграции это самая недооценённая часть аудита, потому что снаружи всё выглядит рабочим до первого сбоя после смены владельца:
- Эквайринг: если оплата подключена через T‑Bank/WooCommerce или похожий модуль, счёт привязан к юрлицу продавца, и после сделки его придётся переоформлять на новые реквизиты с новыми ключами API;
- Доставка: если расчёт зон и тарифов СДЭК настроен через встроенный калькулятор или отдельную интеграцию, проверяю, на чей аккаунт СДЭК она заведена;
- CRM: amoCRM, Bitrix24 или самописная база, куда падают заявки с сайта, и есть ли доступ администратора, а не только менеджера;
- Telegram-бот на aiogram: токен BotFather нужно перевыпустить на новый аккаунт сразу после покупки, иначе прежний владелец в любой момент может отозвать бота;
- Автоматизации в n8n: где развёрнут инстанс, свой сервер или облако продавца, есть ли доступ к панели и хранилищу учётных данных, потому что сценарии почти всегда содержат чужие API-ключи, которые придётся ротировать после сделки.
Комиссия эквайринга зависит от тарифа банка, а не от того, лендинг это или интернет-магазин, и при смене реквизитов её в любом случае придётся согласовывать заново с банком.
Сколько стоит независимый аудит сайта и как его организовать
Порядок действий, который у меня отработан на практике: сначала NDA, потом доступ на чтение без прав редактирования, домен, хостинг, админка CMS, счётчики аналитики, кабинеты платёжных и логистических сервисов. Простой лендинг на Tilda проверяю за один рабочий день, а интернет-магазин на WooCommerce с эквайрингом, СДЭК и CRM проверяю за три-пять дней, потому что там больше точек интеграции и внешних кабинетов.
Начинаю обычно с консультации от 3 000 ₽, на которой определяем объём работы по стеку конкретного сайта, а цену самого аудита после этого считаю индивидуально, потому что лендинг на пять страниц и интернет-магазин с тысячей товаров и десятком интеграций это разные объёмы проверки. После покупки бизнеса имеет смысл сразу закрыть техническую сторону, а не оставлять сайт без ответственного: для этого предлагаю техподдержку сайта на регулярной основе, чтобы обновления, бэкапы и мониторинг были на ком-то одном с первого дня после сделки.
Результат аудита оформляю как документ с приоритетами: что критично и должно быть исправлено до перевода денег, что можно доделать после сделки, и на какую сумму разумно снизить цену с учётом найденных рисков.
Частые вопросы
Сколько времени занимает техническая проверка сайта перед покупкой бизнеса?
Простой лендинг на Tilda без сложных интеграций проверяю за один рабочий день. Интернет-магазин с эквайрингом, доставкой СДЭК и CRM занимает три-пять дней, потому что нужно пройтись по каждому внешнему кабинету и сверить права доступа.
Можно ли обойтись без аудита, если продавец сам открыл доступ к Метрике и админке?
Временный доступ с ролью просмотра не показывает историю изменений, список администраторов и содержимое базы данных. Продавец может честно ничего не скрывать и всё равно не знать про уязвимый плагин или просроченный SSL-сертификат, поэтому независимая проверка нужна в любом случае.
Кто должен оплачивать технический аудит, покупатель или продавец?
Обычно платит покупатель, потому что аудит защищает именно его деньги и его интересы. Стоимость проверки можно вынести в переговоры и попросить продавца компенсировать её, если аудит подтвердит, что сайт в порядке и сделка состоится.
Что делать, если аудит нашёл серьёзные проблемы уже после внесения задатка?
Находки аудита это аргумент для пересмотра цены или условий сделки, а не повод молча продолжать. Критичные проблемы вроде домена, оформленного на постороннее лицо, или невозможности передать эквайринг, дают право требовать их устранения до окончательного расчёта или выйти из сделки с возвратом задатка, если это прописано в предварительном договоре.